From owner-ietf-ppp@merit.edu Sun Dec 1 03:22:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00985 for ; Sun, 1 Dec 2002 03:22:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C38AF91217; Sun, 1 Dec 2002 03:25:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48EC69121A; Sun, 1 Dec 2002 03:25:10 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 722B491217 for ; Sun, 1 Dec 2002 03:25:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 575645DED8; Sun, 1 Dec 2002 03:25:08 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from web (unknown [218.52.92.166]) by segue.merit.edu (Postfix) with SMTP id 8A2EE5DDA7 for ; Sun, 1 Dec 2002 03:24:57 -0500 (EST) Reply-To: web@merit.edu From: 정보 To: Subject: (광고)경매함정까지 만드는 노하우가 듬뿍! 부동산경매도서안내 Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 1 Dec 2002 17:25:01 +0900 Message-Id: <20021201082457.8A2EE5DDA7@segue.merit.edu> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다

본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다
먼저 사전 허락없이 광고메일을 보내게 되어 죄송하게 생각하며 정중히 양해 부탁드립니다.
제목에 [광고]라고 표기한 광고메일이며 수신을 원치 않으시면 수신거부를 눌러주세요. (글 하단에 있습니다.)
  [부동산경매스킬]이라는 책이 나왔습니다.
2002년 7월부터 달라지는 법원경매에 대비한 부동산경매지침서 인데 "서류판독에서 인도까지 끝내는 부동산경매스킬"로 법률적인 권리분석에서 경제적 가치분석과 현실적인 인도·명도까지 끝낼 수 있도록 일목요연하게 정리하고 있습니다.
 경매절차, 권리분석, 경낙후 인도·명도, 매각기일 법원목록 예시 등 크게 4가 지 테마로 이뤄지며,  특히 경매함정에 빠지기 쉬운 세대합가분석, 임차권양도분석, 대지권미등기, 토지별도등기 등 권리분석에서 유치권신고, 항고장작성, 인도협상방법 및 인도 시 합의각서의 작성 등 서류작성, 점유이전금지가처분, 인도명령, 명도소송을 전문가의 도움없이 해결할 수 있는 방법을 제시하고 있습니다.
 특히 법원경매 사건기록을 예시하여 경매당일 법대에서 최종 권리분석을 확실하게 하여 함정에 빠지는 것을 피할 수 있도록 제시하여 많은 도움이 됩니다.  현장 실무경험을 바탕을 바탕으로 저술하고 있어 경매에 관심이 있거나 경매 취득자 또는 경매대상물에 거주하는 세입자 등 이해관계인은 물론 초보자부터 전문가까지 부동산경매에 관해 쉽게 이해 할 수 있습니다.

   ■ 책  소 개
1. 책의 내용
 
○ 본 서는 2002년 7월 1일 민사집행법 시행에 맞춰 크게 4가지 테마로 이루어진다. 첫 번째장은 부동산경매절차에 대한 설명으로 민사집행법에 경매절차를 집중분석했다. 두 번째장은 부동산경매의 권리분석에 대하여, 세 번째장은 경낙 후 인도·명도에 대하여, 네 번째장은 매각기일 법원목록(민사기록)을 예시함으로서 실질적이고 구체적으로 경매참여자들에게 도움을 주고자 한다.

○ 부동산경매절차에서는 2002년 7월 1일부터 시행하는 민사집행법에 맞춰 경매신청에서부터 배당절차까지를 총망라하였으며 또한 관련 대법원판례의 내용을 담았다.
○ 부동산권리분석에서는 등기부에 나타나는 권리분석과 나타나지 않는 권리분석에 관하여 철저히 분석하였고, 특히 경매함정이 많은 세대합가분석, 임차권양도분석과 유치권, 법정지상권, 대지권미등기건물, 토지별도등기분석에 관하여 자세히 분석하였다.
 
○ 부동산 인도·명도에서는 인도협상방법 및 인도협상시 합의각서의 작성법, 경낙 후 사는 사람을 가장 빨리, 적은 비용으로 경낙부동산을 인수하는 방법인 점유이전금지가처분, 인도명령, 명도소송을 전문가의 도움없이 해결할 수 있는 방법을 제시한다.

○ 매각기일 법원목록편에서는 실전사례(사건기록)를 예시하여 응찰자들이 매각기일 당일 법대에서의 서류열람과 판독시 상당한 도움을 주도록 하였다.
 
○ 특히 유치권 신고방법, 즉시항고장 작성, 인도, 명도 합의이행각서, 점유이전금지가처분, 인도명령, 명도소송, 체납관리비 회수방법 등을 제시하여 실전에 상당한 도움을 주고자 하였으며 각 단원별 대법원 판례를 수록하여 이해를 돕고자 하였다.

2. 목차내용

1. 부동산경매의 절차
A. 부동산경매의 절차
  1. 부동산경매의 종류와 대상
     1-1. 부동산경매의 종류
     1-2. 강제경매와 임의경매의 차이점
     1-3. 부동산경매의 대상
     1-4. 처분이 제한되는 부동산
  2. 부동산경매의 절차
  3. 부동산경매신청
     3-1. 강제경매신청
     3-2. 임의경매신청
     3-3. 경매신청서 및 기재사항
     3-4. 비용의 예납 및 신청서 접수
  4. 경매개시결정
     4-1. 경매개시결정
     4-2. 경매개시결정의 효력
     4-3. 경매개시결정의 등기
     4-4. 경매개시결정의 송달
  5. 경매개시결정에 대한 이의
     5-1. 경매개시결정에 대한 이의사유
  6. 임의경매절차의 정지
  7. 경매절차의 이해관계인
     7-1. 경매절차의 이해관계인이란
     7-2. 이해관계인의 범위
     7-3. 경매절차에서의 이해관계인이 될 수 없는 자
     7-4. 이해관계인의 권리
  8. 매각의 준비
     8-1. 부동산의 현황조사
     8-2. 감정평가의 명령과 최저경매가격의 결정
     8-3. 배당요구의 종기결정 및 공고와 각종의 최고 및 통지
     8-4. 매각물건명세서의 비치
     8-5. 매각기일·매각결정기일 등의 지정
     8-6. 매각조건
  9. 매각방법과 재매각
     9-1. 매각의 방법
     9-2. 입찰표의 기재
     9-3. 매수신청보증금 봉투 및 입찰봉투의 작성과 투입
     9-4. 매각기일의 종결과 차순위매수신고
 10. 매각허가와 항고
     10-1. 매각결정기일
     10-2. 매각허가에 대한 이의신청
     10-.3 매각허가결정
     10-4. 매각불허가 결정
     10-5. 매각허가여부에 대한 항고
     10-6. 매가허가결정의 취소신청
  11. 대금납무와 소유권이전
     11-1. 매각대금의 지급
     11-2. 소유권이전 
 12. 배당절차
     12-1. 배당 받을 채권자의 범위
     12-2. 배당요구
     12-3. 배당요구에 대한 법원의 처리
     12-4. 배당요구의 효력
     12-5. 채권계산서
     12-6. 배당기일과 배당실시
     12-7. 배당표에 대한 이의
     12-8. 배당이의의 소
     12-9. 배당요구가 필요한 채권자가 배당요구를 하지 않은 경우
     12-10. 국세 등의 교부청구

B. 즉시항고와 취하, 취소
  1. 즉시항고와 매각허가 여부에 대한 항고
     1-1. 항고권자와 상대방
     1-2. 항고제기의 방법과 심리절차
     1-3. 즉시항고의 효력
     1-4. 매각허가여부에 대한 이해관계인의 즉시항고와 항고보증금
     1-5. 항고보증금에 대한 처리
     1-6. 항고시 대처방법
   2. 경매취하
     2-1. 취하의 의미
     2-2. 취하의 요건 및 가능시한
     2-3. 취하의 효력
  3. 부동산의 멸실 등으로 말미암은 경매취소
  4. 남을 가망이 없을 경우의 경매취소
  5. 채무자, 소유자가 단독으로 경매의 취소를 구하는 방법
     5-1. 강제경매
     5-2. 임의경매

Ⅱ. 부동산경매의 권리분석

A. 인수되는 권리와 소멸되는 권리
  1. 인수되는 권리와 소멸되는 권리
     1-1. 소제주의와 인수주의
     1-2. 말소기준권리의 의미와 소멸·인수
     1-3. 매각으로 인하여 소멸되는 권리
     1-4. 매각 뒤 인수해야 하는 권리
     1-5. 말소주의 원칙의 예외
     1-6. 인수, 소멸되는 권리를 찾는 방법

B. 등기부 갑구에 나타나는 권리분석
  1. 가압류의 권리분석
     1-1. 가압류의 의미
     1-2. 경매로 인하여 인수, 소멸여부
  2. 가등기의 권리분석
     2-1. 가등기의 종류
     2-2. 가등기의 효력
     2-3. 경매법원의 가등기권리자에 대한 최고
     2-4. 가등기의 대항력
  3. 가처분의 권리분석
     3-1. 가처분의 의의와 종류
     3-2. 매각시 소멸 되지 않는 가처분
     3-3. 매각시 소멸되는 가처분
  4. 압류의 권리분석
  5. 토지별도등기의 권리분석
     5-1. 토지별도등기가 무엇이냐
     5-2. 토지별도등기의 인수, 소멸여부
     5-3. 토지별도등기의 물건에 입찰할 때는
  6. 대지권미등기 건물의 권리분석
     6-1. 대지권이란?
     6-2. 대지권등기
     6-3. 경낙시 대지권을 취득할 수 있는 경우
     6-4. 대지권을 취득하지 못하는 경우
  7. 지분등기의 권리분석
  8. 예고등기의 권리분석
  9. 환매등기의 권리분석

C. 등기부 을구에 나타나는 권리분석
  1. 저당권의 권리분석
     1-1. 저당권의 의의와 성질
     1-2. 저당권의 성립
     1-3. 저당궈의 효력
     1-4. 저당권의 실행
     1-5. 저당권의 처분
     1-6. 저당권의 소멸
     1-7. 경매에 있어서의 저당권의 권리분석
  2. 지상권의 권리분석
     2-1. 지상권 의의 및 성질
     2-2. 지상권의 종속기간
     2-3. 지상권의 효력
     2-4. 지상권의 소멸
  3. 저당권과 동시에 설정된 지상권의 권리분석
  4. 전세권의 권리분석
     4-1. 전세권의 의의와 성질
     4-2. 전세권의 변동
     4-3. 전세권의 효력
     4-4. 전세권의 처분
     4-5. 전세권의 소멸
     4-6. 경매에 있어서의 소멸되는 전세권과 소멸되지 않는 전세권
     4-7. 건물만의 전세권자가 대지의 매각대금으로부터 배당여부

D. 등기부에 나타나지 않는 권리분석
  1. 권리순위 바뀌는 대위변제
     1-1. 대위변제란
     1-2. 대위변제를 할 수 있는 시기와 매수자의 법적조치
  2. 필요비, 유익비 등 비용상환청구권의 권리분석
     2-1. 필요비와 유익비의 요건과 상환청구시기
     2-2. 필요비, 유익비의 배당순위와 배당요건
  3. 유치권의 권리분석
     3-1. 유치권의 내용
     3-2. 유치권의 성립
     3-3. 유치권자의 권리와 의무
     3-4. 유치권의 소멸
     3-5. 부동산경매에 있어서의 유치권의 권리분석
  4. 법정지상권의 권리분석
     4-1. 법정지상권의 의미
     4-2. 법정지상권의 종류
     4-3. 법정지상권의 성립요건
     4-4. 법정지상권의 효력발생요건 및 범위
     4-5. 법정지상권과 임차인의 대항력
     4-6. 법정지상권 물건의 입찰
  5. 분묘기지권의 권리분석
     5-1. 분묘기지권의 의미
     5-2. 분묘기지권의 성립요건
  6. 제시외 물건의 권리분석
  7. 주택임차인의 권리분석
     7-1. 주택임대차보호법의 적용범위
     7-2. 대항력 있는 임차인이란
     7-3. 확정일자부 임차인의 우선변제권
     7-4. 소액임차인의 최우선변제권
     7-5. 소유자가 매도하고 임차인이 된 경우
     7-6. 허위·위장 임차인의 분석
     7-7. 모르면 낭패 세대합가 분석
  8. 상가건물임차인의 권리분석
     8-1. 상가건물임대차보호법의 적용범위
     8-2. 대항력 있는 상가건물임차인
     8-3. 확정일자 상가건물임차인의 우선변제권
     8-4. 보증금 중 일정액의 최우선변제권
     8-5. 기타 상가건물임차인 권리분석시 알아두어야 할 사항

E. 각종 서류의 열람 확인과 판독
  1. 토지이용계획 확인원
  2. 토지대장·건축물대장
  3. 주민등록등본
  4. 관리비·공과금 납입현황
  5. 사업자등록증 등
  6. 매각물건명세서
  7. 현황조사보고서 및 임대차관계조사서
  8. 감정평가서

F. 투자비분석과 적정 입찰가격의 산정
  1. 투자비분석
     1-1. 입찰보증금
     1-2. 잔금
     1-3. 등기비용 등 제세공과금
     1-4. 인도, 명도에 들어가는 비용
     1-5. 투자액에 대한 금융비용과 체납공과금
  2. 적정 입찰예정가 산정
     2-1. 감정평가서의 가격분석
     2-2. 시세분석 및 적정 입찰예정가 산출

Ⅲ. 부동산경매의 인도, 명도
 A. 보다 빨리 그리고 적은 비용으로 인도, 명도 하는 방법
  1. 점유이전금지가처분
     1-1. 점유이전금지가처분이 필요한 이유
     1-2. 점유이전금지 가처분의 신청과 집행
  2. 인도, 명도 협상과 합의 이행각서 작성
  3. 인도명령
     3-1. 인도명령이란
     3-2. 인도명령의 당사자
     3-3. 인도명령의 신청과 집행
     3-4. 물건을 들어내는 경우
     3-4. 인도집행 후 재침입한 경우
  4. 송달불능과 주소보정 및 특별송달
     4-1. 주소보정서의 작성요령
     4-2. 상대방의 주민등록등본 발급요령
     4-3. 특별송달 신청요령
     4-4. 공시송달의 신청요령
  5. 명도소송
     5-1. 명도소송이란
     5-2. 명도소송의 당사자
     5-3. 명도소송시 청구의 내용
     5-4. 명도판결 및 집행 시까지의 기간
  6. 경매시 보증금을 돌려받지 못한 임차인의 대처법
  7. 소가와 인지액 계산
     7-1. 소가란
     7-2. 금전을 청구하는 소송에서의 소가
     7-3. 부동산 관련 소송에 있어서 소가의 산정방법
     7-4. 인지액의 계산
     7-5. 송달료의 계산

Ⅳ. 매각기일 법원기록 열람과 판독

A. 매각기일 법원기록 열람과 판독
    
B. 법원경매사건기록 목록(당일목록예시)
     목록의 표지
     이해관계인 열람표
     등기부등본
     부동산경매신청서
     저당권설정계약서
     등기촉탁서
     경매개시결정문
     최고서
     현황조서명령서
     평가명령서
     우편송달통지서
     권리신고 및 배당신청서
     임대차계약서
     감정평가서
     부동산현황조사보고서
     입찰명령서
     경매 입찰물건명세서
     입찰기일공고 및 공고게시보고서
     우편송달부
     입찰불능조서
     입찰명령서
     낙찰불허가결정공고보고서
     낙찰기일조서
     낙찰결정문
     즉시항고장
     의견서
     소송기록송부서
     항고기각결정문
     재항고장
     대금지급지일지정서
     대금지급기일조서
     재입찰명령서
     입찰명령서
     입찰조서
     
Ⅴ. 부   록
  1. 민사집행법
  2. 주택임대차보호법
  3. 주택임대차보호법 시행령
  4. 상가건물임대차보호법

      정가 : 25,000원
 ★   현금구매시 : 10% 할인 22,500원 (배송비포함)
      주문전화 부동산경매스킬 031-742-2114     입금계좌 :  농협구좌번호 169-01-296202  이영미   
  ★ 신용카드구매시 :10% 할인 22,500원 인터넷서점 알라딘             



버튼을 클릭하시면 수신거부처리가 이루어 집니다.

 귀하의 e메일은 웹서핑을 통하여 수집되었으며, 다른 개인신상정보는 아무 것도 갖고 있지 않습니다. 원치  않으시는 정보였다면 진심으로 고개 숙여 사과드립니다.

From owner-ietf-ppp@merit.edu Wed Dec 4 07:36:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07956 for ; Wed, 4 Dec 2002 07:36:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 463D691295; Wed, 4 Dec 2002 07:39:21 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15D1B912B7; Wed, 4 Dec 2002 07:39:21 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 11F8691295 for ; Wed, 4 Dec 2002 07:39:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3DD95DE0F; Wed, 4 Dec 2002 07:39:19 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 6713D5DDA8 for ; Wed, 4 Dec 2002 07:39:19 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07907; Wed, 4 Dec 2002 07:36:28 -0500 (EST) Message-Id: <200212041236.HAA07907@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-08.txt Date: Wed, 04 Dec 2002 07:36:27 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-pppext-rfc2284bis-08.txt Pages : 36 Date : 2002-12-3 This document defines the Extensible Authentication Protocol (EAP), an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and retransmission. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-rfc2284bis-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-12-3142428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-rfc2284bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-3142428.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Thu Dec 5 19:38:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06760 for ; Thu, 5 Dec 2002 19:38:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D4186912DB; Thu, 5 Dec 2002 19:41:12 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D54F912DC; Thu, 5 Dec 2002 19:41:12 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B8ED912DB for ; Thu, 5 Dec 2002 19:41:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 76A4A5DF71; Thu, 5 Dec 2002 19:41:11 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from hotmail.com (f157.law10.hotmail.com [64.4.15.157]) by segue.merit.edu (Postfix) with ESMTP id 389D15DF56 for ; Thu, 5 Dec 2002 19:41:11 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 5 Dec 2002 16:41:10 -0800 Received: from 198.242.58.71 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 06 Dec 2002 00:41:10 GMT X-Originating-IP: [198.242.58.71] From: "manoj juneja" To: ietf-ppp@merit.edu Subject: Doubt about ECP and CCP Date: Thu, 05 Dec 2002 17:41:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Dec 2002 00:41:10.0722 (UTC) FILETIME=[2C180220:01C29CC0] Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi All, Can anyone please explain the format of a PPP data packet that is both compressed and encrypted ? Also, if compression/encryption is enabled/negotitation then is it mandatory to use it for each data packet ? If both encryption and compression are enabled/negotiated then is it possible to send a data packet that is encrypted and not compressed ? Thanks in Advance, Regards, manoj. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-ietf-ppp@merit.edu Mon Dec 16 16:19:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18646 for ; Mon, 16 Dec 2002 16:19:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6076991271; Mon, 16 Dec 2002 16:21:34 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2393591272; Mon, 16 Dec 2002 16:21:34 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87C0291271 for ; Mon, 16 Dec 2002 16:21:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E32A5DFB0; Mon, 16 Dec 2002 16:21:29 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 1FB785DDB0 for ; Mon, 16 Dec 2002 16:21:29 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16805; Mon, 16 Dec 2002 14:21:22 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gBGLLMmt013469; Mon, 16 Dec 2002 16:21:22 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id gBGLLM4A061224; Mon, 16 Dec 2002 16:21:22 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id gBGLLMdG061221; Mon, 16 Dec 2002 16:21:22 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15870.17362.41094.696653@gargle.gargle.HOWL> Date: Mon, 16 Dec 2002 16:21:22 -0500 From: James Carlson To: Thomas Narten Cc: Karl Fox , ietf-ppp@merit.edu Subject: Re: request to publish: draft-heath-ppp-v44-02.txt In-Reply-To: Thomas Narten's message of 22 October 2002 11:23:35 References: <200210221523.g9MFNZR31118@rotala.raleigh.ibm.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Thomas Narten writes: > The IESG has been asked to publish: > > PPP V.44 Compression Protocol > draft-heath-ppp-v44-02.txt > > as an informational document. > > Have folks in the WG had a chance to review this? Any opinions > (positive or negative)? My comments are probably arriving way too late, but I'm vaguely uncomfortable with a compression protocol that has modes requiring sequencing and that (unlike all of the other CCP algorithms defined to date) includes no sequencing header. I'd certainly prefer either a one or two octet header before the compressed data, as has been done with RFCs 1974, 1975, 1977, 1979, 2118, or a trailing checksum as with 1978. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Dec 24 20:39:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16302 for ; Tue, 24 Dec 2002 20:39:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C4C4791232; Tue, 24 Dec 2002 20:42:23 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 949D491239; Tue, 24 Dec 2002 20:42:23 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55A6691232 for ; Tue, 24 Dec 2002 20:42:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 30F235DDC2; Tue, 24 Dec 2002 20:42:22 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by segue.merit.edu (Postfix) with ESMTP id B9DB65DD94 for ; Tue, 24 Dec 2002 20:42:21 -0500 (EST) Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.6/8.12.6) with ESMTP id gBP1gLhn001167; Tue, 24 Dec 2002 17:42:21 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.12.6/8.12.3) with ESMTP id gBP1gLef010254; Tue, 24 Dec 2002 17:42:21 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id gBP1gKq07112; Tue, 24 Dec 2002 17:42:20 -0800 Date: Tue, 24 Dec 2002 17:42:20 -0800 From: Frank Cusack To: manoj juneja Cc: ietf-ppp@merit.edu Subject: Re: Doubt about ECP and CCP Message-ID: <20021224174220.A7022@google.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from manojkumarjuneja@hotmail.com on Thu, Dec 05, 2002 at 05:41:10PM -0700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Thu, Dec 05, 2002 at 05:41:10PM -0700, manoj juneja wrote: > Can anyone please explain the format of a PPP data packet that is > both compressed and encrypted ? For IP, just encrypted: 0x0053 (encrypted datagram) | ... (encryption header) | -> 0x0021 (IP datagram) | ... (IP data) and compressed: 0x0053 (encrypted datagram) | ... (encryption header) | -> 0x00fd (compressed datagram) | ... (compression header) | -> 0x21 (IP datagram) | ... (IP data) Of course, everything past the encryption header isn't actually visible as such until decryption, and likewise for compression. > Also, if compression/encryption is enabled/negotitation then is it mandatory > to use it for each data packet ? No, but an implementation can enforce this. The receiver can only enforce this after the fact, of course (dropping the link upon reception of a non-encrypted/compressed packet). > If both encryption and compression are enabled/negotiated then is it > possible to send a data packet that is encrypted and not compressed ? Sure, but again an implementation can enforce both. /fc From owner-ietf-ppp@merit.edu Wed Dec 25 01:01:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18616 for ; Wed, 25 Dec 2002 01:01:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7997791205; Wed, 25 Dec 2002 01:04:47 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D7C291239; Wed, 25 Dec 2002 01:04:47 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 20D0F91205 for ; Wed, 25 Dec 2002 01:04:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 058C85DE38; Wed, 25 Dec 2002 01:04:46 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by segue.merit.edu (Postfix) with ESMTP id 89AF25DE33 for ; Wed, 25 Dec 2002 01:04:45 -0500 (EST) Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.6/8.12.6) with ESMTP id gBP64jhn030977; Tue, 24 Dec 2002 22:04:45 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.12.6/8.12.3) with ESMTP id gBP64ief021666; Tue, 24 Dec 2002 22:04:44 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id gBP64ik07406; Tue, 24 Dec 2002 22:04:44 -0800 Date: Tue, 24 Dec 2002 22:04:44 -0800 From: Frank Cusack To: manoj juneja Cc: ietf-ppp@merit.edu Subject: Re: Doubt about ECP and CCP Message-ID: <20021224220444.A7382@google.com> References: <20021224174220.A7022@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021224174220.A7022@google.com>; from fcusack@fcusack.com on Tue, Dec 24, 2002 at 05:42:20PM -0800 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Tue, Dec 24, 2002 at 05:42:20PM -0800, Frank Cusack wrote: > On Thu, Dec 05, 2002 at 05:41:10PM -0700, manoj juneja wrote: > > If both encryption and compression are enabled/negotiated then is it > > possible to send a data packet that is encrypted and not compressed ? > > Sure, but again an implementation can enforce both. Actually, not. If you look at RFC 1979 (deflate) and others, you'll see that special handling has to be done when receiving non-compressed packets. After negotiating compression, all packets are implicitly considered to have passed through the compressor. This doesn't seem to be the case for the ECP protocols. /fc From owner-ietf-ppp@merit.edu Wed Dec 25 12:58:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19574 for ; Wed, 25 Dec 2002 12:58:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 335F79120C; Wed, 25 Dec 2002 13:01:37 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECF2491233; Wed, 25 Dec 2002 13:01:36 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B95799120C for ; Wed, 25 Dec 2002 13:01:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 565E85DDEE; Wed, 25 Dec 2002 13:01:34 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from hotmail.com (f29.law10.hotmail.com [64.4.15.29]) by segue.merit.edu (Postfix) with ESMTP id CD0B25DDAD for ; Wed, 25 Dec 2002 13:01:33 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Dec 2002 09:59:34 -0800 Received: from 67.24.126.246 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 25 Dec 2002 17:59:34 GMT X-Originating-IP: [67.24.126.246] From: "manoj juneja" To: ietf-ppp@merit.edu Subject: Usage of PPP, PPP-Mux and MP in 3G networks Date: Wed, 25 Dec 2002 10:59:34 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Dec 2002 17:59:34.0803 (UTC) FILETIME=[62118E30:01C2AC3F] Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi All, Is there any paper which explains the usage of PPP/PPP-Mux and MP in 3G networks ? Regards, manoj. _________________________________________________________________ The new MSN 8: smart spam protection and 3 months FREE*. http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU= http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_smartspamprotection_3mf From owner-ietf-ppp@merit.edu Wed Dec 25 16:58:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21545 for ; Wed, 25 Dec 2002 16:58:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0BAD191233; Wed, 25 Dec 2002 17:01:43 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B990991239; Wed, 25 Dec 2002 17:01:42 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76D4D91233 for ; Wed, 25 Dec 2002 17:01:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 440D85DDBB; Wed, 25 Dec 2002 17:01:41 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from exchange.Ic4ic.com (unknown [194.90.135.194]) by segue.merit.edu (Postfix) with SMTP id 8418E5DDA5 for ; Wed, 25 Dec 2002 17:01:40 -0500 (EST) Received: through eSafe SMTP Relay 1040832187; Thu Dec 26 00:58:37 2002 content-class: urn:content-classes:message Subject: RE: Usage of PPP, PPP-Mux and MP in 3G networks MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2AC61.4AE9CFFC" Date: Thu, 26 Dec 2002 00:02:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <88BC9E379956AE4DB689CC5FF6F5A43D308450@exchange.Ic4ic.com> Thread-Topic: Usage of PPP, PPP-Mux and MP in 3G networks Thread-Index: AcKsP8sP1RXAMPl4QzWTQ3q45AnangAIU1aQ From: "Daniel Feldman" To: "manoj juneja" , Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------_=_NextPart_001_01C2AC61.4AE9CFFC Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Try the 3GPP doc 25.933. You can find it at ftp://ftp.3gpp.org/Specs/2002-12/Rel-5/25_series/25933-520.zip. Regards, Daniel. -----Original Message----- From: manoj juneja [mailto:manojkumarjuneja@hotmail.com] Sent: Wednesday, December 25, 2002 8:00 PM To: ietf-ppp@merit.edu Subject: Usage of PPP, PPP-Mux and MP in 3G networks Hi All, Is there any paper which explains the usage of PPP/PPP-Mux and MP in=20 3G networks ? Regards, manoj. _________________________________________________________________ The new MSN 8: smart spam protection and 3 months FREE*. =20 http://join.msn.com/?page=3Dfeatures/junkmail&xAPID=3D42&PS=3D47575&PI=3D= 7324&DI =3D7474&SU=3D=20 http://www.hotmail.msn.com/cgi-bin/getmsg&HL=3D1216hotmailtaglines_smarts= p amprotection_3mf ------_=_NextPart_001_01C2AC61.4AE9CFFC Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable ftp://ftp=
Regards,
Daniel.

-----Original Message-----
From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
Sent: Wednesday, December 25, 2002 8:00 PM
To: ietf-ppp@merit.edu
Subject: Usage of PPP, PPP-Mux and MP in 3G networks


Hi All,
        Is there an= y paper which explains the usage of PPP/PPP-Mux and MP in
3G networks ?

Regards,
manoj.





_______________________________________________________= __________
The new MSN 8: smart spam protection and 3 months FREE= *. 
http://join.msn.com/?= page=3Dfeatures/junkmail&xAPID=3D42&PS=3D47575&PI=3D7324&DI=3D7474&SU=3D<= /A>
http://www.hotmail.msn.c= om/cgi-bin/getmsg&HL=3D1216hotmailtaglines_smartspamprotection_3mf

------_=_NextPart_001_01C2AC61.4AE9CFFC-- From owner-ietf-ppp@merit.edu Fri Dec 27 10:03:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09196 for ; Fri, 27 Dec 2002 10:03:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E013A91217; Fri, 27 Dec 2002 10:06:43 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1F4091220; Fri, 27 Dec 2002 10:06:43 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B9E691217 for ; Fri, 27 Dec 2002 10:06:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A3BA5DE6F; Fri, 27 Dec 2002 10:06:42 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 281AC5DDB6 for ; Fri, 27 Dec 2002 10:06:42 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04813; Fri, 27 Dec 2002 08:06:40 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gBRF6emt013351; Fri, 27 Dec 2002 10:06:40 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id gBRF6exO023826; Fri, 27 Dec 2002 10:06:40 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id gBRF6e8i023823; Fri, 27 Dec 2002 10:06:40 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15884.27775.904198.428404@gargle.gargle.HOWL> Date: Fri, 27 Dec 2002 10:06:39 -0500 From: James Carlson To: Frank Cusack Cc: manoj juneja , ietf-ppp@merit.edu Subject: Re: Doubt about ECP and CCP In-Reply-To: Frank Cusack's message of 24 December 2002 22:04:44 References: <20021224174220.A7022@google.com> <20021224220444.A7382@google.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Frank Cusack writes: > On Tue, Dec 24, 2002 at 05:42:20PM -0800, Frank Cusack wrote: > > Sure, but again an implementation can enforce both. > > Actually, not. If you look at RFC 1979 (deflate) and others, you'll > see that special handling has to be done when receiving non-compressed > packets. After negotiating compression, all packets are implicitly > considered to have passed through the compressor. I liked your earlier message better. ;-} What you say is true of a few of the algorithms -- including Deflate and BSD Compress, though, notably, not STAC LZS (which requires a history reset in the 'standard' modes, and bit C=0 for extended mode). However, when it is true, the sender can decline to compress any particular packet he chooses as long as he updates his dictionary as required (or reinitializes CCP itself). So, if what the original poster wants is confirmation that all packets sent *always* have compressed data in them, I don't think that can be given. > This doesn't seem to be the case for the ECP protocols. The rules are a little different there, since expansion over the MTU is 'supposed' to be handled by using MP. What RFC 1968 does say is this: An implementation MUST NOT transmit data until ECP negotiation has completed successfully. If ECP negotiation is not successful the link SHOULD be brought down. I think a reasonable interpretation of that statement (and the security context) is that network data also must not be sent unencrypted once ECP is up. It doesn't actually come out and say that, though, nor do 2419 and 2420. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Fri Dec 27 11:18:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10340 for ; Fri, 27 Dec 2002 11:18:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 272C291225; Fri, 27 Dec 2002 11:21:36 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E929091227; Fri, 27 Dec 2002 11:21:35 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0C6891225 for ; Fri, 27 Dec 2002 11:21:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id B60055DEB1; Fri, 27 Dec 2002 11:21:34 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from tx2.wvinternetservices.com (tx2.wvinternetservices.com [66.118.65.7]) by segue.merit.edu (Postfix) with ESMTP id 3AC025DE88 for ; Fri, 27 Dec 2002 11:21:34 -0500 (EST) Received: from a (63-144-68-57.citynet.net [63.144.68.57]) by tx2.wvinternetservices.com (8.12.6/8.12.6=Outbound) with SMTP id gBRGGFqw022918 for ; Fri, 27 Dec 2002 11:16:15 -0500 Message-ID: <000b01c2adc3$c230c800$3944903f@a> From: "Bill Cunningham" To: Subject: PPP Date: Fri, 27 Dec 2002 11:19:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hey all, Other than rfc 1661, what rfc's should I look at to be up to date on today's PPP? The rfc-editor has so many rfcs. Surely some must be repetative. From owner-ietf-ppp@merit.edu Fri Dec 27 11:51:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11013 for ; Fri, 27 Dec 2002 11:51:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 098A691227; Fri, 27 Dec 2002 11:54:47 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD8369123F; Fri, 27 Dec 2002 11:54:46 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB7B391227 for ; Fri, 27 Dec 2002 11:54:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id A3F5D5DE7E; Fri, 27 Dec 2002 11:54:45 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 279635DE7C for ; Fri, 27 Dec 2002 11:54:45 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10221; Fri, 27 Dec 2002 08:54:43 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gBRGsh5f014575; Fri, 27 Dec 2002 11:54:43 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id gBRGshxO023923; Fri, 27 Dec 2002 11:54:43 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id gBRGshON023920; Fri, 27 Dec 2002 11:54:43 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15884.34259.144515.703957@gargle.gargle.HOWL> Date: Fri, 27 Dec 2002 11:54:43 -0500 From: James Carlson To: "Bill Cunningham" Cc: Subject: Re: PPP In-Reply-To: Bill Cunningham's message of 27 December 2002 11:19:39 References: <000b01c2adc3$c230c800$3944903f@a> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bill Cunningham writes: > Other than rfc 1661, what rfc's should I look at to be up to date on > today's PPP? A lot, and the exact list depends on what you're trying to do. > The rfc-editor has so many rfcs. Surely some must be > repetative. Uh, not exactly. Making the rash assumption that you're trying to do IP over asynchronous links (since you didn't indicate otherwise), you'll need to look over at least these RFCs: 1662, 1332, 1334, 1994. (RFC 1994 "obsoletes" 1334, but, in truth, there are still a lot of uses of PAP in the world, so 1334 is still needed.) You may need quite a few others. Without details of what you're trying to accomplish, it would be hard to make specific recommendations of what to look at. The lists are long. For instance, if you're in an MS environment, you might want 1877, 2118, 2433, 2637, 2759, 3078, and 3079 (note that 2118 and 3078 need 1962, a standard, non-MS protocol). Perhaps even a few others for IPX. Some environments require SONET/SDH support, or OSINLCP, or even AppleTalk. You'll need to work that out first. Of course, before you look at any of this, I strongly recommend that you avoid reinventing the wheel. Look around for free implementations of PPP. The protocols themselves aren't all that complex, but getting all of the interactions right is quite hard. The long-standing bugs in many deployed implementations are a testament to this fact. Adding a new bug-ridden implementation to that list wouldn't necessarily be a good thing. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Fri Dec 27 12:02:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11222 for ; Fri, 27 Dec 2002 12:02:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E4B869123F; Fri, 27 Dec 2002 12:05:48 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B08CE91242; Fri, 27 Dec 2002 12:05:48 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BCF1D9123F for ; Fri, 27 Dec 2002 12:05:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2E5E5DE80; Fri, 27 Dec 2002 12:05:47 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by segue.merit.edu (Postfix) with ESMTP id 62C935DE7E for ; Fri, 27 Dec 2002 12:05:47 -0500 (EST) Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gBRH5eKv004018; Fri, 27 Dec 2002 09:05:40 -0800 (PST) Received: (from cbemis@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA21776; Fri, 27 Dec 2002 09:05:39 -0800 (PST) From: Curtis Bemis Message-Id: <200212271705.JAA21776@cisco.com> Subject: Re: PPP To: james.d.carlson@east.sun.com (James Carlson) Date: Fri, 27 Dec 2002 09:05:39 -0800 (PST) Cc: billc44@citynet.net (Bill Cunningham), ietf-ppp@merit.edu In-Reply-To: <15884.34259.144515.703957@gargle.gargle.HOWL> from "James Carlson" at Dec 27, 2002 11:54:43 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit And, you were kind and definitely not self-serving ;-) I recommend "PPP Design, Implementation, and Debugging, 2nd Edition", James Carlson, Addison-Wesley, 2000, ISBN 0-201-70053-0, complete with a CD. Curt... > > Bill Cunningham writes: > > Other than rfc 1661, what rfc's should I look at to be up to date on > > today's PPP? > > A lot, and the exact list depends on what you're trying to do. > > > The rfc-editor has so many rfcs. Surely some must be > > repetative. > > Uh, not exactly. > > Making the rash assumption that you're trying to do IP over > asynchronous links (since you didn't indicate otherwise), you'll need > to look over at least these RFCs: 1662, 1332, 1334, 1994. (RFC 1994 > "obsoletes" 1334, but, in truth, there are still a lot of uses of PAP > in the world, so 1334 is still needed.) > > You may need quite a few others. Without details of what you're > trying to accomplish, it would be hard to make specific > recommendations of what to look at. The lists are long. For > instance, if you're in an MS environment, you might want 1877, 2118, > 2433, 2637, 2759, 3078, and 3079 (note that 2118 and 3078 need 1962, a > standard, non-MS protocol). Perhaps even a few others for IPX. > > Some environments require SONET/SDH support, or OSINLCP, or even > AppleTalk. You'll need to work that out first. > > Of course, before you look at any of this, I strongly recommend that > you avoid reinventing the wheel. Look around for free implementations > of PPP. The protocols themselves aren't all that complex, but getting > all of the interactions right is quite hard. The long-standing bugs > in many deployed implementations are a testament to this fact. Adding > a new bug-ridden implementation to that list wouldn't necessarily be a > good thing. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > -- ________________________________________________________________________ *Curt Bemis * || || *Cisco Systems, Inc *Phone: 561.741.0300 * .||||. .||||. *San Jose, CA 95134 *Cell: 561.329.4769 * ..:||||||:..:||||||:.. * *Email: cbemis@cisco.com * Cisco Systems, Inc. * (home-Jupiter, FL) _________________________________________________________________________ From owner-ietf-ppp@merit.edu Fri Dec 27 19:15:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16838 for ; Fri, 27 Dec 2002 19:15:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7BE819125A; Fri, 27 Dec 2002 19:18:11 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B9E99125B; Fri, 27 Dec 2002 19:18:11 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDF959125A for ; Fri, 27 Dec 2002 19:18:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id C4BCF5DE31; Fri, 27 Dec 2002 19:18:09 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from tx2.wvinternetservices.com (tx2.wvinternetservices.com [66.118.65.7]) by segue.merit.edu (Postfix) with ESMTP id 498CB5DDFE for ; Fri, 27 Dec 2002 19:18:09 -0500 (EST) Received: from a (63-144-68-60.citynet.net [63.144.68.60]) by tx2.wvinternetservices.com (8.12.6/8.12.6=Outbound) with SMTP id gBS0Clqw007241; Fri, 27 Dec 2002 19:12:47 -0500 Message-ID: <000a01c2ae06$55031f60$3c44903f@a> From: "Bill Cunningham" To: "James Carlson" Cc: References: <000b01c2adc3$c230c800$3944903f@a> <15884.34259.144515.703957@gargle.gargle.HOWL> Subject: Re: PPP Date: Fri, 27 Dec 2002 19:16:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit I guess I wasn't specific. But yes I don't want to reinvent the wheel. PPTP, a MS protocol for linux is kinda what I'm looking at. I know PPTP is proprietary, but something similar should work for linux. If it doesn't already exist, and I'm not aware of it. ----- Original Message ----- From: "James Carlson" To: "Bill Cunningham" Cc: Sent: Friday, December 27, 2002 11:54 AM Subject: Re: PPP > Bill Cunningham writes: > > Other than rfc 1661, what rfc's should I look at to be up to date on > > today's PPP? > > A lot, and the exact list depends on what you're trying to do. > > > The rfc-editor has so many rfcs. Surely some must be > > repetative. > > Uh, not exactly. > > Making the rash assumption that you're trying to do IP over > asynchronous links (since you didn't indicate otherwise), you'll need > to look over at least these RFCs: 1662, 1332, 1334, 1994. (RFC 1994 > "obsoletes" 1334, but, in truth, there are still a lot of uses of PAP > in the world, so 1334 is still needed.) > > You may need quite a few others. Without details of what you're > trying to accomplish, it would be hard to make specific > recommendations of what to look at. The lists are long. For > instance, if you're in an MS environment, you might want 1877, 2118, > 2433, 2637, 2759, 3078, and 3079 (note that 2118 and 3078 need 1962, a > standard, non-MS protocol). Perhaps even a few others for IPX. > > Some environments require SONET/SDH support, or OSINLCP, or even > AppleTalk. You'll need to work that out first. > > Of course, before you look at any of this, I strongly recommend that > you avoid reinventing the wheel. Look around for free implementations > of PPP. The protocols themselves aren't all that complex, but getting > all of the interactions right is quite hard. The long-standing bugs > in many deployed implementations are a testament to this fact. Adding > a new bug-ridden implementation to that list wouldn't necessarily be a > good thing. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > From owner-ietf-ppp@merit.edu Fri Dec 27 19:23:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17073 for ; Fri, 27 Dec 2002 19:23:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF13B9125C; Fri, 27 Dec 2002 19:26:28 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A69CB9125D; Fri, 27 Dec 2002 19:26:28 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8D139125C for ; Fri, 27 Dec 2002 19:26:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A6FE5DF38; Fri, 27 Dec 2002 19:26:27 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ns1.avatar.com (ns1.avatar.com [199.33.206.1]) by segue.merit.edu (Postfix) with ESMTP id 685925DDE8 for ; Fri, 27 Dec 2002 19:26:27 -0500 (EST) Received: from tomcat (tomcat.avatar.com [199.33.206.20]) by ns1.avatar.com (Postfix) with SMTP id DB6F5A4B12; Fri, 27 Dec 2002 16:26:26 -0800 (PST) From: "Kory Hamzeh" To: "Bill Cunningham" , "James Carlson" Cc: Subject: RE: PPP Date: Fri, 27 Dec 2002 16:26:24 -0800 Message-ID: <005a01c2ae07$c0d53ec0$14ce21c7@avatar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <000a01c2ae06$55031f60$3c44903f@a> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-ppp@merit.edu [mailto:owner-ietf-ppp@merit.edu]On > Behalf Of Bill Cunningham > Sent: Friday, December 27, 2002 4:16 PM > To: James Carlson > Cc: ietf-ppp@merit.edu > Subject: Re: PPP > > > I guess I wasn't specific. But yes I don't want to reinvent the > wheel. PPTP, > a MS protocol for linux is kinda what I'm looking at. I know PPTP is > proprietary, but something similar should work for linux. If it doesn't > already exist, and I'm not aware of it. > Look at L2TP. Does what PPTP does plus more and non-proprietary. Kory From owner-ietf-ppp@merit.edu Fri Dec 27 19:26:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17103 for ; Fri, 27 Dec 2002 19:26:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2686A9125D; Fri, 27 Dec 2002 19:29:44 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E852F9125E; Fri, 27 Dec 2002 19:29:43 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC4919125D for ; Fri, 27 Dec 2002 19:29:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA9D25DF81; Fri, 27 Dec 2002 19:29:42 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 4E9A95DF38 for ; Fri, 27 Dec 2002 19:29:42 -0500 (EST) Received: from gwzw2k (sjc-vpn1-939.cisco.com [10.21.99.171]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id QAA06815; Fri, 27 Dec 2002 16:29:33 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Bill Cunningham" , "James Carlson" Cc: Subject: RE: PPP Date: Fri, 27 Dec 2002 16:29:31 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <000a01c2ae06$55031f60$3c44903f@a> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Bill Cunningham [mailto:billc44@citynet.net] writes: > I guess I wasn't specific. But yes I don't want to reinvent the > wheel. PPTP, > a MS protocol for linux is kinda what I'm looking at. I know PPTP is > proprietary, but something similar should work for linux. How about L2TP (http://www.l2tpd.org/)? > If it doesn't > already exist, and I'm not aware of it. > > ----- Original Message ----- > From: "James Carlson" > To: "Bill Cunningham" > Cc: > Sent: Friday, December 27, 2002 11:54 AM > Subject: Re: PPP > > > > Bill Cunningham writes: > > > Other than rfc 1661, what rfc's should I look at to be up > to date on > > > today's PPP? > > > > A lot, and the exact list depends on what you're trying to do. > > > > > The rfc-editor has so many rfcs. Surely some must be > > > repetative. > > > > Uh, not exactly. > > > > Making the rash assumption that you're trying to do IP over > > asynchronous links (since you didn't indicate otherwise), you'll need > > to look over at least these RFCs: 1662, 1332, 1334, 1994. (RFC 1994 > > "obsoletes" 1334, but, in truth, there are still a lot of uses of PAP > > in the world, so 1334 is still needed.) > > > > You may need quite a few others. Without details of what you're > > trying to accomplish, it would be hard to make specific > > recommendations of what to look at. The lists are long. For > > instance, if you're in an MS environment, you might want 1877, 2118, > > 2433, 2637, 2759, 3078, and 3079 (note that 2118 and 3078 need 1962, a > > standard, non-MS protocol). Perhaps even a few others for IPX. > > > > Some environments require SONET/SDH support, or OSINLCP, or even > > AppleTalk. You'll need to work that out first. > > > > Of course, before you look at any of this, I strongly recommend that > > you avoid reinventing the wheel. Look around for free implementations > > of PPP. The protocols themselves aren't all that complex, but getting > > all of the interactions right is quite hard. The long-standing bugs > > in many deployed implementations are a testament to this fact. Adding > > a new bug-ridden implementation to that list wouldn't necessarily be a > > good thing. > > > > -- > > James Carlson, Solaris Networking > > Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 > > > > > From owner-ietf-ppp@merit.edu Fri Dec 27 21:43:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18742 for ; Fri, 27 Dec 2002 21:43:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A6DD591267; Fri, 27 Dec 2002 21:45:31 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7275091268; Fri, 27 Dec 2002 21:45:31 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E17891267 for ; Fri, 27 Dec 2002 21:45:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id A36BB5DEAD; Fri, 27 Dec 2002 21:45:27 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by segue.merit.edu (Postfix) with ESMTP id 07ADD5DE98 for ; Fri, 27 Dec 2002 21:45:27 -0500 (EST) Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.6/8.12.6) with ESMTP id gBS2jFhn001734; Fri, 27 Dec 2002 18:45:15 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.12.6/8.12.3) with ESMTP id gBS2jFef029503; Fri, 27 Dec 2002 18:45:15 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id gBS2jBZ10807; Fri, 27 Dec 2002 18:45:11 -0800 Date: Fri, 27 Dec 2002 18:45:10 -0800 From: Frank Cusack To: Kory Hamzeh Cc: Bill Cunningham , James Carlson , ietf-ppp@merit.edu Subject: Re: PPP Message-ID: <20021227184510.B10769@google.com> References: <000a01c2ae06$55031f60$3c44903f@a> <005a01c2ae07$c0d53ec0$14ce21c7@avatar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <005a01c2ae07$c0d53ec0$14ce21c7@avatar.com>; from kory@avatar.com on Fri, Dec 27, 2002 at 04:26:24PM -0800 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Fri, Dec 27, 2002 at 04:26:24PM -0800, Kory Hamzeh wrote: > > > -----Original Message----- > > From: owner-ietf-ppp@merit.edu [mailto:owner-ietf-ppp@merit.edu]On > > Behalf Of Bill Cunningham > > > > I guess I wasn't specific. But yes I don't want to reinvent the > > wheel. PPTP, > > a MS protocol for linux is kinda what I'm looking at. I know PPTP is > > proprietary, but something similar should work for linux. If it doesn't > > already exist, and I'm not aware of it. > > > > > Look at L2TP. Does what PPTP does plus more and non-proprietary. PPTP is not proprietary. L2TP is, though. Freely available, stable, unix implementations of PPTP do exist. http://pptpclient.sourceforge.net/ is a popular client implementation, http://www.poptop.org/ is a popular server implementation. /fc /fc From owner-ietf-ppp@merit.edu Fri Dec 27 21:58:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18868 for ; Fri, 27 Dec 2002 21:58:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8FE7391268; Fri, 27 Dec 2002 22:00:37 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D8F591269; Fri, 27 Dec 2002 22:00:37 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3721091268 for ; Fri, 27 Dec 2002 22:00:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BCB35DDF2; Fri, 27 Dec 2002 22:00:36 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from pit.databus.com (p72-185.acedsl.com [66.114.72.185]) by segue.merit.edu (Postfix) with ESMTP id 948125DDD2 for ; Fri, 27 Dec 2002 22:00:35 -0500 (EST) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.6/8.12.6) with ESMTP id gBS30Xk3055065; Fri, 27 Dec 2002 22:00:33 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.6/8.12.6/Submit) id gBS30XX7055064; Fri, 27 Dec 2002 22:00:33 -0500 (EST) (envelope-from barney) Date: Fri, 27 Dec 2002 22:00:33 -0500 From: Barney Wolff To: Frank Cusack Cc: ietf-ppp@merit.edu Subject: Re: PPP Message-ID: <20021228030033.GA54989@pit.databus.com> References: <000a01c2ae06$55031f60$3c44903f@a> <005a01c2ae07$c0d53ec0$14ce21c7@avatar.com> <20021227184510.B10769@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021227184510.B10769@google.com> User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Fri, Dec 27, 2002 at 06:45:10PM -0800, Frank Cusack wrote: > > PPTP is not proprietary. L2TP is, though. You seem to have a very odd definition of proprietary. Both protocols are published, but PPTP is strictly under Microsoft's control, while L2TP is a standards-track IETF effort. If sourceforge is your criterion, both protocols are there. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-ietf-ppp@merit.edu Fri Dec 27 22:47:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19711 for ; Fri, 27 Dec 2002 22:47:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F15F691269; Fri, 27 Dec 2002 22:50:25 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8E8B9126A; Fri, 27 Dec 2002 22:50:24 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B2FD991269 for ; Fri, 27 Dec 2002 22:50:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98FA55DF81; Fri, 27 Dec 2002 22:50:23 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from ns1.avatar.com (ns1.avatar.com [199.33.206.1]) by segue.merit.edu (Postfix) with ESMTP id 773255DDE8 for ; Fri, 27 Dec 2002 22:50:23 -0500 (EST) Received: from tomcat (tomcat.avatar.com [199.33.206.20]) by ns1.avatar.com (Postfix) with SMTP id D6292A4B29; Fri, 27 Dec 2002 19:50:22 -0800 (PST) From: "Kory Hamzeh" To: "Barney Wolff" , "Frank Cusack" Cc: Subject: RE: PPP Date: Fri, 27 Dec 2002 19:50:22 -0800 Message-ID: <000a01c2ae24$3f723460$14ce21c7@avatar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20021228030033.GA54989@pit.databus.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-ppp@merit.edu [mailto:owner-ietf-ppp@merit.edu]On > Behalf Of Barney Wolff > > On Fri, Dec 27, 2002 at 06:45:10PM -0800, Frank Cusack wrote: > > > > PPTP is not proprietary. L2TP is, though. > > You seem to have a very odd definition of proprietary. Both protocols > are published, but PPTP is strictly under Microsoft's control, while > L2TP is a standards-track IETF effort. If sourceforge is your criterion, > both protocols are there. > Took the words right out of my mouth. Thank you. Kory From owner-ietf-ppp@merit.edu Fri Dec 27 23:35:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20207 for ; Fri, 27 Dec 2002 23:35:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 471389126C; Fri, 27 Dec 2002 23:37:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0B4C9126D; Fri, 27 Dec 2002 23:37:51 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2ADB9126C for ; Fri, 27 Dec 2002 23:37:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id C24CC5DF82; Fri, 27 Dec 2002 23:37:50 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by segue.merit.edu (Postfix) with ESMTP id 50B5B5DDE8 for ; Fri, 27 Dec 2002 23:37:50 -0500 (EST) Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.6/8.12.6) with ESMTP id gBS4bohn014420; Fri, 27 Dec 2002 20:37:50 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.12.6/8.12.3) with ESMTP id gBS4bnef029464; Fri, 27 Dec 2002 20:37:49 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id gBS4bnl10967; Fri, 27 Dec 2002 20:37:49 -0800 Date: Fri, 27 Dec 2002 20:37:49 -0800 From: Frank Cusack To: Barney Wolff Cc: ietf-ppp@merit.edu Subject: Re: PPP Message-ID: <20021227203749.A10935@google.com> References: <000a01c2ae06$55031f60$3c44903f@a> <005a01c2ae07$c0d53ec0$14ce21c7@avatar.com> <20021227184510.B10769@google.com> <20021228030033.GA54989@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20021228030033.GA54989@pit.databus.com>; from barney@pit.databus.com on Fri, Dec 27, 2002 at 10:00:33PM -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Fri, Dec 27, 2002 at 10:00:33PM -0500, Barney Wolff wrote: > On Fri, Dec 27, 2002 at 06:45:10PM -0800, Frank Cusack wrote: > > > > PPTP is not proprietary. L2TP is, though. > > You seem to have a very odd definition of proprietary. Both protocols > are published, but PPTP is strictly under Microsoft's control, while > L2TP is a standards-track IETF effort. If sourceforge is your criterion, > both protocols are there. Yes, I guess I'm using a different (incorrect) definition of proprietary. What I really meant was, PPTP is freely implementable. L2TP is not. I can write and publish an implementation of PPTP, without being beholden to Microsoft whereas I must license L2TP from Cisco. Of course, please correct me if Cisco has granted no-cost license terms to anyone for L2TP. /fc From owner-ietf-ppp@merit.edu Sat Dec 28 00:16:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20725 for ; Sat, 28 Dec 2002 00:16:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E4C1791201; Sat, 28 Dec 2002 00:19:33 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B08709121C; Sat, 28 Dec 2002 00:19:33 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A047F91201 for ; Sat, 28 Dec 2002 00:19:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C7D35DF82; Sat, 28 Dec 2002 00:19:32 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id E89E95DE12 for ; Sat, 28 Dec 2002 00:19:31 -0500 (EST) Received: from gwzw2k (sjc-vpn3-219.cisco.com [10.21.64.219]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id VAA21119; Fri, 27 Dec 2002 21:19:24 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Frank Cusack" , "Barney Wolff" Cc: Subject: RE: PPP Date: Fri, 27 Dec 2002 21:19:22 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <20021227203749.A10935@google.com> Importance: Normal Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Frank Cusack [mailto:fcusack@fcusack.com] writes: > On Fri, Dec 27, 2002 at 10:00:33PM -0500, Barney Wolff wrote: > > On Fri, Dec 27, 2002 at 06:45:10PM -0800, Frank Cusack wrote: > > > > > > PPTP is not proprietary. L2TP is, though. > > > > You seem to have a very odd definition of proprietary. Both protocols > > are published, but PPTP is strictly under Microsoft's control, while > > L2TP is a standards-track IETF effort. If sourceforge is your > criterion, > > both protocols are there. > > Yes, I guess I'm using a different (incorrect) definition of proprietary. > What I really meant was, PPTP is freely implementable. L2TP is not. ?? > > I can write and publish an implementation of PPTP, without being beholden > to Microsoft whereas I must license L2TP from Cisco. Of course, please > correct me if Cisco has granted no-cost license terms to anyone for L2TP. L2TP is is sole subject of RFC 2661. Cisco holds no IPR WRT L2TP, nor does it license it to or from anybody. > > /fc > > From owner-ietf-ppp@merit.edu Sat Dec 28 01:03:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21210 for ; Sat, 28 Dec 2002 01:03:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 98D6C9121C; Sat, 28 Dec 2002 01:06:38 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62A509126E; Sat, 28 Dec 2002 01:06:38 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 504DA9121C for ; Sat, 28 Dec 2002 01:06:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E4885DDF7; Sat, 28 Dec 2002 01:06:37 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from 216-239-45-4.google.com (216-239-45-4.google.com [216.239.45.4]) by segue.merit.edu (Postfix) with ESMTP id A23C75DDE8 for ; Sat, 28 Dec 2002 01:06:36 -0500 (EST) Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.6/8.12.6) with ESMTP id gBS66Shn023698; Fri, 27 Dec 2002 22:06:28 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.12.6/8.12.3) with ESMTP id gBS66Sef022626; Fri, 27 Dec 2002 22:06:28 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id gBS66S011072; Fri, 27 Dec 2002 22:06:28 -0800 Date: Fri, 27 Dec 2002 22:06:28 -0800 From: Frank Cusack To: Glen Zorn Cc: ietf-ppp@merit.edu Subject: Re: PPP Message-ID: <20021227220628.B11008@google.com> References: <20021227203749.A10935@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from gwz@cisco.com on Fri, Dec 27, 2002 at 09:19:22PM -0800 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Fri, Dec 27, 2002 at 09:19:22PM -0800, Glen Zorn wrote: > L2TP is is sole subject of RFC 2661. Cisco holds no IPR WRT L2TP, nor does > it license it to or from anybody. Thank you for that clarification. My confusion has been that L2TP is derived from L2F, for which Cisco holds patent 5,918,019. The text of the patent ends with: Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention can be modified in arrangement and detail without departing from such principles. I claim all modifications and variation coming within the spirit and scope of the following claims. Are you stating that L2TP is sufficently different from L2F as to not differ "in arrangment and detail without departing from such principles"? [I do not know L2TP vs L2F well enough to give my own opinion.] Given your history with the ietf, and your association with Cisco, I will take your statement at face value. Cisco issued a statement to the ietf saying that *if* any IPR claims for L2TP apply they will issue license terms in non-discriminatory fashion. Such a statement clearly leaves the door open for possible future legal action. Up till now, I don't think there has been any clear statement that L2TP does not infringe; e.g. the book _L2TP_ by Richard Shea has a section warning of possible patent issues. Perhaps you could have Cisco issue a statement to the IETF saying that L2TP does not infringe on the L2F patent? /fc From owner-ietf-ppp@merit.edu Sat Dec 28 01:56:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21833 for ; Sat, 28 Dec 2002 01:56:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 736929126F; Sat, 28 Dec 2002 01:59:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4720391271; Sat, 28 Dec 2002 01:59:16 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 578BC9126F for ; Sat, 28 Dec 2002 01:59:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DFFB5DEEE; Sat, 28 Dec 2002 01:59:15 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from pit.databus.com (p72-185.acedsl.com [66.114.72.185]) by segue.merit.edu (Postfix) with ESMTP id C27DD5DEED for ; Sat, 28 Dec 2002 01:59:14 -0500 (EST) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.6/8.12.6) with ESMTP id gBS6wwk3055958; Sat, 28 Dec 2002 01:58:58 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.6/8.12.6/Submit) id gBS6wwCP055957; Sat, 28 Dec 2002 01:58:58 -0500 (EST) (envelope-from barney) Date: Sat, 28 Dec 2002 01:58:58 -0500 From: Barney Wolff To: Glen Zorn Cc: Frank Cusack , Barney Wolff , ietf-ppp@merit.edu Subject: Re: PPP Message-ID: <20021228065858.GB55880@pit.databus.com> References: <20021227203749.A10935@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Fri, Dec 27, 2002 at 09:19:22PM -0800, Glen Zorn wrote: > Frank Cusack [mailto:fcusack@fcusack.com] writes: > > > I can write and publish an implementation of PPTP, without being beholden > > to Microsoft whereas I must license L2TP from Cisco. Of course, please > > correct me if Cisco has granted no-cost license terms to anyone for L2TP. > > L2TP is is sole subject of RFC 2661. Cisco holds no IPR WRT L2TP, nor does > it license it to or from anybody. L2TP != L2F and I don't know that even L2F would require a license. Something of a moot point, these days. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-ietf-ppp@merit.edu Sun Dec 29 22:10:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06737 for ; Sun, 29 Dec 2002 22:10:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A4A0912A5; Sun, 29 Dec 2002 22:13:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBDC0912A6; Sun, 29 Dec 2002 22:13:23 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF914912A5 for ; Sun, 29 Dec 2002 22:13:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95AEF5DF96; Sun, 29 Dec 2002 22:13:22 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 479A05DE2E for ; Sun, 29 Dec 2002 22:13:22 -0500 (EST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23969; Sun, 29 Dec 2002 20:13:17 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gBU3DG5f020504; Sun, 29 Dec 2002 22:13:16 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id gBU3DGxO024834; Sun, 29 Dec 2002 22:13:16 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id gBU3DG0g024831; Sun, 29 Dec 2002 22:13:16 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15887.47564.208282.104058@gargle.gargle.HOWL> Date: Sun, 29 Dec 2002 22:13:16 -0500 From: James Carlson To: , Barney Wolff Cc: "Frank Cusack" , Subject: RE: PPP In-Reply-To: Glen Zorn's message of 27 December 2002 21:19:22 References: <20021227203749.A10935@google.com> <20021228065858.GB55880@pit.databus.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Glen Zorn writes: > L2TP is is sole subject of RFC 2661. Cisco holds no IPR WRT L2TP, nor does > it license it to or from anybody. I would very much like to hear a clear statement from Cisco's lawyers on this subject. The last such public communication that I know of was this one: http://www.ietf.org/ietf/IPR/CISCO-L2TP This certainly leaves the situation a lot less clear than you seem to be indicating, at least to me. For what it's worth, I personally know several folks who've been contacted by lawyers involved in L2TP IPR litigation (including myself), and who are thus quite adverse to implementing any part of that standard for that reason. Talking to lawyers about IPR is not an enjoyable part of the job. If Cisco is not pursuing these claims, then I think that'd be wonderful news to make known more widely so that the standard can become more widely used. Barney Wolff writes: > > L2TP is is sole subject of RFC 2661. Cisco holds no IPR WRT L2TP, nor does > > it license it to or from anybody. > > L2TP != L2F and I don't know that even L2F would require a license. > Something of a moot point, these days. It doesn't matter what magic letters you use to identify the protocol, nor what RFC numbers get assigned. It doesn't matter if you think you invented the protocol independently. It doesn't matter if you think the protocol is "dead" or a "moot point." What matters when you are forced to defend what you've done in court, as I am reliably told by the law folk around me, are the individual claims made by the patent, the validity of those claims as determined by the court, and whether what you've done infringes on *any* of the valid claims in the patent. US Patent 5,918,019, assigned to Cisco and cited by some 32 other L2TP patents as prior art, includes these claims (I have omitted a few that are related to L2F authentication; see www.uspto.gov for the full text): 1. A method for creating a virtual dial-up session from a remote client to a local network through an internet service provider, comprising: establishing a point-to-point link between the remote client and the internet service provider using a link level protocol; and conducting a layer 2 forwarding protocol between the internet service provider and the local network that projects the point-to-point link from the internet service provider to the local network thereby creating a virtual direct dial-up session between the remote client and said local network. [...] 3. A method according to claim 1 wherein the link level protocol comprises at least one of a point-to-point protocol (PPP) and a serial line interface protocol (SLIP). 4. A method according to claim 3 wherein the forwarding protocol projects a link control protocol (LCP) from the internet service provider to the local network. [...] 8. A method according to claim 1 wherein the internet service provider is connected to at least one of a public switched telephone network access and an integrated services digital network access. [...] 9. A method according to claim 1 wherein projecting the point-to-point link includes the following steps: establishing a layer 2 tunnel between the internet service provider and the local network; encapsulating the link level protocol in the forwarding protocol; forwarding the encapsulated link level protocol through the tunnel; stripping the forwarding protocol from the link level protocol and processing the link level protocol with the local network as a direct point-to-point connection with the remote client. 10. A method according to claim 1 including identifying the remote client as one of a virtual dial-up client and an internet service provider client and conducting the forwarding protocol only for the virtual dial-up client. 11. A method for establishing a virtual direct dial-up link with a network access server, comprising: conducting a point-to-point protocol session with remote clients; identifying remote clients having virtual dial-up addresses; authenticating remote clients having authorized access to a home gateway according to a layer 2 forwarding protocol; establishing a layer 2 tunnel connection with the home gateway for authenticated remote clients; and projecting the point-to-point protocol session through the layer 2 tunnel to the home gateway according to the layer 2 forwarding protocol thereby establishing a virtual direct dial-up link to the home gateway. [...] 13. A method according to claim 11 wherein the step of projecting comprises encapsulating the point-to-point protocol session in a layer 2 forwarding protocol header and transmitting the encapsulated point-to-point session through the layer 2 tunnel. 14. A method according to claim 13 wherein the layer 2 forwarding protocol header includes a multiplex identification field for multiplexing multiple remote clients through the layer 2 tunnel at the same time. 15. A method according to claim 13 wherein the layer 2 forwarding protocol header includes a client ID field for demultiplexing multiple tunnels. 16. A method according to claim 13 wherein the layer 2 forwarding protocol header includes a packet key for transmitting encrypted authentication responses between the network access server and the home gateway. 17. A virtual dial-up system, comprising: an internet infrastructure; a dial-up server connected to the internet infrastructure; a private local network; a home gateway connected between the private network and the internet; a remote client connected to the dial-up server, the remote client conducting a point-to-point link level session with the dial-up server; and a virtual dial-up protocol operating on the dial-up server for automatically projecting the link level session from the dial-up server to the home gateway thereby establishing a virtual direct dial-up session between the remote client and the private local network through the internet infrastructure. [...] 24. A network access server, comprising: an input receiving a point-to-point protocol session with a remote client; an output connected to an internet infrastructure for transferring information using an internet protocol; and a processor and memory connected between the input and the output for conducting a layer 2 forwarding protocol that projects the link level session through the internet infrastructure to a local network independently of the internet protocol. 25. A network access server according to claim 24 wherein the processor attaches a forwarding protocol header to the point-to-point protocol session. 26. A network access server according to claim 25 wherein the processor negotiates a tunnel through the internet infrastructure to the local network and transmits the forwarding protocol header and the point-to-point protocol session over the tunnel. 27. A network access server according to claim 26 wherein the tunnel is established independently of a dial-up phone number used by the remote client for dialing up the network access server. 28. A home gateway, comprising: an input connected to an internet infrastructure for receiving point-to-point link level packets encapsulated in a virtual dial-up protocol and transported using an internet protocol; an output connected to a local network; and a processor connected between the input and the output for conducting a direct dial-up point-to-point link session through the internet infrastructure to a remote client according to the virtual dial-up protocol independently of the internet transport protocol. 29. A home gateway according to claim 28 wherein the processor establishes a tunnel connection with a remote client according to the virtual dial-up protocol. 30. A home gateway according to claim 29 wherein the processor authenticates the remote client according to the virtual dial-up protocol prior to establishing the tunnel connection. If you feel that you can implement L2TP without running afoul of any of those claims, then please be my guest. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Mon Dec 30 19:50:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04874 for ; Mon, 30 Dec 2002 19:50:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A1C491233; Mon, 30 Dec 2002 19:52:59 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C08B91239; Mon, 30 Dec 2002 19:52:59 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03A5491233 for ; Mon, 30 Dec 2002 19:52:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE1EF5DEAA; Mon, 30 Dec 2002 19:52:57 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from gateway.hns.com (gateway.hns.com [208.236.67.14]) by segue.merit.edu (Postfix) with ESMTP id 79CDA5DEA4 for ; Mon, 30 Dec 2002 19:52:57 -0500 (EST) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id gBV0qsPM009503; Mon, 30 Dec 2002 19:52:55 -0500 (EST) Received: from atlas (atlas.hns.com [139.85.177.110]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gBV0qn101580; Mon, 30 Dec 2002 19:52:49 -0500 (EST) To: James Carlson , ietf-ppp@merit.edu Cc: Karl Fox , Thomas Narten , border@hns.com Subject: draft-heath-ppp-v44-02.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: jheath@hns.com Date: Mon, 30 Dec 2002 16:52:46 -0800 X-MIMETrack: Serialize by Router on Atlas/HNS(Release 5.0.10 |March 22, 2002) at 12/30/2002 07:50:53 PM, Serialize complete at 12/30/2002 07:50:53 PM Content-Type: text/plain; charset="us-ascii" X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com gBV0qn101580 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu James Thanks for your comment on draft-heath-ppp-v44-02.txt. In answer to your concern that the draft contains modes that require sequencing without specifying a sequencing header as part of the V.44 compression protocol, I have included below some sections of RFC1663, RFC1967, and RFC1993. It is my impression that RFC1663 is designed to provide a reliable link and thus maintain sequencing for compression protocols over PPP. RFC's 1967 and 1993 are examples of two other compression protocols that also have modes that require sequencing, also do not provide a sequencing header, and also reference RFC1663 as one method of providing the required reliable transmission and sequencing. I considered such a sequencing header for the V.44 compression protocol but when I looked at some RFC's like 1974 that made use of such a header and the methods used to keep the dictionaries synchronized I thought these sequencing methods were far too complex and conflicted with the basic premise of compression, which is to reduce the number of bytes being transmitted. I think is much better to leave it to each network architect to determine the type of reliable transport that is used to maintain any packet sequencing and data integrity that is required for compression or other features. I also think that the compression function and the reliable transport/data integrity functions should be kept separate to allow maximum flexibility in where and how they are implemented within protocol stacks. Certainly compression, regardless of the packet sequencing issue, requires that the data passed to the de-compressor be uncorrupted and free of link errors. But since compression is often not the only protocol component that requires error free data I don't think the compression function needs it's own checksum independent of other CRC's or checksums that are appended to network datagrams. I am not that familiar with all the most common implementations of PPP, so if it is the case that RFC1663, PPP Reliable Transport, is not widely used and in real PPP networks using PPP compression it is much more desirable that the compression protocol provide internal methods to maintain any required sequencing then I can revisit this issue. But I would prefer that the methods used to maintain sequencing and insure the integrity of compressed data be kept separate from the V.44 compression protocol in PPP. regards Jeff Heath RFC1663 PPP Reliable Transmission Generally, serial link reliability is not a major issue. The architecture of protocols used in datagram networking presume best-effort non-sequential delivery. When errors are detected, datagrams are discarded. However, in certain circumstances, it is advisable to provide a reliable link, at least for a subset of the messages. The most obvious case is when the link is compressed. Since the dictionary is recovered from the compressed data stream, and a lost datagram corrupts the dictionary, datagrams must not be lost. Not all compression types will require a reliable data stream, since the cost to detect and reset a corrupt dictionary is small. RFC 1967 PPP LZS-DCP Compression Protocol (LZS-DCP) When using one or more compression histories, the implementation MUST rely on either a lower layer reliable link protocol (RFC 1663), use a technique to keep the compressor and decompressor histories in synchronization, or both. The LZS-DCP protocol provides the Request-Req and Request-Ack bits in the DCP header for this purpose. Since this synchronization is done on a per history basis, the history number fields are required to be the same size in both directions of the link. Any data contained in the packet is processed after the signaling bits are processed. RFC1993 PPP Gandalf FZA Compression Protocol Reliability and Sequencing The FZA algorithm expects a reliable link, as described in "PPP Reliable Transmission" [6]. FZA expects the packets to be delivered in sequence. James Carlson writes: > My comments are probably arriving way too late, but I'm vaguely > uncomfortable with a compression protocol that has modes requiring > sequencing and that (unlike all of the other CCP algorithms defined to > date) includes no sequencing header. > I'd certainly prefer either a one or two octet header before the > compressed data, as has been done with RFCs 1974, 1975, 1977, 1979, > 2118, or a trailing checksum as with 1978. > -- > James Carlson, Solaris Networking > SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Dec 31 12:51:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26483 for ; Tue, 31 Dec 2002 12:51:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D534091207; Tue, 31 Dec 2002 12:53:56 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A718B9120D; Tue, 31 Dec 2002 12:53:56 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B338991207 for ; Tue, 31 Dec 2002 12:53:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id A07425DE37; Tue, 31 Dec 2002 12:53:55 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 244015DE1E for ; Tue, 31 Dec 2002 12:53:55 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23042; Tue, 31 Dec 2002 09:53:53 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id gBVHrqmt008744; Tue, 31 Dec 2002 12:53:52 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6) with ESMTP id gBVHrqxO027986; Tue, 31 Dec 2002 12:53:52 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.6+Sun/8.12.6/Submit) id gBVHrq8q027983; Tue, 31 Dec 2002 12:53:52 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15889.55728.447864.607165@gargle.gargle.HOWL> Date: Tue, 31 Dec 2002 12:53:52 -0500 From: James Carlson To: jheath@hns.com Cc: ietf-ppp@merit.edu, Karl Fox , Thomas Narten , border@hns.com Subject: Re: draft-heath-ppp-v44-02.txt In-Reply-To: jheath@hns.com's message of 30 December 2002 16:52:46 References: X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit jheath@hns.com writes: > Thanks for your comment on draft-heath-ppp-v44-02.txt. In answer to your concern that the draft contains modes that require > sequencing without specifying a sequencing header as part of the V.44 > compression protocol, I have included below some sections of RFC1663, > RFC1967, and RFC1993. Yes, I'm familar with those. RFC 1663 is LAP-B, which isn't just error detection, but also error *correction*. I recommend looking over RFC 3366 ("Advice to link designers on link Automatic Repeat reQuest (ARQ)") section 2.1 for a discussion of the sorts of upper-level problems this can cause. > It is my impression that RFC1663 is designed to > provide a reliable link and thus maintain sequencing for compression > protocols over PPP. It might be appropriate to use 1663 for a single link-layer hop that has non-negligible error rate, such as (say) a synchronous link. One could imagine, for instance, running RFC 1663 PPP over the raw synchronous interface provided by V.{34,90,...}, and using V.44 compression in PPP rather than V.42bis. However, I think it's hard to say that use of 1663 is generally a good idea in *all* cases or even in *many* cases. If you want to require implementation of RFC 1663 for some proprietary compression scheme, I suppose that's fine. It will likely limit the cases in which the compression mode can be used, since 1663 is somewhat rare (I know that Cisco has it; any others?), but that's by definition not a problem for anyone else. If, however, this is for a non-proprietary scheme, then I think it would be best to follow the precedent established by the commonly-used compression algorithms for PPP. These are: - RFC 1974 STAC LZS Compression Protocol - RFC 1977 BSD Compression Protocol - RFC 1979 PPP Deflate Protocol - RFC 2118 Microsoft Point-To-Point Compression (MPPC) Protocol All of these use embedded check bytes to validate synchronization, rather than requiring the underlying layer to be perfectly reliable. > RFC's 1967 and 1993 are examples of two other > compression protocols that also have modes that require sequencing, also > do not provide a sequencing header, and also reference RFC1663 as one > method of providing the required reliable transmission and sequencing. RFC 1967 does *not* require the use of RFC 1663. Section 2.3 says: When using one or more compression histories, the implementation MUST rely on either a lower layer reliable link protocol (RFC 1663), use a technique to keep the compressor and decompressor histories in synchronization, or both. [...] However, if you look at section 2.5, you'll see that the packet header has provisions for both sequence numbers and LCB for error detection: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PPP Protocol | DCP-Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (History Number) | (Seq Num) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (LCB) | +-+-+-+-+-+-+-+-+ (Cisco has a 1967 implementation; I don't know of any others. I've never seen it used in practice.) You're right that RFC 1993 does require a reliable underlying link (and suggests RFC 1663 as one way to achieve that). It's a stand-out in this area, and is a proprietary protocol. I don't know of any implementations, though I'd be interested to hear about them. > I considered such a sequencing header for the V.44 compression protocol > but when I looked at some RFC's like 1974 that made use of such a header > and the methods used to keep the dictionaries synchronized I thought these > sequencing methods were far too complex and conflicted with the basic > premise of compression, which is to reduce the number of bytes being > transmitted. I agree that RFC 1974 is over the top. How about the simple sequence numbering used in RFC 1977 or RFC 1979? > I think is much better to leave it to each network architect > to determine the type of reliable transport that is used to maintain any > packet sequencing and data integrity that is required for compression or > other features. I also think that the compression function and the > reliable transport/data integrity functions should be kept separate to > allow maximum flexibility in where and how they are implemented within > protocol stacks. I mostly agree with that philosophy, except that I think it would require an overhaul of RFC 1663 to give it characteristics similar to the simple error detection (without retransmission) already used in most PPP compression implementations. > Certainly compression, regardless of the packet sequencing issue, requires > that the data passed to the de-compressor be uncorrupted and free of link > errors. But since compression is often not the only protocol component > that requires error free data I don't think the compression function needs > it's own checksum independent of other CRC's or checksums that are > appended to network datagrams. There are varying levels of "error free" available here. PPP assumes that the underlying transport delivers frames in-order, and little else. It typically runs over protocols (such as RFC 1662 framing) that provide only error detection -- meaning that the upper levels of PPP see only error-free frames, not necessarily *all* frames. Frames with errors are discarded rather than retransmitted. I do recommend looking through the PILC RFCs. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677