From owner-ietf-ppp@merit.edu Mon Dec 1 12:54:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA21417; Mon, 1 Dec 1997 12:54:40 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 12:47:53 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA21233 for ietf-ppp-outgoing; Mon, 1 Dec 1997 12:47:52 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-21.dialip.mich.net [141.211.7.63]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA21219 for ; Mon, 1 Dec 1997 12:47:44 -0500 (EST) Date: Mon, 1 Dec 97 16:34:55 GMT From: "William Allen Simpson" Message-ID: <6833.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Final Agenda for Washington IETF Sender: owner-ietf-ppp@merit.edu > From: Karl Fox > Well, at least it's final until Monday when I get back. Please send > me any corrections; I had to guess at bits and pieces. Also, one > person isn't listed at all yet because I'm waiting for some details. > > There will be no PPP over SONET/SDH discussion in this working group. > It has moved to a BOF entitled > > OPS posse Packet Over SONET/SDH Examination BOF > Wednesday, December 10 at 1300-1500 > (opposite ipp, ldapext, dhc, roamops, ospf, smime, avt) > Great! > Monday, December 8 at 0930-1130 > (opposite calsch, pktway, mboned, manet, pkix, tcpsat, intserv) > Tuesday, December 9 at 1015-1115 > (opposite rip, webdav, dhc, ulp-BOF, 2000, rap, mboned) > Monday MORNING?!? When did we get moved to Monday? I'm singing Messiah Sunday afternoon in Ann Arbor, could only get there by Monday morning if I drive all night without sleep (the last plane leaves before I can get to the airport). Botheration! Any chance you could move all mine to Tuesday? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 1 12:53:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA21403; Mon, 1 Dec 1997 12:53:53 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 12:47:54 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA21240 for ietf-ppp-outgoing; Mon, 1 Dec 1997 12:47:54 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-21.dialip.mich.net [141.211.7.63]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA21226 for ; Mon, 1 Dec 1997 12:47:45 -0500 (EST) Date: Mon, 1 Dec 97 16:47:14 GMT From: "William Allen Simpson" Message-ID: <6834.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: draft-ietf-pppext-sonet-ds-00 Sender: owner-ietf-ppp@merit.edu > From: Stuart Venters > > Note that Stuart did not include most of my comments and questions. > > Noted, but the reasons are 1) you are wearing me down, and 2) I > feel that things will go faster if the scope of the discussion > narrows until we get to common ground and then look and see > what issues are left. > Heck, I'm getting worn down myself. If you cannot answer technical details asked, then you have not given me sufficient information to reply. I don't see why I should waste my time guessing. Step back. Look at the WHOLE picture. > > Which ones? Specifically? I have a pile from 1991 and 1992.... > > Again, the point was that they were _all_ like this. No, _NONE_ that I have were "like this". _NONE_ displayed at Interop '91, '92 or '93 were "like this". Since that is the time frame when RFC-1619 was researched, and the first implementation was developed, you cannot expect anything else. > It appears to be > the way things are done. However, the data sheets I looked at today > were the current Amp, Lucent, and Hp single mode OC-3 units with Pecl > interfaces but no clock recovery. > No clock recovery? What does this mean? Clock recovery is required for both SONet and SDH. Are you saying that none of these interfaces meets the requirements? Bring these latest data sheets to IETF. This isn't going to be solved on a mailing list. > > less than 20KHz??? > > That's many orders of magnitude less than we are talking about here.... > > > Consider an atacker sending a 1500 byte packet thru which results in a > fiber bit stream with a one sprinkled every two or three bytes (overhead > bytes excluded of course). The nasty pattern detector would be none > the wiser, but the duty cycle and transition density would be way off > for 80uS. This seems sufficient time for something with a > 50uS time constant to be affected. > > What's wrong with this attack senario? > I cannot make any sense of this scenario. Are you sure that you didn't mistype KHz for MHz? Why are overhead bytes excluded? They are in the middle of the stream, too. And forget about two or three bytes. A one sprinkled every nine bytes (72 bits), to give the worst case meeting the SDH G.957 pseudo-test, would be: Mbps KHz (sic) 155 2153 622 8639 etc Orders of magnitude.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 1 13:50:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA22531; Mon, 1 Dec 1997 13:50:53 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 13:50:24 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA22498 for ietf-ppp-outgoing; Mon, 1 Dec 1997 13:50:24 -0500 (EST) Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA22486 for ; Mon, 1 Dec 1997 13:50:18 -0500 (EST) Received: from brtpsa05.us.nortel.com (actually 47.239.68.230) by bcarsde4.localhost; Mon, 1 Dec 1997 11:30:47 -0500 Received: from nrtpde0a.us.nt.com (actually nrtpde0a.us.nortel.com) by brtpsa05.us.nortel.com; Mon, 1 Dec 1997 09:28:23 -0500 Received: by nrtpde0a.us.nt.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCFE3A.FD778CC0@nrtpde0a.us.nt.com>; Mon, 1 Dec 1997 09:24:57 -0500 Message-ID: From: "Tom Taylor" To: "ietf-ppp@merit.edu" Cc: "Tim Armstrong" Subject: Re: draft-ietf-pppext-sonet-ds-00.txt Date: Mon, 1 Dec 1997 09:23:53 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu We at Nortel wish to add our support to the position expressed in draft-manchester-pppext-transper-00.txt. We have put two contributions into ANSI T1X1.5, quantifying the exposures resulting from failure to scramble, and comparing the effectiveness of various possible solutions. In brief summary: * outages can be caused by adverse patterns even when interleaved with other traffic on higher speed systems; * the problem can't be fixed by tightening up timing in the SONET/SDH systems, because that would increase vulnerability to jitter; * prophylactic byte stuffing can be countered by the attacker; * set/reset scrambling as proposed in draft-ietf-pppext-pppsonet-scrambler-00.txt is overly complex and forces close coupling between the SONET/SDH path and scrambling functions. The conclusions of our submissions to ANSI T1X1.5 are as follows: Because scrambling offers the best security in the considered solution set, it is selected. Because of the numerous advantages with respect to set-reset scramblers of self-synchronous scramblers, a self-synchronous scrambler represents the best solution. Because of its selection as the scrambler for the ATM cell payload mapping into SONET/SDH, the 1 + x**43 polynomial is familiar. It is also simple, which makes it an obvious choice as a solution with which interoperability can quickly and easily be achieved. The most effective implementation would scramble the entire HDLC frame. This removes any concerns with deterministic patterns due to HDLC overhead, or due to post-scrambling escape byte insertion. Because of its robustness relative to CRC-16, CRC-32 should be used as the HDLC Frame Check Sequence. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 1 14:22:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA23209; Mon, 1 Dec 1997 14:22:19 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 14:21:22 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA23165 for ietf-ppp-outgoing; Mon, 1 Dec 1997 14:21:21 -0500 (EST) Received: from cbgw1.lucent.com (cbgw1.lucent.com [207.24.196.51]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA23161 for ; Mon, 1 Dec 1997 14:21:16 -0500 (EST) From: manchester@bell-labs.com Received: from hotair.hobl.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id OAA17060; Mon, 1 Dec 1997 14:11:18 -0500 Received: from camus.hobl.lucent.com ([199.118.135.96]) by hotair.hobl.lucent.com (4.1/EMS-L SunOS) id AA17720; Mon, 1 Dec 97 14:20:55 EST Message-Id: <34830B73.862DFB72@bell-labs.com> Date: Mon, 01 Dec 1997 14:09:39 -0500 Original-From: James Manchester Reply-To: manchester@bell-labs.com Organization: Advanced Networking Technologies X-Mailer: Mozilla 4.0 [en] (Win95; I) Mime-Version: 1.0 To: "ietf-ppp@merit.edu" Subject: On scrambling and transparency... X-Priority: 3 (Normal) Content-Type: multipart/mixed; boundary="------------7023392FED93A87D3F2BBC42" Sender: owner-ietf-ppp@merit.edu This is a multi-part message in MIME format. --------------7023392FED93A87D3F2BBC42 Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The attached ID hasn't been announced yet. I figure it is caught in a backlog as I was not able to submit until the afternoon of the 21st. Anyway, I will be presenting the same material to T1X1.5 tomorrow. --------------7023392FED93A87D3F2BBC42 Content-Type: text/plain; charset=iso-8859-1; name="draft-manchester-pppext-transper-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="draft-manchester-pppext-transper-00.txt" Internet-Draft J. Manchester S. Dravida B. Doshi J. Anderson Lucent Technologies R. Broberg Cisco Systems Peter Lothberg Sprint Corporation November 21st, 1997 Enabling Transparency for the PPP over SONET/SDH Mapping Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract Recent Internet Draft submissions and discussion on the PPP Extensions Working Group email list have highlighted a transparency deficiency with the PPP over SONET/SDH mapping described in IETF RFC 1619. This ID proposes that a 1+x**43 scrambler be used to overcome the transparency deficiency of IETF RFC 1619. Manchester, et al Expires May 21st, 1998 [Page 1] =0C Internet Draft Nov.21, 1997 1. Introduction Reference [1] describes a deficiency with the IETF RFC 1619 [2] PPP over SONET/SDH mapping that allows a user to gain control of a significant portion of the SONET/SDH SPE by emulating the SONET/SDH scrambler. It has been known since 1988 that data mappings should be scrambled before they are mapped into the SONET/SDH payload; hence a 1+x**43 self-synchronous scrambler is used to scramble the ATM payload before ATM cells are mapped into the SONET/SDH payload. The ATM scrambler is easy to implement and its characteristics are well known. The use of the ATM scrambler would thus be a convenient fix for RFC 1619. References [3] and [4] provide an analysis of the ATM scrambler with the PPP over SONET/SDH mapping. The studies show that the error multiplication due to the self-synchronous nature of the scrambler does not result in appreciable degradation in the error detection capability of the 16 bit HDLC FCS used in the mapping. Since this mapping does not use FEC in the protocol overhead or in the payload, other impacts of error multiplication are not an issue. The ATM scrambler is also shown to be effective in avoiding zero transition density. For a detailed analysis of the issues see [4]. It is also important to recognize the following points with regard to this issue: 1. The IETF RFC process is in place to stimulate and challenge thereby bringing about open discussion. The past month has shown that it works and can lead to good multi-vendor solutions. The past month's dialogue has been dealing with normal issues generated by Requests For Comment; IETF RFC 1619 is not yet an IETF standard. 2. The discussions of the past month have pointed out a deficiency in RFC 1619 that must be corrected before it is adopted as a standard. 3. Wide area, multi-carrier point-to-point links based on RFC 1619 have been in operation for over a year now with and without scrambling. While it is impossible to trace and determine whether transient operational problems can be attributed to the payload transparency problem, we should consider ourselves quite lucky that this problem has surfaced early in the standardization process. 4. Doubts (presented in [3]) regarding error multiplication and HDLC's 16 bit FCS (the HDLC FCS is described in [5]) have not been seen operationally. There are several factors involved here. First, burst errors, when they occur, often result in packet truncation. When this occurs the truncated packet, if it passes the 16 bit FCS Manchester, et al Expires May 21st, 1998 [Page 2] =0C Internet Draft Nov.21, 1997 will be tossed by length checks of the IP header. Subsequent remnants, if they pass, will be discarded via IP header validation. Passing the 16 bit FCS and IP header validation is considered highly unlikely. 5. Error multiplication may have an impact on the ability to perform FEC on the protocol overhead bytes and on the payload. Since PPP over SONET mapping does not use FEC anywhere, this is not a concern for the current PPP over SONET mapping. The scrambler issue should be revisited when a different mapping and/or FEC capabilities are considered. 2. Recommendations It is recommended that the following text be added to an appendix of IETF RFC 1619. For adequate transparency, data signals mapped directly into SONET/SDH payloads should be scrambled. For backwards compatibility, the scrambler should have an on/off capability where the scrambler is bypassed entirely when it is in the off mode. Scrambling provides security against emulation of the SONET/SDH scrambler pattern causing negative operational situations in SONET networks. For PPP over SONET/SDH, the entire SONET/SDH payload (SPE minus the path overhead and any fixed stuff) shall be scrambled using a self synchronous scrambler of polynomial 1+X**43. The transmitter and receiver operation are depicted below [3]: Transmitter schematic: Unscrambled Data | v +-------------------------------------+ +---+ +->| --> 43 bit shift register --> |--->|xor| | +-------------------------------------+ +---+ | | +-----------------------------------------------+ | v Scrambled Data Manchester, et al Expires May 21st, 1998 [Page 3] =0C Internet Draft Nov.21, 1997 Receiver schematic: Scrambled Data | +-----------------------------------------------+ | | | v | +-------------------------------------+ +---+ +->| --> 43 bit shift register --> |--->|xor| +-------------------------------------+ +---+ | v Unscrambled Data The HDLC FCS is calculated least significant bit first as shown: <- <- <- <- A B C D, That is, the FCS calculator is fed as follows: A[0], A[1], ... A[7], B[0], B[1], etc... Scrambling is done in the opposite manner, most significant bit first, as shown: -> -> -> -> A B C D. That is, the scrambler is fed as follows: A[7], A[6], ... A[0], B[7], B[6], etc... The scrambler shall operate continuously through the bytes of the SPE, bypassing bytes of SONET Path Overhead. The scrambling state at the beginning of a SPE shall be the state at the end of the previous SPE. Thus, the scrambler runs continuously and is not reset per frame. An initial seed is unspecified. Consequently, the first 43 transmitted bits following startup or reframe operation will not be descrambled correctly. Security Consideration This Internet Draft presents a proposed solution to specific security vulnerabilities associated with the PPP over SONET/SDH mapping of RFC 1619. Note this consideration is from the viewpoint of the SONET network. Acknowledgments Manchester, et al Expires May 21st, 1998 [Page 4] =0C Internet Draft Nov.21, 1997 The members of the Manchester Pub are greatly thanked for their philosophical inspiration. Author Addresses J. Manchester Bell Laboratories, Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA Email: manchester@bell-labs.com S. Dravida Bell Laboratories, Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA Email: dravida@bell-labs.com B. Doshi Bell Laboratories, Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA Email: bdoshi@bell-labs.com J. Anderson Bell Laboratories, Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA Email: jonanderson@bell-labs.com Manchester, et al Expires May 21st, 1998 [Page 5] =0C Internet Draft Nov.21, 1997 R. Broberg Cisco Systems 170 West Tasman Drive San Jose, CA 94513 USA Email: rbroberg@cisco.com Peter Lothberg Sprint 12490 Sunrise Valley Dr, Reston, VA 20196 USA Email: roll@sprint.net References [1] J. Manchester, et al., "PPP over SONET/SDH," , work in progress. [2] W. Simpson, "PPP over SONET/SDH," RFC 1619, May 1994. [3] D. Ferguson and R. Cherukuri, "Self-Synchronous Scramblers For PPP Over Sonet/SDH: Some Analysis," , work in progress. [3] B. Doshi, et al., "Scramblers for PPP over SONET/SDH: Performance Considerations and Analysis,"to be published. [5] W. Simpson, "PPP in HDLC-like Framing," RFC 1662, July 1994. Manchester, et al Expires May 21st, 1998 [Page 6] =0C --------------7023392FED93A87D3F2BBC42-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 1 14:49:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA23865; Mon, 1 Dec 1997 14:49:57 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 14:49:25 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA23817 for ietf-ppp-outgoing; Mon, 1 Dec 1997 14:49:24 -0500 (EST) Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA23813 for ; Mon, 1 Dec 1997 14:49:14 -0500 (EST) Received: from relay2.server.ibm.com (relay2.server.ibm.com [9.14.2.99]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id OAA26628 for ; Mon, 1 Dec 1997 14:51:04 -0500 Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by relay2.server.ibm.com (8.8.7/8.7) with SMTP id OAA17794 for ; Mon, 1 Dec 1997 14:47:32 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400015322855; Mon, 1 Dec 1997 14:52:31 -0500 From: John Martz To: Subject: Some Win95 PPP "How to?" questions Message-ID: <5010400015322855000003L053*@MHS> Date: Mon, 1 Dec 1997 14:52:31 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Folks, I really, really, really do NOT want to start a flame war here. So please take 10 deep breaths before replying to this post. Over the last few days I've been getting some questions about how to do some things in Win95 PPP that I think are just not supported. However, I have no way of knowing whether something is not supported in the Win95 PPP implementation or whether I just do not know how to do it. Was hoping I could find out by posting to this list. If there *IS* a way to do the following under Windows '95, would someone please tell me how to do it? - CHAP periodic rechallenge of Win95. It seems to me that Win '95 ignores any CHAP challenge sent to it after the authentication phase has completed. Is there a way to enable Win '95 to be compliant with RFC 1994? - Win95 CHAP authentication of peer. I don't know of a way to get Win95 to authenticate it's peer via CHAP (or PAP for that matter). Is this possible or does Win95 only provide for authentication of itself to the peer, not the other way around? - Win95 CHAP periodic rechallenge of peer. (If I can't get Win95 to issue a CHAP challenge, then I certainly don't know how to get it to periodically rechallenge it's peer :-). Has anyone put together a list of what (otherwise mandated) portions of the RFC's are not supported in the Win95 PPP implementation? If so, I'd appreciate a pointer to it. Thanks, -john martz, IBM AS/400 PPP development - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 1 15:50:25 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA25007; Mon, 1 Dec 1997 15:50:24 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 15:47:26 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA24947 for ietf-ppp-outgoing; Mon, 1 Dec 1997 15:47:25 -0500 (EST) Received: from ub-gate.UB.com (ub-gate.UB.com [192.216.34.11]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA24943 for ; Mon, 1 Dec 1997 15:47:21 -0500 (EST) Received: from andr.ub.com. (sunny.andr.ub.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.9.1]) id AA00840; Mon, 1 Dec 97 12:43:13 PST Received: from ironbridge.andr.ub.com (ironbridge.andr.ub.com [138.120.246.66]) by andr.ub.com. (8.8.5/8.8.5) with SMTP id PAA06735; Mon, 1 Dec 1997 15:41:38 -0500 (EST) Received: by ironbridge.andr.ub.com (SMI-8.6/SMI-SVR4) id PAA23225; Mon, 1 Dec 1997 15:40:06 -0500 Date: Mon, 1 Dec 1997 15:40:06 -0500 Message-Id: <199712012040.PAA23225@ironbridge.andr.ub.com> From: James Carlson To: jmartz@us.ibm.com Cc: ietf-ppp@merit.edu In-Reply-To: <5010400015322855000003L053*@MHS> (message from John Martz on Mon, 1 Dec 1997 14:52:31 -0500) Subject: Re: Some Win95 PPP "How to?" questions References: <5010400015322855000003L053*@MHS> Sender: owner-ietf-ppp@merit.edu > Over the last few days I've been getting some questions about how to do some > things in Win95 PPP that I think are just not supported. However, I have no way > of knowing whether something is not supported in the Win95 PPP implementation > or whether I just do not know how to do it. Was hoping I could find out by > posting to this list. I'm not trying to flame your request, but it would probably be better to contact the folks at Microsoft directly. As for what I've seen: > - CHAP periodic rechallenge of Win95. It seems to me that Win '95 ignores any > CHAP challenge sent to it after the authentication phase has completed. Is > there a way to enable Win '95 to be compliant with RFC 1994? No. > - Win95 CHAP authentication of peer. I don't know of a way to get Win95 to > authenticate it's peer via CHAP (or PAP for that matter). Is this possible or > does Win95 only provide for authentication of itself to the peer, not the other > way around? No. Win95 PPP appears to believe in the "client/server" model of computing, rather than PPP's standard peer-to-peer model. Since it's always a "client" (by definition; if you want a "server," then you run NT), there's no need to validate the peer. (Before others flame me: I am NOT endorsing this view of the world. It is clearly wrong.) > - Win95 CHAP periodic rechallenge of peer. (If I can't get Win95 to issue a > CHAP challenge, then I certainly don't know how to get it to periodically > rechallenge it's peer :-). No. > Has anyone put together a list of what (otherwise mandated) portions of the > RFC's are not supported in the Win95 PPP implementation? If so, I'd appreciate > a pointer to it. If Microsoft doesn't publish such a specification, then I strongly doubt that it exists. If you do obtain one under terms which will permit you to post it to this list, please do. I think we'd all be interested. -- James Carlson, Consulting Engineer IronBridge Networks / 5 Corporate Drive Vox: +1 978 691 4644 Andover MA 01810-2448 / USA Fax: +1 978 691 6300 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 1 17:39:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA27870; Mon, 1 Dec 1997 17:39:55 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 17:38:15 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA27830 for ietf-ppp-outgoing; Mon, 1 Dec 1997 17:38:14 -0500 (EST) Received: from gvmail.globalvillage.com ([198.93.137.253]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA27825 for ; Mon, 1 Dec 1997 17:38:09 -0500 (EST) Received: from sleet.globalvillage.com [198.93.138.50] by gvmail.globalvillage.com (SMTPD32-4.02c) id AC4F2F1B008E; Mon, 01 Dec 1997 14:38:07 PST Received: from ianp by sleet.globalvillage.com (SMI-8.6/SMI-SVR4) id OAA12079; Mon, 1 Dec 1997 14:37:54 -0800 Message-ID: <009601bcfea9$e1874cc0$46bf8acf@ianp.globalvillage.com> From: "Ian Puleston" To: Subject: Re: Some Win95 PPP "How to?" questions Date: Mon, 1 Dec 1997 14:38:43 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ppp@merit.edu >> - CHAP periodic rechallenge of Win95. It seems to me that Win '95 ignores any >> CHAP challenge sent to it after the authentication phase has completed. Is >> there a way to enable Win '95 to be compliant with RFC 1994? > >No. I heard somewhere that Microsoft are planning to fix that, but when I don't know. Maybe in Windows 98 ? >> - Win95 CHAP authentication of peer. I don't know of a way to get Win95 to >> authenticate it's peer via CHAP (or PAP for that matter). Is this possible or >> does Win95 only provide for authentication of itself to the peer, not the other >> way around? > >No. Win95 PPP appears to believe in the "client/server" model of >computing, rather than PPP's standard peer-to-peer model. Since it's >always a "client" (by definition; if you want a "server," then you run >NT), there's no need to validate the peer. Not quite true. If you install the ISDN accelerator pack (a freebie from MS for 95, and built into Win-98) then Windows 95 can function as a server (the Dial-Up Server as it is known) and will authenticate incoming calls with CHAP, PAP or MS-CHAP. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 1 17:53:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA28245; Mon, 1 Dec 1997 17:53:42 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 17:53:14 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA28188 for ietf-ppp-outgoing; Mon, 1 Dec 1997 17:53:13 -0500 (EST) Received: from smtp4.ny.us.ibm.COM (smtp4.ny.us.ibm.com [198.133.22.43]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA28184 for ; Mon, 1 Dec 1997 17:53:09 -0500 (EST) Received: from relay2.server.ibm.com (relay2.server.ibm.com [9.14.2.99]) by smtp4.ny.us.ibm.COM (8.8.7/8.8.7) with ESMTP id RAA11776; Mon, 1 Dec 1997 17:54:59 -0500 Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by relay2.server.ibm.com (8.8.7/8.7) with SMTP id RAA12310; Mon, 1 Dec 1997 17:51:27 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400015339539; Mon, 1 Dec 1997 17:56:25 -0500 From: John Martz To: Cc: Subject: Re: Some Win95 PPP "How to?" questions Message-ID: <5010400015339539000002L092*@MHS> Date: Mon, 1 Dec 1997 17:56:25 -0500 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu James, > I'm not trying to flame your request, but it would probably be better > to contact the folks at Microsoft directly. What you suggest makes a lot of sense. However, I have a very low opinion of my own understanding of Win95. It seemed more reasonable and expedient to post to this list and get some assurance that the problem was not me before attempting to get feedback from MicroSoft. >> Has anyone put together a list of what (otherwise mandated) portions of the >> RFC's are not supported in the Win95 PPP implementation? If so, I'd appreciate >> a pointer to it. > If Microsoft doesn't publish such a specification, then I strongly > doubt that it exists. > If you do obtain one under terms which will permit you to post it to > this list, please do. I think we'd all be interested. I have no desire to feel the wrath of Microsoft either. But I hope there is nothing inappropriate in asking for comments/advice on interacting with the Win95 PPP implementation. If an incorrect statement is posted, I'm sure that Microsoft will post a correction ASAP. No? I'll try not to make a nuisance of myself. (At least no more than in the past ... that leaves quite a lot of wiggle room I suppose :) -john martz IBM AS/400 PPP development - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 1 19:29:52 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA00307; Mon, 1 Dec 1997 19:29:49 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 19:28:47 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA00252 for ietf-ppp-outgoing; Mon, 1 Dec 1997 19:28:46 -0500 (EST) Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA00247 for ; Mon, 1 Dec 1997 19:28:39 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.8.8/8.6.12) id TAA17772 for ; Mon, 1 Dec 1997 19:28:38 -0500 (EST) Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma017767; Mon Dec 1 19:28:13 1997 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 2 Dec 1997 00:28:13 UT Received: (from smap@localhost) by ca.newbridge.com. (8.8.6/8.8.6) id TAA27024 for ; Mon, 1 Dec 1997 19:28:12 -0500 (EST) Received: from popmail.ca.newbridge.com(138.120.118.14) by kanmaster.ca.newbridge.com via smap (V1.3) id sma027014; Mon Dec 1 19:27:45 1997 Received: from [138.120.55.57] by popmail.ca.newbridge.com (SMI-8.6/SMI-SVR4) id TAA16961; Mon, 1 Dec 1997 19:25:41 -0500 X-Sender: james@popmail.ca.newbridge.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 1 Dec 1997 19:27:38 -0500 To: ietf-ppp@merit.edu From: James Watt Subject: Last call on draft-ietf-pppext-aal5-03.txt Sender: owner-ietf-ppp@merit.edu Folks: I know we have been around this a few times but I'm afraid the text we have in Section 4 may cause interoperability problems. Point (3) says: 3. If an implementation is connecting though a Frame Relay/ATM FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, then it MUST support LLC encapsulated PPP payloads. However, only the customer knows if this is true; the device certainly doesn't. Thus, for interoperability it would seem I would have to assume this is always true. However, point (2) says: 2. MAY use LLC encapsulated PPP payloads on PVCs as described in section 6 below by mutual configuration or negotiation of both end points. This technique is referred to as "LLC encapsulated PPP". Normally, point (2) would lead me to assume this is an optional capability. However, given that only the customer can tell if point (3) applies, point (3) suggests such support is mandatory. If it is mandatory, then we should say so, i.e. collapse points (2) and (3) into one and say "it MUST ... in case the connection traverses..." Comments ? -james ____________________________________________________________________________ James W. Watt, jamesw@newbridge.com Ph: (613) 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX: (613) 591-3680 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 1 19:30:47 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA00349; Mon, 1 Dec 1997 19:30:46 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 1 Dec 1997 19:28:21 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA00240 for ietf-ppp-outgoing; Mon, 1 Dec 1997 19:28:20 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA00203 for ; Mon, 1 Dec 1997 19:27:01 -0500 (EST) Received: by mail5.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Mon, 1 Dec 1997 16:28:28 -0800 Message-ID: From: Bruce Johnson To: "'John Martz'" Cc: ietf-ppp@merit.edu Subject: RE: Some Win95 PPP "How to?" questions Date: Mon, 1 Dec 1997 16:27:02 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ppp@merit.edu The released versions of Windows 95 will not respond to multiple CHAP challenges. This has been fixed in a Dial-Up Networking update (MSDUN12.EXE) for Windows 95 & OSR2. The update can be downloaded from Microsoft at http://www.microsoft.com/windows95/info/dialup.htm. Windows 95 Dial-Up Networking does not support authenticating a peer when functioning as a dial-in client. If you have further questions, you can contact me at bjohnson@microsoft.com. Bruce Johnson Microsoft > ---------- > From: John Martz[SMTP:jmartz@us.ibm.com] > Sent: Monday, December 01, 1997 11:52 AM > To: ietf-ppp@merit.edu > Subject: Some Win95 PPP "How to?" questions > > Folks, > > I really, really, really do NOT want to start a flame war here. So please > take > 10 deep breaths before replying to this post. > > Over the last few days I've been getting some questions about how to do > some > things in Win95 PPP that I think are just not supported. However, I have > no way > of knowing whether something is not supported in the Win95 PPP > implementation > or whether I just do not know how to do it. Was hoping I could find out by > posting to this list. > > If there *IS* a way to do the following under Windows '95, would someone > please > tell me how to do it? > > - CHAP periodic rechallenge of Win95. It seems to me that Win '95 ignores > any > CHAP challenge sent to it after the authentication phase has completed. Is > there a way to enable Win '95 to be compliant with RFC 1994? > > - Win95 CHAP authentication of peer. I don't know of a way to get Win95 to > authenticate it's peer via CHAP (or PAP for that matter). Is this possible > or > does Win95 only provide for authentication of itself to the peer, not the > other > way around? > > - Win95 CHAP periodic rechallenge of peer. (If I can't get Win95 to issue > a > CHAP challenge, then I certainly don't know how to get it to periodically > rechallenge it's peer :-). > > Has anyone put together a list of what (otherwise mandated) portions of > the > RFC's are not supported in the Win95 PPP implementation? If so, I'd > appreciate > a pointer to it. > > Thanks, > -john martz, IBM AS/400 PPP development > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 2 15:35:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA17003; Tue, 2 Dec 1997 15:35:50 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 2 Dec 1997 15:30:09 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA16899 for ietf-ppp-outgoing; Tue, 2 Dec 1997 15:30:08 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA16892 for ; Tue, 2 Dec 1997 15:30:02 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id MAA15631; Tue, 2 Dec 1997 12:29:56 -0800 Received: from ascend.com by ascend.com with ESMTP id MAA06436; Tue, 2 Dec 1997 12:29:55 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id MAA02367; Tue, 2 Dec 1997 12:29:54 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id MAA13166; Tue, 2 Dec 1997 12:29:38 -0800 Date: Tue, 2 Dec 1997 12:29:38 -0800 Message-Id: <199712022029.MAA13166@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu CC: pppsdh@greendragon.com, Jeffrey Burgan , Thomas Narten Subject: Re: draft-ietf-pppext-sonet-ds-00.txt Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu I'd like to clear up some misunderstandings that have been voiced here over the last week or so. > For the record, consensus was achieved because there were no valid > technical objections raised. Being the chair, the task falls to me to make the final judgment as to whether consensus has been achieved. This would include reviewing the mailing list(s), plus possibly asking explicitly for dissenting votes or any last comments. However, in view of the scheduled "Packet Over SONET/SDH Examination BOF" in the OPS area next Wednesday at 1300-1500, and since it appears that Frame Relay over SONET suffers from exactly the same vulnerabilities as PPP over SONET, I can only conclude that this problem does not fall under our jurisdiction after all. It is a more generic "packet over SONET", or perhaps "HDLC over SONET" problem. If the folks at the BOF fail to or do not have the authority to make a decision, then whichever group decides such things will do so and the successor to RFC 1619 will refer to their new method. > I'll also point out that the PPPSDH mailing list is, as far as I can tell, > not at all under the charter of the PPP WG or any other IETF group. It's > simply a mailing list. I am to blame for failing to adequately publicize it; I should have announced it myself on the ietf-ppp mailing list after Bill's unofficial invitation, and I should have put it on the PPPEXT WG web page at http://www.ietf.org/html.charters/pppext-charter.html. Bill created the list last December after asking my permission. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 2 17:33:03 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAB19239; Tue, 2 Dec 1997 17:32:58 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 2 Dec 1997 17:31:26 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA19191 for ietf-ppp-outgoing; Tue, 2 Dec 1997 17:31:25 -0500 (EST) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA19187 for ; Tue, 2 Dec 1997 17:31:13 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA23213; Tue, 2 Dec 1997 14:31:09 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id OAA24700; Tue, 2 Dec 1997 14:27:22 -0800 Date: Tue, 2 Dec 1997 14:27:22 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: James Watt cc: ietf-ppp@merit.edu Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu James, I think the idea is that if I want to use LLC encapsulation between two devices I am free to do so if I am NOT doing Frame Relay interworking (point 2). Point 3 say if I am doing FRAME relay interworking then I must use LLC encapsulation. It is true that only the customer`s know. Both the local and remote systems using AAL5 must be compatibly configured. regards, Philip Rakity FlowPoint On Mon, 1 Dec 1997, James Watt wrote: > Folks: > I know we have been around this a few times but I'm afraid the > text we have in Section 4 may cause interoperability problems. > > Point (3) says: > > 3. If an implementation is connecting though a Frame Relay/ATM > FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, > then it MUST support LLC encapsulated PPP payloads. > > However, only the customer knows if this is true; the device > certainly doesn't. Thus, for interoperability it would seem I > would have to assume this is always true. > > However, point (2) says: > > 2. MAY use LLC encapsulated PPP payloads on PVCs as described in > section 6 below by mutual configuration or negotiation of both end > points. This technique is referred to as "LLC encapsulated PPP". > > Normally, point (2) would lead me to assume this is an optional > capability. However, given that only the customer can tell if point (3) > applies, point (3) suggests such support is mandatory. > > If it is mandatory, then we should say so, i.e. collapse points (2) and (3) > into one and say "it MUST ... in case the connection traverses..." > > Comments ? > -james > > ____________________________________________________________________________ > James W. Watt, jamesw@newbridge.com Ph: (613) 591-3600 > Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX: (613) > 591-3680 > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 00:43:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA24489; Wed, 3 Dec 1997 00:43:38 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 00:41:24 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA24457 for ietf-ppp-outgoing; Wed, 3 Dec 1997 00:41:23 -0500 (EST) Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA24453 for ; Wed, 3 Dec 1997 00:41:19 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.8.8/8.6.12) id AAA07176; Wed, 3 Dec 1997 00:39:59 -0500 (EST) Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma007155; Wed Dec 3 00:39:29 1997 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 3 Dec 1997 05:39:29 UT Received: (from smap@localhost) by ca.newbridge.com. (8.8.6/8.8.6) id AAA01340; Wed, 3 Dec 1997 00:39:29 -0500 (EST) Received: from popmail.ca.newbridge.com(138.120.118.14) by kanmaster.ca.newbridge.com via smap (V1.3) id sma001334; Wed Dec 3 00:39:03 1997 Received: from [138.120.55.57] by popmail.ca.newbridge.com (SMI-8.6/SMI-SVR4) id AAA00150; Wed, 3 Dec 1997 00:36:57 -0500 X-Sender: james@popmail.ca.newbridge.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Dec 1997 00:39:00 -0500 To: Philip Rakity From: James Watt Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt Cc: James Watt , ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu At 17:27 -0500 1997.12.02, Philip Rakity wrote: >James, > >I think the idea is that if I want to use LLC encapsulation between two >devices I am free to do so if I am NOT doing Frame Relay interworking >(point 2). +-------- I thought that was what we agreed to. However the text says "MUST support", not "MUST use". > >Point 3 say if I am doing FRAME relay interworking then I must use LLC >encapsulation. > >It is true that only the customer`s know. Both the local and remote >systems using AAL5 must be compatibly configured. +-------- Agreed. Perhaps all I'm hung up on is "implementation ... MUST support" vs "implementation ... MUST use", i.e. all implementations must be capable of doing both but points (1) through (3) control which method they use in various cases ? Thanks -james +-------- > >regards, > >Philip Rakity >FlowPoint > > >On Mon, 1 Dec 1997, James Watt wrote: > >> Folks: >> I know we have been around this a few times but I'm afraid the >> text we have in Section 4 may cause interoperability problems. >> >> Point (3) says: >> >> 3. If an implementation is connecting though a Frame Relay/ATM >> FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, >> then it MUST support LLC encapsulated PPP payloads. >> >> However, only the customer knows if this is true; the device >> certainly doesn't. Thus, for interoperability it would seem I >> would have to assume this is always true. >> >> However, point (2) says: >> >> 2. MAY use LLC encapsulated PPP payloads on PVCs as described in >> section 6 below by mutual configuration or negotiation of both end >> points. This technique is referred to as "LLC encapsulated PPP". >> >> Normally, point (2) would lead me to assume this is an optional >> capability. However, given that only the customer can tell if point (3) >> applies, point (3) suggests such support is mandatory. >> >> If it is mandatory, then we should say so, i.e. collapse points (2) and (3) >> into one and say "it MUST ... in case the connection traverses..." >> >> Comments ? >> -james >> >> ____________________________________________________________________________ >> James W. Watt, jamesw@newbridge.com Ph: (613) 591-3600 >> Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX: (613) >> 591-3680 >> >> ____________________________________________________________________________ James W. Watt, jamesw@newbridge.com Ph: (613) 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX: (613) 591-3680 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 02:40:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id CAA25323; Wed, 3 Dec 1997 02:40:52 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 02:40:14 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA25285 for ietf-ppp-outgoing; Wed, 3 Dec 1997 02:40:14 -0500 (EST) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA25281 for ; Wed, 3 Dec 1997 02:40:06 -0500 (EST) Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Wed, 03 Dec 1997 12:58:45 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id MAA15591 for ; Wed, 3 Dec 1997 12:41:35 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <3485CA31@msgate.future.futsoft.com>; Wed, 03 Dec 97 13:08:01 PST From: sunilkrd To: pppietf Subject: Padding when ECP On Bundle with DESE alg Date: Wed, 03 Dec 97 11:43:00 PST Message-Id: <3485CA31@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Hello, The rfc on DESE (all of them ?) state that DESE implementations should pad the datagrams to a multiple of 8 octets. This can be done by negotiating the LCP Self describing padding option on every link on which ECP is to be negotiated. However if ECP is to be negotiated on an MP bundle(80fd) with the DESE algorithm, there is no way to negotiate Padding on the bundle. How does the DESE algorithm work in such an implementation ? Regards, Sunil Kumar Reddy, (sunilkrd@future.futsoft.com) Future Software Pvt. Ltd. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 06:24:05 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id GAA26426; Wed, 3 Dec 1997 06:23:57 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 06:17:22 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id GAA26373 for ietf-ppp-outgoing; Wed, 3 Dec 1997 06:17:22 -0500 (EST) Received: from lynx.europe.shiva.com (lynx.europe.shiva.com [134.191.64.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id GAA26369 for ; Wed, 3 Dec 1997 06:17:16 -0500 (EST) Received: from chryses.europe.shiva.com (gerry@chryses.europe.shiva.com [89.0.0.223]) by lynx.europe.shiva.com (8.8.8/8.8.5) with ESMTP id LAA19179; Wed, 3 Dec 1997 11:16:39 GMT Received: from localhost (gerry@localhost) by chryses.europe.shiva.com (8.8.8/8.8.5) with SMTP id LAA29785; Wed, 3 Dec 1997 11:16:38 GMT Date: Wed, 3 Dec 1997 11:16:37 +0000 (GMT) From: Gerry Meyer To: sunilkrd cc: pppietf Subject: Re: Padding when ECP On Bundle with DESE alg In-Reply-To: <3485CA31@msgate.future.futsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Wed, 3 Dec 1997, sunilkrd wrote: > Hello, > The rfc on DESE (all of them ?) state that DESE implementations should > pad the datagrams to a multiple of 8 octets. This can be done by negotiating > the LCP Self describing padding option on every link on which ECP is to be > negotiated. > However if ECP is to be negotiated on an MP bundle(80fd) with the DESE > algorithm, there is no way to negotiate Padding on the bundle. How does the > DESE algorithm work in such an implementation ? LCP Self Describing Padding is not negotiated when using any of the encryption options (or not for any purpose related to encryption). The padding scheme is NOT separately negotiated - it is implicitly activated through the negotiation of the Encryption option itself (through ECP negotiation). draft-ietf-pppext-des-encrypt-v2-01.txt hopefully clarifies this in Section 6.1: 6.1. Padding Considerations Since the DES algorithm operates on blocks of 8 octets, plain text packets which are of length not a multiple of 8 octets must be padded. ...... Consequently, this specification requires that the unambiguous technique described below MUST be applied to ALL plain text packets. The method of padding is based on that described for the LCP Self- Describing-Padding (SDP) option (as defined in RFC 1570[4]), but differs in two respects: first, maximum-pad value is fixed to be 8, and second, the method is to be applied to ALL packets, not just "specifically identified protocols". ..... The padding operation described above is performed independently of whether or not the LCP Self-Describing-Padding (SDP) option has been negotiated. If it has, SDP would be applied to the packet as a whole after it had been ciphered and after the Encryption Protocol Identifiers had been prepended. Gerry - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 09:41:41 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA28331; Wed, 3 Dec 1997 09:41:40 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 09:40:57 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA28297 for ietf-ppp-outgoing; Wed, 3 Dec 1997 09:40:57 -0500 (EST) Received: from sw.microcom.com (sw.microcom.com [205.136.71.194]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA28293 for ; Wed, 3 Dec 1997 09:40:53 -0500 (EST) Received: from sw.microcom.com (root@localhost) by sw.microcom.com (8.7.5/8.7.3) with ESMTP id JAA27216 for ; Wed, 3 Dec 1997 09:40:03 -0500 (EST) Received: from mail.microcom.com ([207.31.204.10]) by sw.microcom.com (8.7.5/8.7.3) with ESMTP id JAA27212 for ; Wed, 3 Dec 1997 09:40:03 -0500 (EST) Received: from maloned.microcom.com ([192.77.183.152]) by mail.microcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA10198 for ; Wed, 3 Dec 1997 09:38:53 -0500 Message-ID: <34856FC6.149BC279@microcom.com> Date: Wed, 03 Dec 1997 09:42:15 -0500 From: "Dan Malone" Organization: Microcom Systems, Inc. X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: "'ietf_ppp'" Subject: Is there an IPCP extension negotiating Def Gateway Addr X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu All : Just a shot in the dark.. I have looked through all of the PPP related RFC's and RFC Drafts and have not been successful in finding anything relating to negotiation or just plain forwarding of a default gateway address. Is there an obscure RFC/draft that addresses this.. has there been any discussion relating to this type of scenario ?? Any information positive or negative would be greatly appreciated. best regards, Dan Malone malone@microcom.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 10:24:05 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA29045; Wed, 3 Dec 1997 10:24:05 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 10:23:39 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA29019 for ietf-ppp-outgoing; Wed, 3 Dec 1997 10:23:38 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA29015 for ; Wed, 3 Dec 1997 10:23:34 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20562; Wed, 3 Dec 1997 10:23:29 -0500 (EST) Message-Id: <199712031523.KAA20562@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-funi-03.txt Date: Wed, 03 Dec 1997 10:23:29 -0500 Sender: owner-ietf-ppp@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 : PPP Over FUNI Author(s) : M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross Filename : draft-ietf-pppext-funi-03.txt Pages : 10 Date : 02-Dec-97 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Frame User Network Interface (FUNI) for framing PPP encapsulated packets. Internet-Drafts are 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-funi-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-funi-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-funi-03.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971202095425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-funi-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-funi-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971202095425.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 11:05:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA29934; Wed, 3 Dec 1997 11:05:34 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 11:05:03 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA29900 for ietf-ppp-outgoing; Wed, 3 Dec 1997 11:05:02 -0500 (EST) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA29896 for ; Wed, 3 Dec 1997 11:04:57 -0500 (EST) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id IAA20430; Wed, 3 Dec 1997 08:04:55 -0800 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA14685; Wed, 3 Dec 1997 09:04:42 -0700 Date: Wed, 3 Dec 1997 09:04:42 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199712031604.JAA14685@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: re: Is there an IPCP extension negotiating Def Gateway Addr Cc: dmalone@microcom.com Sender: owner-ietf-ppp@merit.edu > From: "Dan Malone" > Just a shot in the dark.. I have looked through all of the PPP related > RFC's and RFC Drafts and have not been successful in finding anything > relating to negotiation or just plain forwarding of a default gateway > address. Is there an obscure RFC/draft that addresses this.. has there > been any discussion relating to this type of scenario ?? Any information > positive or negative would be greatly appreciated. That PPP has a bunch of negotiating machinery does not imply that absolutely everything must be negotiated by PPP. What is wrong with the Internet Router Discovery Protocol or RIP? For that matter, why not simply use the IP address of the peer determined during the IPCP negotiations? That this and similar questions (e.g. concerning DNS servers) keep coming up (and worse, getting mis-solved by various big outfits that do not understand IP, PPP, DNS, and the rest) says that there should be a PPP RFC that tells people what PPP is not. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 11:16:12 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA00231; Wed, 3 Dec 1997 11:16:12 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 11:15:52 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA00209 for ietf-ppp-outgoing; Wed, 3 Dec 1997 11:15:51 -0500 (EST) Received: from ub-gate.UB.com (ub-gate.UB.com [192.216.34.11]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA00205 for ; Wed, 3 Dec 1997 11:15:47 -0500 (EST) Received: from andr.ub.com. (sunny.andr.ub.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.9.1]) id AA24932; Wed, 3 Dec 97 08:15:00 PST Received: from ironbridge.andr.ub.com (ironbridge.andr.ub.com [138.120.246.66]) by andr.ub.com. (8.8.5/8.8.5) with SMTP id LAA16780; Wed, 3 Dec 1997 11:15:05 -0500 (EST) Received: by ironbridge.andr.ub.com (SMI-8.6/SMI-SVR4) id LAA20313; Wed, 3 Dec 1997 11:13:29 -0500 Date: Wed, 3 Dec 1997 11:13:29 -0500 Message-Id: <199712031613.LAA20313@ironbridge.andr.ub.com> From: James Carlson To: dmalone@microcom.com Cc: ietf-ppp@merit.edu In-Reply-To: <34856FC6.149BC279@microcom.com> (dmalone@microcom.com) Subject: Re: Is there an IPCP extension negotiating Def Gateway Addr References: <34856FC6.149BC279@microcom.com> Sender: owner-ietf-ppp@merit.edu > Just a shot in the dark.. I have looked through all of the PPP related > RFC's and RFC Drafts and have not been successful in finding anything > relating to negotiation or just plain forwarding of a default gateway > address. Is there an obscure RFC/draft that addresses this.. has there > been any discussion relating to this type of scenario ?? Any information > positive or negative would be greatly appreciated. I don't think it is at all necessary. If the PPP link is your only network link, then it is sufficient to treat the peer as the "default gateway." As far as you're concerned, the entire world lives on the other side of that PPP link. Thus gateway == remote address. If the PPP link isn't your only network link, then you'll need either static routes or participation in a regular routing protocol to establish routes (including a default route, if any). It's hard to see how a default gateway would be helpful here. (For the special case of a device with only a "local LAN" and a PPP link, again, the PPP link can be treated as in the first case; the remote peer is the gateway.) On the other hand, like name sever addresses (don't get me started on RFC 1877...), you can acquire a default gateway through BOOTP over PPP if you're sure you need one. -- James Carlson, Consulting Engineer IronBridge Networks / 5 Corporate Drive Vox: +1 978 691 4644 Andover MA 01810-2448 / USA Fax: +1 978 691 6300 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 13:08:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA02627; Wed, 3 Dec 1997 13:08:30 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 13:07:04 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA02592 for ietf-ppp-outgoing; Wed, 3 Dec 1997 13:07:04 -0500 (EST) Received: from sw.microcom.com (sw.microcom.com [205.136.71.194]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA02588 for ; Wed, 3 Dec 1997 13:06:58 -0500 (EST) Received: from sw.microcom.com (root@localhost) by sw.microcom.com (8.7.5/8.7.3) with ESMTP id NAA08672 for ; Wed, 3 Dec 1997 13:06:11 -0500 (EST) Received: from mail.microcom.com ([207.31.204.10]) by sw.microcom.com (8.7.5/8.7.3) with ESMTP id NAA08668 for ; Wed, 3 Dec 1997 13:06:11 -0500 (EST) Received: from maloned.microcom.com ([192.77.183.152]) by mail.microcom.com (Netscape Messaging Server 3.0) with ESMTP id AAA19106 for ; Wed, 3 Dec 1997 13:04:54 -0500 Message-ID: <34859FBD.56B19121@microcom.com> Date: Wed, 03 Dec 1997 13:06:54 -0500 From: "Dan Malone" Organization: Microcom Systems, Inc. X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: "'ietf_ppp'" Subject: re: Is there an IPCP extension negotiating Def Gateway Addr X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu All : To everyone who responded to my previous post (see below).. I was trying to solve a very specific problem and thought I may have missed something in my search. I am by NO means advocating we start a discussion that DGW addressing be included as an option to IPCP. I am network protocol savy enough to know there are well established ways of getting the DGW address and I fully agree it should NOT be part of IPCP. My intention was to check with the group to see if it had overlooked a discussion or implimentation because of RFC1877. Thanks to all who responded.. I will retreat to the cave to pursue another route to solve my problem ! Best regards, Dan Malone malone@microcom.com From: "Dan Malone" > Just a shot in the dark.. I have looked through all of the PPP related > RFC's and RFC Drafts and have not been successful in finding anything > relating to negotiation or just plain forwarding of a default gateway > address. Is there an obscure RFC/draft that addresses this.. has there > been any discussion relating to this type of scenario ?? Any information > positive or negative would be greatly appreciated. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 14:08:31 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA03962; Wed, 3 Dec 1997 14:08:31 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 14:07:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA03928 for ietf-ppp-outgoing; Wed, 3 Dec 1997 14:07:49 -0500 (EST) Received: from m3.sprynet.com (m3.sprynet.com [165.121.1.55]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA03924 for ; Wed, 3 Dec 1997 14:07:45 -0500 (EST) Received: from sprynet.com (sea3272.inhouse.compuserve.com [149.174.32.72]) by m3.sprynet.com (8.6.12/8.6.12) with ESMTP id LAA18476; Wed, 3 Dec 1997 11:13:07 -0800 Message-ID: <3485A0D0.36A6DB60@sprynet.com> Date: Wed, 03 Dec 1997 10:11:28 -0800 From: Kelly McGrew Reply-To: kelly@mcgrew.net Organization: The McGrew Family X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Dan Malone CC: "'ietf_ppp'" Subject: Re: Is there an IPCP extension negotiating Def Gateway Addr References: <34856FC6.149BC279@microcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Dan Malone wrote: > All : > > Just a shot in the dark.. I have looked through all of the PPP related > RFC's and RFC Drafts and have not been successful in finding anything > relating to negotiation or just plain forwarding of a default gateway > address. Is there an obscure RFC/draft that addresses this.. has there > been any discussion relating to this type of scenario ?? Any information > positive or negative would be greatly appreciated. > > best regards, > > Dan Malone malone@microcom.com RFC 1877, PPP Internet Protocol Control Protocol Extensions for Name Server Addresses, by S. Cobb of Microsoft is an Informational RFC which provides an IPCP mechanism to convey DNS primary and secondary addresses from a PPP server to a remote client. It also permits the assignment of primary and secondary NetBIOS Name Servers (aka WINS servers) to remote clients. Is this what you mean when you say "relating to negotiation or just plain forwarding of a default gateway address"? - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 17:45:29 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA09188; Wed, 3 Dec 1997 17:45:27 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 17:44:04 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA09145 for ietf-ppp-outgoing; Wed, 3 Dec 1997 17:44:03 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA09140 for ; Wed, 3 Dec 1997 17:43:51 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA28882; Wed, 3 Dec 1997 14:43:44 -0800 Received: from ascend.com by ascend.com with ESMTP id OAA20739; Wed, 3 Dec 1997 14:43:43 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA01822; Wed, 3 Dec 1997 14:43:42 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA21703; Wed, 3 Dec 1997 14:43:38 -0800 Date: Wed, 3 Dec 1997 14:43:38 -0800 Message-Id: <199712032243.OAA21703@gump.eng.ascend.com> From: Karl Fox To: Jeffrey Burgan , Thomas Narten Cc: ietf-ppp@merit.edu, Steve Coya Subject: PPP Triple-DES Encryption Protocol (3DESE) to Proposed Standard Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Jeff and Thomas, The PPPEXT Working Group recommends that The PPP Triple-DES Encryption Protocol (3DESE), draft-ietf-pppext-3des-encrypt-00.txt, be advanced to Informational Standard. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 19:31:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA10921; Wed, 3 Dec 1997 19:31:08 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 19:29:55 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA10876 for ietf-ppp-outgoing; Wed, 3 Dec 1997 19:29:54 -0500 (EST) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA10872 for ; Wed, 3 Dec 1997 19:29:50 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA298; Wed, 3 Dec 1997 16:29:41 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id QAA15310; Wed, 3 Dec 1997 16:25:54 -0800 Date: Wed, 3 Dec 1997 16:25:54 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: Vernon Schryver cc: ietf-ppp@merit.edu, dmalone@microcom.com Subject: re: Is there an IPCP extension negotiating Def Gateway Addr In-Reply-To: <199712031604.JAA14685@mica.denver.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Vernon, There is no IP address of the peer if the link is unnumbered nor do most ISPs respond to RIP regards, Philip Rakity On Wed, 3 Dec 1997, Vernon Schryver wrote: > > From: "Dan Malone" > > > Just a shot in the dark.. I have looked through all of the PPP related > > RFC's and RFC Drafts and have not been successful in finding anything > > relating to negotiation or just plain forwarding of a default gateway > > address. Is there an obscure RFC/draft that addresses this.. has there > > been any discussion relating to this type of scenario ?? Any information > > positive or negative would be greatly appreciated. > > That PPP has a bunch of negotiating machinery does not imply that > absolutely everything must be negotiated by PPP. What is wrong with > the Internet Router Discovery Protocol or RIP? For that matter, why > not simply use the IP address of the peer determined during the IPCP > negotiations? > > That this and similar questions (e.g. concerning DNS servers) keep > coming up (and worse, getting mis-solved by various big outfits that do > not understand IP, PPP, DNS, and the rest) says that there should be a > PPP RFC that tells people what PPP is not. > > > Vernon Schryver, vjs@sgi.com > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 19:42:08 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA11073; Wed, 3 Dec 1997 19:42:07 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 19:41:54 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA11048 for ietf-ppp-outgoing; Wed, 3 Dec 1997 19:41:53 -0500 (EST) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id TAA11044 for ; Wed, 3 Dec 1997 19:41:48 -0500 (EST) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id QAA04789; Wed, 3 Dec 1997 16:41:45 -0800 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id RAA16103; Wed, 3 Dec 1997 17:41:36 -0700 Date: Wed, 3 Dec 1997 17:41:36 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199712040041.RAA16103@mica.denver.sgi.com> To: dmalone@microcom.com, ietf-ppp@merit.edu Subject: re: Is there an IPCP extension negotiating Def Gateway Addr Sender: owner-ietf-ppp@merit.edu > From: Philip Rakity > There is no IP address of the peer if the link is unnumbered nor do most > ISPs respond to RIP Please recall the old and neverending IPCP address negotiation discussions. Please name two PPP implementations that really run the link unnumbered, which is to say that they do not (eventually) send an IPCP Configure-Request containing their own IP address. As James said, that IP address can almost always be used as a de facto default IP route. From what I've seen, most PPP boxes used in situations where the PPP peer needs an IP gateway address do understand RIP, albeit often less than perfectly. Even bridges can be said to understand RIP since they will blindly forward RIP broadcasts and multicasts. It is fairly common for ISP's to send RIP default routes over PPP links just in case the peer needs one. It is true that most ISP's don't care to play RIP with their customers, but they generally do like to play IPCP Address games. > ... > > That this and similar questions (e.g. concerning DNS servers) keep > > coming up (and worse, getting mis-solved by various big outfits that do > > not understand IP, PPP, DNS, and the rest) says that there should be a > > PPP RFC that tells people what PPP is not. We really need an RFC that points out that practically no IP/PPP link in the real world is completely unnumbered, and that the peer's IP address is usually the right answer for synthesizing a static default route and even for sending UDP packets to port 53. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 20:01:16 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA11293; Wed, 3 Dec 1997 20:01:16 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 20:00:47 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA11271 for ietf-ppp-outgoing; Wed, 3 Dec 1997 20:00:46 -0500 (EST) Received: from vandys-pc.cisco.com (vandys-pc.cisco.com [171.69.51.26]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA11267 for ; Wed, 3 Dec 1997 20:00:42 -0500 (EST) Received: (from vandys@localhost) by vandys-pc.cisco.com (8.8.5/8.8.5) id RAA04413; Wed, 3 Dec 1997 17:00:09 -0800 (PST) Date: Wed, 3 Dec 1997 17:00:09 -0800 (PST) From: Andy Valencia Message-Id: <199712040100.RAA04413@vandys-pc.cisco.com> To: pmr@flowpoint.com Cc: ietf-ppp@merit.edu Subject: Re: Is there an IPCP extension negotiating Def Gateway Addr References: <199712031604.JAA14685@mica.denver.sgi.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-ietf-ppp@merit.edu >There is no IP address of the peer if the link is unnumbered nor do most >ISPs respond to RIP Yes, but since it's not like you need to ARP on a PPP link, so what? You know that your default route is out the PPP link, and that's all you *need* to know. Andy Valencia - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 3 20:18:13 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA11529; Wed, 3 Dec 1997 20:18:12 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Dec 1997 20:17:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA11500 for ietf-ppp-outgoing; Wed, 3 Dec 1997 20:17:49 -0500 (EST) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA11496 for ; Wed, 3 Dec 1997 20:17:44 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA1722; Wed, 3 Dec 1997 17:17:21 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id RAA20310; Wed, 3 Dec 1997 17:13:30 -0800 Date: Wed, 3 Dec 1997 17:13:30 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: Andy Valencia cc: ietf-ppp@merit.edu Subject: Re: Is there an IPCP extension negotiating Def Gateway Addr In-Reply-To: <199712040100.RAA04413@vandys-pc.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Andy, You are absolutely right, but I was answering Vernon's point about RIP or using the IPCP address passed by the ISP. Philip On Wed, 3 Dec 1997, Andy Valencia wrote: > >There is no IP address of the peer if the link is unnumbered nor do most > >ISPs respond to RIP > > Yes, but since it's not like you need to ARP on a PPP link, so what? You > know that your default route is out the PPP link, and that's all you *need* > to know. > > Andy Valencia > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 03:48:24 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id DAA16858; Thu, 4 Dec 1997 03:48:22 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 03:45:13 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA16827 for ietf-ppp-outgoing; Thu, 4 Dec 1997 03:45:12 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA16820 for ; Thu, 4 Dec 1997 03:45:08 -0500 (EST) Received: from nisms (nisms.tei.ericsson.se [141.137.75.1]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/glacier-1.12) with SMTP id JAA19998 for ; Thu, 4 Dec 1997 09:45:04 +0100 (MET) Received: from rd.tei.ericsson.se ([141.137.74.114]) by nisms (4.1/LME-2.2.1) id AA17091; Thu, 4 Dec 97 09:45:37 +0100 Message-Id: <34866DA5.5F5E9E7E@rd.tei.ericsson.se> Date: Thu, 04 Dec 1997 09:45:25 +0100 From: Giorgio Andreoli Organization: Ericsson X-Mailer: Mozilla 4.03 [en] (Win95; I) Mime-Version: 1.0 To: ietf-ppp@merit.edu Subject: PPTP for Unix Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi, in the latest draft (v3.0) of ADSL Forum SNAG white paper it is mentioned that PPTP is also available for Unix OSs: may anyone please give me more information on the subject? (I apologize if this is not the right mailing list to post requests of information for PPTP products but I don't know how to join PPTP lists...) Regards, Giorgio - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 04:04:04 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA16996; Thu, 4 Dec 1997 04:04:03 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 04:01:47 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA16948 for ietf-ppp-outgoing; Thu, 4 Dec 1997 04:01:46 -0500 (EST) Received: from djwhome.demon.co.uk (root@djwhome.demon.co.uk [158.152.19.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA16944 for ; Thu, 4 Dec 1997 04:01:41 -0500 (EST) Received: (from david@localhost) by djwhome.demon.co.uk (8.8.8/8.7.3) id IAA00798; Tue, 2 Dec 1997 08:18:07 GMT From: David Woolley Message-Id: <199712020818.IAA00798@djwhome.demon.co.uk> Subject: Re: Some Win95 PPP "How to?" questions To: jmartz@us.ibm.com (John Martz) Date: Tue, 2 Dec 1997 08:18:05 +0000 (GMT) Cc: ietf-ppp@merit.edu In-Reply-To: <5010400015322855000003L053*@MHS> from "John Martz" at Dec 1, 97 02:52:31 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > > Has anyone put together a list of what (otherwise mandated) portions of the > RFC's are not supported in the Win95 PPP implementation? If so, I'd appreciate > a pointer to it. I can't remember whether it is Win 95 and or NT, and which NT, but the IPX routing protocol negotiation is highly suspect. There seems to be a problem in this area anyway as the specs seem to be too open to interpretation. (The Linux implementation went round in several circles and I don't think it yet agrees with my interpretation, but I think it now interworks with Microsoft and itself, which probably covers most people's wants.) I'd have to search back to find the exact details, but it was to do with unsupported protocols and/or multiple options. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 09:55:43 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA19511; Thu, 4 Dec 1997 09:55:40 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 09:45:35 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA19343 for ietf-ppp-outgoing; Thu, 4 Dec 1997 09:45:35 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA19336 for ; Thu, 4 Dec 1997 09:45:30 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15845; Thu, 4 Dec 1997 09:45:20 -0500 (EST) Message-Id: <199712041445.JAA15845@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-eapdss-01.txt Date: Thu, 04 Dec 1997 09:45:20 -0500 Sender: owner-ietf-ppp@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 : PPP EAP DSS Public Key Authentication Protocol Author(s) : J. Zmuda, W. Nace Filename : draft-ietf-pppext-eapdss-01.txt Pages : 13 Date : 03-Dec-97 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. PPP Extensible Authentication Protocol (EAP) [2] provides for a number of authentication mechanisms. This document specifies yet another authentication mechanism that may be used within the EAP framework. This document defines the DSS Public Key Authentication Protocol within PPP EAP. Internet-Drafts are 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-eapdss-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eapdss-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eapdss-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971203153841.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eapdss-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eapdss-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971203153841.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 09:59:15 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA19593; Thu, 4 Dec 1997 09:59:15 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 09:57:35 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA19549 for ietf-ppp-outgoing; Thu, 4 Dec 1997 09:57:34 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA19545 for ; Thu, 4 Dec 1997 09:57:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16220; Thu, 4 Dec 1997 09:57:27 -0500 (EST) Message-Id: <199712041457.JAA16220@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-crtxchg-01.txt Date: Thu, 04 Dec 1997 09:57:26 -0500 Sender: owner-ietf-ppp@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 : PPP Certificate Exchange Protocol Author(s) : J. Zmuda, W. Nace Filename : draft-ietf-pppext-crtxchg-01.txt Pages : 16 Date : 03-Dec-97 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. The Certificate exchange protocol is an extension to PPP that is in the form of an additional phase, called the certificate exchange phase, that would allow for a PPP entity to request certificates from a peer. If configured, this phase would be negotiated during the LCP exchange. This exchange of certificates is aimed at easing configuration issues by providing for the exchange of certificate path information in a standard manner across different strong, or public-key certificate-based, authentication protocols. The certificate exchange protocol accomodates arbitrary sized certificates. Internet-Drafts are 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-crtxchg-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-crtxchg-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-crtxchg-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971203154307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-crtxchg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-crtxchg-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971203154307.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 09:55:44 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA19507; Thu, 4 Dec 1997 09:55:40 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 09:51:56 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA19440 for ietf-ppp-outgoing; Thu, 4 Dec 1997 09:51:56 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA19436 for ; Thu, 4 Dec 1997 09:51:50 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16050; Thu, 4 Dec 1997 09:51:46 -0500 (EST) Message-Id: <199712041451.JAA16050@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-feep-01.txt Date: Thu, 04 Dec 1997 09:51:46 -0500 Sender: owner-ietf-ppp@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 : PPP Fortezza Encryption Encapsulation Protocol Author(s) : J. Zmuda, W. Nace Filename : draft-ietf-pppext-feep-01.txt Pages : 12 Date : 03-Dec-97 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. One of the Authentication protocols that can be negotiated is the EAP. The EAP can be used in any of a number of variants. When the EAP is used in it's KEA variant, this results in mutual authentication and key generation. This key is available for use during the PPP data transfer phase by an encryption encapsulation. The encryption encapsulation that is described in this memo is one possible encapsulation that can use the keying material generated by the EAP KEA protocol. Internet-Drafts are 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-feep-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-feep-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-feep-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971203154932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-feep-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-feep-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971203154932.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 10:07:06 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA19735; Thu, 4 Dec 1997 10:07:06 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 10:05:30 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA19682 for ietf-ppp-outgoing; Thu, 4 Dec 1997 10:05:30 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA19677 for ; Thu, 4 Dec 1997 10:05:25 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA16447; Thu, 4 Dec 1997 10:05:21 -0500 (EST) Message-Id: <199712041505.KAA16447@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-eapkea-01.txt Date: Thu, 04 Dec 1997 10:05:21 -0500 Sender: owner-ietf-ppp@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 : PPP EAP KEA Public Key Authentication Protocol Author(s) : P. Yee, J. Zmuda, W. Nace Filename : draft-ietf-pppext-eapkea-01.txt Pages : 18 Date : 03-Dec-97 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. PPP Extensible Authentication Protocol (EAP) [2] provides for a number of authentication mechanisms. This document specifies yet another authentication mechanism that may be used within the EAP framework. This document defines the KEA Public Key Authentication Protocol within PPP EAP. A side effect of KEA public key authentication is the creation of a session key for encryption of data on the PPP link. Internet-Drafts are 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-eapkea-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eapkea-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eapkea-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971203154613.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eapkea-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eapkea-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971203154613.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 10:13:38 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA19826; Thu, 4 Dec 1997 10:13:38 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 10:12:07 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA19787 for ietf-ppp-outgoing; Thu, 4 Dec 1997 10:12:07 -0500 (EST) Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA19783 for ; Thu, 4 Dec 1997 10:12:01 -0500 (EST) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id KAA24303; Thu, 4 Dec 1997 10:08:38 -0500 Received: from spice.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id KAA21291; Thu, 4 Dec 1997 10:10:59 -0500 Received: from localhost by spice.cascade (SMI-8.6/SMI-SVR4) id KAA01344; Thu, 4 Dec 1997 10:10:59 -0500 Date: Thu, 4 Dec 1997 10:10:58 -0500 (EST) From: "Andrew G. Malis" X-Sender: amalis@spice To: James Watt cc: Philip Rakity , ietf-ppp@merit.edu Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu James, The intent was that implementations may, but are not required, to support LLC encapsulation. However, going through an FRF.8 service interworking unit requires the use of LLC encapsulation. Thus, only implementations that support LLC encapsulation may utilize service interworking. Since service interworking is (at least currently) for PVCs only, this all has to be configured manually. In point 3, changing "MUST support" to "MUST use" is fine with me. Cheers, Andy - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 17:56:50 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA28211; Thu, 4 Dec 1997 17:56:50 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 17:55:05 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA28166 for ietf-ppp-outgoing; Thu, 4 Dec 1997 17:55:04 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA28161 for ; Thu, 4 Dec 1997 17:54:59 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id OAA05375 for ; Thu, 4 Dec 1997 14:54:58 -0800 Received: from ascend.com by ascend.com with ESMTP id OAA27146 for ; Thu, 4 Dec 1997 14:54:54 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id OAA28319 for ; Thu, 4 Dec 1997 14:54:45 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id OAA27987 for ; Thu, 4 Dec 1997 14:54:33 -0800 Date: Thu, 4 Dec 1997 14:54:33 -0800 Message-Id: <199712042254.OAA27987@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu Subject: 40th IETF PPPEXT Working Group Agenda (Final. Really!) Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu PPP Extensions Working Group 40th IETF Washington, D.C. Monday, December 8 at 0930-1130 (opposite calsch, pktway, mboned, manet, pkix, tcpsat, intserv) Tuesday, December 9 at 1015-1115 (opposite rip, webdav, dhc, ulp-BOF, 2000, rap, mboned) The PPP over SONET/SDH discussion has been moved to OPS/posse/Packet Over SONET/SDH Examination BOF Wednesday, December 10 at 1300-1500 (opposite ipp, ldapext, dhc, roamops, ospf, smime, avt) Agenda Monday, December 8 at 0930-1130 The PPP Triple-DES Encryption Protocol (3DESE) draft-ietf-pppext-3des-encrypt-00.txt Draft Status [Announcement] PPP over AAL5 draft-ietf-pppext-aal5-03.txt Draft Status [Announcement] PPP over FUNI draft-ietf-pppext-funi-03.txt Draft Status [Announcement] PPP LCP Extensions draft-ietf-pppext-lcpext-ds-02.txt Draft Status [Announcement] PPP LCP CallBack draft-ietf-pppext-callback-ds-01.txt Call for Interoperability Experience [Announcement] PPP LCP Self Describing Padding draft-ietf-pppext-padding-ds-00.txt Call for Interoperability Experience [Announcement] Multi-link Multi-node PPP draft-ietf-pppext-mmp-discovery-00.txt Gary Malkin [20 minutes] Next CIUG Interoperability Workshop week of Feb. 23rd Anita Freeman [5 minutes] PPP Consistent Overhead Byte Stuffing (COBS) draft-ietf-pppext-cobs-00.txt James Carlson Stuart Cheshire [25 minutes] L2TP MIB draft-ietf-pppext-l2tp-mib-00.txt Pat Calhoun [10 minutes] L2TP Security Extensions for Non-IP networks draft-ietf-pppext-l2tp-sec-02.txt Pat Calhoun [10 minutes] L2TP draft-ietf-pppext-l2tp-08.txt William Mark Townsley [10 minutes] L2TP Header compression draft-ietf-pppext-l2tphc-00.txt William Mark Townsley [10 minutes] L2TP Alternate Data Channel draft-ietf-pppext-l2tpadc-00.txt Bill Palter [10 minutes] Securing L2TP using IPSEC draft-ietf-pppext-l2tp-security-00.txt Baiju Patel [20 minutes] Tuesday, December 9 at 1015-1115 PPP EAP TLS Authentication Protocol draft-ietf-pppext-eaptls-02.txt Bernard Aboba [10 minutes] PPP with Framing Conversion draft-ietf-pppext-conversion-00.txt Bill Simpson [20 minutes] PPP in Frame Relay draft-ietf-pppext-framerelay-ds-00.txt Bill Simpson [5 minutes] PPP in X.25 draft-ietf-pppext-x25-ds-00.txt Bill Simpson [5 minutes] PPP for Asynchronous PAD to Synchronous X.25 access draft-rfced-info-khana-01.txt Bill Simpson [5 minutes] -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 18:12:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA28479; Thu, 4 Dec 1997 18:12:55 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 18:12:18 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA28447 for ietf-ppp-outgoing; Thu, 4 Dec 1997 18:12:17 -0500 (EST) Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1]) by merit.edu (8.8.7/8.8.5) with SMTP id SAA28442 for ; Thu, 4 Dec 1997 18:12:12 -0500 (EST) To: "Andrew G. Malis" , James Watt Cc: Philip Rakity , ietf-ppp@merit.edu, gmg@garage.lucent.com Received: from garage.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id SAA07610; Thu, 4 Dec 1997 18:20:21 -0500 Received: by garage.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id SAA03864; Thu, 4 Dec 1997 18:09:23 -0500 Date: Thu, 4 Dec 1997 18:09:23 -0500 Message-Id: <199712042309.SAA03864@garage.lucent.com> From: gmg@garage.lucent.com (garage!gmg) Original-To: "Andrew G. Malis" , James Watt Original-Cc: Philip Rakity , ietf-ppp@merit.edu, gmg@garage.lucent.com Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, I share the concern that has been expressed about the text in section 4 point 3. At the very least I will revise it in ID version 4 to say "MUST use" instead of "MUST support". Although I'd rather not re-visit all the ground we covered on this topic earlier this year back in April, it seems to me that more clarification is needed in this part of the ID. Here's my shot at revising point 3's text: 3. If an implementation is connecting through a Frame Relay/ATM FRF.8 service inter-working unit to an RFC 1973 end point, then it MUST use LLC-encapsulated PPP payloads. An implementation that elects to inter-operate with all prospective end points MUST implement both VC-multiplexed PPP payloads and LLC-encapsulated payloads. The intent of point 3 is say that those end points that *choose* to inter-work with an RFC1973/FRF.8 service MUST be prepared to accept LLC- encapsulated PPP. By implication, the ID allows a RFC1973/FRF.8 IWF end point to support *only* LLC-encapsulated PPP and not VC-mux'ed PPP. This is effectively an exception to point 1, which says you MUST support VC-mux'ed PPP. So inter-working with a RFC1973/FRF.8 service end point reduces to two cases: a) When administering an AAL5 PVC, choose the same PPP technique at both end points. Some FRF.8/ATM IWF units MAY support VC-mux'ed PPP, but all MUST support LLC-encapsulated PPP. As a consequence, if you want to inter-operate with _all_ potential PPP over AAL5 end points, you MUST implement LLC-encapsulated PPP. b) If negotiating an AAL5 SVC, then the discussion in section 7 applies. Unfortunately, there is the SVC case of an originating end point that offers only VC-mux'd PPP to an RFC1973/FRF.8 end point that wants to accept only LLC-encapsulated PPP. The FRF.8/ATM IWF unit will refuse the call. They will *not* inter-operate. Of course if the FRF.8/ATM IWF is clever, both SVC end points MAY agree to do VC-mux'ed PPP instead of LLC-encapsulated PPP. Bottom line: the current ID text leaves the following question unanswered: ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF *mandatory* for compliance with this spec? Or is it optional? Please tell me your preference. BTW, I should point out that the recent exchanges on the PPP list about "active" versus "passive" bridging convertors are directly applicable to this situation. When handling PPP sessions, the existing FRF.8 IWF is strictly a "passive" FR/ATM bridging convertor, and so it will fall into the same inter-operability problems that have been identified with that implementation choice as were discussed for other media. George Gross - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 4 21:02:38 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA00753; Thu, 4 Dec 1997 21:02:33 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 4 Dec 1997 21:01:51 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA00723 for ietf-ppp-outgoing; Thu, 4 Dec 1997 21:01:49 -0500 (EST) Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA00718 for ; Thu, 4 Dec 1997 21:01:42 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.8.8/8.6.12) id VAA13009; Thu, 4 Dec 1997 21:00:53 -0500 (EST) Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma012980; Thu Dec 4 21:00:30 1997 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 5 Dec 1997 02:00:30 UT Received: (from smap@localhost) by ca.newbridge.com. (8.8.6/8.8.6) id VAA05105; Thu, 4 Dec 1997 21:00:29 -0500 (EST) Received: from popmail.ca.newbridge.com(138.120.118.14) by kanmaster.ca.newbridge.com via smap (V1.3) id sma005085; Thu Dec 4 21:00:24 1997 Received: from [138.120.55.57] by popmail.ca.newbridge.com (SMI-8.6/SMI-SVR4) id UAA25674; Thu, 4 Dec 1997 20:58:16 -0500 X-Sender: james@popmail.ca.newbridge.com (Unverified) Message-Id: In-Reply-To: <199712042309.SAA03864@garage.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Dec 1997 20:59:24 -0500 To: gmg@garage.lucent.com (garage!gmg) From: James Watt Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt Cc: "Andrew G. Malis" , Philip Rakity , ietf-ppp@merit.edu, gmg@garage.lucent.com Sender: owner-ietf-ppp@merit.edu At 18:09 -0500 1997.12.04, garage!gmg wrote: >... >3. If an implementation is connecting through a Frame Relay/ATM FRF.8 > service inter-working unit to an RFC 1973 end point, then it MUST > use LLC-encapsulated PPP payloads. An implementation that elects > to inter-operate with all prospective end points MUST implement both > VC-multiplexed PPP payloads and LLC-encapsulated payloads. +------ This looks good by me and clarifies the ambiguity that was of concern. +-------- >Bottom line: the current ID text leaves the following question unanswered: > > ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF >*mandatory* for > compliance with this spec? Or is it optional? Please tell me your > preference. +-------- For the most basic of reasons, i.e. that both RFC 1973 and FRF.* already exist, I would suggest that interoperability is mandatory. Regards, -james ____________________________________________________________________________ James W. Watt, jamesw@newbridge.com Ph: (613) 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX: (613) 591-3680 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 5 04:51:05 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA04540; Fri, 5 Dec 1997 04:51:04 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 5 Dec 1997 04:50:08 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA04513 for ietf-ppp-outgoing; Fri, 5 Dec 1997 04:50:08 -0500 (EST) Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by merit.edu (8.8.7/8.8.5) with SMTP id EAA04507 for ; Fri, 5 Dec 1997 04:50:03 -0500 (EST) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id EAA01692; Fri, 5 Dec 1997 04:47:01 -0500 Received: from amalis.casc.com by casc.com (SMI-8.6/SMI-SVR4-bob.2) id EAA27083; Fri, 5 Dec 1997 04:49:19 -0500 Message-Id: <3.0.3.32.19971205044747.00771d40@152.148.10.6> X-Sender: amalis@152.148.10.6 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 05 Dec 1997 04:47:47 -0500 To: James Watt From: "Andrew G. Malis" Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt Cc: gmg@garage.lucent.com (garage!gmg), "Andrew G. Malis" , Philip Rakity , ietf-ppp@merit.edu, gmg@garage.lucent.com In-Reply-To: References: <199712042309.SAA03864@garage.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu James, >+-------- >>Bottom line: the current ID text leaves the following question unanswered: >> >> ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF >>*mandatory* for >> compliance with this spec? Or is it optional? Please tell me your >> preference. >+-------- >For the most basic of reasons, i.e. that both RFC 1973 and FRF.* already exist, >I would suggest that interoperability is mandatory. I disagree. The primary (although certainly not the only) application for this specification is for use with ADSL. For that particular application, interoperation with PPP over FR is of no interest whatsover, and the ability to do so should not be required in order to have a compliant implementation of this spec. HOWEVER, for other applications, the ability to interoperate may certainly make sense, and vendors will find it in their competitive interest to include the ability to do so. We can discuss this further in the WG meeting. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 5 07:07:28 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA05432; Fri, 5 Dec 1997 07:07:16 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 5 Dec 1997 07:01:10 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA05379 for ietf-ppp-outgoing; Fri, 5 Dec 1997 07:01:10 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id HAA05372 for ; Fri, 5 Dec 1997 07:01:04 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id EAA04193 for ; Fri, 5 Dec 1997 04:01:02 -0800 Received: from ascend.com by ascend.com with ESMTP id EAA10972 for ; Fri, 5 Dec 1997 04:01:02 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id EAA10945 for ; Fri, 5 Dec 1997 04:01:01 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id EAA01554 for ; Fri, 5 Dec 1997 04:00:59 -0800 Date: Fri, 5 Dec 1997 04:00:59 -0800 Message-Id: <199712051200.EAA01554@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu Subject: The PPP DES Encryption Protocol, Version 2 (DESE-bis) - Working Group Last Call Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu This is last call. I will advise the area directors that we want to take The PPP DES Encryption Protocol, Version 2 (DESE-bis) (draft-ietf-pppext-des-encrypt-v2-01.txt) to Informational Standard on December 19 unless there is substantive comment raised on the list. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 5 10:18:14 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA07732; Fri, 5 Dec 1997 10:16:49 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 5 Dec 1997 10:15:33 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA07672 for ietf-ppp-outgoing; Fri, 5 Dec 1997 10:15:32 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA07664 for ; Fri, 5 Dec 1997 10:15:26 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA13835; Fri, 5 Dec 1997 10:15:22 -0500 (EST) Message-Id: <199712051515.KAA13835@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-security-00.txt Date: Fri, 05 Dec 1997 10:15:21 -0500 Sender: owner-ietf-ppp@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 : Securing L2TP using IPSEC Author(s) : B. Aboba, B. Patel Filename : draft-ietf-pppext-l2tp-security-00.txt Pages : 14 Date : 04-Dec-97 This document discusses how L2TP may utilize IPSEC to provide for tun- nel authentication, privacy protection, integrity check and replay protection. Both the voluntary and compulsory tunneling cases are dis- cussed. Internet-Drafts are 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-l2tp-security-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-security-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-security-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971204105052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-security-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-security-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204105052.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 5 15:42:50 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA14096; Fri, 5 Dec 1997 15:42:49 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 5 Dec 1997 15:41:24 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA14056 for ietf-ppp-outgoing; Fri, 5 Dec 1997 15:41:23 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA14052 for ; Fri, 5 Dec 1997 15:41:18 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA24997; Fri, 5 Dec 1997 15:41:14 -0500 (EST) Message-Id: <199712052041.PAA24997@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-crtxchg-01.txt Date: Fri, 05 Dec 1997 15:41:13 -0500 Sender: owner-ietf-ppp@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 : PPP Certificate Exchange Protocol Author(s) : J. Zmuda, W. Nace Filename : draft-ietf-pppext-crtxchg-01.txt Pages : 16 Date : 03-Dec-97 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication of its peer before allowing Network Layer protocols to transmit over the link. The Certificate exchange protocol is an extension to PPP that is in the form of an additional phase, called the certificate exchange phase, that would allow for a PPP entity to request certificates from a peer. If configured, this phase would be negotiated during the LCP exchange. This exchange of certificates is aimed at easing configuration issues by providing for the exchange of certificate path information in a standard manner across different strong, or public-key certificate-based, authentication protocols. The certificate exchange protocol accomodates arbitrary sized certificates. Internet-Drafts are 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-crtxchg-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-crtxchg-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-crtxchg-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971203154307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-crtxchg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-crtxchg-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971203154307.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 9 18:53:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA06391; Tue, 9 Dec 1997 18:53:17 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 9 Dec 1997 18:45:08 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA06277 for ietf-ppp-outgoing; Tue, 9 Dec 1997 18:45:08 -0500 (EST) Received: from dogwood-fddi.cisco.com (dogwood-fddi.cisco.com [171.68.122.80]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA06270 for ; Tue, 9 Dec 1997 18:45:02 -0500 (EST) Received: from chsharp-pc.cisco.com (sj-dial-3-12.cisco.com [171.68.179.13]) by dogwood-fddi.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id SAA27050 for ; Tue, 9 Dec 1997 18:44:27 -0500 (EST) Message-Id: <3.0.3.32.19971209115254.0071ffd8@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 09 Dec 1997 11:52:54 -0500 To: ietf-ppp@merit.edu From: Chip Sharp Subject: Comments on PPP Conversion draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu General --------- I support the designation of this as a BCP. There is ambiguity in the definition of converter. This is understandable considering the proliferation of converter types in the field. There needs to be a distinction between conversion and rate adaptation (e.g., V.120, V.110, etc.). There seem to be many that don't understand this distinction. A converter must take some active role in the handling of HDLC and/or PPP (even if it is passive). The draft is fairly vague about the failure modes of converters. Some explicit examples would be appreciated. Passive Converter ----------------- To what level does a passive converter interact with PPP or HDLC? For example, for asynch-synch conversion is it assumed that a passive converter terminate HDLC on the asynch side and regenerate it on the synch side? It would be clearer if an explicit example is given of a failure mode. In the fourth multiline paragraph, it isn't clear what model you are using. I assume this is a "low-speed" asynch to "high-speed" synch converter. An explicit example of options that fail would illustrate the problem better. Since the passive converter is not explicitly defined, it is unclear what is being deprecated. Active Converter ---------------- It seems that an active converter does more than intercept and examine LCP messages. It must actively participate in LCP messages, modifying and/or adding options. This is implied in the first paragraph, but not clearly stated. In addition, it must also perform operations on the actual data stream. In the last paragraph of this section, it ight be useful to state that ineffectual options should not be propogated. Multilink --------- I can't support this section as written. There are many asynch-to-synch PPP converters on the market that work fairly well. They are much preferable to running V.120 over multiple links. Therefore, the multilink section must be reworded to reflect this fact. If this is a BCP, then it should reflect the best current practice of doing single link to multilink conversion on an asynch-to-synch converter. If you wish, you could state that the use of single-link to multi-link conversion is outside the scope of the document. Chip -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng -ISP/Telco -------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 11 04:24:36 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA00677; Thu, 11 Dec 1997 04:24:18 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Dec 1997 04:16:53 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA00530 for ietf-ppp-outgoing; Thu, 11 Dec 1997 04:16:52 -0500 (EST) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA00519 for ; Thu, 11 Dec 1997 04:16:38 -0500 (EST) Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 11 Dec 1997 14:34:32 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id OAA07361 for ; Thu, 11 Dec 1997 14:20:51 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <34906C95@msgate.future.futsoft.com>; Thu, 11 Dec 97 14:43:33 PST From: shenoyh To: PPPMailing-List Subject: MP+ Protocol doubt... Date: Thu, 11 Dec 97 14:36:00 PST Message-Id: <34906C95@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Hi, On page 7, rfc1934 (Multilink Protocol Plus), the error control procedure table shows a state * Start * to which transition takes place on the reception of a few events such as Received ACK_MSG in the Idle state. This Start state is however not listed in the table itself, nor is it explained subsequently. Has the start state been missed out from the table ? Or does it imply remaining in the same state ? Could anyone please help us on this ? Is there any material available other than rfc1934 on MP Plus ? Does anyone know if an update to the rfc 1934 is in the pipeline or any drafts regarding the same are available ? In addition to the above, the rfc has a few other inconsistencies such as : The abscence of description on who sends (or when) a MP_PLUS_CLEAR_REQUEST (though the reception of such an event is explained, no where in the rfc is the transmission of such a request described ). Also the "frame reteransmit timer" in the Error Control layer's State Event diagram has no explanation whatsoever. Thanx in advance, Regards, Shenoy H. (shenoyh@future.futsoft.com) Sandeep S. (sandeeps@future.futsoft.com) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 11 06:52:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id GAA01567; Thu, 11 Dec 1997 06:52:19 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Dec 1997 06:47:39 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id GAA01520 for ietf-ppp-outgoing; Thu, 11 Dec 1997 06:47:39 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id GAA01516 for ; Thu, 11 Dec 1997 06:47:34 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id DAA19376; Thu, 11 Dec 1997 03:47:00 -0800 Received: from ascend.com by ascend.com with ESMTP id DAA11920; Thu, 11 Dec 1997 03:46:58 -0800 Received: from ascend.com by ascend.com id DAA18298; Thu, 11 Dec 1997 03:44:20 -0800 Message-Id: <3.0.5.32.19971211034652.008dbc60@darla> X-Sender: mhold@darla X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Dec 1997 03:46:52 -0800 To: shenoyh From: Matt Holdrege Subject: Re: MP+ Protocol doubt... Cc: PPPMailing-List In-Reply-To: <34906C95@msgate.future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu At 02:36 PM 12/11/97 PST, shenoyh wrote: > >Hi, > On page 7, rfc1934 (Multilink Protocol Plus), the error control >procedure table shows a state * Start * to which transition takes place on >the reception of a few events such as Received ACK_MSG in the Idle state. > This Start state is however not listed in the table itself, nor is it >explained subsequently. Has the start state been missed out from the table ? >Or does it imply remaining in the same state ? >Could anyone please help us on this ? > Is there any material available other than rfc1934 on MP Plus ? Does >anyone know if an update to the rfc 1934 is in the pipeline or any drafts >regarding the same are available ? > In addition to the above, the rfc has a few other inconsistencies such >as : >The abscence of description on who sends (or when) a MP_PLUS_CLEAR_REQUEST >(though the reception of such an event is explained, no where in the rfc is >the transmission of such a request described ). >Also the "frame reteransmit timer" in the Error Control layer's State Event >diagram has no explanation whatsoever. Shenoyh, In case you've missed it, RFC 1934 or MP+ is Ascend's Multilink protocol. It is informational only. It predated RFC 2125 (BACP) and should not be confused with RFC 1990 both of which are standards track protocols. There are no plans to update this protocol. If you truly need to find out more about RFC 1934, please email me privately since it has little to do with current IETF PPP development. Matt Holdrege http://www.ascend.com matt@ascend.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 11 11:12:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA04792; Thu, 11 Dec 1997 11:12:39 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Dec 1997 11:10:33 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA04732 for ietf-ppp-outgoing; Thu, 11 Dec 1997 11:10:32 -0500 (EST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA04728 for ; Thu, 11 Dec 1997 11:10:28 -0500 (EST) Received: by INET-01-IMC with Internet Mail Service (5.5.1960.3) id ; Thu, 11 Dec 1997 08:10:25 -0800 Message-ID: From: Timothy Kwok To: "'Andrew G. Malis'" , James Watt Cc: gmg@garage.lucent.com, "Andrew G. Malis" , Philip Rakity , ietf-ppp@merit.edu, gmg@garage.lucent.com, "'nigel@orckit.com'" , "'jf_kervan@optilink.dsccc.com'" , "'dallan@nortel.ca'" Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt Date: Thu, 11 Dec 1997 08:09:56 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ppp@merit.edu I am also very surprised that we reopen this issue at this very last minute. The biggest driving original motivation for this draft is to support ADSL. The ADSL Forum has supported a draft specification based on null encapsulation for PPP over ATM. There are 38 companies supporting this currently. The draft specification is going out of ballot after last week's meeting to targeted become a final specification for the next meeting. If we reopen this at the last minute, it will have significant ramification for the ADSL industry and further delay the consensus we have been trying very hard to achieve in the past 18 months at the ADSL Forum I fully understand the need to interoperate with FR. However, for an entity that is only interested in supporting ADSL applications for PPP over AAL5, we should not impose restrictions on such devices. Hence, we must allow entities that don't have intent of supporting FR can implement on null encap without being noncompliant to the draft. I wasn't able to make this IETF, but I hope our liason from the ADSL Forum (Dave Allan) will or has already made this case at the IETF meeting. Tim > -----Original Message----- > From: Andrew G. Malis [SMTP:malis@alpo.casc.com] > Sent: Friday, December 05, 1997 1:48 AM > To: James Watt > Cc: gmg@garage.lucent.com; Andrew G. Malis; Philip Rakity; > ietf-ppp@merit.edu; gmg@garage.lucent.com > Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt > > James, > > >+-------- > >>Bottom line: the current ID text leaves the following question > unanswered: > >> > >> ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF > >>*mandatory* for > >> compliance with this spec? Or is it optional? Please tell me your > >> preference. > >+-------- > >For the most basic of reasons, i.e. that both RFC 1973 and FRF.* already > exist, > >I would suggest that interoperability is mandatory. > > I disagree. The primary (although certainly not the only) application for > this specification is for use with ADSL. For that particular application, > interoperation with PPP over FR is of no interest whatsover, and the > ability to do so should not be required in order to have a compliant > implementation of this spec. > > HOWEVER, for other applications, the ability to interoperate may certainly > make sense, and vendors will find it in their competitive interest to > include the ability to do so. > > We can discuss this further in the WG meeting. > > Cheers, > Andy > > ________________________________________________________________________ > Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 > Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 11 16:22:20 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA11466; Thu, 11 Dec 1997 16:22:18 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Dec 1997 16:20:59 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA11411 for ietf-ppp-outgoing; Thu, 11 Dec 1997 16:20:58 -0500 (EST) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA11395 for ; Thu, 11 Dec 1997 16:20:30 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA15955; Thu, 11 Dec 1997 13:19:59 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id OAA05137; Thu, 11 Dec 1997 14:20:38 -0800 Date: Thu, 11 Dec 1997 14:20:38 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: Timothy Kwok cc: "'Andrew G. Malis'" , James Watt , gmg@garage.lucent.com, "Andrew G. Malis" , ietf-ppp@merit.edu, gmg@garage.lucent.com, "'nigel@orckit.com'" , "'jf_kervan@optilink.dsccc.com'" , "'dallan@nortel.ca'" Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Tim, While it is true that the ADSL forum endorsed your proposal, I explicitly asked you at the meeting about the omission of LLC multiplexing. You replied that it was outside the scope of the proposal and if I am not mistaken was not being voted on either in for or against sense of the proposal. Philip Rakity FlowPoint On Thu, 11 Dec 1997, Timothy Kwok wrote: > I am also very surprised that we reopen this issue at this very last minute. > The biggest driving original motivation for this draft is to support ADSL. > The ADSL Forum has supported a draft specification based on null > encapsulation for PPP over ATM. There are 38 companies supporting this > currently. The draft specification is going out of ballot after last week's > meeting to targeted become a final specification for the next meeting. If we > reopen this at the last minute, it will have significant ramification for > the ADSL industry and further delay the consensus we have been trying very > hard to achieve in the past 18 months at the ADSL Forum > > I fully understand the need to interoperate with FR. However, for an entity > that is only interested in supporting ADSL applications for PPP over AAL5, > we should not impose restrictions on such devices. Hence, we must allow > entities that don't have intent of supporting FR can implement on null encap > without being noncompliant to the draft. > > I wasn't able to make this IETF, but I hope our liason from the ADSL Forum > (Dave Allan) will or has already made this case at the IETF meeting. > > Tim > > > -----Original Message----- > > From: Andrew G. Malis [SMTP:malis@alpo.casc.com] > > Sent: Friday, December 05, 1997 1:48 AM > > To: James Watt > > Cc: gmg@garage.lucent.com; Andrew G. Malis; Philip Rakity; > > ietf-ppp@merit.edu; gmg@garage.lucent.com > > Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt > > > > James, > > > > >+-------- > > >>Bottom line: the current ID text leaves the following question > > unanswered: > > >> > > >> ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF > > >>*mandatory* for > > >> compliance with this spec? Or is it optional? Please tell me your > > >> preference. > > >+-------- > > >For the most basic of reasons, i.e. that both RFC 1973 and FRF.* already > > exist, > > >I would suggest that interoperability is mandatory. > > > > I disagree. The primary (although certainly not the only) application for > > this specification is for use with ADSL. For that particular application, > > interoperation with PPP over FR is of no interest whatsover, and the > > ability to do so should not be required in order to have a compliant > > implementation of this spec. > > > > HOWEVER, for other applications, the ability to interoperate may certainly > > make sense, and vendors will find it in their competitive interest to > > include the ability to do so. > > > > We can discuss this further in the WG meeting. > > > > Cheers, > > Andy > > > > ________________________________________________________________________ > > Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 > > Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 11 16:42:36 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA11918; Thu, 11 Dec 1997 16:42:35 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Dec 1997 16:42:20 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA11889 for ietf-ppp-outgoing; Thu, 11 Dec 1997 16:42:19 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA11885 for ; Thu, 11 Dec 1997 16:42:11 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id NAA20144; Thu, 11 Dec 1997 13:41:35 -0800 Received: from ascend.com by ascend.com with ESMTP id NAA19522; Thu, 11 Dec 1997 13:41:31 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id NAA06269; Thu, 11 Dec 1997 13:41:31 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id NAA11187; Thu, 11 Dec 1997 13:41:25 -0800 Date: Thu, 11 Dec 1997 13:41:25 -0800 Message-Id: <199712112141.NAA11187@gump.eng.ascend.com> From: Karl Fox To: Stephen Casner , Carsten Bormann CC: ietf-ppp@merit.edu Subject: IP/CRTP compression protocol numbers Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu At the Tuesday meeting in Washington, D.C. the (slim) consensus of the group was that the 16-bit protocol numbers you had requested should be moved from the 0x2000 range to the 0x8000 range. Somebody at the meeting mentioned that they thought some document somewhere reserved ranges by function, so I went searching and found little or nothing. The one thing I found that seems relevant is that many CCP compression algorithms will only compress protocols in the range 0x0001-0x3FFF. Should messages in these protocols be CCP compressed? Protocol Numbers for IP/CRTP Header Compression Name Old # New # FULL_HEADER 0061 0061 COMPRESSED_TCP 0063 0063 COMPRESSED_NON_TCP 0065 0065 COMPRESSED_UDP_8 0067 0067 COMPRESSED_RTP_8 0069 0069 COMPRESSED_TCP_NODELTA 2063 8063 CONTEXT_STATE 2065 8065 COMPRESSED_UDP_16 2067 8067 COMPRESSED_RTP_16 2069 8069 -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 11 16:48:48 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA12030; Thu, 11 Dec 1997 16:48:47 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Dec 1997 16:48:35 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA12008 for ietf-ppp-outgoing; Thu, 11 Dec 1997 16:48:35 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA12004 for ; Thu, 11 Dec 1997 16:48:21 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id NAA20682; Thu, 11 Dec 1997 13:48:20 -0800 Received: from ascend.com by ascend.com with ESMTP id NAA19989; Thu, 11 Dec 1997 13:48:16 -0800 Received: from ascend.com by ascend.com id NAA21171; Thu, 11 Dec 1997 13:45:36 -0800 Message-Id: <3.0.5.32.19971211134800.008b1420@darla> X-Sender: mhold@darla X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 11 Dec 1997 13:48:00 -0800 To: ietf-ppp@merit.edu From: Matt Holdrege Subject: PPPEXT WG minutes from Washington, D.C. Cc: minutes@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Here are the minutes from the two PPPEXT WG sessions earlier this week. Any mistakes or misinterpretations are my own. Please report any issues to the list. PPP Extensions Working Group Minutes Monday, December 08, 1997, Tuesday, December 9th, 1997. Minutes - Matt Holdrege - matt@ascend.com Chair - Karl Fox - karl@Ascend.com The PPP Triple-DES Encryption Protocol (3DESE) Draft-ietf-pppext-3des-encrypt-00.txt Sent to IESG on Dec. 3rd. Informational RFC PPP over AAL5 draft-ietf-pppext-aal5-03.txt Draft Status Last Call until Dec. 10th Andy Malis and George Gross discussed LLC encapsulation. No resolution. PPP over FUNI draft-ietf-pppext-funi-03.txt Draft Status Last Call until Dec. 10th PPP LCP Extensions draft-ietf-pppext-lcpext-ds-02.txt Draft Status Sent to IESG PPP LCP CallBack draft-ietf-pppext-callback-ds-01.txt Call for Interoperability Experience PPP LCP Self Describing Padding draft-ietf-pppext-padding-ds-00.txt Call for Interoperability Experience No one has claimed to have implemented this protocol. Multi-link Multi-node PPP Draft-ietf-pppext-mmp-discovery-00.txt Gary Malkin - gmalkin@baynetworks.com Gary discussed certain points of his draft. Mechanism needed to randomize the bundle head. The point was brought up that different vendors handle LCP negotiation differently and remote peers may have difficulties. Security was brought up since a big denial of service hole exists. Packets need to be authenticated to prevent this. Multicast should be required for efficiency. IANA would need to issue a multicast number. Next CIUG Interoperability Workshop Week of February 23rd Anita Freeman - anfreema@cisco.com Park Plaza Motel - San Francisco Fee of $300 per person. EAP, CCP, BACP and L2TP will be tested. PPP Consistent Overhead Byte Stuffing (COBS) Draft-ietf-pppext-cobs-00.txt James Carlson - jcarlson@andr.ub.com Stuart Cheshire - cheshire@dsg.stanford.edu Stuart presented his draft. There are no intellectual property restrictions (patents) for COBS. L2TP MIB Draft-ietf-pppext-l2tp-mib-01.txt Pat Calhoun - pcalhoun@usr.com Pat presented his draft. L2TP Security Extensions for Non-IP networks Draft-ietf-pppext-l2tp-sec-02.txt Pat Calhoun - pcalhoun@usr.com Many changes were to simplify the implementation. L2TP Draft-ietf-pppext-l2tp-08.txt Mark Townsley - townsley@cisco.com Congestion Control will be clarified in draft -09 which will be out before the end of 1997. The next interoperability workshop in February will be based on draft -09. Should sequence numbers be MUST or SHOULD? Mark will put text in the next draft for MUST but allow for it to be administratively disabled. L2TP Header Compression Draft-ietf-pppext-l2tphc-00.txt Mark Townsley - townsley@cisco.com Mark described the draft and answered questions. L2TP Alternate Data Channel Draft-ietf-pppext-l2tpadc-00.txt Bill Palter - palter@cisco.com Bill presented his draft. Securing L2TP using IPSEC Draft-ietf-pppext-l2tp-security-00.txt Baiju Patel - baiju@ideal.jf.intel.com Baiju presented his draft. ISAKMP/Oakley for authentication and key management. IPSEC ESP for protection of traffic. Integrity using ESP with NULL encryption. Confidentiality using ESP with DES (or others). The objective is to provide adequate protection for L2TP control traffic. Integrity is MUST. Confidentiality is SHOULD. Provide protection for L2TP data traffic. Integrity is SHOULD. Confidentiality is MAY. For L2TP over non-IP networks, non-IP networks must transport packets. They must carry UDP packets of ISAKMP/Oakley in band or out of band (need to specify in media specific document). Carry ESP payload (no need for IP header). Next header of ESP is 0 (or we can require a new protocol type). In summary, one protocol for securing L2TP traffic over IP and non-IP networks. Proven solution. Must comply with this document to claim L2TP security requirement compliant implementation. Pat Calhoun said that Ipsec shouldn't be mandated for non-ip. Some questioned that this method is a proven solution. Bill Simpson said that null ESP may not be desirable. RTP Compression Carsten Borman - Steve Casner Changes suggested in Munich have been made. Minutes said request would be approved if no objections. They have a set of numbers to propose and are seeking approval. FULL_HEADER 0061 COMPRESSED_TCP 0063 COMPRESSED_NON_TCP 0065 COMPRESSED_UDP_8 0067 COMPRESSED_RTP_8 0069 COMPRESSED_TCP_NODELTA 8063 CONTEXT_STATE 8065 COMPRESSED_UDP_16 8067 COMPRESSED_RTP_16 8069 ISSLOW also requests LCP options, 25 Multilink Header Format (different from 18 as it has a parameter), 26 Prefix elision option I draft-ietf-issll-isslow-02.txt (In WG last call) PS draft-ietf-issll-isslow-mcml-02.txt (In WG last call) PS draft-ietf-issll-isslow-rtf-02.txt (to go to WG last call after IETF) Bill Simpson said to use the 8000 range rather than 2000. Craig Fox said that the 4000 range would be better to handle old code. 8000 range was the rough consensus. PPP EAP TLS Authentication Protocol draft-ietf-pppext-eaptls-02.txt Bernard Aboba Bernard discussed the draft. Bill said that EAP doesn't have a good match as a key negotiation protocol. Bill is against fragmentation here. This will be taken to the list. PPP with Framing Conversion draft-ietf-pppext-conversion-00.txt Bill Simpson This is to cover async/sync converters. Recommended to go forward as BCP. PPP in Frame Relay draft-ietf-pppext-framerelay-ds-00.txt Bill Simpson Same as RFC 1973 except it adds a reference to frame conversion. Need to get a list of implementers to advance to draft standard. Cisco and Ascend were noted as the only current implementers present. PPP in X.25 draft-ietf-pppext-x25-ds-00.txt Bill Simpson Simplification of wording in current RFC. Bill will ask on the list for implementations. PPP for Asynchronous PAD to Synchronous X.25 access draft-rfced-info-khana-01.txt Bill Simpson Bill said this work should fall under the domain of the ITU since it involves ITU numbers. Bill said details of PPP through PAD's should be handled as an appendix to the PPP in X.25 RFC. Bill also suggested that we submit this to the ITU Study Group 7. PPP EAP KEA Public Key Authentication Protocol Draft-ietf-pppext-eapkea-01.txt Jim Zmuda - jzmuda@spyrus.com Pat Calhoun raised a possible IBM patent issue. PPP Certificate Exchange Protocol Draft-ietf-pppext-crtxcgh-01.txt Jim Zmuda - jzmuda@spyrus.com Bernard asked why anyone would use EAP if they had this protocol. PPP Fortezza Encryption Encapsulation Protocol Draft-ietf-pppext-feep-01.txt Jim Zmuda - jzmuda@spyrus.com Fortezza is currently classified. Bill Simpson said that ISAKMP was originally designed for Fortezza and that we should use ISAKMP rather than Fortezza. Jim said he would look into it. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 11 20:23:11 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA15547; Thu, 11 Dec 1997 20:23:09 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Dec 1997 20:22:09 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA15509 for ietf-ppp-outgoing; Thu, 11 Dec 1997 20:22:08 -0500 (EST) Received: from dienstmann.informatik.uni-bremen.de (cabo@dienstmann-lane.informatik.uni-bremen.de [134.102.214.88]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA15505 for ; Thu, 11 Dec 1997 20:22:04 -0500 (EST) Received: by dienstmann.informatik.uni-bremen.de (8.7.3/30.7.96cl) id CAA11592 Fri, 12 Dec 1997 02:21:48 +0100 (MET) Date: Fri, 12 Dec 1997 02:21:48 +0100 (MET) Message-Id: <199712120121.CAA11592@dienstmann.informatik.uni-bremen.de> From: Carsten Bormann To: Karl Fox Cc: Stephen Casner , Carsten Bormann , ietf-ppp@merit.edu Subject: Re: IP/CRTP compression protocol numbers In-Reply-To: <199712112141.NAA11187@gump.eng.ascend.com> References: <199712112141.NAA11187@gump.eng.ascend.com> Sender: owner-ietf-ppp@merit.edu Karl Fox writes: > The one thing I found that seems relevant is that many CCP compression > algorithms will only compress protocols in the range 0x0001-0x3FFF. > > Should messages in these protocols be CCP compressed? Yes, definitely. > COMPRESSED_TCP_NODELTA 2063 8063 This is a form of semi-header-compressed TCP. > CONTEXT_STATE 2065 8065 I wouldn't care much about this -- it's a status message, but there is little reason why it should NOT be compressed. > COMPRESSED_UDP_16 2067 8067 > COMPRESSED_RTP_16 2069 8069 These are just the same as the 8-bit versions, except that they use 16-bit IDs for the compression context. While there is some reason to believe that RTP packets will often already have been application-compressed, this is true of both RTP_8 and RTP_16. So, it seems we should stick to 20xx. BTW, the document that assigns a meaning to 80xx is ftp://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers. Somebody should update the guidance in there. Gruesse, Carsten - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 11 23:06:34 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id XAA17340; Thu, 11 Dec 1997 23:06:32 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Dec 1997 23:05:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA17310 for ietf-ppp-outgoing; Thu, 11 Dec 1997 23:05:48 -0500 (EST) Received: from netman.iscs.nus.sg (root@netman.iscs.nus.sg [137.132.87.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id XAA17306 for ; Thu, 11 Dec 1997 23:05:43 -0500 (EST) Received: from decunx.iscs.nus.sg (limlipye@decunx.iscs.nus.sg [137.132.90.9]) by netman.iscs.nus.sg (8.8.5/8.8.5) with ESMTP id KAA26132 for ; Fri, 12 Dec 1997 10:59:52 +0800 (GMT+0800) Received: from localhost (limlipye@localhost) by decunx.iscs.nus.sg (8.8.5/8.8.5) with SMTP id KAA27002 for ; Fri, 12 Dec 1997 10:59:51 +0800 (SST) Date: Fri, 12 Dec 1997 10:59:50 +0800 (SST) From: Lim Lip Yeow X-Sender: limlipye@decunx.iscs.nus.sg Reply-To: Lim Lip Yeow To: ietf-ppp@merit.edu Subject: mipv4 config for ipcp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu i'm currently implementing the above draft (on linux). does anyone know of any existing implementation for the draft on mobile IP v4 configuration for ppp ipcp ? if yes, can you pls give me more info. thanx! lip yeow - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 12 00:40:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA18161; Fri, 12 Dec 1997 00:40:52 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 12 Dec 1997 00:38:35 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA18123 for ietf-ppp-outgoing; Fri, 12 Dec 1997 00:38:35 -0500 (EST) Received: from hydra.precept.com (hydra.precept.com [204.162.119.8]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA18119 for ; Fri, 12 Dec 1997 00:38:31 -0500 (EST) Received: from little-bear.precept.com (little-bear.precept.com [204.162.119.40]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id VAA09249; Thu, 11 Dec 1997 21:36:19 -0800 (PST) Date: Thu, 11 Dec 1997 21:36:16 -0800 (PST) From: Stephen Casner To: Carsten Bormann cc: Karl Fox , ietf-ppp@merit.edu Subject: Re: IP/CRTP compression protocol numbers In-Reply-To: <199712120121.CAA11592@dienstmann.informatik.uni-bremen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 12 Dec 1997, Carsten Bormann wrote: > Karl Fox writes: > > The one thing I found that seems relevant is that many CCP compression > > algorithms will only compress protocols in the range 0x0001-0x3FFF. ... > > So, it seems we should stick to 20xx. Karl, I am about to resubmit draft-engan-ip-compress-01.txt with the selected PPP assignments inserted. Shall I use 20xx rather than 80xx, based on the above discussion? -- Steve - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 12 08:24:03 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA20830; Fri, 12 Dec 1997 08:23:52 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 12 Dec 1997 08:15:53 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA20727 for ietf-ppp-outgoing; Fri, 12 Dec 1997 08:15:52 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA20723 for ; Fri, 12 Dec 1997 08:15:48 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id FAA22391; Fri, 12 Dec 1997 05:15:35 -0800 Received: from ascend.com by ascend.com with ESMTP id FAA00279; Fri, 12 Dec 1997 05:15:34 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id FAA20332; Fri, 12 Dec 1997 05:15:34 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id FAA13599; Fri, 12 Dec 1997 05:15:31 -0800 Date: Fri, 12 Dec 1997 05:15:31 -0800 Message-Id: <199712121315.FAA13599@gump.eng.ascend.com> From: Karl Fox To: Stephen Casner Cc: Carsten Bormann , ietf-ppp@merit.edu Subject: Re: IP/CRTP compression protocol numbers In-Reply-To: References: <199712120121.CAA11592@dienstmann.informatik.uni-bremen.de> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Stephen Casner writes: > On Fri, 12 Dec 1997, Carsten Bormann wrote: > > Karl Fox writes: > > > The one thing I found that seems relevant is that many CCP compression > > > algorithms will only compress protocols in the range 0x0001-0x3FFF. > ... > > > > So, it seems we should stick to 20xx. > > Karl, I am about to resubmit draft-engan-ip-compress-01.txt with the > selected PPP assignments inserted. > > Shall I use 20xx rather than 80xx, based on the above discussion? I would say yes, since we now have a solid reason to prefer 20xx over 80xx. > > -- Steve > -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 12 15:18:10 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA26984; Fri, 12 Dec 1997 15:18:04 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 12 Dec 1997 15:16:39 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA26940 for ietf-ppp-outgoing; Fri, 12 Dec 1997 15:16:37 -0500 (EST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA26935 for ; Fri, 12 Dec 1997 15:16:27 -0500 (EST) Received: by INET-01-IMC with Internet Mail Service (5.5.1960.3) id ; Fri, 12 Dec 1997 12:16:26 -0800 Message-ID: From: Timothy Kwok To: "'Philip Rakity'" Cc: "'Andrew G. Malis'" , "'James Watt'" , "'gmg@garage.lucent.com'" , "'Andrew G. Malis'" , "'ietf-ppp@merit.edu'" , "'gmg@garage.lucent.com'" , "'nigel@orckit.com'" , "'jf_kervan@optilink.dsccc.com'" , "'dallan@nortel.ca'" Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt Date: Fri, 12 Dec 1997 11:48:44 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ppp@merit.edu Just to clarify, this is not only our proposal, but the proposal jointly with 38 companies to accelerate the ADSL standard efforts. It took us a very long long time to reach this level of consensus. The core part of the proposal is PPP over ATM with null encapsulation and after last week's ADSL Forum meeting, it has been agreed to send that out for ballot. e believe we have a good chance to have the ADSL Forum issued a specification on this so the ADSL deployment can be accelerated, instead of stalled by lack of end to end interoperability. Philip, you are right, the LLC SNAP is outside this current draft specification of the ADSL Forum. I haven't heard any proposal to vote on this separately and I don't believe we intend to do so because we already achieved that level of consensus within the ADSL Forum to adopt PPP over ATM with null encapsulation. Since your question is surrounding the process of the ADSL Forum, we should take this offline or on the ADSL Forum list. Tim > -----Original Message----- > From: Philip Rakity [SMTP:pmr@flowpoint.com] > Sent: Thursday, December 11, 1997 2:21 PM > To: Timothy Kwok > Cc: 'Andrew G. Malis'; James Watt; gmg@garage.lucent.com; Andrew G. > Malis; ietf-ppp@merit.edu; gmg@garage.lucent.com; 'nigel@orckit.com'; > 'jf_kervan@optilink.dsccc.com'; 'dallan@nortel.ca' > Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > > > Tim, > > While it is true that the ADSL forum endorsed your proposal, I explicitly > asked you at the meeting about the omission of LLC multiplexing. You > replied that it was outside the scope of the proposal and if I am not > mistaken was not being voted on either in for or against sense of the > proposal. > > Philip Rakity > FlowPoint > > > On Thu, 11 Dec 1997, Timothy Kwok wrote: > > > I am also very surprised that we reopen this issue at this very last > minute. > > The biggest driving original motivation for this draft is to support > ADSL. > > The ADSL Forum has supported a draft specification based on null > > encapsulation for PPP over ATM. There are 38 companies supporting this > > currently. The draft specification is going out of ballot after last > week's > > meeting to targeted become a final specification for the next meeting. > If we > > reopen this at the last minute, it will have significant ramification > for > > the ADSL industry and further delay the consensus we have been trying > very > > hard to achieve in the past 18 months at the ADSL Forum > > > > I fully understand the need to interoperate with FR. However, for an > entity > > that is only interested in supporting ADSL applications for PPP over > AAL5, > > we should not impose restrictions on such devices. Hence, we must allow > > entities that don't have intent of supporting FR can implement on null > encap > > without being noncompliant to the draft. > > > > I wasn't able to make this IETF, but I hope our liason from the ADSL > Forum > > (Dave Allan) will or has already made this case at the IETF meeting. > > > > Tim > > > > > -----Original Message----- > > > From: Andrew G. Malis [SMTP:malis@alpo.casc.com] > > > Sent: Friday, December 05, 1997 1:48 AM > > > To: James Watt > > > Cc: gmg@garage.lucent.com; Andrew G. Malis; Philip Rakity; > > > ietf-ppp@merit.edu; gmg@garage.lucent.com > > > Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt > > > > > > James, > > > > > > >+-------- > > > >>Bottom line: the current ID text leaves the following question > > > unanswered: > > > >> > > > >> ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF > > > >>*mandatory* for > > > >> compliance with this spec? Or is it optional? Please tell me > your > > > >> preference. > > > >+-------- > > > >For the most basic of reasons, i.e. that both RFC 1973 and FRF.* > already > > > exist, > > > >I would suggest that interoperability is mandatory. > > > > > > I disagree. The primary (although certainly not the only) application > for > > > this specification is for use with ADSL. For that particular > application, > > > interoperation with PPP over FR is of no interest whatsover, and the > > > ability to do so should not be required in order to have a compliant > > > implementation of this spec. > > > > > > HOWEVER, for other applications, the ability to interoperate may > certainly > > > make sense, and vendors will find it in their competitive interest to > > > include the ability to do so. > > > > > > We can discuss this further in the WG meeting. > > > > > > Cheers, > > > Andy > > > > > > > ________________________________________________________________________ > > > Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 > 392-1484 > > > Ascend Communications, Inc. 1 Robbins Road Westford, MA > 01886 > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 15 19:26:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA28180; Mon, 15 Dec 1997 19:26:28 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 15 Dec 1997 19:21:39 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA28100 for ietf-ppp-outgoing; Mon, 15 Dec 1997 19:21:38 -0500 (EST) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.7/8.8.5) with SMTP id TAA28093 for ; Mon, 15 Dec 1997 19:21:34 -0500 (EST) Received: (rtio@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id QAA01113; Mon, 15 Dec 1997 16:21:02 -0800 From: Rene Tio Message-Id: <199712160021.QAA01113@greatdane.cisco.com> Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt To: timkwok@microsoft.com (Timothy Kwok) Date: Mon, 15 Dec 1997 16:21:02 -0800 (PST) Cc: ietf-ppp@merit.edu In-Reply-To: from "Timothy Kwok" at Dec 12, 97 11:48:44 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu I agree with Tim on this point. Given the current architectures: - prem-to-POP SVCs: last I saw there was no frame relay to ATM service interworking defined for SVCs, perhaps it's in the works but even then it might take a while to be deployed. - PVCs: we've all decided prem-to-POP PVCs is impractical. If it's prem to CO then you'd either tunnel or route at the CO. Either way, LLC encapsulation is of limited utility. Saying it's a "should" for completeness is probably enough. - Rene > From owner-ietf-ppp@merit.edu Fri Dec 12 12:31:48 1997 > > Just to clarify, this is not only our proposal, but the proposal jointly > with 38 companies to accelerate the ADSL standard efforts. It took us a very > long long time to reach this level of consensus. > > The core part of the proposal is PPP over ATM with null encapsulation and > after last week's ADSL Forum meeting, it has been agreed to send that out > for ballot. e believe we have a good chance to have the ADSL Forum issued a > specification on this so the ADSL deployment can be accelerated, instead of > stalled by lack of end to end interoperability. > > Philip, you are right, the LLC SNAP is outside this current draft > specification of the ADSL Forum. I haven't heard any proposal to vote on > this separately and I don't believe we intend to do so because we already > achieved that level of consensus within the ADSL Forum to adopt PPP over ATM > with null encapsulation. > > Since your question is surrounding the process of the ADSL Forum, we should > take this offline or on the ADSL Forum list. > > Tim > > -----Original Message----- > > From: Philip Rakity [SMTP:pmr@flowpoint.com] > > Sent: Thursday, December 11, 1997 2:21 PM > > To: Timothy Kwok > > Cc: 'Andrew G. Malis'; James Watt; gmg@garage.lucent.com; Andrew G. > > Malis; ietf-ppp@merit.edu; gmg@garage.lucent.com; 'nigel@orckit.com'; > > 'jf_kervan@optilink.dsccc.com'; 'dallan@nortel.ca' > > Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > > > > > > Tim, > > > > While it is true that the ADSL forum endorsed your proposal, I explicitly > > asked you at the meeting about the omission of LLC multiplexing. You > > replied that it was outside the scope of the proposal and if I am not > > mistaken was not being voted on either in for or against sense of the > > proposal. > > > > Philip Rakity > > FlowPoint > > > > > > On Thu, 11 Dec 1997, Timothy Kwok wrote: > > > > > I am also very surprised that we reopen this issue at this very last > > minute. > > > The biggest driving original motivation for this draft is to support > > ADSL. > > > The ADSL Forum has supported a draft specification based on null > > > encapsulation for PPP over ATM. There are 38 companies supporting this > > > currently. The draft specification is going out of ballot after last > > week's > > > meeting to targeted become a final specification for the next meeting. > > If we > > > reopen this at the last minute, it will have significant ramification > > for > > > the ADSL industry and further delay the consensus we have been trying > > very > > > hard to achieve in the past 18 months at the ADSL Forum > > > > > > I fully understand the need to interoperate with FR. However, for an > > entity > > > that is only interested in supporting ADSL applications for PPP over > > AAL5, > > > we should not impose restrictions on such devices. Hence, we must allow > > > entities that don't have intent of supporting FR can implement on null > > encap > > > without being noncompliant to the draft. > > > > > > I wasn't able to make this IETF, but I hope our liason from the ADSL > > Forum > > > (Dave Allan) will or has already made this case at the IETF meeting. > > > > > > Tim > > > > > > > -----Original Message----- > > > > From: Andrew G. Malis [SMTP:malis@alpo.casc.com] > > > > Sent: Friday, December 05, 1997 1:48 AM > > > > To: James Watt > > > > Cc: gmg@garage.lucent.com; Andrew G. Malis; Philip Rakity; > > > > ietf-ppp@merit.edu; gmg@garage.lucent.com > > > > Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt > > > > > > > > James, > > > > > > > > >+-------- > > > > >>Bottom line: the current ID text leaves the following question > > > > unanswered: > > > > >> > > > > >> ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF > > > > >>*mandatory* for > > > > >> compliance with this spec? Or is it optional? Please tell me > > your > > > > >> preference. > > > > >+-------- > > > > >For the most basic of reasons, i.e. that both RFC 1973 and FRF.* > > already > > > > exist, > > > > >I would suggest that interoperability is mandatory. > > > > > > > > I disagree. The primary (although certainly not the only) application > > for > > > > this specification is for use with ADSL. For that particular > > application, > > > > interoperation with PPP over FR is of no interest whatsover, and the > > > > ability to do so should not be required in order to have a compliant > > > > implementation of this spec. > > > > > > > > HOWEVER, for other applications, the ability to interoperate may > > certainly > > > > make sense, and vendors will find it in their competitive interest to > > > > include the ability to do so. > > > > > > > > We can discuss this further in the WG meeting. > > > > > > > > Cheers, > > > > Andy > > > > > > > > > > ________________________________________________________________________ > > > > Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 > > 392-1484 > > > > Ascend Communications, Inc. 1 Robbins Road Westford, MA > > 01886 > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 15 19:40:28 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA28392; Mon, 15 Dec 1997 19:40:27 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 15 Dec 1997 19:40:02 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA28363 for ietf-ppp-outgoing; Mon, 15 Dec 1997 19:40:01 -0500 (EST) Received: from SantaClara01.pop.internex.net (santaclara01.pop.InterNex.Net [205.158.3.18]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA28356 for ; Mon, 15 Dec 1997 19:39:56 -0500 (EST) Received: from flowpoint.com ([192.84.210.69]) by SantaClara01.pop.internex.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with ESMTP id AAA29288; Mon, 15 Dec 1997 16:39:53 -0800 Received: from localhost (pmr@localhost) by flowpoint.com (8.8.4/8.8.4) with SMTP id QAA09092; Mon, 15 Dec 1997 16:40:31 -0800 Date: Mon, 15 Dec 1997 16:40:31 -0800 (PST) From: Philip Rakity X-Sender: pmr@flowpnt To: Rene Tio cc: Timothy Kwok , ietf-ppp@merit.edu Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt In-Reply-To: <199712160021.QAA01113@greatdane.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Rene, Could you please explain what a prem is? thanks, Philip On Mon, 15 Dec 1997, Rene Tio wrote: > I agree with Tim on this point. Given the current architectures: > > - prem-to-POP SVCs: last I saw there was no frame relay to ATM service > interworking defined for SVCs, perhaps it's in the works but even then it > might take a while to be deployed. > > - PVCs: we've all decided prem-to-POP PVCs is impractical. If it's prem to > CO then you'd either tunnel or route at the CO. > > Either way, LLC encapsulation is of limited utility. Saying it's a "should" > for completeness is probably enough. > > - Rene > > > > From owner-ietf-ppp@merit.edu Fri Dec 12 12:31:48 1997 > > > > Just to clarify, this is not only our proposal, but the proposal jointly > > with 38 companies to accelerate the ADSL standard efforts. It took us a very > > long long time to reach this level of consensus. > > > > The core part of the proposal is PPP over ATM with null encapsulation and > > after last week's ADSL Forum meeting, it has been agreed to send that out > > for ballot. e believe we have a good chance to have the ADSL Forum issued a > > specification on this so the ADSL deployment can be accelerated, instead of > > stalled by lack of end to end interoperability. > > > > Philip, you are right, the LLC SNAP is outside this current draft > > specification of the ADSL Forum. I haven't heard any proposal to vote on > > this separately and I don't believe we intend to do so because we already > > achieved that level of consensus within the ADSL Forum to adopt PPP over ATM > > with null encapsulation. > > > > Since your question is surrounding the process of the ADSL Forum, we should > > take this offline or on the ADSL Forum list. > > > > Tim > > > -----Original Message----- > > > From: Philip Rakity [SMTP:pmr@flowpoint.com] > > > Sent: Thursday, December 11, 1997 2:21 PM > > > To: Timothy Kwok > > > Cc: 'Andrew G. Malis'; James Watt; gmg@garage.lucent.com; Andrew G. > > > Malis; ietf-ppp@merit.edu; gmg@garage.lucent.com; 'nigel@orckit.com'; > > > 'jf_kervan@optilink.dsccc.com'; 'dallan@nortel.ca' > > > Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > > > > > > > > > Tim, > > > > > > While it is true that the ADSL forum endorsed your proposal, I explicitly > > > asked you at the meeting about the omission of LLC multiplexing. You > > > replied that it was outside the scope of the proposal and if I am not > > > mistaken was not being voted on either in for or against sense of the > > > proposal. > > > > > > Philip Rakity > > > FlowPoint > > > > > > > > > On Thu, 11 Dec 1997, Timothy Kwok wrote: > > > > > > > I am also very surprised that we reopen this issue at this very last > > > minute. > > > > The biggest driving original motivation for this draft is to support > > > ADSL. > > > > The ADSL Forum has supported a draft specification based on null > > > > encapsulation for PPP over ATM. There are 38 companies supporting this > > > > currently. The draft specification is going out of ballot after last > > > week's > > > > meeting to targeted become a final specification for the next meeting. > > > If we > > > > reopen this at the last minute, it will have significant ramification > > > for > > > > the ADSL industry and further delay the consensus we have been trying > > > very > > > > hard to achieve in the past 18 months at the ADSL Forum > > > > > > > > I fully understand the need to interoperate with FR. However, for an > > > entity > > > > that is only interested in supporting ADSL applications for PPP over > > > AAL5, > > > > we should not impose restrictions on such devices. Hence, we must allow > > > > entities that don't have intent of supporting FR can implement on null > > > encap > > > > without being noncompliant to the draft. > > > > > > > > I wasn't able to make this IETF, but I hope our liason from the ADSL > > > Forum > > > > (Dave Allan) will or has already made this case at the IETF meeting.. > > > > > > > > Tim > > > > > > > > > -----Original Message----- > > > > > From: Andrew G. Malis [SMTP:malis@alpo.casc.com] > > > > > Sent: Friday, December 05, 1997 1:48 AM > > > > > To: James Watt > > > > > Cc: gmg@garage.lucent.com; Andrew G. Malis; Philip Rakity; > > > > > ietf-ppp@merit.edu; gmg@garage.lucent.com > > > > > Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt > > > > > > > > > > James, > > > > > > > > > > >+-------- > > > > > >>Bottom line: the current ID text leaves the following question > > > > > unanswered: > > > > > >> > > > > > >> ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF > > > > > >>*mandatory* for > > > > > >> compliance with this spec? Or is it optional? Please tell me > > > your > > > > > >> preference. > > > > > >+-------- > > > > > >For the most basic of reasons, i.e. that both RFC 1973 and FRF.* > > > already > > > > > exist, > > > > > >I would suggest that interoperability is mandatory. > > > > > > > > > > I disagree. The primary (although certainly not the only) application > > > for > > > > > this specification is for use with ADSL. For that particular > > > application, > > > > > interoperation with PPP over FR is of no interest whatsover, and the > > > > > ability to do so should not be required in order to have a compliant > > > > > implementation of this spec. > > > > > > > > > > HOWEVER, for other applications, the ability to interoperate may > > > certainly > > > > > make sense, and vendors will find it in their competitive interest to > > > > > include the ability to do so. > > > > > > > > > > We can discuss this further in the WG meeting. > > > > > > > > > > Cheers, > > > > > Andy > > > > > > > > > > > > > ________________________________________________________________________ > > > > > Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 > > > 392-1484 > > > > > Ascend Communications, Inc. 1 Robbins Road Westford, MA > > > 01886 > > > > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 15 20:40:21 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA28987; Mon, 15 Dec 1997 20:40:19 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 15 Dec 1997 20:39:39 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA28965 for ietf-ppp-outgoing; Mon, 15 Dec 1997 20:39:38 -0500 (EST) Received: from gvmail.globalvillage.com ([198.93.137.253]) by merit.edu (8.8.7/8.8.5) with SMTP id UAA28961 for ; Mon, 15 Dec 1997 20:39:32 -0500 (EST) Received: from sleet.globalvillage.com [198.93.138.50] by gvmail.globalvillage.com (SMTPD32-4.02c) id ABCF9D00CE; Mon, 15 Dec 1997 17:39:27 PST Received: from ianp by sleet.globalvillage.com (SMI-8.6/SMI-SVR4) id RAA00809; Mon, 15 Dec 1997 17:39:12 -0800 Message-ID: <005501bd09c3$8910e360$46bf8acf@ianp.globalvillage.com> From: "Ian Puleston" To: Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt Date: Mon, 15 Dec 1997 17:40:03 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ppp@merit.edu Rewording point 3. in section 4 as follows would clarify it and prevent us from having to implement something which would not be needed in ADSL equipment. 3. Support of connecting though a Frame Relay/ATM FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point is optional. If it is to be supported by an implementation, then that implementation MUST support LLC encapsulated PPP payloads, and MUST use this technique on such a connection. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 15 21:08:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA29220; Mon, 15 Dec 1997 21:08:39 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 15 Dec 1997 21:08:11 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA29195 for ietf-ppp-outgoing; Mon, 15 Dec 1997 21:08:10 -0500 (EST) Received: from services.paradyne.com (mailhost.paradyne.com [204.128.146.50]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA29191 for ; Mon, 15 Dec 1997 21:08:06 -0500 (EST) Received: from mercury.nj.paradyne.com ([135.26.110.41]) by services.paradyne.com (Netscape Messaging Server 3.01) with ESMTP id AAA22951; Mon, 15 Dec 1997 21:07:35 -0500 Received: from [135.90.99.7] (annex-port16.is.paradyne.com [135.90.99.16]) by mercury.nj.paradyne.com (8.7.5/8.7.3) with ESMTP id VAA25168; Mon, 15 Dec 1997 21:07:31 -0500 (EST) X-Sender: mjk@pop.nj.paradyne.com Message-Id: In-Reply-To: <005501bd09c3$8910e360$46bf8acf@ianp.globalvillage.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Dec 1997 21:06:49 -0500 To: "Ian Puleston" From: Manu Kaycee Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt Cc: , Manu Kaycee Sender: owner-ietf-ppp@merit.edu At 8:40 PM -0500 12/15/97, Ian Puleston wrote: >Rewording point 3. in section 4 as follows would clarify it and prevent us >from having to implement something which would not be needed in ADSL >equipment. > > 3. Support of connecting though a Frame Relay/ATM FRF.8 [7] > service inter-working unit to an RFC 1973 [6] end point is optional. > If it is to be supported by an implementation, then that > implementation MUST support LLC encapsulated PPP payloads, > and MUST use this technique on such a connection. I suggest we use Ian's recommendation, support it, and move on. Objections, disagreements, anyone? Later, Manu ____________________________________________________________________ Paradyne Corporation +1-603-434-6088 (V) 21 Bear Meadow Road +1-603-434-6178 (F) Londonderry, NH 03053-2618 mjk@nj.paradyne.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 16 00:05:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA01160; Tue, 16 Dec 1997 00:05:56 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 16 Dec 1997 00:03:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA01124 for ietf-ppp-outgoing; Tue, 16 Dec 1997 00:03:48 -0500 (EST) Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA01117 for ; Tue, 16 Dec 1997 00:03:44 -0500 (EST) Received: (from smap@localhost) by ns.newbridge.com (8.8.8/8.6.12) id AAA20785; Tue, 16 Dec 1997 00:03:41 -0500 (EST) Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma018776; Tue Dec 16 00:01:57 1997 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 16 Dec 1997 05:01:56 UT Received: (from smap@localhost) by ca.newbridge.com. (8.8.6/8.8.6) id AAA23448; Tue, 16 Dec 1997 00:01:55 -0500 (EST) Received: from popmail.ca.newbridge.com(138.120.118.14) by kanmaster.ca.newbridge.com via smap (V1.3) id sma023411; Tue Dec 16 00:01:15 1997 Received: from [138.120.49.125] by popmail.ca.newbridge.com (SMI-8.6/SMI-SVR4) id XAA12377; Mon, 15 Dec 1997 23:58:53 -0500 X-Sender: james@popmail.ca.newbridge.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Dec 1997 00:01:07 -0500 To: Timothy Kwok From: James Watt Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu Tim: I didn't intend to re-open this issue; I too thought we had discussed this on the working group mailing list months ago. My original comment to the list was because it wasn't clear to me that the text reflected what had been agreed on the mailing list. Although the ADSL Forum has provided the "first application" that motivated producing the PPP/ATM document, IETF documents have a habit of being used for many applications. The interoperability issue is simple yet real. Consider the sequence of an ATM-attached PPP speaker through an FRF.8 compliant inter-working unit to a FR-attached PPP speaker. If the ATM-attached PPP-speaker supports only the null encapsulation, there is _no_ way to carry IP end to end if you have compliant FRF.8 and PPP/FR devices. This scenario would seem possible in the ADSL world, with ADSL devices being the ATM-attached PPP speakers and the IP provider's router being FR attached. One could observe that RFC 1973 doesn't cover the SVC case and, as it is updated, it could require FR-attached PPP speakers to speak null encapsulation in addition to NLPID. If so, it would only be ATM-attached PPP speakers that use PVCs that require LLC support for interoperability. In summary, my concern was simply to point out that the working group is being ask to publish a document that leads to "conformant but non-interoperable" implementations. I believe that everyone should now understand the issue. Regards, -james >I am also very surprised that we reopen this issue at this very last minute. >The biggest driving original motivation for this draft is to support ADSL. >The ADSL Forum has supported a draft specification based on null >encapsulation for PPP over ATM. There are 38 companies supporting this >currently. The draft specification is going out of ballot after last week's >meeting to targeted become a final specification for the next meeting. If we >reopen this at the last minute, it will have significant ramification for >the ADSL industry and further delay the consensus we have been trying very >hard to achieve in the past 18 months at the ADSL Forum > >I fully understand the need to interoperate with FR. However, for an entity >that is only interested in supporting ADSL applications for PPP over AAL5, >we should not impose restrictions on such devices. Hence, we must allow >entities that don't have intent of supporting FR can implement on null encap >without being noncompliant to the draft. > >I wasn't able to make this IETF, but I hope our liason from the ADSL Forum >(Dave Allan) will or has already made this case at the IETF meeting. > >Tim > >> -----Original Message----- >> From: Andrew G. Malis [SMTP:malis@alpo.casc.com] >> Sent: Friday, December 05, 1997 1:48 AM >> To: James Watt >> Cc: gmg@garage.lucent.com; Andrew G. Malis; Philip Rakity; >> ietf-ppp@merit.edu; gmg@garage.lucent.com >> Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt >> >> James, >> >> >+-------- >> >>Bottom line: the current ID text leaves the following question >> unanswered: >> >> >> >> ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF >> >>*mandatory* for >> >> compliance with this spec? Or is it optional? Please tell me your >> >> preference. >> >+-------- >> >For the most basic of reasons, i.e. that both RFC 1973 and FRF.* already >> exist, >> >I would suggest that interoperability is mandatory. >> >> I disagree. The primary (although certainly not the only) application for >> this specification is for use with ADSL. For that particular application, >> interoperation with PPP over FR is of no interest whatsover, and the >> ability to do so should not be required in order to have a compliant >> implementation of this spec. >> >> HOWEVER, for other applications, the ability to interoperate may certainly >> make sense, and vendors will find it in their competitive interest to >> include the ability to do so. >> >> We can discuss this further in the WG meeting. >> >> Cheers, >> Andy >> >> ________________________________________________________________________ >> Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 >> Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 ____________________________________________________________________________ James W. Watt, jamesw@newbridge.com Ph: (613) 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:(613) 591-3680 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 16 08:28:42 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA04844; Tue, 16 Dec 1997 08:28:14 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 16 Dec 1997 08:19:56 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA04755 for ietf-ppp-outgoing; Tue, 16 Dec 1997 08:19:55 -0500 (EST) Received: from brfw1.boca.stn.siemens.com (brfw1ext.stn.siemens.com [208.158.176.40]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA04751 for ; Tue, 16 Dec 1997 08:19:51 -0500 (EST) From: Robert.Jenness@stn.siemens.com Received: from BI01.boca.ssc.siemens.com (bi01.boca.ssc.siemens.com [135.1.82.80]) by brfw1.boca.stn.siemens.com (8.8.7/8.8.7) with SMTP id IAA09300; Tue, 16 Dec 1997 08:19:49 -0500 (EST) Received: by BI01.boca.ssc.siemens.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 8525656F.00490E42 ; Tue, 16 Dec 1997 08:17:57 -0500 X-Lotus-FromDomain: SIEMENS_STROMBERG-CARLSON To: James Watt cc: ietf-ppp@merit.edu Message-ID: <8525656F.004774E3.00@BI01.boca.ssc.siemens.com> Date: Tue, 16 Dec 1997 08:19:57 -0500 Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=TSqKrpzK9qCmCToBCj5hvJMfSt4hVWlWqtRX7dkZNXJzzf0ucSNlggQc" Sender: owner-ietf-ppp@merit.edu --0__=TSqKrpzK9qCmCToBCj5hvJMfSt4hVWlWqtRX7dkZNXJzzf0ucSNlggQc Content-type: text/plain; charset=us-ascii James and Tim: I agree with James that the issue of FR interworking is a real one. PPP over ATM for ADSL encourages the deployment of 2 new networking technologies - ADSL and ATM (SVC capable) access networks. Unfortunately, the very motivation for the proposal - to provide a way to interwork with existing ISP networking which uses PPP - is also a motivation to interwork with FR, since many of those ISP networks apparently already connect via FR, and many existing access networks haven't deployed ATM at all yet. That said, I also know that the reality of the Prem (that's end customer premises) equipment will include PCs that are capable of agility between packet and cell modes. Is the proposed new text for point 3 (Ian Puleston) sufficient to define a mode-agile access network that can reflect either FR or ATM to such a mode-agile prem ADSL host? That would be desirable, I think, but I don't understand the details well enough yet to know whether it's OK as written, a modest extension of scope, or a new document. Bob Jenness James Watt on 12/16/97 12:01:07 AM To: Timothy Kwok cc: ietf-ppp@merit.edu (bcc: Robert Jenness/Development/Siemens_Stromberg-Carlson/US) Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt Tim: I didn't intend to re-open this issue; I too thought we had discussed this on the working group mailing list months ago. My original comment to the list was because it wasn't clear to me that the text reflected what had been agreed on the mailing list. Although the ADSL Forum has provided the "first application" that motivated producing the PPP/ATM document, IETF documents have a habit of being used for many applications. The interoperability issue is simple yet real. Consider the sequence of an ATM-attached PPP speaker through an FRF.8 compliant inter-working unit to a FR-attached PPP speaker. If the ATM-attached PPP-speaker supports only the null encapsulation, there is _no_ way to carry IP end to end if you have compliant FRF.8 and PPP/FR devices. This scenario would seem possible in the ADSL world, with ADSL devices being the ATM-attached PPP speakers and the IP provider's router being FR attached. One could observe that RFC 1973 doesn't cover the SVC case and, as it is updated, it could require FR-attached PPP speakers to speak null encapsulation in addition to NLPID. If so, it would only be ATM-attached PPP speakers that use PVCs that require LLC support for interoperability. In summary, my concern was simply to point out that the working group is being ask to publish a document that leads to "conformant but non-interoperable" implementations. I believe that everyone should now understand the issue. Regards, -james >I am also very surprised that we reopen this issue at this very last minute. >The biggest driving original motivation for this draft is to support ADSL. >The ADSL Forum has supported a draft specification based on null >encapsulation for PPP over ATM. There are 38 companies supporting this >currently. The draft specification is going out of ballot after last week's >meeting to targeted become a final specification for the next meeting. If we >reopen this at the last minute, it will have significant ramification for >the ADSL industry and further delay the consensus we have been trying very >hard to achieve in the past 18 months at the ADSL Forum > >I fully understand the need to interoperate with FR. However, for an entity >that is only interested in supporting ADSL applications for PPP over AAL5, >we should not impose restrictions on such devices. Hence, we must allow >entities that don't have intent of supporting FR can implement on null encap >without being noncompliant to the draft. > >I wasn't able to make this IETF, but I hope our liason from the ADSL Forum >(Dave Allan) will or has already made this case at the IETF meeting. > >Tim > >> -----Original Message----- >> From: Andrew G. Malis [SMTP:malis@alpo.casc.com] >> Sent: Friday, December 05, 1997 1:48 AM >> To: James Watt >> Cc: gmg@garage.lucent.com; Andrew G. Malis; Philip Rakity; >> ietf-ppp@merit.edu; gmg@garage.lucent.com >> Subject: Re: Last call on draft-ietf-pppext-aal5-03.txt >> >> James, >> >> >+-------- >> >>Bottom line: the current ID text leaves the following question >> unanswered: >> >> >> >> ===> Is the ability to inter-operate with an RFC1973/FRF.8 IWF >> >>*mandatory* for >> >> compliance with this spec? Or is it optional? Please tell me your >> >> preference. >> >+-------- >> >For the most basic of reasons, i.e. that both RFC 1973 and FRF.* already >> exist, >> >I would suggest that interoperability is mandatory. >> >> I disagree. The primary (although certainly not the only) application for >> this specification is for use with ADSL. For that particular application, >> interoperation with PPP over FR is of no interest whatsover, and the >> ability to do so should not be required in order to have a compliant >> implementation of this spec. >> >> HOWEVER, for other applications, the ability to interoperate may certainly >> make sense, and vendors will find it in their competitive interest to >> include the ability to do so. >> >> We can discuss this further in the WG meeting. >> >> Cheers, >> Andy >> >> ________________________________________________________________________ >> Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 >> Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 ___________________________________________________________________________ _ James W. Watt, jamesw@newbridge.com Ph: (613) 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:(613) 591-3680 --0__=TSqKrpzK9qCmCToBCj5hvJMfSt4hVWlWqtRX7dkZNXJzzf0ucSNlggQc Content-type: application/octet-stream; name="att1.eml" Content-transfer-encoding: base64 UmVjZWl2ZWQ6IGZyb20gYnJmdzEuYm9jYS5zdG4uc2llbWVucy5jb20gKFsxMzUuMS45MC4xMF0p IGJ5IEJJMDEuYm9jYS5zc2Muc2llbWVucy5jb20gKExvdHVzIFNNVFAgTVRBIFNNVFAgdjQuNiAo NDYyLjIgOS0zLTE5OTcpKSB3aXRoIFNNVFAgaWQgODUyNTY1NkYuMDAxQ0U2Qzk7IFR1ZSwgMTYg RGVjIDE5OTcgMDA6MTU6NDAgLTA1MDANClJlY2VpdmVkOiBmcm9tIG1lcml0LmVkdSAobWVyaXQu ZWR1IFsxOTguMTA4LjEuNDJdKQ0KCWJ5IGJyZncxLmJvY2Euc3RuLnNpZW1lbnMuY29tICg4Ljgu Ny84LjguNykgd2l0aCBFU01UUCBpZCBBQUEwNTc0NzsNCglUdWUsIDE2IERlYyAxOTk3IDAwOjE3 OjI4IC0wNTAwIChFU1QpDQpSZWNlaXZlZDogZnJvbSBsb2NhbGhvc3QgKGRhZW1vbkBsb2NhbGhv c3QpDQoJYnkgbWVyaXQuZWR1ICg4LjguNy84LjguNSkgd2l0aCBTTVRQIGlkIEFBQTAxMTQxOw0K CVR1ZSwgMTYgRGVjIDE5OTcgMDA6MDQ6MTggLTA1MDAgKEVTVCkNClJlY2VpdmVkOiBieSBtZXJp dC5lZHUgKGJ1bGtfbWFpbGVyIHYxLjUpOyBUdWUsIDE2IERlYyAxOTk3IDAwOjAzOjQ5IC0wNTAw DQpSZWNlaXZlZDogKGZyb20gbWFqb3Jkb21AbG9jYWxob3N0KQ0KCWJ5IG1lcml0LmVkdSAoOC44 LjcvOC44LjUpIGlkIEFBQTAxMTI0DQoJZm9yIGlldGYtcHBwLW91dGdvaW5nOyBUdWUsIDE2IERl YyAxOTk3IDAwOjAzOjQ4IC0wNTAwIChFU1QpDQpSZWNlaXZlZDogZnJvbSBucy5uZXdicmlkZ2Uu Y29tIChucy5uZXdicmlkZ2UuY29tIFsxOTIuNzUuMjMuNjddKQ0KCWJ5IG1lcml0LmVkdSAoOC44 LjcvOC44LjUpIHdpdGggRVNNVFAgaWQgQUFBMDExMTcNCglmb3IgPGlldGYtcHBwQG1lcml0LmVk dT47IFR1ZSwgMTYgRGVjIDE5OTcgMDA6MDM6NDQgLTA1MDAgKEVTVCkNClJlY2VpdmVkOiAoZnJv bSBzbWFwQGxvY2FsaG9zdCkgYnkgbnMubmV3YnJpZGdlLmNvbSAoOC44LjgvOC42LjEyKSBpZCBB QUEyMDc4NTsgVHVlLCAxNiBEZWMgMTk5NyAwMDowMzo0MSAtMDUwMCAoRVNUKQ0KUmVjZWl2ZWQ6 IGZyb20ga2FuYXRhLWd3MSgxOTIuNzUuMjMuNzIpIGJ5IG5zIHZpYSBzbWFwIChWMS4zKQ0KCWlk IHNtYTAxODc3NjsgVHVlIERlYyAxNiAwMDowMTo1NyAxOTk3DQpSZWNlaXZlZDogZnJvbSBrYW5t YXN0ZXIuY2EubmV3YnJpZGdlLmNvbSBieSBrYW5hdGEtZ3cxLmNhLm5ld2JyaWRnZS5jb20NCiAg ICAgICAgICB2aWEgc210cGQgKGZvciBucy5uZXdicmlkZ2UuY29tIFsxOTIuNzUuMjMuNjddKSB3 aXRoIFNNVFA7IDE2IERlYyAxOTk3IDA1OjAxOjU2IFVUDQpSZWNlaXZlZDogKGZyb20gc21hcEBs b2NhbGhvc3QpDQoJYnkgY2EubmV3YnJpZGdlLmNvbS4gKDguOC42LzguOC42KSBpZCBBQUEyMzQ0 ODsNCglUdWUsIDE2IERlYyAxOTk3IDAwOjAxOjU1IC0wNTAwIChFU1QpDQpSZWNlaXZlZDogZnJv bSBwb3BtYWlsLmNhLm5ld2JyaWRnZS5jb20oMTM4LjEyMC4xMTguMTQpIGJ5IGthbm1hc3Rlci5j YS5uZXdicmlkZ2UuY29tIHZpYSBzbWFwIChWMS4zKQ0KCWlkIHNtYTAyMzQxMTsgVHVlIERlYyAx NiAwMDowMToxNSAxOTk3DQpSZWNlaXZlZDogZnJvbSBbMTM4LjEyMC40OS4xMjVdIGJ5IHBvcG1h aWwuY2EubmV3YnJpZGdlLmNvbSAoU01JLTguNi9TTUktU1ZSNCkNCglpZCBYQUExMjM3NzsgTW9u LCAxNSBEZWMgMTk5NyAyMzo1ODo1MyAtMDUwMA0KWC1TZW5kZXI6IGphbWVzQHBvcG1haWwuY2Eu bmV3YnJpZGdlLmNvbQ0KTWVzc2FnZS1JZDogPHYwNDAwMmEwMWIwYmJiN2M3OGUzMEBbMTM4LjEy MC40OS4xMjVdPg0KSW4tUmVwbHktVG86IA0KIDxFRDdFNzEwNEYyMzZEMTExOTBEODAwODA1RkZF ODk5NTAyMjU1QjlBQHJlZC1tc2ctNDkuZG5zLm1pY3Jvc29mdC5jb20+DQpNaW1lLVZlcnNpb246 IDEuMA0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkRhdGU6 IFR1ZSwgMTYgRGVjIDE5OTcgMDA6MDE6MDcgLTA1MDANClRvOiBUaW1vdGh5IEt3b2sgPHRpbWt3 b2tAbWljcm9zb2Z0LmNvbT4NCkZyb206IEphbWVzIFdhdHQgPGphbWVzQE5ld2JyaWRnZS5DT00+ DQpTdWJqZWN0OiBSRTogTGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtcHBwZXh0LWFhbDUtMDMudHh0 DQpDYzogaWV0Zi1wcHBAbWVyaXQuZWR1DQpTZW5kZXI6IG93bmVyLWlldGYtcHBwQG1lcml0LmVk dQ0KDQpUaW06DQoNCkkgZGlkbid0IGludGVuZCB0byByZS1vcGVuIHRoaXMgaXNzdWU7IEkgdG9v IHRob3VnaHQgd2UgaGFkIGRpc2N1c3NlZCB0aGlzDQpvbiB0aGUgd29ya2luZyBncm91cCBtYWls aW5nIGxpc3QgbW9udGhzIGFnby4gTXkgb3JpZ2luYWwgY29tbWVudCB0byB0aGUNCmxpc3Qgd2Fz IGJlY2F1c2UgaXQgd2Fzbid0IGNsZWFyIHRvIG1lIHRoYXQgdGhlIHRleHQgcmVmbGVjdGVkIHdo YXQgaGFkDQpiZWVuIGFncmVlZCBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQpBbHRob3VnaCB0aGUg QURTTCBGb3J1bSBoYXMgcHJvdmlkZWQgdGhlICJmaXJzdCBhcHBsaWNhdGlvbiIgdGhhdCBtb3Rp dmF0ZWQNCnByb2R1Y2luZyB0aGUgUFBQL0FUTSBkb2N1bWVudCwgSUVURiBkb2N1bWVudHMgaGF2 ZSBhIGhhYml0IG9mIGJlaW5nIHVzZWQNCmZvciBtYW55IGFwcGxpY2F0aW9ucy4NCg0KVGhlIGlu dGVyb3BlcmFiaWxpdHkgaXNzdWUgaXMgc2ltcGxlIHlldCByZWFsLiBDb25zaWRlciB0aGUgc2Vx dWVuY2Ugb2YgYW4NCkFUTS1hdHRhY2hlZCBQUFAgc3BlYWtlciB0aHJvdWdoIGFuIEZSRi44IGNv bXBsaWFudCBpbnRlci13b3JraW5nIHVuaXQgdG8gYQ0KRlItYXR0YWNoZWQgUFBQIHNwZWFrZXIu IElmIHRoZSBBVE0tYXR0YWNoZWQgUFBQLXNwZWFrZXIgc3VwcG9ydHMgb25seSB0aGUNCm51bGwg ZW5jYXBzdWxhdGlvbiwgdGhlcmUgaXMgX25vXyB3YXkgdG8gY2FycnkgSVAgZW5kIHRvIGVuZCBp ZiB5b3UgaGF2ZQ0KY29tcGxpYW50IEZSRi44IGFuZCBQUFAvRlIgZGV2aWNlcy4NCg0KVGhpcyBz Y2VuYXJpbyB3b3VsZCBzZWVtIHBvc3NpYmxlIGluIHRoZSBBRFNMIHdvcmxkLCB3aXRoIEFEU0wg ZGV2aWNlcw0KYmVpbmcgdGhlIEFUTS1hdHRhY2hlZCBQUFAgc3BlYWtlcnMgYW5kIHRoZSBJUCBw cm92aWRlcidzIHJvdXRlciBiZWluZyBGUg0KYXR0YWNoZWQuDQoNCk9uZSBjb3VsZCBvYnNlcnZl IHRoYXQgUkZDIDE5NzMgZG9lc24ndCBjb3ZlciB0aGUgU1ZDIGNhc2UgYW5kLCBhcyBpdCBpcw0K dXBkYXRlZCwgaXQgY291bGQgcmVxdWlyZSBGUi1hdHRhY2hlZCBQUFAgc3BlYWtlcnMgdG8gc3Bl YWsgbnVsbA0KZW5jYXBzdWxhdGlvbiBpbiBhZGRpdGlvbiB0byBOTFBJRC4gIElmIHNvLCBpdCB3 b3VsZCBvbmx5IGJlIEFUTS1hdHRhY2hlZA0KUFBQIHNwZWFrZXJzIHRoYXQgdXNlIFBWQ3MgdGhh dCByZXF1aXJlIExMQyBzdXBwb3J0IGZvciBpbnRlcm9wZXJhYmlsaXR5Lg0KDQpJbiBzdW1tYXJ5 LCBteSBjb25jZXJuIHdhcyBzaW1wbHkgdG8gcG9pbnQgb3V0IHRoYXQgdGhlIHdvcmtpbmcgZ3Jv dXAgaXMNCmJlaW5nIGFzayB0byBwdWJsaXNoIGEgZG9jdW1lbnQgdGhhdCBsZWFkcyB0byAiY29u Zm9ybWFudCBidXQNCm5vbi1pbnRlcm9wZXJhYmxlIiBpbXBsZW1lbnRhdGlvbnMuICBJIGJlbGll dmUgdGhhdCBldmVyeW9uZSBzaG91bGQgbm93DQp1bmRlcnN0YW5kIHRoZSBpc3N1ZS4NCg0KUmVn YXJkcywNCi1qYW1lcw0KDQo+SSBhbSBhbHNvIHZlcnkgc3VycHJpc2VkIHRoYXQgd2UgcmVvcGVu IHRoaXMgaXNzdWUgYXQgdGhpcyB2ZXJ5IGxhc3QgbWludXRlLg0KPlRoZSBiaWdnZXN0IGRyaXZp bmcgb3JpZ2luYWwgbW90aXZhdGlvbiBmb3IgdGhpcyBkcmFmdCBpcyB0byBzdXBwb3J0IEFEU0wu DQo+VGhlIEFEU0wgRm9ydW0gaGFzIHN1cHBvcnRlZCBhIGRyYWZ0IHNwZWNpZmljYXRpb24gYmFz ZWQgb24gbnVsbA0KPmVuY2Fwc3VsYXRpb24gZm9yIFBQUCBvdmVyIEFUTS4gVGhlcmUgYXJlIDM4 IGNvbXBhbmllcyBzdXBwb3J0aW5nIHRoaXMNCj5jdXJyZW50bHkuIFRoZSBkcmFmdCBzcGVjaWZp Y2F0aW9uIGlzIGdvaW5nIG91dCBvZiBiYWxsb3QgYWZ0ZXIgbGFzdCB3ZWVrJ3MNCj5tZWV0aW5n IHRvIHRhcmdldGVkIGJlY29tZSBhIGZpbmFsIHNwZWNpZmljYXRpb24gZm9yIHRoZSBuZXh0IG1l ZXRpbmcuIElmIHdlDQo+cmVvcGVuIHRoaXMgYXQgdGhlIGxhc3QgbWludXRlLCBpdCB3aWxsIGhh dmUgc2lnbmlmaWNhbnQgcmFtaWZpY2F0aW9uIGZvcg0KPnRoZSBBRFNMIGluZHVzdHJ5IGFuZCBm dXJ0aGVyIGRlbGF5IHRoZSBjb25zZW5zdXMgd2UgaGF2ZSBiZWVuIHRyeWluZyB2ZXJ5DQo+aGFy ZCB0byBhY2hpZXZlIGluIHRoZSBwYXN0IDE4IG1vbnRocyBhdCB0aGUgQURTTCBGb3J1bQ0KPg0K PkkgZnVsbHkgdW5kZXJzdGFuZCB0aGUgbmVlZCB0byBpbnRlcm9wZXJhdGUgd2l0aCBGUi4gSG93 ZXZlciwgZm9yIGFuIGVudGl0eQ0KPnRoYXQgaXMgb25seSBpbnRlcmVzdGVkIGluIHN1cHBvcnRp bmcgQURTTCBhcHBsaWNhdGlvbnMgZm9yIFBQUCBvdmVyIEFBTDUsDQo+d2Ugc2hvdWxkIG5vdCBp bXBvc2UgcmVzdHJpY3Rpb25zIG9uIHN1Y2ggZGV2aWNlcy4gSGVuY2UsIHdlIG11c3QgYWxsb3cN Cj5lbnRpdGllcyB0aGF0IGRvbid0IGhhdmUgaW50ZW50IG9mIHN1cHBvcnRpbmcgRlIgY2FuIGlt cGxlbWVudCBvbiBudWxsIGVuY2FwDQo+d2l0aG91dCBiZWluZyBub25jb21wbGlhbnQgdG8gdGhl IGRyYWZ0Lg0KPg0KPkkgd2Fzbid0IGFibGUgdG8gbWFrZSB0aGlzIElFVEYsIGJ1dCBJIGhvcGUg b3VyIGxpYXNvbiBmcm9tIHRoZSBBRFNMIEZvcnVtDQo+KERhdmUgQWxsYW4pIHdpbGwgb3IgaGFz IGFscmVhZHkgbWFkZSB0aGlzIGNhc2UgYXQgdGhlIElFVEYgbWVldGluZy4NCj4NCj5UaW0NCj4N Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOglBbmRyZXcgRy4gTWFsaXMg W1NNVFA6bWFsaXNAYWxwby5jYXNjLmNvbV0NCj4+IFNlbnQ6CUZyaWRheSwgRGVjZW1iZXIgMDUs IDE5OTcgMTo0OCBBTQ0KPj4gVG86CUphbWVzIFdhdHQNCj4+IENjOglnbWdAZ2FyYWdlLmx1Y2Vu dC5jb207IEFuZHJldyBHLiBNYWxpczsgUGhpbGlwIFJha2l0eTsNCj4+IGlldGYtcHBwQG1lcml0 LmVkdTsgZ21nQGdhcmFnZS5sdWNlbnQuY29tDQo+PiBTdWJqZWN0OglSZTogTGFzdCBjYWxsIG9u IGRyYWZ0LWlldGYtcHBwZXh0LWFhbDUtMDMudHh0DQo+Pg0KPj4gSmFtZXMsDQo+Pg0KPj4gPist LS0tLS0tLQ0KPj4gPj5Cb3R0b20gbGluZTogdGhlIGN1cnJlbnQgSUQgdGV4dCBsZWF2ZXMgdGhl IGZvbGxvd2luZyBxdWVzdGlvbg0KPj4gdW5hbnN3ZXJlZDoNCj4+ID4+DQo+PiA+PiA9PT0+IElz IHRoZSBhYmlsaXR5IHRvIGludGVyLW9wZXJhdGUgd2l0aCBhbiBSRkMxOTczL0ZSRi44IElXRg0K Pj4gPj4qbWFuZGF0b3J5KiBmb3INCj4+ID4+ICAgICAgY29tcGxpYW5jZSB3aXRoIHRoaXMgc3Bl Yz8gT3IgaXMgaXQgb3B0aW9uYWw/IFBsZWFzZSB0ZWxsIG1lIHlvdXINCj4+ID4+ICAgICAgcHJl ZmVyZW5jZS4NCj4+ID4rLS0tLS0tLS0NCj4+ID5Gb3IgdGhlIG1vc3QgYmFzaWMgb2YgcmVhc29u cywgaS5lLiB0aGF0IGJvdGggUkZDIDE5NzMgYW5kIEZSRi4qIGFscmVhZHkNCj4+IGV4aXN0LA0K Pj4gPkkgd291bGQgc3VnZ2VzdCB0aGF0IGludGVyb3BlcmFiaWxpdHkgaXMgbWFuZGF0b3J5Lg0K Pj4NCj4+IEkgZGlzYWdyZWUuICBUaGUgcHJpbWFyeSAoYWx0aG91Z2ggY2VydGFpbmx5IG5vdCB0 aGUgb25seSkgYXBwbGljYXRpb24gZm9yDQo+PiB0aGlzIHNwZWNpZmljYXRpb24gaXMgZm9yIHVz ZSB3aXRoIEFEU0wuICBGb3IgdGhhdCBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9uLA0KPj4gaW50ZXJv cGVyYXRpb24gd2l0aCBQUFAgb3ZlciBGUiBpcyBvZiBubyBpbnRlcmVzdCB3aGF0c292ZXIsIGFu ZCB0aGUNCj4+IGFiaWxpdHkgdG8gZG8gc28gc2hvdWxkIG5vdCBiZSByZXF1aXJlZCBpbiBvcmRl ciB0byBoYXZlIGEgY29tcGxpYW50DQo+PiBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzIHNwZWMuDQo+ Pg0KPj4gSE9XRVZFUiwgZm9yIG90aGVyIGFwcGxpY2F0aW9ucywgdGhlIGFiaWxpdHkgdG8gaW50 ZXJvcGVyYXRlIG1heSBjZXJ0YWlubHkNCj4+IG1ha2Ugc2Vuc2UsIGFuZCB2ZW5kb3JzIHdpbGwg ZmluZCBpdCBpbiB0aGVpciBjb21wZXRpdGl2ZSBpbnRlcmVzdCB0bw0KPj4gaW5jbHVkZSB0aGUg YWJpbGl0eSB0byBkbyBzby4NCj4+DQo+PiBXZSBjYW4gZGlzY3VzcyB0aGlzIGZ1cnRoZXIgaW4g dGhlIFdHIG1lZXRpbmcuDQo+Pg0KPj4gQ2hlZXJzLA0KPj4gQW5keQ0KPj4NCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gQW5kcmV3IEcuIE1hbGlzICBtYWxpc0Bhc2NlbmQuY29tICBwaG9uZTo5Nzgg OTUyLTc0MTQgICBmYXg6OTc4IDM5Mi0xNDg0DQo+PiBBc2NlbmQgQ29tbXVuaWNhdGlvbnMsIElu Yy4gICAgICAgIDEgUm9iYmlucyBSb2FkICAgICBXZXN0Zm9yZCwgTUEgMDE4ODYNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpKYW1lcyBXLiBXYXR0LAlqYW1lc3dAbmV3YnJpZGdlLmNvbQkJIFBo OiAoNjEzKSA1OTEtMzYwMA0KTmV3YnJpZGdlIE5ldHdvcmtzCTYwMCBNYXJjaCBSZCBLYW5hdGEg T04gQ2FuYWRhIEsySyAyRTYJIEZBWDooNjEzKQ0KNTkxLTM2ODANCg0KDQo= --0__=TSqKrpzK9qCmCToBCj5hvJMfSt4hVWlWqtRX7dkZNXJzzf0ucSNlggQc-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 16 10:45:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA06586; Tue, 16 Dec 1997 10:45:04 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 16 Dec 1997 10:44:36 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA06552 for ietf-ppp-outgoing; Tue, 16 Dec 1997 10:44:36 -0500 (EST) Received: from algw2.lucent.com (algw2.lucent.com [205.147.213.2]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA06548 for ; Tue, 16 Dec 1997 10:44:32 -0500 (EST) Cc: ietf-ppp@merit.edu, jhalpern@Newbridge.COM, dallan@nortel.com, timkwok@microsoft.com Received: from garage.lucent.com by alig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id KAA27281; Tue, 16 Dec 1997 10:47:06 -0500 Received: by garage.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id KAA01260; Tue, 16 Dec 1997 10:38:28 -0500 Date: Tue, 16 Dec 1997 10:38:28 -0500 Message-Id: <199712161538.KAA01260@garage.lucent.com> From: gmg@garage.lucent.com (garage!gmg) To: Robert.Jenness@stn.siemens.com, James Watt Original-Cc: ietf-ppp@merit.edu, jhalpern@Newbridge.COM, dallan@nortel.com, timkwok@microsoft.com Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, Here's what I would like to nominate as the final version of the text passage in question: 3. If an implementation is connecting through a Frame Relay/ATM FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, then it MUST use LLC encapsulated PPP payloads. Implementations that want to inter-operate with all potential end points MUST implement LLC encapsulated PPP payloads. The -03 version said "MUST support LLC encapsulated PPP..." instead of MUST use. The last sentence in the above text reflects a discussion held last week at the IETF between Andy Malis, James Watt, David Allan, and myself. The intent is to highlight the consequences of implementing only VC-multiplexed PPP payloads. George - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 16 16:40:18 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA12711; Tue, 16 Dec 1997 16:40:10 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 16 Dec 1997 16:39:14 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA12666 for ietf-ppp-outgoing; Tue, 16 Dec 1997 16:39:13 -0500 (EST) Received: from smtp-gw.BayNetworks.COM (ns3.BayNetworks.COM [192.32.253.3]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA12662 for ; Tue, 16 Dec 1997 16:39:08 -0500 (EST) Received: from mailhost.BayNetworks.COM ([134.177.1.109] (may be forged)) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id QAA09921 for ; Tue, 16 Dec 1997 16:38:20 -0500 (EST) Received: from lobster1.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with SMTP id NAA26156 for ; Tue, 16 Dec 1997 13:37:28 -0800 (PST) Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0) by lobster1.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA23646; Tue, 16 Dec 97 16:37:29 EST for ietf-ppp@merit.edu Received: from msun.corpeast.baynetworks.com ([141.251.20.106]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA25734 for ; Tue, 16 Dec 1997 16:37:03 -0500 Message-Id: <3.0.1.32.19971216152909.006d14b0@bl-mail1.corpeast.baynetworks.com> X-Sender: msun@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 16 Dec 1997 15:29:09 -0600 To: ietf-ppp@merit.edu From: Moses_Sun@BayNetworks.COM (Moses Sun) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu subsribe - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 17 09:32:48 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA20253; Wed, 17 Dec 1997 09:32:29 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Dec 1997 09:26:59 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA20185 for ietf-ppp-outgoing; Wed, 17 Dec 1997 09:26:59 -0500 (EST) Received: from bcarsde4.nortel.ca (mailgate.nortel.ca [192.58.194.74]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA20181 for ; Wed, 17 Dec 1997 09:26:53 -0500 (EST) Received: from zrchh190.us.nortel.com by bcarsde4.nortel.ca; Wed, 17 Dec 1997 09:26:03 -0500 Received: from nrtpde0a.us.nt.com (actually nrtpde0a.us.nortel.com) by zrchh190.us.nortel.com; Wed, 17 Dec 1997 08:23:08 -0600 Received: by nrtpde0a.us.nt.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD0ACD.0A8E18E0@nrtpde0a.us.nt.com>; Wed, 17 Dec 1997 09:20:39 -0500 Message-ID: From: "David Allan" To: "'Robert.Jenness@stn.siemens.com'" , "'James Watt'" , "'gmg@garage.lucent.com'" Cc: "'ietf-ppp@merit.edu'" , "'jhalpern@Newbridge.COM'" , "'timkwok@microsoft.com'" Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt Date: Wed, 17 Dec 1997 09:18:58 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu George: Only suggestion for readability of the section would be to move the third para out of the list. So you get: "When transporting.... 1) MUST 2) MAY 3) Used to be para 4 --> For SVC set up, an implementation.... If an implementation ....." No actual content change implied or otherwise.:-) Regards Dave >---------- >From: gmg@garage.lucent.com[SMTP:gmg@garage.lucent.com] >Sent: Tuesday, December 16, 1997 10:38 AM >To: Robert.Jenness@stn.siemens.com; James Watt >Cc: Allan, David (D.); ietf-ppp@merit.edu; jhalpern@Newbridge.COM; >timkwok@microsoft.com >Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > >Hi, > Here's what I would like to nominate as the final version of the >text passage in question: > >3. If an implementation is connecting through a Frame Relay/ATM > FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, > then it MUST use LLC encapsulated PPP payloads. Implementations > that want to inter-operate with all potential end points MUST > implement LLC encapsulated PPP payloads. > >The -03 version said "MUST support LLC encapsulated PPP..." instead of MUST >use. The last sentence in the above text reflects a discussion held last >week at the IETF between Andy Malis, James Watt, David Allan, and myself. >The intent is to highlight the consequences of implementing only >VC-multiplexed PPP payloads. > > George > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 17 13:47:28 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA23901; Wed, 17 Dec 1997 13:47:27 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Dec 1997 13:46:39 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA23866 for ietf-ppp-outgoing; Wed, 17 Dec 1997 13:46:39 -0500 (EST) Received: from gvmail.globalvillage.com ([198.93.137.253]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA23862 for ; Wed, 17 Dec 1997 13:46:32 -0500 (EST) Received: from sleet.globalvillage.com [198.93.138.50] by gvmail.globalvillage.com (SMTPD32-4.02c) id AE07585008E; Wed, 17 Dec 1997 10:46:31 PST Received: from ianp by sleet.globalvillage.com (SMI-8.6/SMI-SVR4) id KAA13559; Wed, 17 Dec 1997 10:46:18 -0800 Message-ID: <003e01bd0b1c$2f284500$46bf8acf@ianp.globalvillage.com> From: "Ian Puleston" To: Subject: Comments on draft-ietf-pppext-aal5-03.txt Date: Wed, 17 Dec 1997 10:47:09 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOle: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ppp@merit.edu Here are some comments on the draft: 1. There is no mention of the type of ATM call to make. Must it be UBR, or could it be nrt-VBR or ABR where supported (I'm not advocating anything other than UBR - just pointing out that the RFC doesn't bar them) ? 2. Following discussions at the ADSL Forum, the document should probably say that endpoints MUST implement Peak Cell Rate for transmission on UBR connections. A question here for any ATM experts around - is there also a case for requiring the use of the EFCI (flow control) bit for the same reason ? 3. Sections 5 and 6 are inconsistently formatted: - If Figure 2 was laid out like Figure 3, it would be more obvious how the two are related. - Figure 2 shows padding, Figure 3 doesn't (could imply that padding can be stripped from an LLC encapsulated frame). - Section 5 says that the PPP fields are specified in [1], but Section 6. explicitly specifies those same fields. 4. In section 8. the paragraph on multi-point connections seems to have been inserted in the middle of a discussion on encapsulation techniques. 5. The technique of detecting multi-point connections by looking for multiple LCP responses with the same identifier from different framing addresses seems to be flawed. Firstly there is no concept of a "framing address" to differentiate different senders. Secondly, RFC1661 states: "For retransmissions, the Identifier MAY remain unchanged". Therefore timing problems on a point-to-point VC could lead to multiple responses with the same identifier, which are normally silently discarded. Note also that point-to-multipoint and multipoint-to-point VCs are uni-directional so there would be no LCP responses. Rather than trying to get PPP to detect a multipoint connection, would it not be better to simply specify elsewhere that the ATM VC MUST be point-to-point. 6. The 2nd paragraph of section 8 specifies the difference between LLC-encapsulated and VC-muxed LCP frames, but needs to go farther. Can we rely on checking the 1st octet to be FE or C0 to detect the encapsulation technique, and if it is wrong what do we do? (discard the frame ?). 7. Also on Section 8. This section talks about a frame arriving in an "alternate but equivalent data encapsulation". It is not obvious what this means. Is it a frame with an LLC header when VC-muxing is in use and vice-versa ? If it is something else then the recovery procedures mentioned in the 1st paragraph are missing. If that assumption is correct, then the prescribed technique for handling the change in encapsulation technique (to re-enter link establishment phase) probably won't do much good since the encapsulation technique is not negotiated by LCP. Probably, such wrongly-encapsulated frames should just be silently discarded. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Dec 17 16:51:31 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA27177; Wed, 17 Dec 1997 16:51:21 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Dec 1997 16:50:31 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA27143 for ietf-ppp-outgoing; Wed, 17 Dec 1997 16:50:31 -0500 (EST) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA27131 for ; Wed, 17 Dec 1997 16:50:23 -0500 (EST) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id NAA12794; Wed, 17 Dec 1997 13:50:14 -0800 Received: from ascend.com by ascend.com with ESMTP id NAA17498; Wed, 17 Dec 1997 13:50:11 -0800 Received: from gump.eng.ascend.com (gump.eng.ascend.com [206.65.212.67]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id NAA20535; Wed, 17 Dec 1997 13:50:10 -0800 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id NAA09236; Wed, 17 Dec 1997 13:49:58 -0800 Date: Wed, 17 Dec 1997 13:49:58 -0800 Message-Id: <199712172149.NAA09236@gump.eng.ascend.com> From: Karl Fox To: Jeff Burgan , Thomas Narten CC: ietf-ppp@merit.edu Subject: Washington, D.C. PPPEXT Meeting Summary Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu DESE, PPP over AAL5 and PPP over FUNI are all currently in WG last call. 3DESE and the PPP LCP Extensions draft are awaiting IESG approval. The earlier interoperability experience poll for PPP LCP Callback will be repeated, this time with a detailed form to ensure adequate detail is provided. The Self Describing Padding draft will be reissued awaiting either adequate interoperability experience to move to Draft Standard, or a decision to move it to Informational. PPP with Framing Conversion was recommended to go forward as a BCP. PPP in Frame Relay and PPP in X.25 should move forward to Draft Standard after conducting interoperability polls. The draft "PPP for Asynchronous PAD to Synchronous X.25 access", draft-rfced-info-khana-01.txt, really falls under the domain of the ITU since it basically involves an assigned number used to mark X.3 PAD sessions as carrying PPP. Gary Malkin described Bay's Multi-link Multi-node PPP protocol, receiving a number of requests for enhancements, including the ability for a multilink bundle "server" to receive incoming calls. Questions were raised about the viability of terminating the various links of a bundle on different vendors' equipment, each of which may have different and possibly incompatible default LCP options. Anita Freeman announced the next CIUG Interoperability Workshop, which will be held the week of February 23rd. Stuart Cheshire described a new PPP framing technique that has better average case overhead and dramatically better worst case overhead than the standard PPP byte-stuffing approach. Although it is quite complex, it may be suitable for applications on dialups or SONET links where predictability of link usage is important, e.g. when bandwidth reservation is in use. Draft -09 of L2TP will be published before the end of the year, containing only editorial changes and one operational change. Packet ordering must now be negotiated when an IP network is the carrier, but the NR and NS fields may be omitted from packets at the discretion of the sender. The L2TP MIB structure will be changed to put each tunnel under an interface table entry. Two different drafts were presented for securing L2TP; the -02 version of L2TP Security Extensions for Non-IP Networks, an integrated L2TP-specific extension which incorporates IPSEC concepts, and a new draft which says to use IPSEC on IP networks and describes how to encapsulate IPSEC headers on non-IP networks. Questions were raised on how difficult it would be to apply ISAKMP/Oakley to non-IP situations, as the IP DOI is apparently a less than perfect fit. Drafts were also presented on L2TP header compression and L2TP Alternate Data Channel, a technique for providing multiple L2TP paths to allow splitting the data stream according to differing security (or other) requirements. Bernard Aboba and Jim Zmuda each presented cryptographically based authentication protocols based on EAP, each complaining that EAP is a poor fit. It was suggested that should not use EAP, perhaps working together to come up with a common framework. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 04:10:20 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA03909; Thu, 18 Dec 1997 04:10:17 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 04:08:38 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA03872 for ietf-ppp-outgoing; Thu, 18 Dec 1997 04:08:37 -0500 (EST) Received: from messenger.rnd.co.il ([207.232.32.59]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA03862 for ; Thu, 18 Dec 1997 04:08:27 -0500 (EST) Received: by MESSENGER with Internet Mail Service (5.0.1458.49) id ; Thu, 18 Dec 1997 11:09:33 +0200 Message-ID: <0124851EDBF3D011AAA300008370C8670AAA93@MESSENGER> From: Ohad Dekel To: ietf-ppp@merit.edu Subject: IPCP IP address Date: Thu, 18 Dec 1997 11:09:30 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BD0BA5.6B416880" Sender: owner-ietf-ppp@merit.edu This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_001_01BD0BA5.6B416880 Content-Type: text/plain hi, I'll thank anyone's help in the next issue: When assigning an IP address through the PPP IPCP IP address option, no information about the subnet mask exchanges. Is there a common solution to this problem? ( by using class A/B/C as default \ using always RIP1 on this link \ learning the subnet from HELLO messages(OSPF), or RIP2 routing information exchange ?....) thanx, Ohad Dekel ------ =_NextPart_001_01BD0BA5.6B416880 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

hi,
I'll thank anyone's help in the next issue:

When assigning an IP address through the PPP IPCP IP = address option, no information about the subnet mask exchanges.

Is there a common solution to this problem? ( by = using class A/B/C as default  \  using always  RIP1 on = this link  \  learning the subnet from HELLO messages(OSPF), = or RIP2 routing information exchange ?....)


thanx,
Ohad Dekel

------ =_NextPart_001_01BD0BA5.6B416880-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 08:31:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA05838; Thu, 18 Dec 1997 08:31:44 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 08:27:02 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA05767 for ietf-ppp-outgoing; Thu, 18 Dec 1997 08:27:01 -0500 (EST) Received: from ub-gate.UB.com (ub-gate.UB.com [192.216.34.11]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA05762 for ; Thu, 18 Dec 1997 08:26:56 -0500 (EST) Received: from andr.ub.com. (sunny.andr.ub.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.9.1]) id AA03878; Thu, 18 Dec 97 02:39:35 PST Received: from ironbridge.andr.ub.com (ironbridge.andr.ub.com [138.120.246.66]) by andr.ub.com. (8.8.5/8.8.5) with SMTP id IAA09335; Thu, 18 Dec 1997 08:24:43 -0500 (EST) Received: by ironbridge.andr.ub.com (SMI-8.6/SMI-SVR4) id IAA10943; Thu, 18 Dec 1997 08:22:46 -0500 Date: Thu, 18 Dec 1997 08:22:46 -0500 Message-Id: <199712181322.IAA10943@ironbridge.andr.ub.com> From: James Carlson To: OhadD@rnd.co.il Cc: ietf-ppp@merit.edu In-Reply-To: <0124851EDBF3D011AAA300008370C8670AAA93@MESSENGER> (message from Ohad Dekel on Thu, 18 Dec 1997 11:09:30 +0200) Subject: Re: IPCP IP address References: <0124851EDBF3D011AAA300008370C8670AAA93@MESSENGER> Sender: owner-ietf-ppp@merit.edu > I'll thank anyone's help in the next issue: > > When assigning an IP address through the PPP IPCP IP address option, no > information about the subnet mask exchanges. This is quite intentional. PPP links do not work on broadcast media, so there's no need for a subnet definition. A PPP link simply links two individual IP hosts together. > Is there a common solution to this problem? ( by using class A/B/C as > default \ using always RIP1 on this link \ learning the subnet from > HELLO messages(OSPF), or RIP2 routing information exchange ?....) Personally, I treat the remote address on a PPP link as a host route ("subnet" mask 255.255.255.255) and use any available routing protocol (or static routes) to set up routes to any networks reachable over the link. The subnet mask isn't meaningful, so, for those administrators who insist on having such things, I generate a separate static route to represent it. -- James Carlson, Consulting Engineer IronBridge Networks / 5 Corporate Drive Vox: +1 978 691 4644 Andover MA 01810-2448 / USA Fax: +1 978 691 6300 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 10:05:12 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA07244; Thu, 18 Dec 1997 10:05:07 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 10:04:12 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA07188 for ietf-ppp-outgoing; Thu, 18 Dec 1997 10:04:12 -0500 (EST) Received: from relay2.smtp.psi.net (relay2.smtp.psi.net [38.8.188.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA07178 for ; Thu, 18 Dec 1997 10:04:07 -0500 (EST) Received: from donna.txc.com by relay2.smtp.psi.net (8.8.5/SMI-5.4-PSI) id KAA05248; Thu, 18 Dec 1997 10:04:04 -0500 (EST) Received: from joep.txc.com by donna.txc.com (4.1/SMI-4.1) id AA06265; Thu, 18 Dec 97 10:03:17 EST Message-Id: <9712181503.AA06265@donna.txc.com> From: "Joseph Pereira" To: Cc: "Jati Vij" , "Bill Bartholomay" Subject: PPP Bit ordering for PPP over SONET/SDH Date: Thu, 18 Dec 1997 09:59:28 -0500 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu I would appreciate any input on the following issues: 1. Bit ordering: This is has been a point of confusion for me. Let me illustrate my question with an example: Say I have a PPP frame in HDLC-like framing with 16 bit CRC. And I had one data byte, 0x7D (the control escape character) in the info field. The bytes of the PPP in HDLC like frame should look like 0x7E 0XFF 0X03 0X7D 0X5D CRC CRC. These bits are shown below with the ISO bit ordering for HDLC: MSB LSB Bit 7 6 5 4 3 2 1 0 ---------------------------------------------------------------------------- -------------------------------- 0x7E 0 1 1 1 1 1 1 0 0XFF 1 1 1 1 1 1 1 1 0X03 0 0 0 0 0 0 1 1 0X7D 0 1 1 1 1 1 0 1 0X5D 0 1 0 1 1 1 0 1 CRC X^8 ................................................................... X^15 CRC X^0 .................................................................. X^7 In the ISO documents the bits are transmitted from RIGHT to LEFT. However, what would the outgoing SONET/SDH data stream look like after these bits are serialized? The confusion results because it is my understanding that the SONET/SDH bits are transmitted MSB first. That is I bit 7 above would correspond to the first bit transmitted n the SONET/SDH stream and also corresponds to what is called bit 1 in the SONET/SDH specs. I have shown an example of what I think it would look like but I am not sure that it is correct. An A1 (0xF6) and an A2 (0x28) SONET/SDH framing byte are shown for reference: 1111 0110....0010 1000....0111 1110 1111 1111 0000 0011 0111 1101 0101 1101 X^8...X^15 X^0..X7 0111 1110 ....... The bits above are transmitted from left to right. X^15 .. X^0 are the CRC bits. Let me explain what they mean. Think of the CRC generator as a shift register (serial implementation) with the appropriate XOR feedbacks. Let's number the bits of the SR input -> output 0 -> 15. As an example, the control escape character (0x7D) would be shifted into the CRC generator as 1011 1110, where the bits are shifted in from left to right (i.e. LSB first). It is clear that the coefficient of the highest term is the output end of the SR (bit15). Therefore, the octet 8-15 will be transmitted first. Since this is a 16 bit value (for crc16), and bits 8-15 are the least significant octet, the bit we have numbered 15 is the LSBit of the CRC and the octet. Now, Sonet always transmits MSbit of a byte first. So, the transmission order should be bits 8,9,10,11,12,13,14,15,(LSByte -MSBit first) 0,1,2,3,4,5,6,7 (MSByte -MSBit first). 2) The second question is regarding the 1+X^43 polynomial PPP scrambler. Do the bytes get inserted into the scrambler MSB first or LSB first with respect to the bit ordering shown above? If anyone can help me here, and possible show an example, I would be truly grateful. kind regards, Joseph M. Pereira - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 10:28:42 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA07690; Thu, 18 Dec 1997 10:28:42 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 10:28:25 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA07665 for ietf-ppp-outgoing; Thu, 18 Dec 1997 10:28:25 -0500 (EST) Received: from bcarsde4.nortel.ca (mailgate.nortel.ca [192.58.194.74]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA07661 for ; Thu, 18 Dec 1997 10:28:20 -0500 (EST) Received: from zrchh190.us.nortel.com by bcarsde4.nortel.ca; Thu, 18 Dec 1997 10:25:44 -0500 Received: from nrtpde0a.us.nt.com (actually nrtpde0a.us.nortel.com) by zrchh190.us.nortel.com; Thu, 18 Dec 1997 09:24:28 -0600 Received: by nrtpde0a.us.nt.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BD0B9E.F80EF4F0@nrtpde0a.us.nt.com>; Thu, 18 Dec 1997 10:23:23 -0500 Message-ID: From: "David Allan" To: "'ietf-ppp'" , "'Ian Puleston'" Subject: RE: Comments on draft-ietf-pppext-aal5-03.txt Date: Thu, 18 Dec 1997 09:34:39 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Ian: Re your points 1 and 2. These are really ATM transport issues and orthogonal to the payload protocol spec. I don't think we need to address them in this I-D. As for section 8, a review of my PPPEXT archive does not see a discussion of the problem space so I'm going to make a few guesses and hope someone straightens me out. If this is loss of session over a PVC then I'll admit I'd like to see a more reliable technique for detection and recovery than hoping for an encap configuration change ;-). It is reasonable to assume that if there is an unexpected change in encap, then the link has been down and re-establish procedures are required, but this really looks like a problem with synchronizing provisioning/configuration. If I read section 4 points 1 and 2 correctly, an end point is not provisioned to receive arbitrary encapsulation, it is either provisioned (PVC) or negotiated (SVC) to a single style of encap and your statement that unexpected encap should be silently discarded seems correct: receiving an unexpected encapsulation is an error. It is certainly much simpler to implement silent discard than the heuristic approach suggested, and this would translate to simpler implementations AND more scalable terminations. I would suggest that one (or some small number in a row) of invalid PDUs (not the negotiated encap but otherwise well formed) will result in pushing the link back to link establish state (or call cleared for SVC) combined with silent discard of invalid PDUs on the assumption that the correctly negotiated session has been lost (or under abuse) and the rest is noise. Cheers Dave >---------- >From: Ian Puleston[SMTP:ian_puleston@globalvillage.com] >Sent: Wednesday, December 17, 1997 1:47 PM >To: ietf-ppp >Subject: Comments on draft-ietf-pppext-aal5-03.txt > >Here are some comments on the draft: > >1. There is no mention of the type of ATM call to make. Must it be UBR, or >could it be nrt-VBR or ABR where supported (I'm not advocating anything >other than UBR - just pointing out that the RFC doesn't bar them) ? > >2. Following discussions at the ADSL Forum, the document should probably say >that endpoints MUST implement Peak Cell Rate for transmission on UBR >connections. > >A question here for any ATM experts around - is there also a case for >requiring the use of the EFCI (flow control) bit for the same reason ? > >3. Sections 5 and 6 are inconsistently formatted: >- If Figure 2 was laid out like Figure 3, it would be more obvious how the >two are related. >- Figure 2 shows padding, Figure 3 doesn't (could imply that padding can be >stripped from an LLC encapsulated frame). >- Section 5 says that the PPP fields are specified in [1], but Section 6. >explicitly specifies those same fields. > >4. In section 8. the paragraph on multi-point connections seems to have been >inserted in the middle of a discussion on encapsulation techniques. > >5. The technique of detecting multi-point connections by looking for >multiple LCP responses with the same identifier from different framing >addresses seems to be flawed. Firstly there is no concept of a "framing >address" to differentiate different senders. Secondly, RFC1661 states: "For >retransmissions, the Identifier MAY remain unchanged". Therefore timing >problems on a point-to-point VC could lead to multiple responses with the >same identifier, which are normally silently discarded. > >Note also that point-to-multipoint and multipoint-to-point VCs are >uni-directional so there would be no LCP responses. > >Rather than trying to get PPP to detect a multipoint connection, would it >not be better to simply specify elsewhere that the ATM VC MUST be >point-to-point. > >6. The 2nd paragraph of section 8 specifies the difference between >LLC-encapsulated and VC-muxed LCP frames, but needs to go farther. Can we >rely on checking the 1st octet to be FE or C0 to detect the encapsulation >technique, and if it is wrong what do we do? (discard the frame ?). > >7. Also on Section 8. This section talks about a frame arriving in an >"alternate but equivalent data encapsulation". It is not obvious what this >means. Is it a frame with an LLC header when VC-muxing is in use and >vice-versa ? If it is something else then the recovery procedures mentioned >in the 1st paragraph are missing. > >If that assumption is correct, then the prescribed technique for handling >the change in encapsulation technique (to re-enter link establishment phase) >probably won't do much good since the encapsulation technique is not >negotiated by LCP. Probably, such wrongly-encapsulated frames should just be >silently discarded. > > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 10:36:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA07912; Thu, 18 Dec 1997 10:36:56 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 10:36:38 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA07880 for ietf-ppp-outgoing; Thu, 18 Dec 1997 10:36:37 -0500 (EST) Received: from wwwnni.us.newbridge.com (wwwnni.us.newbridge.com [204.177.219.11]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA07873 for ; Thu, 18 Dec 1997 10:36:32 -0500 (EST) Received: from herndon-gw1.us.newbridge.com (herndon-gw1 [204.177.219.66]) by wwwnni.us.newbridge.com (8.8.5/8.6.12) with SMTP id KAA02671; Thu, 18 Dec 1997 10:41:49 -0500 (EST) Received: from hernmaster.us.newbridge.com ([138.120.108.6]) by herndon-gw1.us.newbridge.com via smtpd (for wwwnni.us.newbridge.com [204.177.219.11]) with SMTP; 18 Dec 1997 15:35:59 UT Received: (from smap@localhost) by us.newbridge.com. (8.8.6/8.8.6) id KAA06917; Thu, 18 Dec 1997 10:35:58 -0500 (EST) Received: from mako.us.newbridge.com(138.120.108.44) by hernmaster.us.newbridge.com via smap (V1.3) id sma006910; Thu Dec 18 10:35:55 1997 Received: from lobster.nni by mako.us.newbridge.com (SMI-8.6/SMI-SVR4) id KAA05595; Thu, 18 Dec 1997 10:35:50 -0500 Received: from localhost by lobster.nni (SMI-8.6/SMI-SVR4) id KAA01786; Thu, 18 Dec 1997 10:35:50 -0500 Date: Thu, 18 Dec 1997 10:35:50 -0500 (EST) From: Joel Halpern X-Sender: jhalpern@lobster To: David Allan cc: "'Robert.Jenness@stn.siemens.com'" , "'James Watt'" , "'gmg@garage.lucent.com'" , "'ietf-ppp@merit.edu'" , "'timkwok@microsoft.com'" Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu I must observe that writing into a proposed RFC text which reads: Implementations Should X Implementations which do not X will not interoperate with Y Is a clear invitation for someone to push harder on the question I am asking: Why not MUST X? Yours, Joel M. Halpern On Wed, 17 Dec 1997, David Allan wrote: > George: > > Only suggestion for readability of the section would be to move the > third para out of the list. So you get: > > "When transporting.... > > 1) MUST > > 2) MAY > > 3) Used to be para 4 --> For SVC set up, an implementation.... > > If an implementation ....." > > No actual content change implied or otherwise.:-) > > Regards > Dave > > >---------- > >From: gmg@garage.lucent.com[SMTP:gmg@garage.lucent.com] > >Sent: Tuesday, December 16, 1997 10:38 AM > >To: Robert.Jenness@stn.siemens.com; James Watt > >Cc: Allan, David (D.); ietf-ppp@merit.edu; jhalpern@Newbridge.COM; > >timkwok@microsoft.com > >Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > > > >Hi, > > Here's what I would like to nominate as the final version of the > >text passage in question: > > > >3. If an implementation is connecting through a Frame Relay/ATM > > FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, > > then it MUST use LLC encapsulated PPP payloads. Implementations > > that want to inter-operate with all potential end points MUST > > implement LLC encapsulated PPP payloads. > > > >The -03 version said "MUST support LLC encapsulated PPP..." instead of MUST > >use. The last sentence in the above text reflects a discussion held last > >week at the IETF between Andy Malis, James Watt, David Allan, and myself. > >The intent is to highlight the consequences of implementing only > >VC-multiplexed PPP payloads. > > > > George > > > > > Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 11:01:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA08472; Thu, 18 Dec 1997 11:01:28 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 11:00:57 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA08447 for ietf-ppp-outgoing; Thu, 18 Dec 1997 11:00:56 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA08443 for ; Thu, 18 Dec 1997 11:00:52 -0500 (EST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Thu, 18 Dec 1997 08:01:45 -0800 Message-ID: From: Timothy Kwok To: "'Joel Halpern'" , David Allan Cc: "'Robert.Jenness@stn.siemens.com'" , "'James Watt'" , "'gmg@garage.lucent.com'" , "'ietf-ppp@merit.edu'" Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt Date: Thu, 18 Dec 1997 08:00:41 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ppp@merit.edu Good question, Joel. The major motivation of driving this RFC is for ADSL environment from vendors and carriers eager to deploy ADSL service ASAP and supporting Y in such environments is not the focus at all. Forcing the ADSL environment to use X is a burden to those environments. Hence, this RFC is really saying 1. X is recommended, but optional (so its not a burden to those who has no intention of supporting Y) 2. AND, IF you are interested in interoperating with Y, you MUST X. Also, IF you are interested interoperating with ALL scenarios, you MUST X. Tim > -----Original Message----- > From: Joel Halpern [SMTP:jhalpern@us.newbridge.com] > Sent: Thursday, December 18, 1997 7:36 AM > To: David Allan > Cc: 'Robert.Jenness@stn.siemens.com'; 'James Watt'; > 'gmg@garage.lucent.com'; 'ietf-ppp@merit.edu'; Timothy Kwok > Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > > I must observe that writing into a proposed RFC text which reads: > Implementations Should X > Implementations which do not X will not interoperate with Y > Is a clear invitation for someone to push harder on the question I am > asking: > Why not MUST X? > > Yours, > Joel M. Halpern > > On Wed, 17 Dec 1997, David Allan wrote: > > > George: > > > > Only suggestion for readability of the section would be to move the > > third para out of the list. So you get: > > > > "When transporting.... > > > > 1) MUST > > > > 2) MAY > > > > 3) Used to be para 4 --> For SVC set up, an implementation.... > > > > If an implementation ....." > > > > No actual content change implied or otherwise.:-) > > > > Regards > > Dave > > > > >---------- > > >From: gmg@garage.lucent.com[SMTP:gmg@garage.lucent.com] > > >Sent: Tuesday, December 16, 1997 10:38 AM > > >To: Robert.Jenness@stn.siemens.com; James Watt > > >Cc: Allan, David (D.); ietf-ppp@merit.edu; > jhalpern@Newbridge.COM; > > >timkwok@microsoft.com > > >Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > > > > > >Hi, > > > Here's what I would like to nominate as the final version of the > > >text passage in question: > > > > > >3. If an implementation is connecting through a Frame Relay/ATM > > > FRF.8 [7] service inter-working unit to an RFC 1973 [6] end point, > > > then it MUST use LLC encapsulated PPP payloads. Implementations > > > that want to inter-operate with all potential end points MUST > > > implement LLC encapsulated PPP payloads. > > > > > >The -03 version said "MUST support LLC encapsulated PPP..." instead of > MUST > > >use. The last sentence in the above text reflects a discussion held > last > > >week at the IETF between Andy Malis, James Watt, David Allan, and > myself. > > >The intent is to highlight the consequences of implementing only > > >VC-multiplexed PPP payloads. > > > > > > George > > > > > > > > > > Yours, > Joel M. Halpern jhalpern@newbridge.com > Newbridge Networks Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 11:56:49 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA09477; Thu, 18 Dec 1997 11:56:48 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 11:54:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA09414 for ietf-ppp-outgoing; Thu, 18 Dec 1997 11:54:48 -0500 (EST) Received: from dogwood-fddi.cisco.com (dogwood-fddi.cisco.com [171.68.122.80]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA09401 for ; Thu, 18 Dec 1997 11:54:42 -0500 (EST) Received: from chsharp-pc.cisco.com (chsharp-isdn1.cisco.com [171.68.116.222]) by dogwood-fddi.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id LAA01420; Thu, 18 Dec 1997 11:54:10 -0500 (EST) Message-ID: <3499549C.4AEF@cisco.com> Date: Thu, 18 Dec 1997 11:51:41 -0500 From: Chip Sharp Reply-To: chsharp@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 3.0C-CISCOENG (Win95; I) MIME-Version: 1.0 To: ietf-ppp@merit.edu CC: karl@ascend.com Subject: PPP with Framing Conversion References: <199712172149.NAA09236@gump.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Karl Fox wrote in PPPEXT Meeting Summary: ...snip... > PPP with Framing Conversion was recommended to go forward as a BCP. ...snip... I assume this will be based on consensus on the list. The PPP with Framing Conversion draft makes sense as a BCP, but there are some modifications I'd recommend before forwarding to the IESG for last call. If you'd like I'll repost my previous post with my comments. Thanks, Chip ------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Engineer-ISP/telco ------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 12:02:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA09634; Thu, 18 Dec 1997 12:02:52 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 12:01:12 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA09580 for ietf-ppp-outgoing; Thu, 18 Dec 1997 12:01:12 -0500 (EST) Received: from wwwnni.us.newbridge.com (wwwnni.us.newbridge.com [204.177.219.11]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA09576 for ; Thu, 18 Dec 1997 12:01:07 -0500 (EST) Received: from herndon-gw1.us.newbridge.com (herndon-gw1 [204.177.219.66]) by wwwnni.us.newbridge.com (8.8.5/8.6.12) with SMTP id MAA03872; Thu, 18 Dec 1997 12:06:24 -0500 (EST) Received: from hernmaster.us.newbridge.com ([138.120.108.6]) by herndon-gw1.us.newbridge.com via smtpd (for wwwnni.us.newbridge.com [204.177.219.11]) with SMTP; 18 Dec 1997 17:00:34 UT Received: (from smap@localhost) by us.newbridge.com. (8.8.6/8.8.6) id MAA02310; Thu, 18 Dec 1997 12:00:33 -0500 (EST) Received: from mako.us.newbridge.com(138.120.108.44) by hernmaster.us.newbridge.com via smap (V1.3) id sma002302; Thu Dec 18 12:00:23 1997 Received: from lobster.nni by mako.us.newbridge.com (SMI-8.6/SMI-SVR4) id MAA06249; Thu, 18 Dec 1997 12:00:09 -0500 Received: from localhost by lobster.nni (SMI-8.6/SMI-SVR4) id MAA01824; Thu, 18 Dec 1997 12:00:09 -0500 Date: Thu, 18 Dec 1997 12:00:08 -0500 (EST) From: Joel Halpern X-Sender: jhalpern@lobster To: Timothy Kwok cc: "'Joel Halpern'" , David Allan , "'Robert.Jenness@stn.siemens.com'" , "'James Watt'" , "'gmg@garage.lucent.com'" , "'ietf-ppp@merit.edu'" Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Thu, 18 Dec 1997, Timothy Kwok wrote: > Good question, Joel. > > The major motivation of driving this RFC is for ADSL environment from > vendors and carriers eager to deploy ADSL service ASAP and supporting Y in > such environments is not the focus at all. Forcing the ADSL environment to > use X is a burden to those environments. > > Hence, this RFC is really saying > 1. X is recommended, but optional (so its not a burden to those who has no > intention of supporting Y) > 2. AND, IF you are interested in interoperating with Y, you MUST X. Also, IF > you are interested interoperating with ALL scenarios, you MUST X. > > Tim Time, I am very sympathetic to your view that there is a specific envirmonemtn where Y does not apply, and that is the problem to be solved. Two issues, from lessor to greater: 1) The Document title and Scope is not "ADSL support", but "PPP Over ATM". If we only want to solve ADSL, we should say so. 2) More significantly, I think that FR interworking does apply to ADSL. For example, consider a work-at-home or remote office, using ADSL to access an ATM service, which is directly interworked with the FR service that the corporation uses. Instead of using L2TP tunnels (which are an option), the user simply establishes VCs directly to the corporate infrastructure and runs IP over them. If I can think of one case, I am sure that there are others. Suppose that the ISP is actually using FR rather than ATM, and is reached through an interworking function. So, I tend to feel that the device can not "know" at manufacturing time that it will never have to deal with FR interworking. > > > -----Original Message----- > > From: Joel Halpern [SMTP:jhalpern@us.newbridge.com] > > Sent: Thursday, December 18, 1997 7:36 AM > > To: David Allan > > Cc: 'Robert.Jenness@stn.siemens.com'; 'James Watt'; > > 'gmg@garage.lucent.com'; 'ietf-ppp@merit.edu'; Timothy Kwok > > Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > > > > I must observe that writing into a proposed RFC text which reads: > > Implementations Should X > > Implementations which do not X will not interoperate with Y > > Is a clear invitation for someone to push harder on the question I am > > asking: > > Why not MUST X? > > > > Yours, > > Joel M. Halpern > > > > ... Other content elided ... Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 13:20:34 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA10914; Thu, 18 Dec 1997 13:20:32 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 13:18:15 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA10877 for ietf-ppp-outgoing; Thu, 18 Dec 1997 13:18:14 -0500 (EST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA10871 for ; Thu, 18 Dec 1997 13:18:08 -0500 (EST) Received: by mail5.microsoft.com with Internet Mail Service (5.5.1960.3) id ; Thu, 18 Dec 1997 10:17:09 -0800 Message-ID: From: Timothy Kwok To: "'Joel Halpern'" Cc: David Allan , "'Robert.Jenness@stn.siemens.com'" , "'James Watt'" , "'gmg@garage.lucent.com'" , "'ietf-ppp@merit.edu'" Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt Date: Thu, 18 Dec 1997 10:14:54 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ietf-ppp@merit.edu Joe, You are right. A vendor may not know what the user is going to use its equipment for. But isn't this a marketing decision for that vendor ? If the vendor reads this RFC, they know that if they only want to target nonFR interworking market, it is optional for them to do X. But if they want to target the FR interworking market in the PVC environment, they MUST do X. This RFC clearly spells that out. We should not remove the choice from the vendor to make their product decisions. Otherwise, we are using this RFC to make the product decision for all vendors, independent of their market. Tim > -----Original Message----- > From: Joel Halpern [SMTP:jhalpern@us.newbridge.com] > Sent: Thursday, December 18, 1997 9:00 AM > To: Timothy Kwok > Cc: 'Joel Halpern'; David Allan; 'Robert.Jenness@stn.siemens.com'; > 'James Watt'; 'gmg@garage.lucent.com'; 'ietf-ppp@merit.edu' > Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > > On Thu, 18 Dec 1997, Timothy Kwok wrote: > > > Good question, Joel. > > > > The major motivation of driving this RFC is for ADSL environment from > > vendors and carriers eager to deploy ADSL service ASAP and supporting Y > in > > such environments is not the focus at all. Forcing the ADSL environment > to > > use X is a burden to those environments. > > > > Hence, this RFC is really saying > > 1. X is recommended, but optional (so its not a burden to those who has > no > > intention of supporting Y) > > 2. AND, IF you are interested in interoperating with Y, you MUST X. > Also, IF > > you are interested interoperating with ALL scenarios, you MUST X. > > > > Tim > > Time, I am very sympathetic to your view that there is a specific > envirmonemtn where Y does not apply, and that is the problem to be solved. > Two issues, from lessor to greater: > 1) The Document title and Scope is not "ADSL support", but "PPP Over ATM". > If we only want to solve ADSL, we should say so. > > 2) More significantly, I think that FR interworking does apply to ADSL. > For example, consider a work-at-home or remote office, using ADSL to > access an ATM service, which is directly interworked with the FR > service that the corporation uses. Instead of using L2TP tunnels > (which are an option), the user simply establishes VCs directly to the > corporate infrastructure and runs IP over them. > If I can think of one case, I am sure that there are others. > Suppose that the ISP is actually using FR rather than ATM, and is > reached through an interworking function. > > So, I tend to feel that the device can not "know" at manufacturing time > that it will never have to deal with FR interworking. > > > > > > -----Original Message----- > > > From: Joel Halpern [SMTP:jhalpern@us.newbridge.com] > > > Sent: Thursday, December 18, 1997 7:36 AM > > > To: David Allan > > > Cc: 'Robert.Jenness@stn.siemens.com'; 'James Watt'; > > > 'gmg@garage.lucent.com'; 'ietf-ppp@merit.edu'; Timothy Kwok > > > Subject: RE: Last call on draft-ietf-pppext-aal5-03.txt > > > > > > I must observe that writing into a proposed RFC text which reads: > > > Implementations Should X > > > Implementations which do not X will not interoperate with Y > > > Is a clear invitation for someone to push harder on the question I am > > > asking: > > > Why not MUST X? > > > > > > Yours, > > > Joel M. Halpern > > > > > > ... Other content elided ... > > Yours, > Joel M. Halpern jhalpern@newbridge.com > Newbridge Networks Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 13:43:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA11361; Thu, 18 Dec 1997 13:43:56 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 13:42:14 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA11294 for ietf-ppp-outgoing; Thu, 18 Dec 1997 13:42:13 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm365-29.dialip.mich.net [207.75.186.39]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA11284; Thu, 18 Dec 1997 13:42:03 -0500 (EST) Date: Thu, 18 Dec 97 16:54:47 GMT From: "William Allen Simpson" Message-ID: <6868.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Cc: "Jati Vij" , "Bill Bartholomay" Subject: Re: PPP Bit ordering for PPP over SONET/SDH Sender: owner-ietf-ppp@merit.edu I tried to answer your question at least once already, when you asked privately. > From: "Joseph Pereira" > In the ISO documents the bits are transmitted from RIGHT to LEFT. > No, on bit-synchronous and asynchronous over many low speed serial links the bits are transmitted least significant to most significant within bytes. This has nothing to do with ISO, and in fact was adopted by IBM for SDLC long ago, and independently by EIA for async. It is media specific. Also, to avoid exactly this problem, as noted in RFC-1662, in the IETF we do not number our bits in transmission order -- a terrible convention that has caused confusion on ethernet as well. Instead, we number them in "canonical" order within bytes. > However, what would the outgoing SONET/SDH data stream look like after > these bits are serialized? The confusion results because it is my > understanding that the SONET/SDH bits are transmitted MSB first. That is correct. What is confusing? The media is the same as FDDI. Instead of wasting time reading ISO documents, stick to RFC-1662. There is no such thing as octet-synchronous in ISOese. RFC-1662 is the standard. > Therefore, the octet 8-15 will be transmitted first. Since this is a 16 bit > value (for crc16), and bits 8-15 are the least significant octet, the bit > we have numbered 15 is the LSBit of the CRC and the octet. Now, Sonet > always transmits MSbit of a byte first. So, the transmission order should > be bits 8,9,10,11,12,13,14,15,(LSByte -MSBit first) 0,1,2,3,4,5,6,7 (MSByte > -MSBit first). > We do not use the old CRC16, we use FCS-16, a different polynomial and algorithm. That bit order looks right, but only if you think of the FCS as a shift register. That is only one implementation. A faster implementation is done with bytes and words, as documented in RFC-1662. > 2) The second question is regarding the 1+X^43 polynomial PPP scrambler. > > Do the bytes get inserted into the scrambler MSB first or LSB first with > respect to the bit ordering shown above? > That is one of the technical issues that was not answered in DC. Ask Cisco what they did, and we'll document it. That's all the DC BOF decided to do -- whatever Cisco was already shipping (unannounced). The IETF doesn't make decisions based on technical rationale anymore.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 13:43:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA11356; Thu, 18 Dec 1997 13:43:52 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 13:42:15 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA11295 for ietf-ppp-outgoing; Thu, 18 Dec 1997 13:42:14 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm365-29.dialip.mich.net [207.75.186.39]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA11287 for ; Thu, 18 Dec 1997 13:42:06 -0500 (EST) Date: Thu, 18 Dec 97 17:22:42 GMT From: "William Allen Simpson" Message-ID: <6869.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Comments on PPP Conversion draft Sender: owner-ietf-ppp@merit.edu > From: Chip Sharp > I support the designation of this as a BCP. > Thank you. > There is ambiguity in the definition of converter. This is > understandable considering the proliferation of converter types in > the field. I thought the definition to be pretty specific: Some forms of bridging convert PPP encapsulated packets between dif- ferent framing formats. It is the responsibility of the bridge to do all stuffing and framing conversions. What is unclear? > There needs to be a distinction between conversion and > rate adaptation (e.g., V.120, V.110, etc.). There seem to be many > that don't understand this distinction. Well, that's because they can sometimes do bridging, and sometimes rate adaptation (adding an outer layer of framing to slow down the effective link speed), trying to be all things to all people. It's a sick world out there.... Rate adaptation is entirely a waste of time in the packet context. Does this BCP need to say that? I wouldn't have thought it within the scope of the title.... > A converter must take some > active role in the handling of HDLC and/or PPP (even if it is > passive). > Yes, it takes the role of "Framing Conversion". I suppose that some folks don't understand what "framing" is, but how much of a tutorial are we expected to write in every document? > The draft is fairly vague about the failure modes of converters. > Some explicit examples would be appreciated. > In the Introduction? An example is already in the next section.... > Passive Converter > ----------------- > To what level does a passive converter interact with PPP or HDLC? A "passive" converter relies on outside PPP peers to conduct all LCP negotiation. The converter inspects any LCP Configure-Acks passing through it, and dynamically updates its configuration accordingly. PPP -- passive LCP inspection. What is unclear? > For example, for asynch-synch conversion is it assumed that a passive > converter terminate HDLC on the asynch side and regenerate it on the > synch side? > Yes, of course. There is a pretty big difference between the transmission mechanisms; how could it be otherwise? > In the fourth multiline paragraph, it isn't clear what model you are > using. I assume this is a "low-speed" asynch to "high-speed" synch > converter. An explicit example of options that fail would illustrate > the problem better. > Heck, the sync could be low-speed, too. What does it matter? (such as Address-and-Control-Field-Compression, FCS-Alternatives, or another vendor specific option), are already listed. > Since the passive converter is not explicitly defined, it is unclear > what is being deprecated. > I thought the definition to be pretty specific: A "passive" converter relies on outside PPP peers to conduct all LCP negotiation. The converter inspects any LCP Configure-Acks passing through it, and dynamically updates its configuration accordingly. What is unclear? > Active Converter > ---------------- > It seems that an active converter does more than intercept and > examine LCP messages. It must actively participate in LCP messages, > modifying and/or adding options. This is implied in the first > paragraph, but not clearly stated. In addition, it must also perform > operations on the actual data stream. > There is no such implication. There is no modification or adding options or passing LCP options across the bridge. It _IS_ the LCP peer -- ab initio. An "active" converter intercepts LCP configuration negotiation, while allowing other PPP traffic to pass unimpeded. The converter becomes the PPP LCP peer on each interface, examining all LCP Link Configura- tion packets (Configure-Request, Configure-Ack, Configure-Nak, and Configure-Reject). What part of "intercept" and "LCP peer" are not understood? Could you suggest additional wording that would clear this up for you? > In the last paragraph of this section, it ight be useful to state > that ineffectual options should not be propogated. > Why? No options are propagated in any case. In the previous paragraph it already says: Inappropriate or ineffectual options .... ... Separate LCP negotiation on each interface prevents these options from propagating incorrect configuration information. > Multilink > --------- > I can't support this section as written. There are many > asynch-to-synch PPP converters on the market that work fairly well. Please name them. Let's see an interoperability test of them. I'll be particularly interested in watching BACP operate on any two of them -- configured back to back.... > They are much preferable to running V.120 over multiple links. > Therefore, the multilink section must be reworded to reflect this > fact. If this is a BCP, then it should reflect the best current > practice of doing single link to multilink conversion on an > asynch-to-synch converter. > The best current practice is that it will not work correctly in all cases, or even most cases, and therefore should not be used. > If you wish, you could state that the use of single-link to > multi-link conversion is outside the scope of the document. > I believe it to be in scope. I believe it important, and others on this list stated that it was important, to indicate that non-routing bridges implementing PPP multi-link should not be used. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 14:15:26 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA11924; Thu, 18 Dec 1997 14:15:25 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 14:15:01 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA11889 for ietf-ppp-outgoing; Thu, 18 Dec 1997 14:15:01 -0500 (EST) Received: from relay2.smtp.psi.net (relay2.smtp.psi.net [38.8.188.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA11882 for ; Thu, 18 Dec 1997 14:14:56 -0500 (EST) Received: from donna.txc.com by relay2.smtp.psi.net (8.8.5/SMI-5.4-PSI) id OAA10696; Thu, 18 Dec 1997 14:14:54 -0500 (EST) Received: from joep.txc.com by donna.txc.com (4.1/SMI-4.1) id AA06870; Thu, 18 Dec 97 14:14:07 EST Message-Id: <9712181914.AA06870@donna.txc.com> From: "Joseph Pereira" To: "William Allen Simpson" , Cc: "Jati Vij" , "Bill Bartholomay" , "Ed Soltysiak" Subject: Re: PPP Bit ordering for PPP over SONET/SDH Date: Thu, 18 Dec 1997 14:10:21 -0500 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Mr. Simpson: Thanks for response. However what is confusing is what is meant by MSB in RFC1662. Is what you call an MSB in RFC1662 the same as MSB in the SONET frame (i.e. the first bit transmitted). For example the control octet has a value of 0x03 (0000 0011) which I understand that the leftmost bit is the MSB. So in the outgoing sonet stream the control field will be transmitted as 0000 0011 from left to right. However when calculating the FCS-16, the control field is inserted into the CRC generator shift register as 1100 0000 one bit at a time from left to right (i.e. LSB first). This is what I believe it is saying. kind regards, Joseph Pereira ---------- > From: William Allen Simpson > To: ietf-ppp@merit.edu > Cc: Jati Vij ; Bill Bartholomay > Subject: Re: PPP Bit ordering for PPP over SONET/SDH > Date: Thursday, December 18, 1997 11:54 AM > > I tried to answer your question at least once already, when you asked > privately. > > > From: "Joseph Pereira" > > In the ISO documents the bits are transmitted from RIGHT to LEFT. > > > No, on bit-synchronous and asynchronous over many low speed serial links > the bits are transmitted least significant to most significant within > bytes. This has nothing to do with ISO, and in fact was adopted by IBM > for SDLC long ago, and independently by EIA for async. It is media > specific. > > Also, to avoid exactly this problem, as noted in RFC-1662, in the IETF > we do not number our bits in transmission order -- a terrible convention > that has caused confusion on ethernet as well. Instead, we number them > in "canonical" order within bytes. > > > > However, what would the outgoing SONET/SDH data stream look like after > > these bits are serialized? The confusion results because it is my > > understanding that the SONET/SDH bits are transmitted MSB first. > > That is correct. What is confusing? The media is the same as FDDI. > > Instead of wasting time reading ISO documents, stick to RFC-1662. There > is no such thing as octet-synchronous in ISOese. > > RFC-1662 is the standard. > > > > Therefore, the octet 8-15 will be transmitted first. Since this is a 16 bit > > value (for crc16), and bits 8-15 are the least significant octet, the bit > > we have numbered 15 is the LSBit of the CRC and the octet. Now, Sonet > > always transmits MSbit of a byte first. So, the transmission order should > > be bits 8,9,10,11,12,13,14,15,(LSByte -MSBit first) 0,1,2,3,4,5,6,7 (MSByte > > -MSBit first). > > > We do not use the old CRC16, we use FCS-16, a different polynomial and > algorithm. > > That bit order looks right, but only if you think of the FCS as a shift > register. That is only one implementation. A faster implementation is > done with bytes and words, as documented in RFC-1662. > > > > 2) The second question is regarding the 1+X^43 polynomial PPP scrambler. > > > > Do the bytes get inserted into the scrambler MSB first or LSB first with > > respect to the bit ordering shown above? > > > That is one of the technical issues that was not answered in DC. Ask > Cisco what they did, and we'll document it. That's all the DC BOF > decided to do -- whatever Cisco was already shipping (unannounced). > > The IETF doesn't make decisions based on technical rationale anymore.... > > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 14:44:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA12448; Thu, 18 Dec 1997 14:44:48 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 14:44:25 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA12419 for ietf-ppp-outgoing; Thu, 18 Dec 1997 14:44:24 -0500 (EST) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA12415 for ; Thu, 18 Dec 1997 14:44:20 -0500 (EST) Received: from smtp.netcoresys.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id OAA19454; Thu, 18 Dec 1997 14:44:19 -0500 (EST) Received: by smtp.netcoresys.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BD0BC3.8AFCE640@smtp.netcoresys.com>; Thu, 18 Dec 1997 14:45:11 -0500 Message-ID: From: Joe Frazier To: "'James Carlson'" , "'OhadD@rnd.co.il'" Cc: "'ietf-ppp@merit.edu'" , Joe Frazier Subject: RE: IPCP IP address Date: Thu, 18 Dec 1997 14:45:08 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi Jim and Ohad, I have a couple of comments below. -----Original Message----- From: James Carlson [SMTP:jcarlson@andr.UB.com] Sent: Thursday, December 18, 1997 8:23 AM To: OhadD@rnd.co.il Cc: ietf-ppp@merit.edu Subject: Re: IPCP IP address > I'll thank anyone's help in the next issue: > > When assigning an IP address through the PPP IPCP IP address option, no > information about the subnet mask exchanges. This is quite intentional. PPP links do not work on broadcast media, so there's no need for a subnet definition. A PPP link simply links two individual IP hosts together. > Is there a common solution to this problem? ( by using class A/B/C as > default \ using always RIP1 on this link \ learning the subnet from > HELLO messages(OSPF), or RIP2 routing information exchange ?....) Personally, I treat the remote address on a PPP link as a host route ("subnet" mask 255.255.255.255) and use any available routing protocol (or static routes) to set up routes to any networks reachable over the link. The subnet mask isn't meaningful, so, for those administrators who insist on having such things, I generate a separate static route to represent it. It definitely is a good idea to use host routes in this situation, and your explanation about the fundamental definition of a PPP link really drives the point home, Jim. However, your last sentence does open the door for a little more discussion. I'm not sure that a static route is beneficial in a "generic" configuration, or an administrators need to insist it. PPP links may be host specific, but the interfaces they use don't have to be. All PPP configuration packages do include the subnet mask as part of the configuration. If an administrator wants to set up a network interface for a PPP link, (he,she) can configure to do so. Of course, the subnet mask is not communicated over the link in IPCP, so both sides of the link would need to be configured to use the same subnet masks. However, since these PPP link "interfaces" are usually non-permanent, a host node configuration would permit a "generic" configuration. And if both sides of the PPP link are capable of routing, then all the routing info can be retrieved via the PPP interface, just like any other interface, Thanks, Joe Frazier -- James Carlson, Consulting Engineer IronBridge Networks / 5 Corporate Drive Vox: +1 978 691 4644 Andover MA 01810-2448 / USA Fax: +1 978 691 6300 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 15:58:38 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA13805; Thu, 18 Dec 1997 15:58:36 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 15:57:30 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA13766 for ietf-ppp-outgoing; Thu, 18 Dec 1997 15:57:29 -0500 (EST) Received: from ub-gate.UB.com (ub-gate.UB.com [192.216.34.11]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA13762 for ; Thu, 18 Dec 1997 15:57:25 -0500 (EST) Received: from andr.ub.com. (sunny.andr.ub.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.9.1]) id AA19021; Thu, 18 Dec 97 10:11:37 PST Received: from ironbridge.andr.ub.com (ironbridge.andr.ub.com [138.120.246.66]) by andr.ub.com. (8.8.5/8.8.5) with SMTP id PAA12803; Thu, 18 Dec 1997 15:56:47 -0500 (EST) Received: by ironbridge.andr.ub.com (SMI-8.6/SMI-SVR4) id PAA17458; Thu, 18 Dec 1997 15:54:51 -0500 Date: Thu, 18 Dec 1997 15:54:51 -0500 Message-Id: <199712182054.PAA17458@ironbridge.andr.ub.com> From: James Carlson To: JFrazier@netcoresys.com Cc: OhadD@rnd.co.il, ietf-ppp@merit.edu In-Reply-To: (message from Joe Frazier on Thu, 18 Dec 1997 14:45:08 -0500) Subject: Re: IPCP IP address References: Sender: owner-ietf-ppp@merit.edu Hey, smokin' Joe, I'd wondered where you'd gone. I had responded to Ohad's mail with this: [...] > Personally, I treat the remote address on a PPP link as a host route > ("subnet" mask 255.255.255.255) and use any available routing > protocol > (or static routes) to set up routes to any networks reachable over > the > link. The subnet mask isn't meaningful, so, for those administrators > who insist on having such things, I generate a separate static route > to represent it. Joe responds: > It definitely is a good idea to use host routes in this situation, and > your explanation about the fundamental definition of a PPP link really > drives the point home, Jim. > > However, your last sentence does open the door for a little more > discussion. I'm not sure that a static route is beneficial in a > "generic" configuration, or an administrators need to insist it. Some administrators think of all interfaces of subnets, whether or not there actually is a subnet in existence. No, there's no need to insist on it. But, then, there's no need for carriers to insist on ATM, either ... > PPP links may be host specific, but the interfaces they use don't have > to be. All PPP configuration packages do include the subnet mask as > part of the configuration. Wrongly, in my opinion. > If an administrator wants to set up a network interface for a PPP > link, (he,she) can configure to do so. Of course, the subnet mask is > not communicated over the link in IPCP, so both sides of the link > would need to be configured to use the same subnet masks. Wrong. The subnet mask on my end of the link represents my belief about the size of your other attached broadcast medium. The subnet mask on your end of the link represents your belief about the size of my attached broadcast medium. They are the same if and only if we both have attached broadcast media (such as Ethernet) with configured subnet masks that are equal. (Or if we're trying to aggregate to the same level ... ugh.) > However, since these PPP link "interfaces" are usually non-permanent, > a host node configuration would permit a "generic" configuration. And > if both sides of the PPP link are capable of routing, then all the > routing info can be retrieved via the PPP interface, just like any > other interface, I couldn't parse that paragraph. If you mean that PPP with IP is perfectly capable of running RIP and other routing protocols, then, yes, that's the right way to do it. -- James Carlson, Consulting Engineer IronBridge Networks / 5 Corporate Drive Vox: +1 978 691 4644 Andover MA 01810-2448 / USA Fax: +1 978 691 6300 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 17:19:18 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA15889; Thu, 18 Dec 1997 17:19:17 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 17:18:32 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA15855 for ietf-ppp-outgoing; Thu, 18 Dec 1997 17:18:31 -0500 (EST) Received: from relay1.smtp.psi.net (relay1.smtp.psi.net [38.8.14.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA15851 for ; Thu, 18 Dec 1997 17:18:26 -0500 (EST) Received: from smtp.netcoresys.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id RAA21020; Thu, 18 Dec 1997 17:18:24 -0500 (EST) Received: by smtp.netcoresys.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BD0BD9.110A2C10@smtp.netcoresys.com>; Thu, 18 Dec 1997 17:19:15 -0500 Message-ID: From: Joe Frazier To: "'James Carlson'" Cc: "'OhadD@rnd.co.il'" , "'ietf-ppp@merit.edu'" Subject: RE: IPCP IP address Date: Thu, 18 Dec 1997 17:19:14 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi Jim, Some comments below: -----Original Message----- From: James Carlson [SMTP:jcarlson@andr.UB.com] Sent: Thursday, December 18, 1997 3:55 PM To: Joe Frazier Cc: OhadD@rnd.co.il; ietf-ppp@merit.edu Subject: Re: IPCP IP address Hey, smokin' Joe, I'd wondered where you'd gone. I had responded to Ohad's mail with this: [...] > Personally, I treat the remote address on a PPP link as a host route > ("subnet" mask 255.255.255.255) and use any available routing > protocol > (or static routes) to set up routes to any networks reachable over > the > link. The subnet mask isn't meaningful, so, for those administrators > who insist on having such things, I generate a separate static route > to represent it. Joe responds: > It definitely is a good idea to use host routes in this situation, and > your explanation about the fundamental definition of a PPP link really > drives the point home, Jim. > > However, your last sentence does open the door for a little more > discussion. I'm not sure that a static route is beneficial in a > "generic" configuration, or an administrators need to insist it. Some administrators think of all interfaces of subnets, whether or not there actually is a subnet in existence. No, there's no need to insist on it. But, then, there's no need for carriers to insist on ATM, either ... I think I see your point. > PPP links may be host specific, but the interfaces they use don't have > to be. All PPP configuration packages do include the subnet mask as > part of the configuration. Wrongly, in my opinion. Since PPP interfaces are non broadcast - you probably are correct. > If an administrator wants to set up a network interface for a PPP > link, (he,she) can configure to do so. Of course, the subnet mask is > not communicated over the link in IPCP, so both sides of the link > would need to be configured to use the same subnet masks. Wrong. The subnet mask on my end of the link represents my belief about the size of your other attached broadcast medium. The subnet mask on your end of the link represents your belief about the size of my attached broadcast medium. They are the same if and only if we both have attached broadcast media (such as Ethernet) with configured subnet masks that are equal. (Or if we're trying to aggregate to the same level ... ugh.) I was under the impression that IP interfaces were more logical, meaning they don't care about the underlying medium. In the case of PPP never being done via broadcast media, I see your point. > However, since these PPP link "interfaces" are usually non-permanent, > a host node configuration would permit a "generic" configuration. And > if both sides of the PPP link are capable of routing, then all the > routing info can be retrieved via the PPP interface, just like any > other interface, I couldn't parse that paragraph. If you mean that PPP with IP is perfectly capable of running RIP and other routing protocols, then, yes, that's the right way to do it. I just meant here that a PPP Interface in most cases is not permanent. By using a host subnet mask, there really needs to be no special subnet configuration (i.e. all PPP interfaces will always have the same host subnet configuration) . As you say, the mask would be meaningless. Any subnet issues for networks that the hosts reside on, will be dealt with by the routing protocol, just like with any other interface type. Thanks again for the dialogue. As we both know, you pretty much have answered Ohad's question with the first email. Thanks, Joe Frazier -- James Carlson, Consulting Engineer IronBridge Networks / 5 Corporate Drive Vox: +1 978 691 4644 Andover MA 01810-2448 / USA Fax: +1 978 691 6300 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Dec 18 17:35:02 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA16231; Thu, 18 Dec 1997 17:35:01 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Dec 1997 17:34:45 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA16202 for ietf-ppp-outgoing; Thu, 18 Dec 1997 17:34:45 -0500 (EST) Received: from gvmail.globalvillage.com ([198.93.137.253]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA16198 for ; Thu, 18 Dec 1997 17:34:41 -0500 (EST) Received: from sleet.globalvillage.com [198.93.138.50] by gvmail.globalvillage.com (SMTPD32-4.02c) id A4FDB000AA; Thu, 18 Dec 1997 14:34:37 PST Received: from ianp by sleet.globalvillage.com (SMI-8.6/SMI-SVR4) id OAA15207; Thu, 18 Dec 1997 14:34:23 -0800 Message-ID: <023601bd0c05$37b01ba0$46bf8acf@ianp.globalvillage.com> From: "Ian Puleston" To: Subject: Re: Comments on PPP Conversion draft Date: Thu, 18 Dec 1997 14:35:17 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: William Allen Simpson To: ietf-ppp@merit.edu Date: Thursday, December 18, 1997 11:01 AM Subject: Re: Comments on PPP Conversion draft >> Active Converter >> ---------------- >> It seems that an active converter does more than intercept and >> examine LCP messages. It must actively participate in LCP messages, >> modifying and/or adding options. This is implied in the first >> paragraph, but not clearly stated. In addition, it must also perform >> operations on the actual data stream. >> >There is no such implication. There is no modification or adding >options or passing LCP options across the bridge. It _IS_ the LCP peer >-- ab initio. The converter must pass some LCP options across the bridge because these can be negotiating capabilities of the end-points which it knows nothing about (authentication protocol for instance). This section seems to be saying that the converter must treat the two sides as separate LCP sessions and carry out separate negotiations on both. That would seem to be adding undue complexity for many cases. Take the case of a convertor used to connect a PPP stack designed for ISDN to an ADSL link running ATM: The only conversion necessary would be to prevent the FCS Alternatives and ACFC options propagating to the ATM side. It seems that this could be achieved by simply returning a Configure Reject for these options in the initial configure request, and then letting all further LCP negotiations proceed end-to-end. The converter has no need for a full LCP negotiation FSM (plus all the complexity of trying to tie the two sets of negotiations together for options which need to go end-to-end). The only obvious disadvantage I can see to this technique would be that the PPP stack could receive two configure rejects, each rejecting a different set of options (the 1st from the converter and the 2nd from the remote peer). Would this cause a problem in exisiting PPP implementations ? One other point. PPP converters could be categorized into two further types: those which convert between two PPP links of different media, and those which convert a PPP stack designed for one media type to run over a different media (i.e. a stack which thinks it is running over media type X may be running over type Y, via a converter, but with no media type X link present). This type of converter could act differently to one where both types of media are actually present - i.e. options specific to media type X (such as ACCM for async links) can be rejected rather than accepted and used on one side only. Maybe the RFC should mention this ? - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 19 07:37:49 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA22934; Fri, 19 Dec 1997 07:37:23 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 19 Dec 1997 07:28:30 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA22857 for ietf-ppp-outgoing; Fri, 19 Dec 1997 07:28:29 -0500 (EST) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id HAA22848 for ; Fri, 19 Dec 1997 07:26:16 -0500 (EST) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id MAA11180 for ; Fri, 19 Dec 1997 12:25:44 GMT Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 49a65360; Fri, 19 Dec 97 12:14:46 +0000 Mime-Version: 1.0 Date: Fri, 19 Dec 1997 12:25:16 +0000 Message-ID: <49a65360@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Comments on PPP Conversion draft To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu It seems to me that there are several forms of active conversion, and it would be useful if the Framing Conversion draft addressed each explicitly, so that we know exactly what Bill Simpson intends to deprecate and why. Anyway, here is my list of them, plus some comments. 1) "Rejecting converter" LCP negotiation takes place end-to-end, but the converter sends Configure Rejects for any options it doesn't like. Local Peer Converter Remote Peer <------------------ LCP -----------------> | | Cfg-Rej <---+ +---> CFG Rej (This is the same as described by Ian Puleston, and I agree with what he said - as far as I can see, this solves the problems inherent in a passive converter.) 2) "Injecting Converter" LCP Negotiation takes place end-to-end, but the converter injects additional options into Configure Request, and then sorts out any subsequent Rejects or Naks affecting these options. (Personally, I doubt this can be made to work, and I'd be happy to see it deprecated. But if someone out there has actually done it successfully.....) 3) "Negotiating converter" Now there are several types of these; they are characterised by the fact the LCP is no longer end-to-end. (Note I've ignored ECP and CCP, which could terminate at the converter or be end-to-end). 3a) Converter with End-to-End authentication Local Peer Converter Remote Peer <--------LCP-------> <-------LCP--------> <------------------ Auth -------------------> <------------------ NCP --------------------> This seems to be what Bill Simpson means by an active converter (although he may mean #3b below). In the multilink case, it would look like: Local Peer Converter Remote Peer <--------LCP-------> <-------LCP--------> <------------------ Auth -------------------> <-------MP---------> <-------BACP-------> <------------------ NCP --------------------> As we discussed on the list back in July, this sort of converter has a real problem with authentication if the local peer is an authenticator. How does it authenticate the 2nd link? For this reason alone, this sort of converter should be deprecated. However, I should like to take issue with Bill when he thinks that it won't interoperate. I've actually implemented a converter exactly like this, and it works fine (authentication notwithstanding). I'm sure several others have similar implementations. 3b) "Authenticating converter" Local Peer Converter Remote Peer <--------LCP-------> <-------LCP--------> <-------Auth-------> <-------MP---------> <-------BACP-------> <------------------ NCP --------------------> (Authentication could also take place between the converter and the local peer as well). This sort of converter seems to solve the problem of #3a, but isn't a router (as I understand it anyway). Perhaps Bill would care to explain exactly why he thinks it won't work and why it should be deprecated in the multilink case. 4) Router Just for reference, here is my understanding of what a router is. Peer Router Peer <--------LCP-------> <-------LCP--------> <--------Auth------> <-------Auth-------> <-------MP---------> <-------BACP-------> <--------NCP-------> <------ NCP--------> 5) Passive Converter If other people are really not sure what it meant by this, perhaps a good definition would be that a passive converter alter the framing, while leaving the PPP Encapsulation (as defined in RFC 1661 section 2) unchanged. Or can a passive converter change the padding as well? --- Jonathan Goodchild P.S. This may be my last contribution to the list for a while (I can almost hear Bill cheering!) - it seems quite likely that I am about to make an involuntary career move. (If anyone is interested, I'll send them details privately). - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 19 12:23:35 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA26694; Fri, 19 Dec 1997 12:23:33 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 19 Dec 1997 12:20:49 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA26633 for ietf-ppp-outgoing; Fri, 19 Dec 1997 12:20:48 -0500 (EST) Received: from atlas.xylogics.com (atlas.xylogics.com [132.245.33.7]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA26629 for ; Fri, 19 Dec 1997 12:20:43 -0500 (EST) Received: from baynetworks.com (gmg-pc.xylogics.com [132.245.33.214]) by atlas.xylogics.com (8.7.3/8.7.3) with ESMTP id MAA00246 for ; Fri, 19 Dec 1997 12:17:07 -0500 (EST) Message-ID: <349AAC88.606B67F@baynetworks.com> Date: Fri, 19 Dec 1997 12:19:04 -0500 From: Gary Greenberg Reply-To: gmg@baynetworks.com Organization: Bay Networks - Remote Access Server Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: IETF-PPP Subject: Microsoft Compatibility with PPP LCP Callback Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Can anyone enlighten me about Microsoft's interoperability with RFC1570 and the July 97 draft? I understand that they implement an NCP protocol called CBCP by specifying an operation field value-6, but will they "fall back" to a standard operation field value in LCP if the Answering Peer does not implement value-6? Thanks, Gary -- Gary M. Greenberg vox: (508) 916-4241 Principal Software Engineer (800) 225-3317 Bay Networks - ITBG fax: (508) 916-4782 8 Federal Street m/s: BL08-05 Billerica, MA 01821 email: gmg@baynetworks.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Dec 19 13:50:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA28010; Fri, 19 Dec 1997 13:50:44 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Fri, 19 Dec 1997 13:50:04 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA27980 for ietf-ppp-outgoing; Fri, 19 Dec 1997 13:50:03 -0500 (EST) Received: from ihgw2.lucent.com (ihgw2.lucent.com [207.19.48.2]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA27975 for ; Fri, 19 Dec 1997 13:50:00 -0500 (EST) Received: from garage.lucent.com by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id MAA28792; Fri, 19 Dec 1997 12:40:31 -0600 Received: by garage.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id NAA29034; Fri, 19 Dec 1997 13:46:58 -0500 Date: Fri, 19 Dec 1997 13:46:58 -0500 Message-Id: <199712191846.NAA29034@garage.lucent.com> From: gmg@garage.lucent.com (garage!gmg) To: "Ian Puleston" , ietf-ppp@merit.edu Subject: Re: Comments on draft-ietf-pppext-aal5-03.txt Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi Ian, Thank you for your comments. Attached below are my responses, which will be applied to the -v04 text. George Gross [snip E-mail header] . . . > Here are some comments on the draft: > > 1. There is no mention of the type of ATM call to make. Must it be UBR, or > could it be nrt-VBR or ABR where supported (I'm not advocating anything > other than UBR - just pointing out that the RFC doesn't bar them) ? AAL5 traffic contract parameters are outside the scope of this document, which only deals with the PPP encapsulation technique. > > 2. Following discussions at the ADSL Forum, the document should probably say > that endpoints MUST implement Peak Cell Rate for transmission on UBR > connections. Section 3, the phrase that begins: "...does not impose any restrictions regarding transmission rate." will be modified to say: "...does not impose any restrictions regarding transmission rate or the underlying ATM layer traffic descriptor parameters." The Internet Draft can not get embroiled in specifying what is an appropriate ATM traffic contract, as that depends on what is required by the application. > > A question here for any ATM experts around - is there also a case for > requiring the use of the EFCI (flow control) bit for the same reason ? > > 3. Sections 5 and 6 are inconsistently formatted: > - If Figure 2 was laid out like Figure 3, it would be more obvious how the > two are related. > - Figure 2 shows padding, Figure 3 doesn't (could imply that padding can be > stripped from an LLC encapsulated frame). > - Section 5 says that the PPP fields are specified in [1], but Section 6. > explicitly specifies those same fields. I have changed figure 3 to include the AAL5 (or FUNI) trailer information. > > 4. In section 8. the paragraph on multi-point connections seems to have been > inserted in the middle of a discussion on encapsulation techniques. This paragraph has been deleted. > > 5. The technique of detecting multi-point connections by looking for > multiple LCP responses with the same identifier from different framing > addresses seems to be flawed. Firstly there is no concept of a "framing > address" to differentiate different senders. Secondly, RFC1661 states: "For > retransmissions, the Identifier MAY remain unchanged". Therefore timing > problems on a point-to-point VC could lead to multiple responses with the > same identifier, which are normally silently discarded. > > Note also that point-to-multipoint and multipoint-to-point VCs are > uni-directional so there would be no LCP responses. > > Rather than trying to get PPP to detect a multipoint connection, would it > not be better to simply specify elsewhere that the ATM VC MUST be > point-to-point. Section 3 third sentence already requires a point-to-point connection. > > 6. The 2nd paragraph of section 8 specifies the difference between > LLC-encapsulated and VC-muxed LCP frames, but needs to go farther. Can we > rely on checking the 1st octet to be FE or C0 to detect the encapsulation > technique, and if it is wrong what do we do? (discard the frame ?). > > 7. Also on Section 8. This section talks about a frame arriving in an > "alternate but equivalent data encapsulation". It is not obvious what this > means. Is it a frame with an LLC header when VC-muxing is in use and > vice-versa ? If it is something else then the recovery procedures mentioned > in the 1st paragraph are missing. > > If that assumption is correct, then the prescribed technique for handling > the change in encapsulation technique (to re-enter link establishment phase) > probably won't do much good since the encapsulation technique is not > negotiated by LCP. Probably, such wrongly-encapsulated frames should just be > silently discarded. > This section of the document was weak, and it has been re-written to be more explicit. These changes have been discussed among several of the co-authors. Here is the revised text for the last two paragraphs in section 8: Once PPP has entered the Network-layer Protocol phase, and successfully negotiated a particular NCP for a PPP Protocol, if a frame arrives using an alternate but equivalent data encapsulation as defined in [4], then the PPP Link MUST: .in +0.5i .sp For a SVC, immediately clear the call with cause value 111, "protocol error, unspecified". .sp For a PVC: tear down the active NCPs, re-enter the Link Establishment state, silently drop all received packets except LCP Configure-Requests, and send a new LCP Configure-Request using the peer's encapsulation technique. If the local end point does not support remote peer's encapsulation technique, then it MUST generate an error message and enter Termination state. .sp .in -0.5i These policies prevent "black-holes" that occur when the peer loses state. An implementation which requires PPP link configuration, and other PPP negotiated features (such as authentication), MAY enter Termination state when configuration fails. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Dec 21 10:11:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12956; Sun, 21 Dec 1997 10:11:34 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Sun, 21 Dec 1997 10:06:12 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA12879 for ietf-ppp-outgoing; Sun, 21 Dec 1997 10:06:11 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm365-12.dialip.mich.net [207.75.186.22]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12862 for ; Sun, 21 Dec 1997 10:06:03 -0500 (EST) Date: Sun, 21 Dec 97 14:16:03 GMT From: "William Allen Simpson" Message-ID: <6874.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Comments on PPP Conversion draft Sender: owner-ietf-ppp@merit.edu > From: "Ian Puleston" > The converter must pass some LCP options across the bridge because these can > be negotiating capabilities of the end-points which it knows nothing about > (authentication protocol for instance). > Sorry, won't work. The bridge has to do the authentication negotiation. If the bridge does not understand the option, then it will not work. > This section seems to be saying that the converter must treat the two sides > as separate LCP sessions and carry out separate negotiations on both. Correct! > That > would seem to be adding undue complexity for many cases. Take the case of a > convertor used to connect a PPP stack designed for ISDN to an ADSL link > running ATM: > Certainly a very complex case; but if you want the complexity of ATM, then you have to live with complexity. > The only conversion necessary would be to prevent the FCS Alternatives and > ACFC options propagating to the ATM side. How do you know that? Prescience? What about new options? What about vendor specific options? What about multi-link options? > It seems that this could be > achieved by simply returning a Configure Reject for these options in the > initial configure request, and then letting all further LCP negotiations > proceed end-to-end. The converter has no need for a full LCP negotiation FSM > (plus all the complexity of trying to tie the two sets of negotiations > together for options which need to go end-to-end). > Sorry, won't work. > The only obvious disadvantage I can see to this technique would be that the > PPP stack could receive two configure rejects, each rejecting a different > set of options (the 1st from the converter and the 2nd from the remote > peer). Would this cause a problem in exisiting PPP implementations ? > Damn straight! > One other point. PPP converters could be categorized into two further types: > those which convert between two PPP links of different media, and those > which convert a PPP stack designed for one media type to run over a > different media (i.e. a stack which thinks it is running over media type X > may be running over type Y, via a converter, but with no media type X link > present). Huh? > This type of converter could act differently to one where both > types of media are actually present - i.e. options specific to media type X > (such as ACCM for async links) can be rejected rather than accepted and used > on one side only. Maybe the RFC should mention this ? > I do not understand your scenario. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Dec 21 10:11:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12964; Sun, 21 Dec 1997 10:11:43 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Sun, 21 Dec 1997 10:06:08 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA12869 for ietf-ppp-outgoing; Sun, 21 Dec 1997 10:06:07 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm365-12.dialip.mich.net [207.75.186.22]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12860 for ; Sun, 21 Dec 1997 10:06:01 -0500 (EST) Date: Sun, 21 Dec 97 13:59:23 GMT From: "William Allen Simpson" Message-ID: <6873.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: PPP Bit ordering for PPP over SONET/SDH Sender: owner-ietf-ppp@merit.edu > From: "Joseph Pereira" > Thanks for response. However what is confusing is what is meant by MSB in > RFC1662. Is what you call an MSB in RFC1662 the same as MSB in the SONET > frame (i.e. the first bit transmitted). > I am sorry that the ITU has confused you. A bit that is "most significant" has nothing what-so-ever to do with transmission order. Please re-read RFC-1662. There is text that I have sent you at least twice already: To remain consistent with standard Internet practice, and avoid confusion for people used to reading RFCs, all binary numbers in the following descriptions are in Most Significant Bit to Least Significant Bit order, reading from left to right, unless otherwise indicated. Note that this is contrary to standard ISO and CCITT practice which orders bits as transmitted (network bit order). Keep this in mind when comparing this document with the international standards documents. SONET is octet-sync, and transmits most significant bit first. Async transmits least significant bit first. They are different media: 4.5. Transmission Considerations 4.5.1. Octet-synchronous The definition of various encodings and scrambling is the responsibility of the DTE/DCE equipment in use, and is outside the scope of this specification. 4.5.2. Asynchronous All octets are transmitted least significant bit first, with one start bit, eight bits of data, and one stop bit. There is no provision for seven bit asynchronous links. > For example the control octet has a value of 0x03 (0000 0011) which I > understand that the leftmost bit is the MSB. So in the outgoing sonet > stream the control field will be transmitted as 0000 0011 from left to > right. Correct! > However when calculating the FCS-16, the control field is > inserted into the CRC generator shift register as 1100 0000 one bit at a > time from left to right (i.e. LSB first). Correct, if you use a shift register. Also correct for the 32-bit FCS. However, as I have advised you, it would not be good engineering practice to use a bit shift register at high speeds, and we have clearly defined a byte calculation technique. But that is your cross to bear. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sun Dec 21 10:11:45 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12962; Sun, 21 Dec 1997 10:11:43 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Sun, 21 Dec 1997 10:06:13 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA12886 for ietf-ppp-outgoing; Sun, 21 Dec 1997 10:06:13 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm365-12.dialip.mich.net [207.75.186.22]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA12866 for ; Sun, 21 Dec 1997 10:06:05 -0500 (EST) Date: Sun, 21 Dec 97 14:26:02 GMT From: "William Allen Simpson" Message-ID: <6875.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Comments on PPP Conversion draft Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > It seems to me that there are several forms of active conversion, and it > would be useful if the Framing Conversion draft addressed each > explicitly, so that we know exactly what Bill Simpson intends to > deprecate and why. > Only one form of "active" converter is discussed in the current draft, and none of those on your list are recommended. The text is: An "active" converter intercepts LCP configuration negotiation, while allowing other PPP traffic to pass unimpeded. A diagram of the form that you used would be: Peer Converter Peer <--------LCP-------> <--------LCP--------> <------------------ Auth -------------------> <------------------ ML -------------------> <------------------ BACP -------------------> <------------------ NCP --------------------> > This seems to be what Bill Simpson means by an active converter (although he > may mean #3b below). In the multilink case, it would look like: > > Local Peer Converter Remote Peer > > <--------LCP-------> <-------LCP--------> > <------------------ Auth -------------------> > <-------MP---------> > <-------BACP-------> > <------------------ NCP --------------------> > Incorrect! How does the converter "know" to intercept multi-link and BACP (and MPP+ et alia)? Omniscience? Prescience? > However, I should like to take issue with Bill when he thinks that it > won't interoperate. I've actually implemented a converter exactly like > this, and it works fine (authentication notwithstanding). I'm sure > several others have similar implementations. > Sorry, I don't believe you. Please demonstrate with CHAP and EAP authentication negotiation. Please demonstrate this by first linking the peers directly, and then inserting a pair of converters (as in your previous example) back to back, without any additional configuration of either peer (as you demanded in your message some months ago). > 3b) "Authenticating converter" > > Local Peer Converter Remote Peer > > <--------LCP-------> <-------LCP--------> > <-------Auth-------> > <-------MP---------> > <-------BACP-------> > <------------------ NCP --------------------> > > (Authentication could also take place between the converter and the > local peer as well). > Incorrect! Configuration nightmare! How does this box without an IP address have RADIUS access? Note that multi-link will still not work correctly. > Just for reference, here is my understanding of what a router is. > > Peer Router Peer > > <--------LCP-------> <-------LCP--------> > <--------Auth------> <-------Auth-------> > <-------MP---------> > <-------BACP-------> > <--------NCP-------> <------ NCP--------> > Correct. Thank you for the contribution. I will add similar diagrams. Apparently, some folks are having trouble visualizing the textual descriptions. (This did not appear to be a problem in the in-person verbal presentation, so there is clearly a dichotomy in expectation for "hearing" text words and "reading" text words. Perhaps the diagrams will help.) WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 22 05:31:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id FAA18421; Mon, 22 Dec 1997 05:31:31 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 22 Dec 1997 05:26:22 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA18373 for ietf-ppp-outgoing; Mon, 22 Dec 1997 05:26:22 -0500 (EST) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA18369 for ; Mon, 22 Dec 1997 05:26:11 -0500 (EST) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id KAA07802 for ; Mon, 22 Dec 1997 10:25:44 GMT Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 49e3d8a0; Mon, 22 Dec 97 10:14:34 +0000 Mime-Version: 1.0 Date: Mon, 22 Dec 1997 10:24:24 +0000 Message-ID: <49e3d8a0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Comments on PPP Conversion draft To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu >> In the multilink case, it would look like: >> >> Local Peer Converter Remote Peer >> >> <--------LCP-------> <-------LCP--------> >> <------------------ Auth -------------------> >> <-------MP---------> >> <-------BACP-------> >> <------------------ NCP --------------------> > >Incorrect! How does the converter "know" to intercept multi-link and >BACP (and MPP+ et alia)? Omniscience? Prescience? Well, since single-link to multilink conversion is the raison d'etre for the converter, the knowledge is hard-coded. >> However, I should like to take issue with Bill when he thinks that it >> won't interoperate. I've actually implemented a converter exactly like >> this, and it works fine (authentication notwithstanding). I'm sure >> several others have similar implementations. >> > Sorry, I don't believe you. What, that others have similar implementations? Or that it works if there is no authentication? > > Please demonstrate with CHAP and EAP authentication negotiation. > > Please demonstrate this by first linking the peers directly, and then > inserting a pair of converters (as in your previous example) back to > back, without any additional configuration of either peer (as you > demanded in your message some months ago). I can't do that because, as I said myself in my message, it doesn't work when the local peer is the authenticator (in the case of converters at both end, then both peers are local peers to their respective converters). I don't think there is any disagreement here - I said myself that this sort of converter should be deprecated. I just thought it worth discussing because there are several converters like this in existence. >> 3b) "Authenticating converter" >> >> Local Peer Converter Remote Peer >> >> <--------LCP-------> <-------LCP--------> >> <-------Auth-------> >> <-------MP---------> >> <-------BACP-------> >> <------------------ NCP --------------------> >> >> (Authentication could also take place between the converter and >> the local peer as well). >> > Incorrect! Again, what do you mean precisely? Are you referring to my sentence in parentheses? I agree that #3b is an incorrect interpretation of what you meant by an active converter. > Configuration nightmare! Quite possibly. But if, for example, the converter is a terminal adaptor, then it has another means with which to communicate to the local peer (i.e. AT commands). > How does this box without an IP address have RADIUS access? It doesn't, of course. I hadn't realised that RADIUS was mandatory. Clearly, if you want RADIUS, then you have to have a router. > Note that multi-link will still not work correctly. Perhaps others on the list would care to refute this statement. Obviously I'm not going to succeed in convincing you that it does work. > Thank you for the contribution. You're welcome. > I will add similar diagrams. That would certainly be very useful. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 22 13:17:40 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA22386; Mon, 22 Dec 1997 13:17:31 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 22 Dec 1997 13:16:36 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA22363 for ietf-ppp-outgoing; Mon, 22 Dec 1997 13:16:35 -0500 (EST) Received: from gvmail.globalvillage.com ([198.93.137.253]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA22359 for ; Mon, 22 Dec 1997 13:16:29 -0500 (EST) Received: from sleet.globalvillage.com [198.93.138.50] by gvmail.globalvillage.com (SMTPD32-4.02c) id AE7C8F500AE; Mon, 22 Dec 1997 10:16:28 PST Received: from ianp by sleet.globalvillage.com (SMI-8.6/SMI-SVR4) id KAA18011; Mon, 22 Dec 1997 10:16:13 -0800 Message-ID: <003e01bd0f05$d1041240$46bf8acf@ianp.globalvillage.com> From: "Ian Puleston" To: Subject: Re: Comments on PPP Conversion draft Date: Mon, 22 Dec 1997 10:17:08 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ppp@merit.edu >> The converter must pass some LCP options across the bridge because these can >> be negotiating capabilities of the end-points which it knows nothing about >> (authentication protocol for instance). >> >Sorry, won't work. The bridge has to do the authentication negotiation. >If the bridge does not understand the option, then it will not work. So how does the bridge know which authentication protocols are supported by the end-point? Omniscience? Prescience? >> The only conversion necessary would be to prevent the FCS Alternatives and >> ACFC options propagating to the ATM side. > >How do you know that? Prescience? > >What about new options? >What about vendor specific options? >What about multi-link options? OK, it prevents the FCS Alternatives and ACFC options propagating to the ATM side, and rejects any options which it does not recognize from either side. I assumed the latter would be taken as read. >> It seems that this could be >> achieved by simply returning a Configure Reject for these options in the >> initial configure request, and then letting all further LCP negotiations >> proceed end-to-end. The converter has no need for a full LCP negotiation FSM >> (plus all the complexity of trying to tie the two sets of negotiations >> together for options which need to go end-to-end). >> >Sorry, won't work. Would you deign to enlighten us as to why ? >> One other point. PPP converters could be categorized into two further types: >> those which convert between two PPP links of different media, and those >> which convert a PPP stack designed for one media type to run over a >> different media (i.e. a stack which thinks it is running over media type X >> may be running over type Y, via a converter, but with no media type X link >> present). > >Huh? > >> This type of converter could act differently to one where both >> types of media are actually present - i.e. options specific to media type X >> (such as ACCM for async links) can be rejected rather than accepted and used >> on one side only. Maybe the RFC should mention this ? >> >I do not understand your scenario. OK here's a real example: A computer contains a PPP stack designed to run over an internal ISDN card and written to RFC-1618 (PPP over ISDN). It is desired to connect some of these computers to an ATM network, but the computer OS manufacturer has no plans to upgrade its PPP stack to support the PPP over ATM RFC. So, the PPP card is replaced with an ATM card, and the ATM card driver does the necessary conversion. The driver is therefore a converter between RFC-1618 and the PPP over ATM RFC, but in fact there is no physical ISDN line involved. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 22 22:29:15 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA29556; Mon, 22 Dec 1997 22:29:12 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 22 Dec 1997 22:28:11 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA29503 for ietf-ppp-outgoing; Mon, 22 Dec 1997 22:28:10 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm369-08.dialip.mich.net [207.75.186.138]) by merit.edu (8.8.7/8.8.5) with SMTP id WAA29495 for ; Mon, 22 Dec 1997 22:28:03 -0500 (EST) Date: Tue, 23 Dec 97 02:11:11 GMT From: "William Allen Simpson" Message-ID: <6880.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Comments on PPP Conversion draft Sender: owner-ietf-ppp@merit.edu > From: "Ian Puleston" > >Sorry, won't work. The bridge has to do the authentication negotiation. > >If the bridge does not understand the option, then it will not work. > > So how does the bridge know which authentication protocols are supported by > the end-point? Omniscience? Prescience? > There is only one LCP option for authentication. The bridge either understands it (passes), or does not (fails). The A-P option does not affect framing. The authentication protocols themselves are not part of LCP (by design). They pass right thru the framing converter, whether the framing converter is active or passive. The end user is never confused by a bridge that appears to successfully negotiate, but does not actually pass network traffic (the stated problem that we are solving). > >Sorry, won't work. > > Would you deign to enlighten us as to why ? > Please re-read the PPP archives of several months ago on this topic. As you do the "thought experiments" to answer the questions explicitly raised, it seems rather obvious. As much as PPP is personally important to me, I get tired of typing the same thing over and over, year after year. Alternatively, I have been known to provide face-to-face tutorials, when I'm paid enough. > >I do not understand your scenario. > > OK here's a real example: > > A computer contains a PPP stack designed to run over an internal ISDN card > and written to RFC-1618 (PPP over ISDN). It is desired to connect some of > these computers to an ATM network, but the computer OS manufacturer has no > plans to upgrade its PPP stack to support the PPP over ATM RFC. So, the PPP > card is replaced with an ATM card, and the ATM card driver does the > necessary conversion. The driver is therefore a converter between RFC-1618 > and the PPP over ATM RFC, but in fact there is no physical ISDN line > involved. > No wonder I didn't understand that. Speaking as the implementor of the first PPP on PRI using the Rockwell board in early '92, I just didn't envision someone doing _anything_ this way ... the performance must be abysmal. This gives rise to a series of questions: Who is shipping this "real example"? Are you sure the ISDN bit-stuffed or (optional) octet-stuffed framing is done in software in the PPP stack? At a higher level than the ISDN driver that is being replaced? Isn't framing done in the ISDN card itself? Isn't framing done in the ATM card itself? Does the ATM driver convert the framing by emulating bit-destuffing or octet-destuffing, and then re-stuffing? Please remember that we are talking about framing. Otherwise, it might be some other kind of converter, but I doubt that is in scope for the Framing Conversion document. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Dec 22 22:29:15 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA29554; Mon, 22 Dec 1997 22:29:12 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 22 Dec 1997 22:28:13 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA29511 for ietf-ppp-outgoing; Mon, 22 Dec 1997 22:28:12 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm369-08.dialip.mich.net [207.75.186.138]) by merit.edu (8.8.7/8.8.5) with SMTP id WAA29497 for ; Mon, 22 Dec 1997 22:28:05 -0500 (EST) Date: Tue, 23 Dec 97 03:12:25 GMT From: "William Allen Simpson" Message-ID: <6881.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Comments on PPP Conversion draft Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > I can't do that because, as I said myself in my message, it doesn't > work when the local peer is the authenticator (in the case of > converters at both end, then both peers are local peers to their > respective converters). > Actually, you said "it works fine (authentication notwithstanding)." It was not obvious that meant it did not work with authentication. > I don't think there is any disagreement here - I said myself that this > sort of converter should be deprecated. I just thought it worth > discussing because there are several converters like this in existence. > This is the IETF. Once upon a time, we used to pride ourselves on not being like ISO. We made choices. We did not standardize things just because they are "in existence". Especially when they are known to have severe failure modes. Most especially when the failure mode involves security! Since you and I and the folks at the IETF DC meeting are in agreement that this sort of thing should be deprecated, then let's get on with it.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 23 05:35:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id FAA02658; Tue, 23 Dec 1997 05:34:49 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 23 Dec 1997 05:30:09 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA02592 for ietf-ppp-outgoing; Tue, 23 Dec 1997 05:30:08 -0500 (EST) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA02587 for ; Tue, 23 Dec 1997 05:29:50 -0500 (EST) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id KAA21654 for ; Tue, 23 Dec 1997 10:29:31 GMT Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 49f8fec0; Tue, 23 Dec 97 10:18:20 +0000 Mime-Version: 1.0 Date: Tue, 23 Dec 1997 10:27:24 +0000 Message-ID: <49f8fec0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Comments on PPP Conversion draft To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu >"William Allen Simpson" >> From: "Ian Puleston" >> >Sorry, won't work. The bridge has to do the authentication negotiation. >> >If the bridge does not understand the option, then it will not work. >> >> So how does the bridge know which authentication protocols are supported >> by the end-point? Omniscience? Prescience? >> > There is only one LCP option for authentication. The bridge either > understands it (passes), or does not (fails). The A-P option does not > affect framing. Can we look at this in a bit more detail. Going back to the diagram for an active converter: Peer Converter Peer <--------LCP-------> <--------LCP--------> <------------------ Auth -------------------> <------------------ NCP --------------------> For authentication to take place end-to-end, both peers need to agree on an authentication protocol, plus any associated options. So the converter has to relay the contents of the authentication option from one side to the other. The converter therefore can't implement LCP exactly according to the FSA in RFC 1661, but has to implement extra events (and possibly states). For example, the Open event in state 2 normally results in irc,scr/6. But the converter can't send out a Configure Request until it has received a Configure Request on the other interface, otherwise it doesn't know what authentication option to include (the same also goes for other options like MRU). In addition, the responses to received configure requests are dependent on what is received on the opposite interface. So this is a lot more complicated than it may appear at first sight. Ok, it can be made to work (I know, because I've done it). But it may be worth including some text in the draft RFC to explain the difficulties. >> >Sorry, won't work. (This was about what I described as a "Rejecting Converter" in a previous message, i.e. a converter that sends Configure Rejects in response to options in Configure Requests which it doesn't like, but otherwise passes everything through.) >> >> Would you deign to enlighten us as to why? >> > Please re-read the PPP archives of several months ago on this topic. > As you do the "thought experiments" to answer the questions explicitly > raised, it seems rather obvious. Well, I've read the archives and I can't find anything which provides an explanation. > As much as PPP is personally important to me, I get tired of typing the > same thing over and over, year after year. > > Alternatively, I have been known to provide face-to-face tutorials, > when I'm paid enough. Ah, so that's why it's so difficult to get anything other than bald statements out of you. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 23 10:06:59 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA04326; Tue, 23 Dec 1997 10:06:53 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 23 Dec 1997 10:05:17 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA04274 for ietf-ppp-outgoing; Tue, 23 Dec 1997 10:05:16 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA04270 for ; Tue, 23 Dec 1997 10:05:12 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA08448; Tue, 23 Dec 1997 10:04:46 -0500 (EST) Message-Id: <199712231504.KAA08448@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ietf-ppp@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tphc-01.txt Date: Tue, 23 Dec 1997 10:04:46 -0500 Sender: owner-ietf-ppp@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 : L2TP Header Compression (''L2TPHC'') Author(s) : A. Valencia Filename : draft-ietf-pppext-l2tphc-01.txt Pages : 6 Date : 22-Dec-97 The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for tunneling PPP sessions over arbitrary media. There exists a class of specific media and applications for which protocol overhead may be optimized, and where such reduction results in improved operation. This document describes the solution space addressed, its underlying motivations, and the protocol modifications required. The enhancement to the L2TP protocol is called L2TP Header Compression, or ``L2TPHC''. Internet-Drafts are 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-l2tphc-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tphc-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tphc-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19971222164806.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tphc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tphc-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971222164806.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 23 10:31:54 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA04729; Tue, 23 Dec 1997 10:31:53 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 23 Dec 1997 10:31:31 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA04695 for ietf-ppp-outgoing; Tue, 23 Dec 1997 10:31:30 -0500 (EST) Received: from Bill.Simpson.DialUp.Mich.Net (pm365-01.dialip.mich.net [207.75.186.11]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA04691 for ; Tue, 23 Dec 1997 10:31:25 -0500 (EST) Date: Tue, 23 Dec 97 14:26:50 GMT From: "William Allen Simpson" Message-ID: <6883.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Comments on PPP Conversion draft Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > >"William Allen Simpson" > > There is only one LCP option for authentication. The bridge either > > understands it (passes), or does not (fails). The A-P option does not > > affect framing. > > For authentication to take place end-to-end, both peers need to agree on > an authentication protocol, plus any associated options. So the > converter has to relay the contents of the authentication option from one > side to the other. Sure, that's a given. I disagree about "any associated options". The standard PPP options, such as A-P, are designed to be self-contained and independent. There are many other options that could be relayed as well. Compression and encryption, for example. But if you don't relay them, the link will still come up. That's how PPP is supposed to work! > The converter therefore can't implement LCP exactly > according to the FSA in RFC 1661, but has to implement extra events (and > possibly states). > I don't see any additional states. > For example, the Open event in state 2 normally results in irc,scr/6. > But the converter can't send out a Configure Request until it has > received a Configure Request on the other interface, otherwise it doesn't > know what authentication option to include (the same also goes for other > options like MRU). > I disagree. Of course you send the C-Req immediately! And when you get another C-Req on the other interface that has another option specially configured for passing through, like authentication or compression or encryption, you just send another C-Req. Easy! The FSA requires that a C-Req can be sent and received at any time. Of course, there are broken stacks (mostly from MicroSoft) that won't work, but anyone who depends on a broken stack has no business being in business.... Vote with your wallet. As to MRU, you usually will not want to relay that, as you might not be able to dynamically adjust your internal buffers. Implementation specific detail. > In addition, the responses to received configure requests are dependent > on what is received on the opposite interface. > > So this is a lot more complicated than it may appear at first sight. Ok, > it can be made to work (I know, because I've done it). > Sure, but that's true with a NAS using RADIUS. This is the usual way of implementing PPP, isn't it? Not terribly complicated to an experienced implementor.... > But it may be worth including some text in the draft RFC to explain the > difficulties. > I'll do my best. > > As much as PPP is personally important to me, I get tired of typing the > > same thing over and over, year after year. > > > > Alternatively, I have been known to provide face-to-face tutorials, > > when I'm paid enough. > > Ah, so that's why it's so difficult to get anything other than bald > statements out of you. > It might have something to do with the fact that I get circa a thousand messages a day, and try to keep my email time to 3-5 hours per day.... And nobody is paying me for email time. FYI, this reply took over 20 minutes to write. Short, specific, concise messages are all I send. Thinking thru the detail, you have to do for yourself. I expect that of anyone. This is an implementors forum, not a tutorial forum. I should not have to re-explain general concepts like "Most Significant Bit" that any engineer with an iota of experience already understands, and I have already written in multiple documents. When I write something once, I'm loath to write it again (unless I cannot remember which of the archives of the past 20 years the previous message is in). And you may have noticed, I really _hate_ nebulous, passing thought, non-specific, maybe we could do this, speculation. If you want WG attention about a problem, you need to be up front about which actual product has the problem. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Dec 23 14:30:49 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA09850; Tue, 23 Dec 1997 14:30:47 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Tue, 23 Dec 1997 14:29:56 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA09824 for ietf-ppp-outgoing; Tue, 23 Dec 1997 14:29:55 -0500 (EST) Received: from gvmail.globalvillage.com ([198.93.137.253]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA09818 for ; Tue, 23 Dec 1997 14:29:50 -0500 (EST) Received: from sleet.globalvillage.com [198.93.138.50] by gvmail.globalvillage.com (SMTPD32-4.02c) id A12014A0108; Tue, 23 Dec 1997 11:29:36 PST Received: from ianp by sleet.globalvillage.com (SMI-8.6/SMI-SVR4) id LAA12189; Tue, 23 Dec 1997 11:29:22 -0800 Message-ID: <006301bd0fd9$34cfdec0$46bf8acf@ianp.globalvillage.com> From: "Ian Puleston" To: "William Allen Simpson" , Subject: Re: Comments on PPP Conversion draft Date: Tue, 23 Dec 1997 11:30:19 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-ppp@merit.edu -----Original Message----- From: William Allen Simpson To: ietf-ppp@merit.edu Date: Monday, December 22, 1997 7:39 PM Subject: Re: Comments on PPP Conversion draft >> From: "Ian Puleston" >> >Sorry, won't work. The bridge has to do the authentication negotiation. >> >If the bridge does not understand the option, then it will not work. >> >> So how does the bridge know which authentication protocols are supported by >> the end-point? Omniscience? Prescience? >> >There is only one LCP option for authentication. The bridge either >understands it (passes), or does not (fails). The A-P option does not >affect framing. Certainly there is only one LCP option, but it can take more then one value. Some PPP implementations (maybe unwisely, but they do it) allow the peer to negotiate an authentication protocol which both ends support. Peer A says use CHAP, peer B returns a Nak specifying I don't support CHAP but I could use PAP, and peer A says OK use PAP. That is what the bridge cannot handle without knowledge of the capabilities of the end-points, or passing the LCP options across. >The authentication protocols themselves are not part of LCP (by design). >They pass right thru the framing converter, whether the framing >converter is active or passive. Understood and agreed. >> A computer contains a PPP stack designed to run over an internal ISDN card >> and written to RFC-1618 (PPP over ISDN). It is desired to connect some of >> these computers to an ATM network, but the computer OS manufacturer has no >> plans to upgrade its PPP stack to support the PPP over ATM RFC. So, the PPP >> card is replaced with an ATM card, and the ATM card driver does the >> necessary conversion. The driver is therefore a converter between RFC-1618 >> and the PPP over ATM RFC, but in fact there is no physical ISDN line >> involved. >> >No wonder I didn't understand that. Speaking as the implementor of the >first PPP on PRI using the Rockwell board in early '92, I just didn't >envision someone doing _anything_ this way ... the performance must be >abysmal. This gives rise to a series of questions: > >Who is shipping this "real example"? I meant "real" as in a real problem waiting to be solved, particularly with ADSL coming along. However there was an announcement recently from ATML, quote from their web site: "ATML's implementation of the PPP driver uses Microsoft's standard PPP stack and binds it to the ATM NIC inside the PC. " >Are you sure the ISDN bit-stuffed or (optional) octet-stuffed framing is >done in software in the PPP stack? > >At a higher level than the ISDN driver that is being replaced? > >Isn't framing done in the ISDN card itself? > >Isn't framing done in the ATM card itself? > >Does the ATM driver convert the framing by emulating bit-destuffing or >octet-destuffing, and then re-stuffing? > >Please remember that we are talking about framing. Otherwise, it might >be some other kind of converter, but I doubt that is in scope for the >Framing Conversion document. Most of the framing is done in the ISDN card, the FF,03 HDLC header being inserted by the PPP stack. However the negotiations of what framing to use (e.g. address/control field compression, alternate FCS if supported) are done by the PPP stack. Don't forget that the PPP over ATM RFC states that we MUST NOT negotiate framing options which don't apply to ATM. The converter is not just a framing converter, it is also a converter of options applying to framing. - - - - - - - - - - - - - - - - -