From owner-ietf-ppp@merit.edu Wed Sep 3 04:05:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA03186; Wed, 3 Sep 1997 04:03:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 3 Sep 1997 03:59:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA03142 for ietf-ppp-outgoing; Wed, 3 Sep 1997 03:59:57 -0400 (EDT) Received: from wjao002-IN.sita.int (wjao002.sita.int [57.250.224.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA03138 for ; Wed, 3 Sep 1997 03:59:53 -0400 (EDT) Received: by wjao002-IN.sita.int; Sendmail 1.40.112.8 (26AUG93-fma/mjr/gauntlet) id AA091373560; Wed, 3 Sep 1997 07:59:20 GMT Received: from unknown(57.4.169.130) by wjao002 via smap (3.2) id xma009116; Wed, 3 Sep 97 07:59:14 GMT Received: from pc_ptpb.pt.nce.sita.int by ncept.pt.nce.sita.int (8.8.5/SitaNet-1.4) id KAA01760; Wed, 3 Sep 1997 10:02:50 +0200 (MET DST) Date: Wed, 3 Sep 97 09:53:37 PDT From: Pierre Brenti Subject: RE: EAP interop To: ietf-ppp@merit.edu, Daniel_Brennan@3com.com X-Mailer: Chameleon V0.05, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-ietf-ppp@merit.edu Does anybody know about client soft and access server/routers including an EAP implementation ? Thanks for any help Pierre Brenti On Tue, 26 Aug 1997 07:22:35 -0400 Daniel_Brennan@3com.com wrote: > > > > > >Anyone willing to do EAP interop testing??? I am looking for both host >(Windows, Unix, etc) and access server/router versions. > >Thanks, >Dan > > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 5 17:22:04 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA24933; Fri, 5 Sep 1997 17:21:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 5 Sep 1997 17:17:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA24824 for ietf-ppp-outgoing; Fri, 5 Sep 1997 17:17:18 -0400 (EDT) Received: from coppermountain.com (tibet.coppermountain.com [206.71.190.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA24818 for ; Fri, 5 Sep 1997 17:17:12 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMail V2.5); Fri, 05 Sep 1997 14:15:55 -0800 Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMail V2.5); Fri, 05 Sep 1997 14:15:51 -0800 Message-Id: <2.2.32.19970905211755.00327ff4@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 05 Sep 1997 14:17:55 -0700 To: ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: PPP over AAL5/FUNI Sender: owner-ietf-ppp@merit.edu At 07:16 PM 8/25/97 -0400, James Watt wrote: >At 17:11 -0400 1997.08.25, Andrew G. Malis wrote: >+--------- >>That said, I agree that exclusivity can be reasonable for some >>applications (such as remote access, as you mentioned) and MUST be >>provisionable (like James, I don't want to completely rule out sharing >>the VC). >> >>Regarding the default - there are two main reasons why one would want >>to use PPP over LLC encaps in the first place. The first is RFC 1973 >>interoperation, for which exclusivity makes sense. The second is VC >>sharing in a VC-constrained environment, for which exclusivity is not >>so wonderful. Which is going to be the more likely? Probably the >>former, so I guess I can agree with making exclusivity the default. >+------ >Agreed. > >Regards, >-james Sorry for the late response. I see no need to require anything in the spec. Note that *either* end can enforce this. If your box wants exclusivity, then don't accept any packets for other code points. Why should you care what the other box does? This is a policy choice, not a standards matter. If the spec wants to point out some things for implementers to consider, go ahead. But don't proscribe things that your one application doesn't like, when other applications like it fine. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 9 18:19:47 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA23377; Tue, 9 Sep 1997 18:16:35 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 9 Sep 1997 18:12:58 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA23285 for ietf-ppp-outgoing; Tue, 9 Sep 1997 18:12:58 -0400 (EDT) Received: from cbgw1.lucent.com (cbgw1.lucent.com [192.20.239.133]) by merit.edu (8.8.7/8.8.5) with SMTP id SAA23281 for ; Tue, 9 Sep 1997 18:12:52 -0400 (EDT) Received: from garage.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id SAA27651; Tue, 9 Sep 1997 18:03:36 -0400 Received: by garage.lucent.com (5.0/EMS-L sol2) id AA27034; Tue, 9 Sep 1997 18:10:20 -0400 Date: Tue, 9 Sep 1997 18:10:20 -0400 Message-Id: <9709092210.AA27034@garage.lucent.com> From: gmg@garage.lucent.com (g.gross) To: "Eric L. Michelsen" , ietf-ppp@merit.edu Cc: gmg@garage.lucent.com Subject: Re: PPP over AAL5/FUNI Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, The LLC encapsulated PPP non-exclusivity topic got some discussion at Munich. It was raised in a question about the security hole that develops if multiple traffic flows are LLC encapsulated, and the traffic outside the PPP session is mistakenly considered secured by the PPP session's authentication or other security mechanisms. The working group decided that the ID's security section should warn about this potential security hole. Also I will be adding text in that same section to say that any protocol that has an active NCP within an LLC- encapsulated PPP session MUST not be transported by LLC-encapsulation over the same virtual circuit. So non-exclusivity is allowed, but with this restriction to improve security. Note that this is similar in spirit to what is stated in RFC1973. George Gross Lucent Technologies (908) 580-4589 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 11 22:05:54 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA12352; Thu, 11 Sep 1997 22:05:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Sep 1997 22:00:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA12202 for ietf-ppp-outgoing; Thu, 11 Sep 1997 22:00:54 -0400 (EDT) Received: from harrier.cisco.com (harrier.cisco.com [171.69.1.173]) by merit.edu (8.8.7/8.8.5) with SMTP id WAA12198 for ; Thu, 11 Sep 1997 22:00:50 -0400 (EDT) Received: from [171.71.249.52] (dhcp-f-249-52.cisco.com [171.71.249.52]) by harrier.cisco.com (8.6.12/8.6.5) with ESMTP id SAA09027; Thu, 11 Sep 1997 18:59:46 -0700 X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <199709041447.KAA19266@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 11 Sep 1997 00:32:49 -0700 To: "David Allan" From: Fred Baker Subject: Re: PPP over ATM Cc: issll@mercury.lcs.mit.edu, ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu At 10:30 AM -0400 9/4/97, David Allan wrote: >I think a reasonable argument can be put forth that the IS requirements >of this differs from both the ISATM and ISSLOW efforts. The transmisison >time for individual frames is somewhat less of an issue that that for >ISSLOW, the connection architecture is different than that for ION/ISATM >(although multicast and local cut-through are possibilities). A bit off-topic, something I have been trying to get someone to explain to me is how the point to point protocol might be used to implement point to multipoint services without putting a router in the CO. Do you think maybe you could help me understand that? My definition of a router, in this context, is a system which receives IP datagrams as layer two messages on one interface (perhaps IP/ATM, perhaps some other format) and transmits them in either the same format or some other format (such as IP/PPP/ADSL) on another, and forwards them based on their using the destination IP Address with a mapping of such addresses to select a set of virtual or physical interfaces to forward them on. This mapping algorithm might include standard routing protocols, especially in the IP Multicast case, or static routing. As I understand it, this is the device that the ADSL Forum is proposing be placed into the CO. I also believe that in at least some cases such a device may not be placed in a CO, under US tarriffing rules. I'm reading the Microsoft white paper, which makes much of the use of ATM in ADSL to provide "service transparency inherent to ATM" and "IP Multicast". It seems to me that the two are incompatible. The service transparency of ATM implies to me that I can send any data over ATM that I choose, and the bits will not be changed. Using IP Multicast means that the router is looking at the IP Header in the first ATM cell to make its forwarding decision, and the use of PPP on the last-mile copper with a multicast service implies that the regional broadband network the white paper assumes is using classical IP/ATM to provide multicast services. It seems like you can't both change and not change the bits, and you can't forward strictly based on ATM headers *and* forward strictly based on IP Multicast routing. These assertions seem mutually exclusive. What am I missing, and where would be a better place to discuss this? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Planning is bringing the future into the present so that you can do something about it now." Alan Lakein - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 11 23:37:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id XAA13959; Thu, 11 Sep 1997 23:37:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 11 Sep 1997 23:37:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA13937 for ietf-ppp-outgoing; Thu, 11 Sep 1997 23:37:10 -0400 (EDT) Received: from emout14.mail.aol.com (emout14.mx.aol.com [198.81.11.40]) by merit.edu (8.8.7/8.8.5) with ESMTP id XAA13930 for ; Thu, 11 Sep 1997 23:37:03 -0400 (EDT) From: Telford001@aol.com Received: (from root@localhost) by emout14.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id XAA15984; Thu, 11 Sep 1997 23:36:31 -0400 (EDT) Date: Thu, 11 Sep 1997 23:36:31 -0400 (EDT) Message-ID: <970911233537_1221451365@emout14.mail.aol.com> To: fred@cisco.com, David.Allan.dallan@nt.com cc: issll@mercury.lcs.mit.edu, ietf-ppp@merit.edu Subject: Re: PPP over ATM Sender: owner-ietf-ppp@merit.edu In a message dated 97-09-11 23:18:50 EDT, fred@cisco.com writes: > A bit off-topic, something I have been trying to get someone to explain to > me is how the point to point protocol might be used to implement point to > multipoint services without putting a router in the CO. Do you think maybe > you could help me understand that? > My definition of a router, in this context, is a system which receives IP > datagrams as layer two messages on one interface (perhaps IP/ATM, perhaps > some other format) and transmits them in either the same format or some > other format (such as IP/PPP/ADSL) on another, and forwards them based on > their using the destination IP Address with a mapping of such addresses to > select a set of virtual or physical interfaces to forward them on. This > mapping algorithm might include standard routing protocols, especially in > the IP Multicast case, or static routing. As I understand it, this is the > device that the ADSL Forum is proposing be placed into the CO. I also > believe that in at least some cases such a device may not be placed in a > CO, under US tarriffing rules. The VLAN Router WAN subsystem (http://members.aol.com/Telford001/vrouter.html) can provide point-to-multipoint multicast without routing turned on via switching within the communications subnet independent of the actual PPP encapsulation (MAC, IP, IPX, AppleTalk etc.). One could argue that there is no logical distinction between switching within the communications subnet and switching between communications subnets (routing), but in providing such point-to-multipoint capability the VLAN router WAN subsystem does not look at network layer addresses at all. Joachim Martillo - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 12 04:13:55 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA17766; Fri, 12 Sep 1997 04:13:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 12 Sep 1997 04:12:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA17748 for ietf-ppp-outgoing; Fri, 12 Sep 1997 04:12:51 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA17744 for ; Fri, 12 Sep 1997 04:12:47 -0400 (EDT) Received: by mail5.microsoft.com with Internet Mail Service (5.5.1664.3) id ; Fri, 12 Sep 1997 01:15:31 -0700 Message-ID: <41CD7A798584CF11B51400805FD4C60D02F01370@RED-100-MSG.dns.microsoft.com> From: Timothy Kwok To: "'Fred Baker'" , David Allan Cc: issll@mercury.lcs.mit.edu, ietf-ppp@merit.edu Subject: RE: PPP over ATM Date: Fri, 12 Sep 1997 01:12:38 -0700 X-Mailer: Internet Mail Service (5.5.1664.3) Sender: owner-ietf-ppp@merit.edu Fred, Thanks for pointing out the issues that weren't clearly presented in our (Alcatel, Cisco, 3Com(USR), Fore, Microsoft and Westell) white paper. The best place to discuss this paper is on the ADSL Forum mailing list (or better, at the ADSL Forum meeting), because an updated version of this white paper has just been formally submitted to the ADSL Forum as a contribution for the Sept meeting (next week) in Brussels. We will have an open discussion on this contribution there. Thanks, Tim > -----Original Message----- > From: Fred Baker [SMTP:fred@cisco.com] > Sent: Thursday, September 11, 1997 12:33 AM > To: David Allan > Cc: issll@mercury.lcs.mit.edu; ietf-ppp@merit.edu > Subject: Re: PPP over ATM > > At 10:30 AM -0400 9/4/97, David Allan wrote: > >I think a reasonable argument can be put forth that the IS > requirements > >of this differs from both the ISATM and ISSLOW efforts. The > transmisison > >time for individual frames is somewhat less of an issue that that for > >ISSLOW, the connection architecture is different than that for > ION/ISATM > >(although multicast and local cut-through are possibilities). > > A bit off-topic, something I have been trying to get someone to > explain to > me is how the point to point protocol might be used to implement point > to > multipoint services without putting a router in the CO. Do you think > maybe > you could help me understand that? > > My definition of a router, in this context, is a system which receives > IP > datagrams as layer two messages on one interface (perhaps IP/ATM, > perhaps > some other format) and transmits them in either the same format or > some > other format (such as IP/PPP/ADSL) on another, and forwards them based > on > their using the destination IP Address with a mapping of such > addresses to > select a set of virtual or physical interfaces to forward them on. > This > mapping algorithm might include standard routing protocols, especially > in > the IP Multicast case, or static routing. As I understand it, this is > the > device that the ADSL Forum is proposing be placed into the CO. I also > believe that in at least some cases such a device may not be placed in > a > CO, under US tarriffing rules. > > I'm reading the Microsoft white paper, which makes much of the use of > ATM > in ADSL to provide "service transparency inherent to ATM" and "IP > Multicast". It seems to me that the two are incompatible. The service > transparency of ATM implies to me that I can send any data over ATM > that I > choose, and the bits will not be changed. Using IP Multicast means > that the > router is looking at the IP Header in the first ATM cell to make its > forwarding decision, and the use of PPP on the last-mile copper with a > multicast service implies that the regional broadband network the > white > paper assumes is using classical IP/ATM to provide multicast services. > It > seems like you can't both change and not change the bits, and you > can't > forward strictly based on ATM headers *and* forward strictly based on > IP > Multicast routing. These assertions seem mutually exclusive. > > What am I missing, and where would be a better place to discuss this? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-= > "Planning is bringing the future into the present so that you can do > something about it now." Alan Lakein > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Sep 13 07:33:50 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA10551; Sat, 13 Sep 1997 07:32:59 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 13 Sep 1997 07:27:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA10508 for ietf-ppp-outgoing; Sat, 13 Sep 1997 07:27:23 -0400 (EDT) Received: from ns.trancell.stph.net (prasan@ns.trancell.stph.net [196.12.55.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id HAA10503 for ; Sat, 13 Sep 1997 07:26:49 -0400 (EDT) Received: from trancell.stph.net (prasan@localhost) by ns.trancell.stph.net (8.7.3/8.7.3) id RAA27222 for ietf-ppp@merit.edu; Sat, 13 Sep 1997 17:35:16 +0530 (IST) From: "N.G.Prasanna Kumar" Message-Id: <199709131205.RAA27222@trancell.stph.net> Subject: CallBack query ?? To: ietf-ppp@merit.edu Date: Sat, 13 Sep 1997 17:35:15 +0530 (IST) 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 Hello everyone, can any one help me for following info on implementation specifics of PPP Callback. - What is standard callback implementation. Does it have to support only LCP extension options 13 with sub-options 0 through 4, or does it have to also support 5 and 6. - Is CBCP part of standrard PPP extensions, or still a proposal? - If peer (either client or server) speak only CBCP, are there any suggestions on how to take care instead of just rejecting that option (I know any protocol not implemented should be rejected). - Are there any commercial products in market which do callback negotiation without CBCP. Is there any PPP stack for win95/NT as shareware/freeware with similar callback implementation? Thankyou in advance for your help, Swamy and Prasanna ---------- mailto: podila@trancell.stph.net - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Sep 15 03:02:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id DAA28459; Mon, 15 Sep 1997 03:01:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 15 Sep 1997 02:56:48 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA28415 for ietf-ppp-outgoing; Mon, 15 Sep 1997 02:56:47 -0400 (EDT) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA28407 for ; Mon, 15 Sep 1997 02:56:33 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Mon, 15 Sep 1997 12:33:01 +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 MAA00262; Mon, 15 Sep 1997 12:01:19 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <341D892E@msgate.future.futsoft.com>; Mon, 15 Sep 97 12:14:54 PDT From: shenoyh To: "'Craig'" , pppkevin Cc: PPPMailing-List Subject: BAP First link concept Date: Mon, 15 Sep 97 11:57:00 PDT Message-Id: <341D892E@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Hi, RFC 2125 on page 18, ( 6.2.1 Phone-Delta Sub-Options, Unique-Digits ), introduces a "new concept" - "First port" of multi-link bundle. This term is not used anywhere , say in rfc1990 ( MP ) or elsewhere. A few doubts that it throws up : What happens if the first link is deleted from a bundle ? Is some other link designated as the first link ? On what basis is another link made the "first link" ? Or shouldnt the first link be deleted at all ? If this is the case, then what value will the "Phone Number" field of a "First link" of the bundle carry ? Will all the digits of the first link's phone number be unique digits ? Regards, Sandeep S, (sandeeps@future.futsoft.com) Shenoy H. (shenoyh@future.futsoft.com) - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Sep 15 14:16:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA08016; Mon, 15 Sep 1997 14:16:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 15 Sep 1997 14:11:08 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA07889 for ietf-ppp-outgoing; Mon, 15 Sep 1997 14:11:08 -0400 (EDT) Received: from funk.com (root@funk.funk.com [198.186.160.66]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA07885 for ; Mon, 15 Sep 1997 14:11:01 -0400 (EDT) Received: from KenZeos.funk.com (machine-154.funk.com [198.186.160.154]) by funk.com (8.8.5/8.8.5) with ESMTP id OAA14207; Mon, 15 Sep 1997 14:07:25 -0400 (EDT) Message-ID: <341D78FB.21238F43@funk.com> Date: Mon, 15 Sep 1997 14:05:47 -0400 From: Ken Culbert Reply-To: ken@funk.com Organization: Funk Software, Inc. X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: "N.G.Prasanna Kumar" CC: ietf-ppp@merit.edu Subject: Re: CallBack query ?? X-Priority: 3 (Normal) References: <199709131205.RAA27222@trancell.stph.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu N.G.Prasanna Kumar wrote: > can any one help me for following info on implementation specifics > of PPP Callback. > > - What is standard callback implementation. > Does it have to support only LCP extension options 13 with sub-options > 0 through 4, or does it have to also support 5 and 6. current rfc is 1570, "LCP Extensions"; Bill Simpson has submitted a new draft > > - Is CBCP part of standrard PPP extensions, or still a proposal? CBCP is a Microsoft proprietary option; I believe it isn't even an information RFC. > - If peer (either client or server) speak only CBCP, are there any > suggestions on how to take care instead of just rejecting that > option (I know any protocol not implemented should be rejected). One way would be to NAK for another operation, and if that failed to REJ the callback option. > - Are there any commercial products in market which do callback > negotiation without CBCP. Is there any PPP stack for win95/NT > as shareware/freeware with similar callback implementation? The PC side (both DOS/WIN3.1 and WIN9x) of Funk Software's WanderLink supports callback with and without CBCP. It is available at http://www.funk.com/demosw.html > Thankyou in advance for your help, > > Swamy and Prasanna > > ---------- > > mailto: podila@trancell.stph.net -- Ken Culbert, Principal Engineer ken@funk.com Funk Software, Inc. http://www.funk.com 222 Third Street voice: +1 617 497-6339 Cambridge, MA 02021 USA fax: +1 617 547-1031 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 16 08:39:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA21689; Tue, 16 Sep 1997 08:37:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 16 Sep 1997 08:33:06 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA21618 for ietf-ppp-outgoing; Tue, 16 Sep 1997 08:33:05 -0400 (EDT) Received: from fsnt.future.futsoft.com ([38.242.192.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA21614 for ; Tue, 16 Sep 1997 08:32:58 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Tue, 16 Sep 1997 18:09:18 +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 RAA14658 for ; Tue, 16 Sep 1997 17:38:23 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <341F2991@msgate.future.futsoft.com>; Tue, 16 Sep 97 17:51:29 PDT From: sunilkrd To: ietf Subject: Padding Option Date: Tue, 16 Sep 97 17:51:00 PDT Message-Id: <341F2991@msgate.future.futsoft.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu can any one help me on the implementation details of Padding option in LCP. After successful negotiation of MPV ( Maximum Pad Value), when any of the NetworkCP is up say CcompressionControlProtocol, where we actually have to pad the packet. will it be in the NCP level or LCP level . please give details clarify. Sunil.. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 16 13:38:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA27283; Tue, 16 Sep 1997 13:38:37 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 16 Sep 1997 13:37:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA27260 for ietf-ppp-outgoing; Tue, 16 Sep 1997 13:37:50 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA27253 for ; Tue, 16 Sep 1997 13:37:42 -0400 (EDT) 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 KAA14870; Tue, 16 Sep 1997 10:36:41 -0700 Received: from ascend.com by ascend.com with ESMTP id KAA03923; Tue, 16 Sep 1997 10:36:36 -0700 Received: from tylenol4.eng.ascend.com (tylenol4.eng.ascend.com [206.65.212.7]) by wopr.eng.ascend.com (8.6.12/8.6.12) with ESMTP id KAA14063; Tue, 16 Sep 1997 10:36:06 -0700 Received: (from clara@localhost) by tylenol4.eng.ascend.com (8.6.12/8.6.12) id KAA12312; Tue, 16 Sep 1997 10:36:04 -0700 Date: Tue, 16 Sep 1997 10:36:04 -0700 From: Clara Mckenzie Message-Id: <199709161736.KAA12312@tylenol4.eng.ascend.com> To: ken@funk.com, prasan@trancell.stph.net Subject: Re: CallBack query ?? Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu N.G.Prasanna Kumar wrote: > - If peer (either client or server) speak only CBCP, are there any > suggestions on how to take care instead of just rejecting that > option (I know any protocol not implemented should be rejected). Then Ken Culbert wrote: > One way would be to NAK for another operation, and if that failed to REJ > the callback option. The way to reject it is to reject the CBCP client's configuration request of the LCP callback option. If you accept, then the client will wait patiently after authentication for you, the CBCP server to start the CBCP protocol. If you do not accept the LCP callback option (with the operation field value of 6), then the client will not expect CBCP. > - Are there any commercial products in market which do callback > negotiation without CBCP. Is there any PPP stack for win95/NT > as shareware/freeware with similar callback implementation? Then Ken Culbert wrote: > The PC side (both DOS/WIN3.1 and WIN9x) of Funk Software's WanderLink > supports callback with and without CBCP. > It is available at http://www.funk.com/demosw.html Ascend also has Windows software - MaxLink - that will accomodate callback from Ascend equipment, maybe other equipment too - I don't have all the details. Clara McKenzie clara@ascend.com Ascend Communications http://www.ascend.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 16 18:07:27 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA03223; Tue, 16 Sep 1997 18:07:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 16 Sep 1997 18:06:44 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA03199 for ietf-ppp-outgoing; Tue, 16 Sep 1997 18:06:43 -0400 (EDT) Received: from cliff.odetics.com (cliff.odetics.com [207.211.74.67]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA03195 for ; Tue, 16 Sep 1997 18:06:38 -0400 (EDT) Received: (from daemon@localhost) by cliff.odetics.com (8.8.5/8.8.5) id PAA13864 for ; Tue, 16 Sep 1997 15:07:37 -0700 (PDT) Received: from newman.odetics.com(198.58.66.17), claiming to be "odetics.com" via SMTP by cliff, id msgidAAAa003O_; Tue Sep 16 15:07:24 1997 Received: from pc_11807.odetics.com by odetics.com (SMI-8.6/SMI-SVR4) id OAA02709; Tue, 16 Sep 1997 14:59:52 -0700 Received: by localhost with Microsoft MAPI; Tue, 16 Sep 1997 15:10:16 -0700 Message-ID: <01BCC2B2.A398D240.mep1@odetics.com> From: Mike Penna To: "'ietf-ppp@merit.edu'" Subject: PPP Over ATM Date: Tue, 16 Sep 1997 15:10:15 -0700 Organization: Odetics, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Can someone please point me in the direction of a site where I can retrieve the latest draft on "PPP Over ATM" ? Thanks, mep1@odetics.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 16 18:32:08 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA03719; Tue, 16 Sep 1997 18:32:06 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 16 Sep 1997 18:31:48 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA03697 for ietf-ppp-outgoing; Tue, 16 Sep 1997 18:31:47 -0400 (EDT) Received: from cbgw1.lucent.com (cbgw1.lucent.com [192.20.239.133]) by merit.edu (8.8.7/8.8.5) with SMTP id SAA03693 for ; Tue, 16 Sep 1997 18:31:42 -0400 (EDT) To: Mike Penna , "'ietf-ppp@merit.edu'" Received: from garage.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id SAA11775; Tue, 16 Sep 1997 18:22:17 -0400 Received: by garage.lucent.com (5.0/EMS-L sol2) id AA17489; Tue, 16 Sep 1997 18:29:05 -0400 Date: Tue, 16 Sep 1997 18:29:05 -0400 Message-Id: <9709162229.AA17489@garage.lucent.com> From: gmg@garage.lucent.com (g.gross) Original-To: Mike Penna , "'ietf-ppp@merit.edu'" Cc: gmg@garage.lucent.com Subject: Re: PPP Over ATM Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, The 7/25/97 draft is available today from the IETF FTP site, and its file name is: draft-ietf-pppext-aal5-01.txt There is also a companion draft that describes PPP over FUNI. I'm revising both of these drafts to reflect the comments I've received from this list and the Munich IETF PPP WG meeting. The version 02 will be available in the next several days (likely by Thursday COB). George Gross Lucent Technologies (908) 580-4589 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 00:47:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA08708; Wed, 17 Sep 1997 00:47:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 00:46:48 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA08678 for ietf-ppp-outgoing; Wed, 17 Sep 1997 00:46:48 -0400 (EDT) Received: from ns.trancell.stph.net (podila@ns.trancell.stph.net [196.12.55.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA08672 for ; Wed, 17 Sep 1997 00:46:27 -0400 (EDT) Received: from trancell.stph.net (podila@localhost) by ns.trancell.stph.net (8.7.3/8.7.3) id KAA22915; Wed, 17 Sep 1997 10:55:02 +0530 (IST) Date: Wed, 17 Sep 1997 10:55:01 +0530 (IST) From: "Swamy P.H.V.S" To: ietf-ppp@merit.edu Subject: Re: CallBack query ?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Clara wrote: > The way to reject it is to reject the CBCP client's configuration > request of the LCP callback option. If you accept, then the client will > wait patiently after authentication for you, the CBCP server to start the > CBCP protocol. If you do not accept the LCP callback option (with the > operation field value of 6), then the client will not expect CBCP. > I have doubts if the client (eg. I tested with NT and 95 with MS stack), which do negotiate CBCP, but if I go to IPCP after authenitcation,they continue further and call gets established! So at LCP if we accept CBCP, and do not actually start CBCP server after Authenitaction, things will go as if callback has not been negotiated! Also, if we NAK the CBCP operation value (6) in callback option with 0-4, the NT client comes with fresh CONF REQ with no callback option at all. I think this is bad, a client cannot expect his remote server, to whom he is dialing-in, to supports CBCP, which is a proprietory protocol. Can anyone comment on this or is there any other way, where MS PPP will start negotiating other than CBCP for callback? Swamy ------------------------------- Graduate life -- it's not just a job, it's an indenture. Swamy Podila podila@trancell.stph.net - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 01:36:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA09406; Wed, 17 Sep 1997 01:36:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 01:36:40 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA09388 for ietf-ppp-outgoing; Wed, 17 Sep 1997 01:36:39 -0400 (EDT) Received: from ns.trancell.stph.net (podila@ns.trancell.stph.net [196.12.55.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id BAA09381 for ; Wed, 17 Sep 1997 01:36:19 -0400 (EDT) Received: from trancell.stph.net (podila@localhost) by ns.trancell.stph.net (8.7.3/8.7.3) id LAA23213; Wed, 17 Sep 1997 11:46:28 +0530 (IST) Date: Wed, 17 Sep 1997 11:46:27 +0530 (IST) From: "Swamy P.H.V.S" To: ietf-ppp@merit.edu Subject: address negotiation in IPCP... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hi every one: In IPCP negotiations, both client (the one who is dialing out) and server (to whome client is dialing into), will come with IP-address. Assuming both have come with some address for respective local ends of the link, it is a common implementation where server may NAK the client-end of link address and propose address which is more acceptable to server and client may accept that address. Similarly, can a client NAK the address of server-end of link, and propose another address for the server-end of the link? Do any one have suggestions on how a PPP-client can propose addresses for both ends of the PPP link and server accepts the proposed addresses? (A practical example is: a site is using NT server as router to access Internet through an ISP through Dialup lines. Normally NT does dial-in to ISP, and ISP assigns addresses. But, if ISP calls into NT (without callback), who will assign the addresses at both ends of the PPP link!?!) Thankyou, Swamy ------------------------------- Graduate life -- it's not just a job, it's an indenture. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 02:37:22 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id CAA10078; Wed, 17 Sep 1997 02:37:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 02:36:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA10056 for ietf-ppp-outgoing; Wed, 17 Sep 1997 02:36:54 -0400 (EDT) Received: from stpn.soft.net (stpn.soft.net [204.143.127.2]) by merit.edu (8.8.7/8.8.5) with SMTP id CAA10052 for ; Wed, 17 Sep 1997 02:36:47 -0400 (EDT) Received: from shilpa.pcl.stpn.soft.net (unverified [204.143.116.98]) by stpn.soft.net (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 17 Sep 1997 12:09:58 +0530 Received: from [192.168.200.142] by shilpa.pcl.stpn.soft.net id aa25846; 17 Sep 97 12:06 IST Message-ID: <341F7B66.3691@pcl.stpn.soft.net> Date: Wed, 17 Sep 1997 12:10:38 +0530 From: Vimal Khanna Organization: PCL Mindware X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Requesting comments on my draft draft-rfced-info-khana-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu I shall be grateful if the interested members of the discussion group could comment on my draft "draft-rfced-info-khana-00.txt" submitted for consideration by the Working Group. Thanks and regards. Vimal SUMMARY : Currently a huge installed base of networking users across the world are connected to Packet Switched Data Networks thru the async. ports of their PCs. The usual mechanisms of access is thru Packet Assemblers and Disassemblers (PADs). This setup and protocol allows only rudimentary applications like remote login be used from these PCs. But these users need to access a complete range of applications and resources, which is not possible in the current scenario. The draft suggests a PPP based protocol which will allow all these PC users to run TCP/IP protocol over their async links to PADs. Thus, the complete range of TCP/IP applications, including Web access, can be run from the PC. The PC can run applications to any TCP/IP based computer on the Internet, and access global resources thru the Web. The protocol requires absolutely no change in the existing setups and equipments and co-exists with the existing protocols. Worldwide a large number of users are accessing PSDNs thru low cost async connections. The numbers are increasing due to the cost advantage and availability of large installed base of PSDNs. Given the omnipresence and immense growth of WWW, we believe such a protocol is necessary to benefit a majority of networking users worldwide. A paper broadly based on this protocol has been accepted in the following journal - [1] Vimal K. Khanna, "A suggested protocol for Internet access on PSDNs", Journal of Systems Architecture, Elsevier Science, (accepted April 1997). - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 07:00:37 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id GAA11898; Wed, 17 Sep 1997 06:58:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 06:54:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id GAA11865 for ietf-ppp-outgoing; Wed, 17 Sep 1997 06:54:28 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-25.dialip.mich.net [141.211.7.193]) by merit.edu (8.8.7/8.8.5) with SMTP id GAA11837; Wed, 17 Sep 1997 06:48:29 -0400 (EDT) Date: Wed, 17 Sep 97 10:23:01 GMT From: "William Allen Simpson" Message-ID: <6570.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: CallBack query ?? Sender: owner-ietf-ppp@merit.edu > From: "N.G.Prasanna Kumar" > - What is standard callback implementation. > Does it have to support only LCP extension options 13 with sub-options > 0 through 4, or does it have to also support 5 and 6. > 0 Identification from the Authentication phase will be used for a database lookup to determine the callback parame- ters. The Message field is not present. This method is required to be supported in all conformant implementations. > - Is CBCP part of standrard PPP extensions, or still a proposal? > Proprietary Microsoft product, with no relevance to IETF. They refused to bring it to this WG before releasing it, and have not granted change control to the IETF. "Embrace and extend." In short, it isn't interoperable, and you can treat it as just another minor bug in the very buggy Microsoft PPP stack. > - If peer (either client or server) speak only CBCP, are there any > suggestions on how to take care instead of just rejecting that > option (I know any protocol not implemented should be rejected). > The FSA already provides for a series of C-Naks followed by a C-Rej when the peer fails to successfully negotiate the option. > - Are there any commercial products in market which do callback > negotiation without CBCP. Ascend and Cisco, for two small unknown insignificant vendors.... :-) > Is there any PPP stack for win95/NT > as shareware/freeware with similar callback implementation? > Not that I know of. This is the PPP implementors list. Let us know when you write one? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 07:34:37 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA12154; Wed, 17 Sep 1997 07:33:14 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 07:32:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA12134 for ietf-ppp-outgoing; Wed, 17 Sep 1997 07:32:48 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-10.dialip.mich.net [141.211.7.178]) by merit.edu (8.8.7/8.8.5) with SMTP id HAA12122 for ; Wed, 17 Sep 1997 07:32:43 -0400 (EDT) Date: Wed, 17 Sep 97 10:49:32 GMT From: "William Allen Simpson" Message-ID: <6571.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: address negotiation in IPCP... Sender: owner-ietf-ppp@merit.edu > From: "Swamy P.H.V.S" > Similarly, can a client NAK the address of server-end of link, and > propose another address for the server-end of the link? > Certainly. But the peer doesn't have to accept it. No NAS code I've written will accept such a mis-assignment. > Do any one have suggestions on how a PPP-client can propose addresses for > both ends of the PPP link and server accepts the proposed addresses? > First of all, there are no clients and servers in PPP. All we have are peers. Why do you care what the address is on the other end of the link? Or if it even has an address? If it has an address, and (1) that address is routable from your box, and (2) isn't already assigned to another interface on your box, then just Ack the address. (This is the code I've always used.) The IP-Address C-Nak is mostly used when the address is unknown or improper. > (A practical example is: a site is using NT server as router to access > Internet through an ISP through Dialup lines. Normally NT does dial-in to > ISP, and ISP assigns addresses. But, if ISP calls into NT (without > callback), who will assign the addresses at both ends of the PPP link!?!) > PPP links can run without addresses. And this sounds like the usual Unix scenario, which SGI and Sun and various other vendors work quite well. Which stack are you writing? NT stack to replace WinNT? Or a NAS stack? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 12:34:10 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA16892; Wed, 17 Sep 1997 12:32:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 12:31:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA16850 for ietf-ppp-outgoing; Wed, 17 Sep 1997 12:31:55 -0400 (EDT) Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA16846 for ; Wed, 17 Sep 1997 12:31:51 -0400 (EDT) Received: from d01lms04.pok.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA29042; Wed, 17 Sep 1997 16:35:29 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400010928361; Wed, 17 Sep 1997 12:34:51 -0400 From: John Martz To: Subject: Two (nit picky) questions on authentication Message-Id: <5010400010928361000002L012*@MHS> Date: Wed, 17 Sep 1997 12:34:51 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Folks, I have two somewhat "nit-picky" questions about how to implement some aspects of PPP authentication. I don't think we're doing anything seriously wrong, but it seems like a good idea to get feedback from the mailing list. The questions came up when we ran some PPP test cases that we purchased from an external company. One of their test cases expects to have the following exchange: us: send configure-request with CHAP (or PAP) authentication option them: send configure-reject for authentication option us: send configure-request without authentication option them: send configure-ack, configure-request us: send configure-ack (LCP is in OPEN state) us: send terminate-request (because authentication was not negotiated above) The above exchange seems rather pointless to me. I realize that it is definitely the way some (UNIX ?) PPP implementations work. However in our implementation the scenario goes as follows: us: send configure-request with CHAP (or PAP) authentication option them: send configure-reject for authentication option us: send terminate-request In other words, if the peer rejects the authentication option ... in effect saying "I won't negotiate authentication" ... and our configuration REQUIRES that the peer authenticate itself to us, then we just give it up at that point. I don't understand why other implementations do this differently. I'm sure there's a good reason ... I just don't appreciate it yet . Can someone explain why the first scenario might be preferred over the second? As I read RFC 1661, our implementation is compliant. The description of configure-reject on page 32 states that you MUST NOT include any of the rejected options in any configure-request sent after receiving a valid configure-reject. Well ... we don't. We never send another configure-request after the configure-reject for the authentication. No? My other question is about the proper handling of delayed responses to a CHAP challenge. If we don't receive a response to a CHAP challenge within the retry-timer period (default 3 seconds) we send another challenge. RFC 1994 page 8 states that the identifier field and challenge value MUST be changed each time a challenge is sent, so we do this (of course ;-). What I've seen happen with the test system is that for some reason it waits from 10-15 seconds before sending the first CHAP response to the CHAP challenges. It then (very quickly) sends us responses to all of the challenges we sent in the order it received them. Currently our implementation discards any CHAP responses whose ID do NOT match the ID of the last CHAP challenge sent to the peer. So when the responses come in, we discard all except the response to the most recent challenge. Is this typical/acceptable? The alternative would be to remember each of the challenges that I've sent to peer and if I get a valid response to any of them, process it. This seems like a lot of work for very little payback (typically) in the normal usage. However, in my reading of RFC 1994 I didn't get a clear sense of whether responses to previous challenges should be processed or discarded. Would appreciate any feedback from others on how their implementations handle this situation. Thanks in advance, -john martz IBM AS/400 TCP/IP PPP jmartz@us.ibm.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 13:42:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA18852; Wed, 17 Sep 1997 13:41:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 13:40:48 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA18818 for ietf-ppp-outgoing; Wed, 17 Sep 1997 13:40:47 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA18813 for ; Wed, 17 Sep 1997 13:40:40 -0400 (EDT) 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 KAA16600 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Wed, 17 Sep 1997 10:40:33 -0700 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 LAA03905 for ietf-ppp@merit.edu; Wed, 17 Sep 1997 11:40:09 -0600 Date: Wed, 17 Sep 1997 11:40:09 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199709171740.LAA03905@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: re: Two (nit picky) questions on authentication Sender: owner-ietf-ppp@merit.edu > From: John Martz >The questions came up when we ran some PPP test cases that we purchased from an > external company. One of their test cases expects to have the following > exchange: > us: send configure-request with CHAP (or PAP) authentication option > them: send configure-reject for authentication option > us: send configure-request without authentication option > them: send configure-ack, configure-request > us: send configure-ack (LCP is in OPEN state) > us: send terminate-request (because authentication was not negotiated above) > > The above exchange seems rather pointless to me. I realize that it is > definitely the way some (UNIX ?) PPP implementations work. Not mine. > However in our > implementation the scenario goes as follows: > us: send configure-request with CHAP (or PAP) authentication option > them: send configure-reject for authentication option > us: send terminate-request That sounds good to me. > In other words, if the peer rejects the authentication option ... in effect > saying "I won't negotiate authentication" ... and our configuration REQUIRES > that the peer authenticate itself to us, then we just give it up at that > point. .... It sounds as if you've run up against the common and silly misconception that because something is in a test suite, it must be right. The standards "MUST" always let you send a Terminate-Request for any reason, starting with not liking the other guy's CHAP secret and continuing through a prejudice against the religous preference of the individual bits from the PPP peer. It can be handy to leave an unauthenticated link up for a little while to allow LQM measurements, but you don't want to help out a denial of service attack. If you are going to immedicately follow the LCP Configure-Ack with a Termiante-Request, why waste the time for the extra LCP packets? You're wasting connect time that could be billed to a legitimate user. > ... > My other question is about the proper handling of delayed responses to a CHAP > challenge. If we don't receive a response to a CHAP challenge within the >retry-timer period (default 3 seconds) we send another challenge. RFC 1994 page > 8 states that the identifier field and challenge value MUST be changed each > time a challenge is sent, so we do this (of course ;-). Good for you. I'm told there are plenty of junk (or at least very weak) implementations that violate the common sense and required precaution of changing the ID. > What I've seen happen with the test system is that for some reason it waits > from 10-15 seconds before sending the first CHAP response to the CHAP > challenges. It then (very quickly) sends us responses to all of the challenges > we sent in the order it received them. Currently our implementation discards >any CHAP responses whose ID do NOT match the ID of the last CHAP challenge sent >to the peer. So when the responses come in, we discard all except the response > to the most recent challenge. > > Is this typical/acceptable? My code does as yours does. What bad things could happen if you do that? The worst I can see is if the last Response is lost, forcing yet another timeout and retry. I think it is both acceptable and in practical code, required for obvious security worries. Never mind the junk implementations that fail to check the ID at all. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 13:44:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA18887; Wed, 17 Sep 1997 13:42:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 13:42:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA18866 for ietf-ppp-outgoing; Wed, 17 Sep 1997 13:42:25 -0400 (EDT) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA18862 for ; Wed, 17 Sep 1997 13:42:17 -0400 (EDT) Received: (fox@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id KAA19170; Wed, 17 Sep 1997 10:41:14 -0700 From: Craig Fox Message-Id: <199709171741.KAA19170@greatdane.cisco.com> Subject: Re: Two (nit picky) questions on authentication To: jmartz@us.ibm.com (John Martz) Date: Wed, 17 Sep 97 10:41:14 PDT Cc: ietf-ppp@merit.edu In-Reply-To: <5010400010928361000002L012*@MHS>; from "John Martz" at Sep 17, 97 12:34 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-ppp@merit.edu > > Folks, > > I have two somewhat "nit-picky" questions about how to implement some aspects > of PPP authentication. I don't think we're doing anything seriously wrong, but > it seems like a good idea to get feedback from the mailing list. > > The questions came up when we ran some PPP test cases that we purchased from an > external company. One of their test cases expects to have the following > exchange: > us: send configure-request with CHAP (or PAP) authentication option > them: send configure-reject for authentication option > us: send configure-request without authentication option > them: send configure-ack, configure-request > us: send configure-ack (LCP is in OPEN state) > us: send terminate-request (because authentication was not negotiated above) > > The above exchange seems rather pointless to me. I realize that it is > definitely the way some (UNIX ?) PPP implementations work. However in our > implementation the scenario goes as follows: > us: send configure-request with CHAP (or PAP) authentication option > them: send configure-reject for authentication option > us: send terminate-request > > In other words, if the peer rejects the authentication option ... in effect > saying "I won't negotiate authentication" ... and our configuration REQUIRES > that the peer authenticate itself to us, then we just give it up at that > point. I don't understand why other implementations do this differently. I'm > sure there's a good reason ... I just don't appreciate it yet . Can someone > explain why the first scenario might be preferred over the second? > It is not. If you refuse to do authentication (and we requested it), Cisco routers will terminate the connection gracefully. > As I read RFC 1661, our implementation is compliant. The description of > configure-reject on page 32 states that you MUST NOT include any of the > rejected options in any configure-request sent after receiving a valid > configure-reject. Well ... we don't. We never send another configure-request > after the configure-reject for the authentication. No? > You are correct. > My other question is about the proper handling of delayed responses to a CHAP > challenge. If we don't receive a response to a CHAP challenge within the > retry-timer period (default 3 seconds) we send another challenge. RFC 1994 page > 8 states that the identifier field and challenge value MUST be changed each > time a challenge is sent, so we do this (of course ;-). > > What I've seen happen with the test system is that for some reason it waits > from 10-15 seconds before sending the first CHAP response to the CHAP > challenges. It then (very quickly) sends us responses to all of the challenges > we sent in the order it received them. Currently our implementation discards > any CHAP responses whose ID do NOT match the ID of the last CHAP challenge sent > to the peer. So when the responses come in, we discard all except the response > to the most recent challenge. > > Is this typical/acceptable? The alternative would be to remember each of the > challenges that I've sent to peer and if I get a valid response to any of them, > process it. This seems like a lot of work for very little payback (typically) > in the normal usage. However, in my reading of RFC 1994 I didn't get a clear > sense of whether responses to previous challenges should be processed or > discarded. Would appreciate any feedback from others on how their > implementations handle this situation. > Your implementation is correct. Craig > Thanks in advance, > > -john martz > IBM AS/400 TCP/IP PPP > jmartz@us.ibm.com > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 16:50:13 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA23049; Wed, 17 Sep 1997 16:46:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 16:43:33 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA22974 for ietf-ppp-outgoing; Wed, 17 Sep 1997 16:43:32 -0400 (EDT) Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA22967 for ; Wed, 17 Sep 1997 16:43:27 -0400 (EDT) Received: (vandys@localhost) by zipper.cisco.com (8.8.4-Cisco.1/8.6.5) id NAA17597; Wed, 17 Sep 1997 13:42:45 -0700 (PDT) Date: Wed, 17 Sep 1997 13:42:45 -0700 (PDT) From: Andrew Valencia Message-Id: <199709172042.NAA17597@zipper.cisco.com> To: vimal@pcl.stpn.soft.net Cc: ietf-ppp@merit.edu Subject: Re: Requesting comments on my draft draft-rfced-info-khana-00.txt Newsgroups: cisco.external.ietf.ppp References: <341F7B66.3691@pcl.stpn.soft.net> X-Newsreader: NN version 6.5.1 #4 (NOV) Sender: owner-ietf-ppp@merit.edu >The draft suggests a PPP based protocol which will allow all these PC >users to run TCP/IP protocol over their async links to PADs. >... If I'm reading this draft correctly, you're saying "run async PPP over a byte stream protocol". I don't think there needs to be a new protocol; we (cisco) implemented exactly this (supported media are X.25 PAD, telnet, and LAT) using this idea. See the "Protocol Translation" part of our manual as a proof by existence that you don't need a new protocol, but rather can do the job with existing standards, admittedly hooked together in an unconventional topology. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 17 21:44:14 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA27285; Wed, 17 Sep 1997 21:44:04 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 17 Sep 1997 21:43:46 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA27262 for ietf-ppp-outgoing; Wed, 17 Sep 1997 21:43:45 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm037-07.dialip.mich.net [141.211.7.80]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA27258 for ; Wed, 17 Sep 1997 21:43:38 -0400 (EDT) Date: Thu, 18 Sep 97 00:22:09 GMT From: "William Allen Simpson" Message-ID: <6575.wsimpson@greendragon.com> To: Subject: Re: Two (nit picky) questions on authentication Sender: owner-ietf-ppp@merit.edu > From: John Martz > I have two somewhat "nit-picky" questions about how to implement some aspects > of PPP authentication. I don't think we're doing anything seriously wrong, but > it seems like a good idea to get feedback from the mailing list. > Alway happy to hear from implementors on the list (instead of privately). > The questions came up when we ran some PPP test cases that we purchased from an > external company. One of their test cases expects to have the following > exchange: > us: send configure-request with CHAP (or PAP) authentication option > them: send configure-reject for authentication option > us: send configure-request without authentication option > them: send configure-ack, configure-request > us: send configure-ack (LCP is in OPEN state) > us: send terminate-request (because authentication was not negotiated above) > > The above exchange seems rather pointless to me. True. Functionally correct, but pointless. OTOH, that's what happens in my code. I don't check to see that all required options are negotiated until I reach Opened. It wastes a little bandwidth, and a little time, but I wouldn't expect that anyone would use such a configuration for long, as they'd never get any service. > However in our > implementation the scenario goes as follows: > us: send configure-request with CHAP (or PAP) authentication option > them: send configure-reject for authentication option > us: send terminate-request > That's much better. > My other question is about the proper handling of delayed responses to a CHAP > challenge. If we don't receive a response to a CHAP challenge within the > retry-timer period (default 3 seconds) we send another challenge. RFC 1994 page > 8 states that the identifier field and challenge value MUST be changed each > time a challenge is sent, so we do this (of course ;-). > Good! > What I've seen happen with the test system is that for some reason it waits > from 10-15 seconds before sending the first CHAP response to the CHAP > challenges. It then (very quickly) sends us responses to all of the challenges > we sent in the order it received them. Currently our implementation discards > any CHAP responses whose ID do NOT match the ID of the last CHAP challenge sent > to the peer. So when the responses come in, we discard all except the response > to the most recent challenge. > You are correct. The tester must be queuing the challenges, perhaps to simulate waiting for a secret from a database, such as RADIUS. > Is this typical/acceptable? The alternative would be to remember each of the > challenges that I've sent to peer and if I get a valid response to any of them, > process it. This seems like a lot of work for very little payback (typically) > in the normal usage. However, in my reading of RFC 1994 I didn't get a clear > sense of whether responses to previous challenges should be processed or > discarded. Discarded. They could be left over from a previous PPP session. You are correct, the text does not say anything specific about discarding. It just says that a Response has to have the "current Challenge Identifier". I'll add another sentence to the next (full) standard draft. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 18 12:30:59 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA07200; Thu, 18 Sep 1997 12:30:00 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Sep 1997 12:24:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA07098 for ietf-ppp-outgoing; Thu, 18 Sep 1997 12:24:35 -0400 (EDT) Received: from zaphod.avm.de (root@mail.avm.de [194.175.125.228]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA07091 for ; Thu, 18 Sep 1997 12:24:25 -0400 (EDT) From: a.schweder@avm.de Received: from mail-cc.avm.de by zaphod.avm.de with smtp (Smail3.2 #3) id m0xBjN4-000b5GC; Thu, 18 Sep 1997 18:24:02 +0200 (MET DST) Received: from ccMail by mail-cc.avm.de (ccMail Link to SMTP R8.00.00) id AA874599493; Thu, 18 Sep 97 17:18:16 GMT Message-Id: <9709188745.AA874599493@mail-cc.avm.de> X-Mailer: ccMail Link to SMTP R8.00.00 Date: Thu, 18 Sep 97 18:23:15 GMT To: , Subject: Betr.: Re: Two (nit picky) questions on authentication MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hello > > However in our > > implementation the scenario goes as follows: > > us: send configure-request with CHAP (or PAP) authentication option > > them: send configure-reject for authentication option > > us: send terminate-request > That's much better. I don`t thing so, because term-req/term-ack dosn't terminate the LCP negotiation (RFC1661 Page 12/13). I think there are only two ways: 1) Drop the Line. 2) Finish the LCP negotiation and send the term-req in the opened state. A. Schweder - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 18 15:30:47 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA11406; Thu, 18 Sep 1997 15:30:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Sep 1997 15:29:49 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA11362 for ietf-ppp-outgoing; Thu, 18 Sep 1997 15:29:48 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA11358 for ; Thu, 18 Sep 1997 15:29:44 -0400 (EDT) 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 MAA22899 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Thu, 18 Sep 1997 12:29:41 -0700 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 NAA06306 for ietf-ppp@merit.edu; Thu, 18 Sep 1997 13:29:35 -0600 Date: Thu, 18 Sep 1997 13:29:35 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199709181929.NAA06306@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: Two (nit picky) questions on authentication Sender: owner-ietf-ppp@merit.edu > From: a.schweder@avm.de > > > However in our > > > implementation the scenario goes as follows: > > > us: send configure-request with CHAP (or PAP) authentication option > > > them: send configure-reject for authentication option > > > us: send terminate-request > > That's much better. > I don`t thing so, because term-req/term-ack dosn't terminate the LCP > negotiation (RFC1661 Page 12/13). > > I think there are only two ways: > 1) Drop the Line. > 2) Finish the LCP negotiation and send the term-req in the opened state. On the contrary, the better, third way that many of us use is: 3) send LCP Terminate-Request including ASCII text indicating the reason, wait a decent interval for a Terminate-Ack, and then drop the line. The response to RTR in State 6, 7, or 8 is "sta". Thus, regardless of whether the peer is still expecting your system to send an LCP Configure-Ack, your system will receive the Terminate-Ack, and can know that the peer has heard and presumably logged your Terminate-Request message. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 18 20:29:47 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA17805; Thu, 18 Sep 1997 20:29:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 18 Sep 1997 20:28:48 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA17780 for ietf-ppp-outgoing; Thu, 18 Sep 1997 20:28:47 -0400 (EDT) Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by merit.edu (8.8.7/8.8.5) with SMTP id UAA17776 for ; Thu, 18 Sep 1997 20:28:40 -0400 (EDT) Received: from d01lms04.pok.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA22936; Fri, 19 Sep 1997 00:32:23 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400011037583; Thu, 18 Sep 1997 20:31:37 -0400 From: John Martz To: Subject: Re: Two (nit picky) questions on authentication Message-Id: <5010400011037583000002L032*@MHS> Date: Thu, 18 Sep 1997 20:31:37 -0400 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu > term-req/term-ack doesn't terminate the LCP negotiation (RFC1661 Page 12/13). > > I think there are only two ways: > 1) Drop the Line. > 2) Finish the LCP negotiation and send the term-req in the opened state. Well, saying I'm "sending term-req" is perhaps leaving too much out. A more complete statement is that the code does the equivalent of a close/open event sequence. This is suggested as an Implementation Note in RFC 1661 on page 18. In my opinion, refusal by the peer to negotiate the authentication option is a "failure of authentication". -john martz IBM AS/400 PPP - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 19 00:42:11 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA21149; Fri, 19 Sep 1997 00:41:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 19 Sep 1997 00:41:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA21114 for ietf-ppp-outgoing; Fri, 19 Sep 1997 00:41:11 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm036-16.dialip.mich.net [141.211.7.58]) by merit.edu (8.8.7/8.8.5) with SMTP id AAA21095 for ; Fri, 19 Sep 1997 00:41:03 -0400 (EDT) Date: Thu, 18 Sep 97 19:18:52 GMT From: "William Allen Simpson" Message-ID: <6578.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Two (nit picky) questions on authentication Sender: owner-ietf-ppp@merit.edu > From: a.schweder@avm.de > I don`t thing so, because term-req/term-ack dosn't terminate the LCP > negotiation (RFC1661 Page 12/13). > > I think there are only two ways: > 1) Drop the Line. > 2) Finish the LCP negotiation and send the term-req in the opened state. > The term-req will get a term-ack back alright. Therefore, for his implementation, assuming that he has changed his state to Stopping, when he gets the term-ack, he will drop the line (tlf). Thus, your (1) is satisfied. As you say, (2) works also. In my case, it requires less code. But that may not be the case for him. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 23 10:35:47 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA00266; Tue, 23 Sep 1997 10:32:21 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 23 Sep 1997 10:29:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA00176 for ietf-ppp-outgoing; Tue, 23 Sep 1997 10:29:03 -0400 (EDT) Received: from cdc8g5.cdc.polimi.it (cdc8g5.cdc.polimi.it [131.175.6.1]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA00172 for ; Tue, 23 Sep 1997 10:28:56 -0400 (EDT) Received: (from pez0013@localhost) by cdc8g5.cdc.polimi.it (8.7.1/8.7.1) id QAA04282; Tue, 23 Sep 1997 16:20:33 +0200 (METDST) From: DAVIDE Message-Id: <199709231420.QAA04282@cdc8g5.cdc.polimi.it> Subject: Info about PPP To: ietf-ppp@merit.edu Date: Tue, 23 Sep 1997 16:20:32 METDST Cc: pez0013@cdc8g5.cdc.polimi.it X-Mailer: Elm [revision: 212.2] Sender: owner-ietf-ppp@merit.edu Hi I'm Davide a student of Politecnico of Milan and I'm looking for info about PPP for my thesis. My questions are: 1)If FCS finds an error in the frame,I must re-send the frame;What is the protocol that does this operation and how? 2)How pad works? Thanks for your time Cordially Davide -- DAVIDE CALVI via L.da VINCI N 60 20060 TRUCCAZZANO (MI) tel:02/9583508 e-mail:pez0013@cdc8g5.cdc.polimi.it - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 24 12:45:16 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA27936; Wed, 24 Sep 1997 12:44:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 24 Sep 1997 12:40:11 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA27839 for ietf-ppp-outgoing; Wed, 24 Sep 1997 12:40:10 -0400 (EDT) Received: from cbgw1.lucent.com (cbgw1.lucent.com [192.20.239.133]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA27831 for ; Wed, 24 Sep 1997 12:40:06 -0400 (EDT) Received: from garage.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id MAA15585; Wed, 24 Sep 1997 12:30:05 -0400 Received: by garage.lucent.com (5.0/EMS-L sol2) id AA18703; Wed, 24 Sep 1997 12:36:58 -0400 Date: Wed, 24 Sep 1997 12:36:58 -0400 Message-Id: <9709241636.AA18703@garage.lucent.com> From: gmg@garage.lucent.com (g.gross) To: ietf-ppp@merit.edu Cc: gmg@garage.lucent.com Subject: PPP over AAL5<->async LCP options Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, I was asked by a colleague how one might inter-work a PC serial or parallel port to a CPE conversion box that had ATM AAL5 on the WAN side. I was about to tell him that the PPP over AAL5 Internet Draft says you can not do ACCM, ACFC, etc, when I noticed that RFC1662 section 6 has a description of how to do sync to async conversion. After reading it, my inclination was clone that text, and revamp it to say that AAL5 to async conversion is done by negotiating ACCM on (and perhaps other "framing" options) and that the AAL5 end point would not do ACCM, but instead the conversion box in the middle would do it. See proposed text fragment below. I have not thought this through yet, but it seems to me at first glance that all the LCP options having to do with framing should be allowed, but that the AAL5 end point should ignore them and let the conversion gadget (if any) do them instead. I wonder if this has any gotchas if one is doing LLC-encapsulated PPP mux'ed with other protocols. I dredged through the PPP working group mail archives, and discovered that back on April 9th 1997 this issue sort of got discussed between Manu Kaycee, Dave Cunningham of Cisco, and Xing Chen of GDC. The drift I got from reading that E-mail was that this ID should not get embroiled in solving inter- working issues. For the moment, I have postponed publishing a new draft until this is settled. George =========== Proposed additional text for the PPP over AAL5 LCP section: PPP over AAL5 to asynchronous PPP conversion is handled in the same way as the asynchronous to synchronous conversion described in [3] section 6. The PPP over AAL5 implementation MUST alway respond to the Asynchronous-Control-Character-Map (ACCM) option with the LCP Configure-Ack. However, acceptance of the Configuration Option does not imply that the PPP over AAL5 implementation will do any ACCM mapping. Instead, all such octet mapping will be performed by the asynchronous to AAL5 convertor. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 24 16:36:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA03383; Wed, 24 Sep 1997 16:36:09 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 24 Sep 1997 16:35:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA03345 for ietf-ppp-outgoing; Wed, 24 Sep 1997 16:35:25 -0400 (EDT) Received: from webster.priacc.com (webster.eng.priacc.com [206.136.9.47]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA03341 for ; Wed, 24 Sep 1997 16:35:20 -0400 (EDT) Received: (from news@localhost) by webster.priacc.com (8.7.4/8.7.3/MDP970721-BSDI-MASTER) id NAA29793; Wed, 24 Sep 1997 13:22:48 -0700 (PDT) To: ietf-ppp@merit.edu Path: splatenb From: splatenb@priacc.com (Scott Platenberg) Newsgroups: priacc.lists.ppp Subject: test - please ignore Date: 24 Sep 1997 20:22:47 GMT Organization: 3Com/Primary Access -- San Diego, CA Lines: 2 Message-ID: <60bsqn$t2v@webster.priacc.com> NNTP-Posting-Host: aztec.eng.priacc.com Sender: owner-ietf-ppp@merit.edu Testing... please ignore. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 25 11:58:56 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA17159; Thu, 25 Sep 1997 11:58:14 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Sep 1997 11:53:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA17085 for ietf-ppp-outgoing; Thu, 25 Sep 1997 11:53:53 -0400 (EDT) Received: from cdc8g5.cdc.polimi.it (cdc8g5.cdc.polimi.it [131.175.6.1]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA17079 for ; Thu, 25 Sep 1997 11:53:44 -0400 (EDT) Received: (from pez0013@localhost) by cdc8g5.cdc.polimi.it (8.7.1/8.7.1) id RAA08287; Thu, 25 Sep 1997 17:10:48 +0200 (METDST) From: DAVIDE Message-Id: <199709251510.RAA08287@cdc8g5.cdc.polimi.it> Subject: Another info about PPP To: pez0013@cdc8g5.cdc.polimi.it (DAVIDE) Date: Thu, 25 Sep 1997 17:10:48 METDST Cc: ietf-ppp@merit.edu In-Reply-To: <199709251506.RAA07794@cdc8g5.cdc.polimi.it>; from "DAVIDE" at Sep 25, 97 5:06 pm X-Mailer: Elm [revision: 212.2] Sender: owner-ietf-ppp@merit.edu Hi I have a new question on PPP: When I have set-up the link, I send the HDLC frame where in the info field there is my datagram,how I can know that it is an IP datagram or an IP datagram? Better,I know every protocol has an indentification number,in the info field where I can find it?Because I must know this number to indetify my datagram. Tkanks for previous help Davide DAVIDE CALVI via L.da VINCI N 60 20060 TRUCCAZZANO (MI) tel:02/9583508 e-mail:pez0013@cdc8g5.cdc.polimi.it - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 25 20:28:53 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA26764; Thu, 25 Sep 1997 20:28:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Sep 1997 20:24:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA26691 for ietf-ppp-outgoing; Thu, 25 Sep 1997 20:24:57 -0400 (EDT) Received: from lms03.us.ibm.com (lms03.ny.us.ibm.com [198.133.22.39]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA26687 for ; Thu, 25 Sep 1997 20:24:52 -0400 (EDT) Received: from US.IBM.COM (d01lms04.pok.ibm.com [9.117.30.25]) by lms03.us.ibm.com (8.8.7/8.8.7) with SMTP id UAA33044 for ; Thu, 25 Sep 1997 20:23:03 -0500 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU002 id 5010400011446708; Thu, 25 Sep 1997 20:27:57 -0400 From: John Martz To: Subject: Using default receive ACCM of 0 for LCP negotiation Message-ID: <5010400011446708000002L082*@MHS> Date: Thu, 25 Sep 1997 20:27:57 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Folks, It seems prudent to begin this note by stating that I *AM* aware of RFC 1661 page 26 which states: "Regardless of which Configuration Options are enabled, all LCP Link Configuration, Link Termination, and Code-Reject packets (codes 1 through 7) are always sent as if no Configuration Options were negotiated". And up until this afternoon, that's exactly the way my implementation worked. However, today we learned that one of the ISDN terminal adapters we're testing with (an US Robotics Courier I-modem (with ISDN/V.34) using flash code revision 2.1.4) can send our box an LCP configure request packet where some of the bytes have not been escaped. (The two FCS bytes are not being correctly escaped. For example, if the FCS is 0xC71F it is sent on the line as C71F instead of C77D3F). In earlier exchanges on this mailing list I've read of implementations which retained the negotiated receive ACCM when dropping back to re-negotiate LCP options. However, in this case the kludge required to allow us to complete LCP negotiation in the first place is to start with a receive ACCM of 0x00000000. If we use the correct default of 0xFFFFFFFF then we silently discard all the packets sent to us due to a bad FCS. As a result I'm planning on adding a back-door hook to our implementation that will let us start with a receive ACCM of 0. It'll also keep any previously negotiated ACCM if we drop back and re-negotiate. (The sending ACCM will always be reset to 0xFFFFFFFF. Only the receive ACCM is tinkered with). I wouldn't bother the members of this mailing list with this, except USR mentioned (and our experience confirms) that Microsoft Win '95 and Win NT PPP have no problems with their I-modem. From this I assume their PPP always uses a default receive ACCM of 0. I'm beginning to think this is very common modification. Anyone have any idea how many implementations out there are bending the letter of the ACCM law in RFC 1661? -john - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 25 20:50:52 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA27151; Thu, 25 Sep 1997 20:50:49 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 25 Sep 1997 20:50:33 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA27113 for ietf-ppp-outgoing; Thu, 25 Sep 1997 20:50:33 -0400 (EDT) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by merit.edu (8.8.7/8.8.5) with SMTP id UAA27108 for ; Thu, 25 Sep 1997 20:50:28 -0400 (EDT) From: Barney Wolff To: Date: Thu, 25 Sep 1997 20:41 EDT Subject: Re: Using default receive ACCM of 0 for LCP negotiation Content-Type: text/plain Message-ID: <342b06d10.3688@databus.databus.com> Sender: owner-ietf-ppp@merit.edu I suggest reading section 7.1 on ACCM in RFC1662, rather than RFC1661, which does not cover ACCM at all. The default for bit-sync ISDN is certainly 0. For V.120, it's not really clear which it should be, but 0 is certainly defensible, and is a literal reading of the text. Barney Wolff - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 26 05:00:31 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id FAA02013; Fri, 26 Sep 1997 05:00:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Sep 1997 04:58:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA01979 for ietf-ppp-outgoing; Fri, 26 Sep 1997 04:58:12 -0400 (EDT) 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 EAA01975 for ; Fri, 26 Sep 1997 04:58:08 -0400 (EDT) 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 JAA05070; Fri, 26 Sep 1997 09:57:58 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 42b77b10; Fri, 26 Sep 97 09:52:01 +0100 Mime-Version: 1.0 Date: Fri, 26 Sep 1997 09:55:13 +0100 Message-ID: <42b77b10@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Using default receive ACCM of 0 for LCP negotiation To: ietf-ppp@merit.edu Cc: John Martz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu John Martz writes: >.. > As a result I'm planning on adding a back-door hook to our > implementation that will let us start with a receive ACCM of 0. It'll > also keep any previously negotiated ACCM if we drop back and > re-negotiate. (The sending ACCM will always be reset to 0xFFFFFFFF. > Only the receive ACCM is tinkered with). > > I wouldn't bother the members of this mailing list with this, except > USR mentioned (and our experience confirms) that Microsoft Win '95 and > Win NT PPP have no problems with their I-modem. From this I assume > their PPP always uses a default receive ACCM of 0. I'm beginning to > think this is very common modification. Anyone have any idea how many > implementations out there are bending the letter of the ACCM law in > RFC 1661? I suspect there are several implementations which use a default Rx ACCM of 0, but it seems that this is broadly in line with the principle of "being generous in what you accept". It doesn't surprise me that there are some implementations which don't apply the Tx ACCM rules properly, although I've not encountered many. Of course, if you don't trust your peer to follow the rules, there is a way round it: process received frames (before LCP is open) with an Rx ACCM of zero, and if the FCS is ok then accept the frame; if anything has injected control characters into the frame then it will result in a bad FCS, in which case process the frame a second time, this time stripping all the control characters (i.e. using an ACCM of 0xFFFFFFFF). Barney Wolff writes: ].. ] The default for bit-sync ISDN is certainly 0. To be pedantic, the ACCM is completely irrelevant to bit-sync PPP (ok, that's effectively the same as an ACCM of zero). ] For V.120, it's not really clear which it should be, but 0 is certainly ] defensible, and is a literal reading of the text. Which text? I disagree - V.120 is just async PPP wrapped in some framing - the actual data is unchanged: on the DTE side of a TA the data stream _is_ async PPP, so the normal async PPP rules apply (i.e. the defaults should be 0xFFFFFFFF). --- Jonathan Goodchild Racal Datacom - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 26 07:29:21 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA03021; Fri, 26 Sep 1997 07:27:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Sep 1997 07:22:11 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA02974 for ietf-ppp-outgoing; Fri, 26 Sep 1997 07:22:10 -0400 (EDT) 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 HAA02921 for ; Fri, 26 Sep 1997 07:16:14 -0400 (EDT) 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 MAA09500 for ; Fri, 26 Sep 1997 12:15:41 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 42b97f70; Fri, 26 Sep 97 12:09:43 +0100 Mime-Version: 1.0 Date: Fri, 26 Sep 1997 12:12:37 +0100 Message-ID: <42b97f70@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: ACCM and bit-sync PPP 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 I wrote: > ].. > ] The default for bit-sync ISDN is certainly 0. > > To be pedantic, the ACCM is completely irrelevant to bit-sync PPP (ok, > that's effectively the same as an ACCM of zero). Come to think of it, it's not the same as an ACCM of zero, because with bit-sync PPP nothing is escaped at all - in async PPP, even with an ACCM of zero you have to escape 0x7D and 0x7E. So as I said, the ACCM is totally irrelevant to bit-synchronous PPP. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 26 13:13:24 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA08706; Fri, 26 Sep 1997 13:13:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Sep 1997 13:12:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA08650 for ietf-ppp-outgoing; Fri, 26 Sep 1997 13:12:31 -0400 (EDT) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA08628 for ; Fri, 26 Sep 1997 13:12:23 -0400 (EDT) From: Barney Wolff To: ietf-ppp@merit.edu Date: Fri, 26 Sep 1997 13:03 EDT Subject: Re: Using default receive ACCM of 0 for LCP negotiation Content-Type: text/plain Message-ID: <342becec0.4305@databus.databus.com> Sender: owner-ietf-ppp@merit.edu > Date: Fri, 26 Sep 1997 09:55:13 +0100 > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > > Barney Wolff writes: > > ].. > ] The default for bit-sync ISDN is certainly 0. > > To be pedantic, the ACCM is completely irrelevant to bit-sync PPP (ok, > that's effectively the same as an ACCM of zero). > > ] For V.120, it's not really clear which it should be, but 0 is certainly > ] defensible, and is a literal reading of the text. > > Which text? I disagree - V.120 is just async PPP wrapped in some > framing - the actual data is unchanged: on the DTE side of a TA the data > stream _is_ async PPP, so the normal async PPP rules apply (i.e. the > defaults should be 0xFFFFFFFF). From RFC1662 section 7.1: For asynchronous links, the default receiving ACCM is 0xffffffff. The default sending ACCM is 0xffffffff, plus the Control Escape and Flag Sequence characters themselves, plus whatever other outgoing characters are flagged (by prior configuration) as likely to be intercepted. For other types of links, the default value is 0, since there is no need for mapping. For V.120, neither this nor the secion on async-sync conversion makes it clear (at least to me). Certainly a TA that talks async to a PC is using async PPP to the PC, but what about between the TA and the ISDN peer? Barney Wolff - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 26 13:59:48 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA09961; Fri, 26 Sep 1997 13:59:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Sep 1997 13:59:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA09937 for ietf-ppp-outgoing; Fri, 26 Sep 1997 13:59:24 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [209.81.17.6]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA09933 for ; Fri, 26 Sep 1997 13:59:16 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id KAA00505; Fri, 26 Sep 1997 10:58:40 -0700 (PDT) Date: Fri, 26 Sep 1997 10:58:40 -0700 (PDT) From: Mike Thornburg To: Barney Wolff cc: ietf-ppp@merit.edu Subject: Re: Using default receive ACCM of 0 for LCP negotiation In-Reply-To: <342becec0.4305@databus.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 26 Sep 1997, Barney Wolff wrote: > > >From RFC1662 section 7.1: > > For asynchronous links, the default receiving ACCM is 0xffffffff. > The default sending ACCM is 0xffffffff, plus the Control Escape > and Flag Sequence characters themselves, plus whatever other > outgoing characters are flagged (by prior configuration) as likely > to be intercepted. > > For other types of links, the default value is 0, since there is > no need for mapping. > > > For V.120, neither this nor the secion on async-sync conversion makes > it clear (at least to me). Certainly a TA that talks async to a PC > is using async PPP to the PC, but what about between the TA and the > ISDN peer? > > Barney Wolff > V.120 is (theoretically) covered in RFC 1618 (PPP over ISDN) which states: Terminal adapters conforming to V.120 [4] can be used as a simple interface to workstations. Asynchronous HDLC framing [2] is accepted at the R reference point. The terminal adapter provides async-sync conversion. Multiple B-channels can be used in parallel. Unfortunately, V.120 has a framing mode of its own for rate adaptation, which is difficult to distinguish from Frame Relay, and which can confuse in-band frame detection. V.120 is not interoperable with bit-synchronous links, since V.120 does not provide octet-stuffing to bit- stuffing conversion. Therefore, V.120 is deprecated in favor of more modern standards, such as "PPP in Frame Relay". This would seem to tell people running V.120 to treat the ISDN link as an octet-stuffed synchronous link and therefore the async-sync conversion in this case does _not_ involve changing octet-stuffing to bit stuffing. However, the async-sync conversion step involved here means that in theory the TA is responsible for adding octet stuffing for any characters received over the synchronous link that are flagged in the ACCM and are not escaped (since the entity at the other end of the synchronous link is allowed to ignore the ACCM. See RFC 1662 section 6). The TA would also be responsible for recognizing an LCP packet and making sure that all control characters in such a packet are escaped before sending them down the async link. In practice, do any TAs running V.120 do this part of async-sync conversion? Or don't they just pass characters transparently inside V.120 encapsulation and assume that the entities at either end will handle the octet stuffing themselves? Is it just me, or is RFC 1618 confusing and not nearly helpful enough when you have a question like this? I don't believe anyone else has brought it up as applicable to this discussion -- perhaps this is telling. Thanks, Mike -------------- Mike Thornburg frigate networks 650.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 26 14:30:30 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA10629; Fri, 26 Sep 1997 14:30:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Sep 1997 14:30:21 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA10611 for ietf-ppp-outgoing; Fri, 26 Sep 1997 14:30:21 -0400 (EDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA10606 for ; Fri, 26 Sep 1997 14:30:16 -0400 (EDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id LAA17037; Fri, 26 Sep 1997 11:29:41 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma017035; Fri Sep 26 11:29:40 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id LAA00386; Fri, 26 Sep 1997 11:29:40 -0700 (PDT) From: Archie Cobbs Message-Id: <199709261829.LAA00386@bubba.whistle.com> Subject: Re: Using default receive ACCM of 0 for LCP negotiation In-Reply-To: from Mike Thornburg at "Sep 26, 97 10:58:40 am" To: mthorn@frigate.com (Mike Thornburg) Date: Fri, 26 Sep 1997 11:29:40 -0700 (PDT) Cc: barney@databus.com, ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > V.120 is (theoretically) covered in RFC 1618 (PPP over ISDN) which states: > > Terminal adapters conforming to V.120 [4] can be used as a > simple interface to workstations. Asynchronous HDLC framing > [2] is accepted at the R reference point. The terminal adapter > provides async-sync conversion. Multiple B-channels can be > used in parallel. Unfortunately, V.120 has a framing mode of > its own for rate adaptation, which is difficult to distinguish > from Frame Relay, and which can confuse in-band frame > detection. V.120 is not interoperable with bit-synchronous > links, since V.120 does not provide octet-stuffing to bit- > stuffing conversion. Therefore, V.120 is deprecated in favor > of more modern standards, such as "PPP in Frame Relay". > > This would seem to tell people running V.120 to treat the ISDN link as an > octet-stuffed synchronous link and therefore the async-sync conversion in > this case does _not_ involve changing octet-stuffing to bit stuffing. > However, the async-sync conversion step involved here means that in theory > the TA is responsible for adding octet stuffing for any characters > received over the synchronous link that are flagged in the ACCM and are > not escaped (since the entity at the other end of the synchronous link is > allowed to ignore the ACCM. See RFC 1662 section 6). The TA would also be > responsible for recognizing an LCP packet and making sure that all control > characters in such a packet are escaped before sending them down the async > link. As I understand it, V.120 simply makes a synchronous link look asynchronous. So at TA that did V.120 wouldn't have to know or do anything about PPP. This could be an oversimplification though... can anyone confirm/deny? > Is it just me, or is RFC 1618 confusing and not nearly helpful enough when > you have a question like this? I don't believe anyone else has brought it > up as applicable to this discussion -- perhaps this is telling. *IMHO* it should say, "These days everybody does PPP over ISDN using the `PPP in HDLC-like framing' method, so you don't need to bother doing it any other way. If you're a terminal adapter, you should do sync-async conversion (eg. a la BitSURFR Pro, 3Com Impact IQ, et.al.) as described in this document, to get you to PPP in HDLC-like framing over the wire." -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 26 14:26:16 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA10518; Fri, 26 Sep 1997 14:26:08 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Sep 1997 14:25:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA10493 for ietf-ppp-outgoing; Fri, 26 Sep 1997 14:25:53 -0400 (EDT) Received: from adtrn-srv1.adtran.com ([206.26.161.245]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA10487 for ; Fri, 26 Sep 1997 14:25:49 -0400 (EDT) Received: from crusher.adtran.com by adtrn-srv1.adtran.com (SMI-8.6/SMI-SVR4) id NAA06958; Fri, 26 Sep 1997 13:25:18 -0500 Message-Id: <199709261825.NAA06958@adtrn-srv1.adtran.com> From: "Kyle Farnsworth" To: Subject: Re: Using default receive ACCM of 0 for LCP negotiation Date: Fri, 26 Sep 1997 13:25:29 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > From: Barney Wolff > > For V.120, neither this nor the secion on async-sync conversion makes > it clear (at least to me). Certainly a TA that talks async to a PC > is using async PPP to the PC, but what about between the TA and the > ISDN peer? > Async V.120 does not care what the ACCM is or even if PPP is running. It takes bytes from end and sends them out the other. There should be no async-to-sync conversion over V.120. Same case for BONDING. Kyle - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 26 14:34:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA10734; Fri, 26 Sep 1997 14:34:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Sep 1997 14:34:47 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA10709 for ietf-ppp-outgoing; Fri, 26 Sep 1997 14:34:47 -0400 (EDT) Received: from SanFrancisco01.POP.InterNex.Net (sanfrancisco01.pop.InterNex.Net [205.158.3.50]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA10705 for ; Fri, 26 Sep 1997 14:34:42 -0400 (EDT) Received: from senior ([205.158.231.117]) by SanFrancisco01.POP.InterNex.Net (post.office MTA v1.9.3 ID# 0-11028) with SMTP id AAA459; Fri, 26 Sep 1997 11:34:35 -0700 Message-Id: <3.0.3.32.19970926111859.00b3ae60@SanFrancisco01.pop.internex.net> X-Sender: larribeau-2@SanFrancisco01.pop.internex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 26 Sep 1997 11:18:59 -0700 To: Mike Thornburg , Barney Wolff From: bob@larribeau.com (Bob Larribeau) Subject: Re: Using default receive ACCM of 0 for LCP negotiation Cc: ietf-ppp@merit.edu In-Reply-To: References: <342becec0.4305@databus.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu V.120 is a protocol that supports asynchronous, HDLC, and bit synchronous data formats. For asynchronous V.120 provides a transparent transmission service so that all characters received at one end of the connection are carried across the ISDN line and delivered at the other end of the connection. There is no need to modify asynchronous PPP carried across V.120 and the other side must be capable of handling asynchronous PPP. V.120 is capable of supporting different speeds at either end of the connection. CompuServe is the only service that I have found that uses PPP over V.120. It is not very efficient because you transmit PPP encapsulation inside of V.120 encapsulation. The last version of the V.120 standard I saw supported speeds only up to 19.2 kb/s. There are V.120 implementations that support 38.4 kb/s and (I think) 57.6 kb/s. The conclusion of RFC 1618 is clear and correct. The explanation will be more clear if you read the V.120 specification and understand that V.120 is used for framing in Frame Relay services. Bob Larribeau At 10:58 AM 9/26/97 -0700, Mike Thornburg wrote: >On Fri, 26 Sep 1997, Barney Wolff wrote: > >> >> >From RFC1662 section 7.1: >> >> For asynchronous links, the default receiving ACCM is 0xffffffff. >> The default sending ACCM is 0xffffffff, plus the Control Escape >> and Flag Sequence characters themselves, plus whatever other >> outgoing characters are flagged (by prior configuration) as likely >> to be intercepted. >> >> For other types of links, the default value is 0, since there is >> no need for mapping. >> >> >> For V.120, neither this nor the secion on async-sync conversion makes >> it clear (at least to me). Certainly a TA that talks async to a PC >> is using async PPP to the PC, but what about between the TA and the >> ISDN peer? >> >> Barney Wolff >> > >V.120 is (theoretically) covered in RFC 1618 (PPP over ISDN) which states: > > Terminal adapters conforming to V.120 [4] can be used as a > simple interface to workstations. Asynchronous HDLC framing > [2] is accepted at the R reference point. The terminal adapter > provides async-sync conversion. Multiple B-channels can be > used in parallel. Unfortunately, V.120 has a framing mode of > its own for rate adaptation, which is difficult to distinguish > from Frame Relay, and which can confuse in-band frame > detection. V.120 is not interoperable with bit-synchronous > links, since V.120 does not provide octet-stuffing to bit- > stuffing conversion. Therefore, V.120 is deprecated in favor > of more modern standards, such as "PPP in Frame Relay". > >This would seem to tell people running V.120 to treat the ISDN link as an >octet-stuffed synchronous link and therefore the async-sync conversion in >this case does _not_ involve changing octet-stuffing to bit stuffing. >However, the async-sync conversion step involved here means that in theory >the TA is responsible for adding octet stuffing for any characters >received over the synchronous link that are flagged in the ACCM and are >not escaped (since the entity at the other end of the synchronous link is >allowed to ignore the ACCM. See RFC 1662 section 6). The TA would also be >responsible for recognizing an LCP packet and making sure that all control >characters in such a packet are escaped before sending them down the async >link. > >In practice, do any TAs running V.120 do this part of async-sync >conversion? Or don't they just pass characters transparently inside V.120 >encapsulation and assume that the entities at either end will handle the >octet stuffing themselves? > >Is it just me, or is RFC 1618 confusing and not nearly helpful enough when >you have a question like this? I don't believe anyone else has brought it >up as applicable to this discussion -- perhaps this is telling. > >Thanks, >Mike >-------------- >Mike Thornburg frigate networks 650.903.2266 >mthorn@frigate.com http://www.frigate.com/ > > ----------------------------------------------------------- Bob Larribeau bob@larribeau.com ISDN Consultant San Francisco - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 26 15:19:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA11938; Fri, 26 Sep 1997 15:19:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Sep 1997 15:19:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA11908 for ietf-ppp-outgoing; Fri, 26 Sep 1997 15:19:35 -0400 (EDT) Received: from adtrn-srv1.adtran.com ([206.26.161.245]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA11904 for ; Fri, 26 Sep 1997 15:19:30 -0400 (EDT) Received: from crusher.adtran.com by adtrn-srv1.adtran.com (SMI-8.6/SMI-SVR4) id OAA08178; Fri, 26 Sep 1997 14:18:14 -0500 Message-Id: <199709261918.OAA08178@adtrn-srv1.adtran.com> From: "Kyle Farnsworth" To: "Mike Thornburg" Cc: Subject: Re: Using default receive ACCM of 0 for LCP negotiation Date: Fri, 26 Sep 1997 14:18:26 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > From: Mike Thornburg > > For V.120, neither this nor the secion on async-sync conversion makes > > it clear (at least to me). Certainly a TA that talks async to a PC > > is using async PPP to the PC, but what about between the TA and the > > ISDN peer? > > > > Barney Wolff > > > > V.120 is (theoretically) covered in RFC 1618 (PPP over ISDN) which states: > > Terminal adapters conforming to V.120 [4] can be used as a > simple interface to workstations. Asynchronous HDLC framing > [2] is accepted at the R reference point. The terminal adapter > provides async-sync conversion. Multiple B-channels can be > used in parallel. Unfortunately, V.120 has a framing mode of > its own for rate adaptation, which is difficult to distinguish > from Frame Relay, and which can confuse in-band frame > detection. V.120 is not interoperable with bit-synchronous > links, since V.120 does not provide octet-stuffing to bit- > stuffing conversion. Therefore, V.120 is deprecated in favor > of more modern standards, such as "PPP in Frame Relay". > > This would seem to tell people running V.120 to treat the ISDN link as an > octet-stuffed synchronous link and therefore the async-sync conversion in > this case does _not_ involve changing octet-stuffing to bit stuffing. Correct. > However, the async-sync conversion step involved here means that in theory > the TA is responsible for adding octet stuffing for any characters > received over the synchronous link that are flagged in the ACCM and are > not escaped (since the entity at the other end of the synchronous link is > allowed to ignore the ACCM. See RFC 1662 section 6). The TA would also be > responsible for recognizing an LCP packet and making sure that all control > characters in such a packet are escaped before sending them down the async > link. Not if your running V.120. In this case, running V.120 on two TA's is no different than running two analog modems. The TA is taking bytes from one asyn PPP device and placing on the DTE of the other Asyn PPP device. > In practice, do any TAs running V.120 do this part of async-sync > conversion? Or don't they just pass characters transparently inside V.120 > encapsulation and assume that the entities at either end will handle the > octet stuffing themselves? The entities are supposed to handle the ACCM. The V.120 sits below the "PPP layer". Kyle - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 26 16:00:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA12757; Fri, 26 Sep 1997 16:00:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 26 Sep 1997 16:00:22 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA12736 for ietf-ppp-outgoing; Fri, 26 Sep 1997 16:00:21 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [209.81.17.6]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA12724 for ; Fri, 26 Sep 1997 16:00:14 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id MAA00736; Fri, 26 Sep 1997 12:59:53 -0700 (PDT) Date: Fri, 26 Sep 1997 12:59:52 -0700 (PDT) From: Mike Thornburg To: Kyle Farnsworth cc: ietf-ppp@merit.edu Subject: Re: Using default receive ACCM of 0 for LCP negotiation In-Reply-To: <199709261918.OAA08178@adtrn-srv1.adtran.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Fri, 26 Sep 1997, Kyle Farnsworth wrote: > > > > This would seem to tell people running V.120 to treat the ISDN link as an > > octet-stuffed synchronous link and therefore the async-sync conversion in > > this case does _not_ involve changing octet-stuffing to bit stuffing. > Correct. > > > However, the async-sync conversion step involved here means that in > theory > > the TA is responsible for adding octet stuffing for any characters > > received over the synchronous link that are flagged in the ACCM and are > > not escaped (since the entity at the other end of the synchronous link is > > allowed to ignore the ACCM. See RFC 1662 section 6). The TA would also be > > responsible for recognizing an LCP packet and making sure that all > control > > characters in such a packet are escaped before sending them down the > async > > link. > Not if your running V.120. In this case, running V.120 on two TA's is no > different than running two analog modems. The TA is taking bytes from one > asyn PPP device and placing on the DTE of the other Asyn PPP device. > But I have a device in my office that is a host with internal ISDN hardware, not a TA, that does V.120 over ISDN and passes the bytes received directly to its PPP layer without ever going through an async serial link. As I read RFC 1662, this host is a synchronous serial device and is therefore allowed to ignore the negotiated ACCM and only escape the Control Escape and Flag Sequence characters. It does not do that, because if it did it would never interoperate with ISDN TAs as they are implemented now. What I am claiming is that a literal reading of RFC 1662 and RFC 1618 would seem to require that a TA receiving PPP frames over V.120 be responsible for adding missing escape sequences into the asynchronous serial stream, yet this is absolutely _not_ industry practice (and is absurd to require, since it would require adding a rudimentary PPP stack into a device that otherwise would not need to know PPP). Either I am misreading the RFCs or they are incompatible with present practice and need to be revised and reissued. > > In practice, do any TAs running V.120 do this part of async-sync > > conversion? Or don't they just pass characters transparently inside V.120 > > encapsulation and assume that the entities at either end will handle the > > octet stuffing themselves? > The entities are supposed to handle the ACCM. The V.120 sits below the > "PPP layer". > Thanks, Mike -------------- Mike Thornburg frigate networks 650.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Sep 27 04:19:01 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id EAA19354; Sat, 27 Sep 1997 04:09:40 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 27 Sep 1997 04:02:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA19304 for ietf-ppp-outgoing; Sat, 27 Sep 1997 04:02:15 -0400 (EDT) Received: from stpn.soft.net (stpn.soft.net [204.143.127.2]) by merit.edu (8.8.7/8.8.5) with SMTP id EAA19300 for ; Sat, 27 Sep 1997 04:02:08 -0400 (EDT) Received: from shilpa.pcl.stpn.soft.net (unverified [204.143.116.98]) by stpn.soft.net (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 27 Sep 1997 13:35:08 +0530 Received: from [192.168.200.142] by shilpa.pcl.stpn.soft.net id aa24756; 27 Sep 97 13:29 IST Message-ID: <342CBE6C.77FE@pcl.stpn.soft.net> Date: Sat, 27 Sep 1997 13:36:04 +0530 From: "Vimal K. Khanna" Organization: Mindware X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Re: Requesting comments on my draft draft-rfced-info-khana-00.txt References: <341F7B66.3691@pcl.stpn.soft.net> <199709172042.NAA17597@zipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Andrew Valencia wrote: > > >The draft suggests a PPP based protocol which will allow all these PC > >users to run TCP/IP protocol over their async links to PADs. > >... > > If I'm reading this draft correctly, you're saying "run async PPP over a > byte stream protocol". I don't think there needs to be a new protocol; we > (cisco) implemented exactly this (supported media are X.25 PAD, telnet, and > LAT) using this idea. See the "Protocol Translation" part of our manual as > a proof by existence that you don't need a new protocol, but rather can do > the job with existing standards, admittedly hooked together in an > unconventional topology. > > Regards, > Andy Valencia >  >  Traditionally this problem is being solved by translating one protocol to another using vendor specific Protocol Translation equipment between the end computers. We have defined this new end-to-end protocol to avoid the need for protocol translation. No additional vendor specific equipment needs to be put. Our protocol works across all the existing X.25/PAD equipments of all the vendors. Further comments/suggestions are requested from the discussion group. In specific, since the work is an extension of the "PPP in X.25" (RFC 1598) protocol, working group members of the protocol are requested to comment. Regards. Vimal - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Sep 27 15:03:17 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA23262; Sat, 27 Sep 1997 15:02:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 27 Sep 1997 14:58:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA23204 for ietf-ppp-outgoing; Sat, 27 Sep 1997 14:58:36 -0400 (EDT) Received: from arl-img-7.compuserve.com (arl-img-7.compuserve.com [149.174.217.137]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA23200 for ; Sat, 27 Sep 1997 14:58:32 -0400 (EDT) Received: (from mailgate@localhost) by arl-img-7.compuserve.com (8.8.6/8.8.6/2.5) id OAA14311 for ietf-ppp@merit.edu; Sat, 27 Sep 1997 14:58:02 -0400 (EDT) Date: Sat, 27 Sep 1997 14:57:38 -0400 From: Bruno Bonnefont Subject: PPP over V.120 To: IETF-PPP Message-ID: <199709271457_MC2-2201-601F@compuserve.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by merit.edu id OAA23201 Sender: owner-ietf-ppp@merit.edu Use of Asynchronous PPP over V.120: The basic architecture, in term of entities, is as follows : [A] [B] ......... ......... . PPP . <-- PPP --> . PPP . ......... ......... | | + (R) + | | ......... ......... . V.120 . <-- V.120 -- > . V.120 . ......... ......... Implementation A may be for example a PC running a PPP stack, linked, through a serial link (R - R reference point) to a TA (Terminal Adapter, "ISDN modem") which implements asynchronous V.120. The PPP-A entity supplies asynchronous PPP frames to the TA (just as it would supply them to an analog modem). The TA assembles the asynchronous byte stream (user data) and splits it into V.120 frames. The TA does not know anything about PPP. It's exactly the same architecture when you use a classical analog modem supporting 'Error Correction', that is, a layer 2 protocol : V.42 (LAP-M) or V.42/annex A (MNP-4). The V.120 entity is functionally equivalent to a V.42 entity. Note that this architecture may also be used for PPP over X.25 (on the D or B-channel). V.120 is based on LAP-D, used in particular as layer 2 in the ISDN D-channel, to convey signalling information (call setup etc.) and also support X.25 in the D-Channel. V.120 allows multiplexing of *several* data links on one channel (D-channel, or B-channel, or whatever). This is one main difference with LAP-B, or LAP-M. In the multiframe mode of operation (MFO) of V.120, a data link is first established (exchange of SABME/UA V.120 frames). Then user data are conveyed in I (Information) V.120 frames. An I-frame acknowledgement and windowing mechanism is implemented (just as in all other LAPS). Therefore error correction and flow control (between the two V.120 peer entities) are available. Negotiation on the link is also implemented, through XID frames. V.120 standardizes the negotiation of compression (V.42bis). V.42bis compression is therefore available on all user data - but only on the data link, not end to end. In practice, multiplexing of data links in the B-channel is not widely used - most implementations support only one data link in the B-channel. When transfering asynchronous PPP frames, over V.120, there is an overhead : - HDLC bit stuffing : nothing is added, with respect to PPP async-to-sync conversion - V.120 encapsulation : standard (practical, for interoperability) I-frame size is 256 bytes. The overhead for each frame is: a 5-byte header, plus a 2-byte FCS. This overhead can be relatively reduced if you use a larger frame size. - Asynchronous PPP character escaping : this can be eliminated completely if the Receive ACCMs of the peer PPP entities are set to all 0. A good TA firmware (we do some!) will implement local DTE/DCE flow control (through RTS/CTS typically). This, in addition to V.120 flow control (between the two peer V.120 entities), allows in practice a very high use the available bandwidth (maximum 8000 user bytes per second in a B-channel) - using an asynchronous serial link (DTE/DCE) rate of minimum 115.2 kbps. I hope this helps, Bruno Bonnefont Omnitel - San Jose CA - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Sep 29 08:55:02 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA09594; Mon, 29 Sep 1997 08:54:17 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 29 Sep 1997 08:48:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA09441 for ietf-ppp-outgoing; Mon, 29 Sep 1997 08:48:28 -0400 (EDT) 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 IAA09431 for ; Mon, 29 Sep 1997 08:48:21 -0400 (EDT) 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 NAA13981 for ; Mon, 29 Sep 1997 13:48:19 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 42fa2230; Mon, 29 Sep 97 13:42:11 +0100 Mime-Version: 1.0 Date: Mon, 29 Sep 1997 13:47:13 +0100 Message-ID: <42fa2230@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: PPP over V.120 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 Bruno Bonnefont writes: >.... >When transfering asynchronous PPP frames, over V.120, there is an >overhead : >.... >- Asynchronous PPP character escaping : this can be eliminated > completely if the Receive ACCMs of the peer PPP entities are set > to all 0. Not completely - 0x7d and 0x7e still need to be escaped. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Sep 29 08:55:04 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA09590; Mon, 29 Sep 1997 08:54:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 29 Sep 1997 08:48:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA09448 for ietf-ppp-outgoing; Mon, 29 Sep 1997 08:48:34 -0400 (EDT) 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 IAA09429 for ; Mon, 29 Sep 1997 08:48:18 -0400 (EDT) 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 NAA13976 for ; Mon, 29 Sep 1997 13:48:12 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 42fa2220; Mon, 29 Sep 97 13:42:10 +0100 Mime-Version: 1.0 Date: Mon, 29 Sep 1997 13:45:11 +0100 Message-ID: <42fa2220@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Using default receive ACCM of 0 for LCP negotiation 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 Archie Cobbs writes: > As I understand it, V.120 simply makes a synchronous link look asynchronous. > So at TA that did V.120 wouldn't have to know or do anything about PPP. > This could be an oversimplification though... can anyone confirm/deny? Yes, a TA which does V.120 wouldn't have to know anything about PPP. If it did, it would do async/sync conversion and the ISDN link would be RFC 1618 compliant. Mike Thornburg writes: ] But I have a device in my office that is a host with internal ISDN ] hardware, not a TA, that does V.120 over ISDN and passes the bytes ] received directly to its PPP layer without ever going through an async ] serial link. As I read RFC 1662, this host is a synchronous serial ] device and is therefore allowed to ignore the negotiated ACCM and only ] escape the Control Escape and Flag Sequence characters. Maybe the terms "synchronous" and "asynchronous" are a bit confusing; if "bit-oriented" and "octet-oriented", were used instead then it's clear that the PPP data stream in the V.120 case is octet-oriented (and therefore follows the rules for asynchronous links), even though V.120 itself is bit-oriented. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Sep 29 12:03:39 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA13790; Mon, 29 Sep 1997 12:03:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 29 Sep 1997 12:01:45 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA13750 for ietf-ppp-outgoing; Mon, 29 Sep 1997 12:01:44 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA13740 for ; Mon, 29 Sep 1997 12:01:35 -0400 (EDT) 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 JAA24207; Mon, 29 Sep 1997 09:01:03 -0700 Received: from ascend.com by ascend.com with ESMTP id JAA01273; Mon, 29 Sep 1997 09:01:02 -0700 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 JAA05186; Mon, 29 Sep 1997 09:00:32 -0700 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 JAA16511; Mon, 29 Sep 1997 09:00:30 -0700 Date: Mon, 29 Sep 1997 09:00:30 -0700 Message-Id: <199709291600.JAA16511@gump.eng.ascend.com> From: Karl Fox To: John Martz Cc: Subject: Using default receive ACCM of 0 for LCP negotiation In-Reply-To: <5010400011446708000002L082*@MHS> References: <5010400011446708000002L082*@MHS> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu There's one issue in John Martz's original note that I haven't seen addressed yet: > I wouldn't bother the members of this mailing list with this, except > USR mentioned (and our experience confirms) that Microsoft Win '95 > and Win NT PPP have no problems with their I-modem. This is a defense that has traditionally been used by relative newbies that didn't know the RFC's very well, except that in days of yore people tested against Cisco instead of Microsoft. It could just as easily mean that Microsoft has designed their PPP to be very tolerant of other peoples' bugs. -- 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 Mon Sep 29 12:43:03 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14470; Mon, 29 Sep 1997 12:42:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 29 Sep 1997 12:41:14 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA14424 for ietf-ppp-outgoing; Mon, 29 Sep 1997 12:41:14 -0400 (EDT) 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 MAA14420 for ; Mon, 29 Sep 1997 12:41:09 -0400 (EDT) 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 RAA21406 for ; Mon, 29 Sep 1997 17:41:07 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 42fd8b80; Mon, 29 Sep 97 17:35:04 +0100 Mime-Version: 1.0 Date: Mon, 29 Sep 1997 17:27:07 +0100 Message-ID: <42fd8b80@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Requesting comments on draft-rfced-info-khan-00.txt 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 Vimal K. Khanna wrote: > Andrew Valencia wrote: > >> >The draft suggests a PPP based protocol which will allow all these PC >> >users to run TCP/IP protocol over their async links to PADs. >> >... >> >> If I'm reading this draft correctly, you're saying "run async PPP over a >> byte stream protocol". I don't think there needs to be a new protocol; we >> (cisco) implemented exactly this (supported media are X.25 PAD, telnet, and >> LAT) using this idea. See the "Protocol Translation" part of our manual as >> a proof by existence that you don't need a new protocol, but rather can do >> the job with existing standards, admittedly hooked together in an >> unconventional topology. > >Traditionally this problem is being solved by translating one protocol >to another using vendor specific Protocol Translation equipment between >the end computers. We have defined this new end-to-end protocol to >avoid the need for protocol translation. No additional vendor specific >equipment needs to be put. Our protocol works across all the existing >X.25/PAD equipments of all the vendors. I think I see where this is coming from - the problem with RFC 1598 is that it requires the device on the boundary of the X.25 network to be PPP aware. If it's a standard Triple-X PAD provided by the network operator it probably knows nothing of PPP. I think Andy is correct - no new protocol is required. But then I'm not sure that the draft does define a new "protocol" - I suppose it's a question of semantics. The value the draft adds is that it defines a mechanism ("protocol" ?) for a called host to be able to determine that the X.25 call is to carry octet-oriented (i.e. Async) PPP instead of some other Triple-X session, and for it to confirm to the caller that it knows it's async PPP. This mechanism certainly isn't essential, because the caller could select the host's async-PPP service by means of a configured subaddress or additional call user data after the PID (after all, it already needs to be configured with the correct NUA). The confirmation isn't really needed either - if the wrong number is called, and the remote service isn't async PPP, then the caller will time out because it won't get any responses to its LCP Config Requests. I think that maybe a standard Call User Data string would be useful to identify the fact that a call carries octet-oriented PPP. But I'm not sure that 01 00 00 00 00 00 00 01 (including the X.29 PID) is the best choice. Maybe 01 00 00 00 CF would be better (as the CUD for RFC 1598 calls is 0xCF, but without the 01 00 00 00 in front of it). There may also be some problems with using an unrestricted response Fast Select call - there may be some X.25 networks which don't support them. >Further comments/suggestions are requested from the discussion group. >In specific, since the work is an extension of the "PPP in X.25" (RFC >1598) protocol, working group members of the protocol are requested to >comment. Maybe RFC 1598 needs to be updated to include a description of the operation of octet-oriented PPP over X.25. While we're at it, maybe RFC 1618 should be updated with a clearer description of PPP over V.120. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Sep 29 12:49:55 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA14635; Mon, 29 Sep 1997 12:49:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 29 Sep 1997 12:48:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA14588 for ietf-ppp-outgoing; Mon, 29 Sep 1997 12:48:25 -0400 (EDT) Received: from ns.frigate.com (ns.frigate.com [209.81.17.6]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA14584 for ; Mon, 29 Sep 1997 12:48:21 -0400 (EDT) Received: from localhost (mthorn@localhost) by ns.frigate.com (8.8.5/8.7.1) with SMTP id JAA06790; Mon, 29 Sep 1997 09:48:08 -0700 (PDT) Date: Mon, 29 Sep 1997 09:48:07 -0700 (PDT) From: Mike Thornburg To: Jonathan Goodchild cc: ietf-ppp@merit.edu Subject: Re: Using default receive ACCM of 0 for LCP negotiation In-Reply-To: <42fa2220@rdl.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Mon, 29 Sep 1997, Jonathan Goodchild wrote: > > Mike Thornburg writes: > > ] But I have a device in my office that is a host with internal ISDN > ] hardware, not a TA, that does V.120 over ISDN and passes the bytes > ] received directly to its PPP layer without ever going through an async > ] serial link. As I read RFC 1662, this host is a synchronous serial > ] device and is therefore allowed to ignore the negotiated ACCM and only > ] escape the Control Escape and Flag Sequence characters. > > Maybe the terms "synchronous" and "asynchronous" are a bit confusing; if > "bit-oriented" and "octet-oriented", were used instead then it's clear > that the PPP data stream in the V.120 case is octet-oriented (and > therefore follows the rules for asynchronous links), even though V.120 > itself is bit-oriented. > RFC 1662 already uses the term octet-synchronous to describe synchronous links that use octet-stuffed framing and bit-synchronous to describe links using bit-stuffed framing; however, Section 6 on "Asynchronous to Synchronous Conversion" fails to specify "bit-synchronous" and merely says "synchronous". This would seem to make the words "acceptance of the Configuration Option does not imply that the synchronous implementation will do any ACCM mapping" apply to octet-synchronous as well as bit-synchronous links. If this is really what is meant in RFC 1662, then I don't think "octet-oriented" is a good choice of terms to clarify the situation with V.120, since the term octet-synchronous would at first glance seem to imply octet-oriented. Could someone who knows more than I do about how section 6 of RFC 1662 came to be written comment on whether or not it was intended to apply to octet-synchronous links? Another approach would be to introduce wording into the PPP over ISDN RFC to the effect that notwithstanding the use of the term "async-sync conversion" in connection with V.120, that V.120 counts as an asynchronous link for the purposes of RFC 1662. Of course, we then get into the problem of how to deal with synchronous V.120, which I understand exists but have never dealt with myself. Thanks, Mike -------------- Mike Thornburg frigate networks 650.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Sep 29 23:37:15 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id XAA24039; Mon, 29 Sep 1997 23:36:59 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 29 Sep 1997 23:34:47 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA24000 for ietf-ppp-outgoing; Mon, 29 Sep 1997 23:34:46 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm001-03.dialip.mich.net [204.38.9.100]) by merit.edu (8.8.7/8.8.5) with SMTP id XAA23996 for ; Mon, 29 Sep 1997 23:34:41 -0400 (EDT) Date: Tue, 30 Sep 97 03:00:38 GMT From: "William Allen Simpson" Message-ID: <6587.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Using default receive ACCM of 0 for LCP negotiation Sender: owner-ietf-ppp@merit.edu As often happens, there are several concepts and threads mixed up in this subject, and only in a few days. I'll try to answer one at a time: > From: John Martz > Date: Thu, 25 Sep 1997 20:27:57 -0400 > However, today we learned that one of the ISDN terminal adapters we're testing > with (an US Robotics Courier I-modem (with ISDN/V.34) using flash code revision > 2.1.4) can send our box an LCP configure request packet where some of the bytes > have not been escaped. > As has been noted earlier, there is not enough information here to describe which form of PPP framing you are using. So, I'll guess. Remember, the PPP packet (link, layer-2) is inside a frame (hardware, layer-1). If this were a bit-stuffed ISDN sync interface, then of course, the ACCM is zero (0). See RFC-1662 page 14. The term V.34 in your message would hint to me that some part of the hardware to the USR ISDN TA is async. Every async frame _MUST_ be octet-stuffed, and the ACCM _MUST_ default to 0xffffffff. You do not care whether the TA is doing some form of async to sync (and octet-stuffed to bit-stuffed) conversion. It MUST appear to be the same as any other form of async link. If this is the case, then it is clear that the USR box is broken badly. It is not properly doing stuffing conversion. Do not break your async implementation. Make USR upgrade their firmware. That's why it is flash ROM. > In earlier exchanges on this mailing list I've read of implementations which > retained the negotiated receive ACCM when dropping back to re-negotiate LCP > options. This is evil (bogus, wrong, technically incorrect, however you want to label it). DO _NOT_ do this. It will not interoperate with most vendors. (As you mentioned earlier, it is explicitly forbidden in RFC-1661.) > I wouldn't bother the members of this mailing list with this, except USR > mentioned (and our experience confirms) that Microsoft Win '95 and Win NT PPP > have no problems with their I-modem. From this I assume their PPP always uses a > default receive ACCM of 0. I'm beginning to think this is very common > modification. Anyone have any idea how many implementations out there are > bending the letter of the ACCM law in RFC 1661? > ACCM is in RFC-1662. The requirement to fall back with _ALL_ options that is in RFC-1661 applies to all options in RFC-1662. "Using MicroSoft is Considered Harmful" And last week, Peter Ford committed to fixing all the NT and 98 stack (TCP+IP+PPP) bugs I could send him. He's a long-time IETFer, and we are depending on his word. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 00:34:14 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA24575; Tue, 30 Sep 1997 00:34:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 00:32:35 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA24538 for ietf-ppp-outgoing; Tue, 30 Sep 1997 00:32:35 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-23.dialip.mich.net [141.211.7.159]) by merit.edu (8.8.7/8.8.5) with SMTP id AAA24530 for ; Tue, 30 Sep 1997 00:32:30 -0400 (EDT) Date: Tue, 30 Sep 97 03:33:26 GMT From: "William Allen Simpson" Message-ID: <6588.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Using default receive ACCM of 0 for LCP negotiation Sender: owner-ietf-ppp@merit.edu > Date: Fri, 26 Sep 1997 09:55:13 +0100 > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > I suspect there are several implementations which use a default Rx ACCM > of 0, but it seems that this is broadly in line with the principle of > "being generous in what you accept". Unfortunately, this is bogus. On receipt, there is a requirement that characters that should have been escaped are thrown away. This decision was made by the WG after 2 years of field testing under the PPP WG, and confirmed in a further 2 years of field testing for the PPPext WG. There are many modems that inject control characters. HP and Multitech come to mind. It will not work without arduous secondary processing (below). > Of course, if you don't trust your peer to follow the rules, there is a > way round it: process received frames (before LCP is open) with an Rx > ACCM of zero, and if the FCS is ok then accept the frame; if anything > has injected control characters into the frame then it will result in a > bad FCS, in which case process the frame a second time, this time > stripping all the control characters (i.e. using an ACCM of 0xFFFFFFFF). > Have you actually implemented this? Has anyone actually implemented this? Why not enforce correct standards compliant implementation? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 00:34:11 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA24580; Tue, 30 Sep 1997 00:34:09 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 00:32:40 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA24549 for ietf-ppp-outgoing; Tue, 30 Sep 1997 00:32:40 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-23.dialip.mich.net [141.211.7.159]) by merit.edu (8.8.7/8.8.5) with SMTP id AAA24532 for ; Tue, 30 Sep 1997 00:32:31 -0400 (EDT) Date: Tue, 30 Sep 97 03:45:26 GMT From: "William Allen Simpson" Message-ID: <6589.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: ISDN and RFC-1618 and deprecation Sender: owner-ietf-ppp@merit.edu This diversion sprung out of nowhere. I saw no reference to V.120 in > Subject: Re: Using default receive ACCM of 0 for LCP negotiation Be that as it may, V.120 was tested as one of the techniques for getting PPP across ISDN. It was deprecated. Those poor souls who had V.120 TAs in 1993 should have thrown them away long ago. We tested and argued about the best way to do ISDN in 3 IETF WGs over 4 years. In the end, we discovered by actual testing and comparison that several methods had inferior performance. V.120 was the worst, but was closely followed by V.110 and BONDING. > > mthorn@frigate.com (Mike Thornburg) > > V.120 is (theoretically) covered in RFC 1618 (PPP over ISDN) which states: > > > > Terminal adapters conforming to V.120 [4] can be used as a > > simple interface to workstations. Asynchronous HDLC framing > > [2] is accepted at the R reference point. The terminal adapter > > provides async-sync conversion. Multiple B-channels can be > > used in parallel. Unfortunately, V.120 has a framing mode of > > its own for rate adaptation, which is difficult to distinguish > > from Frame Relay, and which can confuse in-band frame > > detection. V.120 is not interoperable with bit-synchronous > > links, since V.120 does not provide octet-stuffing to bit- > > stuffing conversion. Therefore, V.120 is deprecated in favor > > of more modern standards, such as "PPP in Frame Relay". > > > > This would seem to tell people running V.120 to treat the ISDN link as an > > octet-stuffed synchronous link and therefore the async-sync conversion in > > this case does _not_ involve changing octet-stuffing to bit stuffing. This is confused. I tried very hard to clearly distinguish the terms async-sync and octet versus bit stuffing, but he is equating them. What this was trying to say was both ends of the link have to be V.120, as it is not compatible with anything else, and cannot be automatically detected. V.120 was designed as yet another all things to all people framing (layer-1, hardware) specification. As such, it does nothing very well. Thus, V.120 not only performs badly, but it is hideously difficult to configure in a heterogenous environment. You have to know what both ends of the PSTN are using. You cannot use X.25 or Frame Relay or SONET-SDH on one end, as V.120 does not do octet-stuffing to bit-stuffing conversion. PPP tried to be self-configuring. V.120 is not self-configuring. Therefore, use of V.120 with PPP is deprecated. > > However, the async-sync conversion step involved here means that in theory > > the TA is responsible for adding octet stuffing for any characters > > received over the synchronous link that are flagged in the ACCM and are > > not escaped (since the entity at the other end of the synchronous link is > > allowed to ignore the ACCM. See RFC 1662 section 6). The TA would also be > > responsible for recognizing an LCP packet and making sure that all control > > characters in such a packet are escaped before sending them down the async > > link. > No. V.120 can be used with an async feed. It takes in async on one end, converts it to synchronous octets, and sends them to another TA. That TA has to convert the octets back to async. The middle link can be X.25, or SONET-SDH, or any of a myriad of other channels. As noted elsewhere, when both ends are async, they both use async octet-stuffing conventions. And that means ACCM default 0xffffffff. > From: Archie Cobbs > As I understand it, V.120 simply makes a synchronous link look asynchronous. > So at TA that did V.120 wouldn't have to know or do anything about PPP. > This could be an oversimplification though... can anyone confirm/deny? > Correct! > > Is it just me, or is RFC 1618 confusing and not nearly helpful enough when > > you have a question like this? I don't believe anyone else has brought it > > up as applicable to this discussion -- perhaps this is telling. > > *IMHO* it should say, "These days everybody does PPP over ISDN > using the `PPP in HDLC-like framing' method, so you don't need > to bother doing it any other way. If you're a terminal adapter, > you should do sync-async conversion (eg. a la BitSURFR Pro, > 3Com Impact IQ, et.al.) as described in this document, to get > you to PPP in HDLC-like framing over the wire." > It _does_ say "you don't need to bother doing it any other way" (that's what DEPRECATED means). I put the "good" and "bad" methods together in the same section for "comparison". It would probably be better "standardese" to put the deprecated techniques in Appendices, so that people will ignore them when reading the main document. Now is a good time to update RFC-1618. If any other parts are confusing, please let me know. Thanks. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 01:12:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA25018; Tue, 30 Sep 1997 01:12:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 01:10:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA24963 for ietf-ppp-outgoing; Tue, 30 Sep 1997 01:10:58 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-08.dialip.mich.net [141.211.7.19]) by merit.edu (8.8.7/8.8.5) with SMTP id BAA24943 for ; Tue, 30 Sep 1997 01:10:49 -0400 (EDT) Date: Tue, 30 Sep 97 04:59:13 GMT From: "William Allen Simpson" Message-ID: <6592.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: MS ACCM considered harmful Sender: owner-ietf-ppp@merit.edu Or, this makes it clear that folks at MS never tested against anything but brand new V.34 modems. And MS has designed their PPP to be very intolerant of robust implementations from other vendors. "embrace and extend" > From: Karl Fox > There's one issue in John Martz's original note that I haven't seen > addressed yet: > > > I wouldn't bother the members of this mailing list with this, except > > USR mentioned (and our experience confirms) that Microsoft Win '95 > > and Win NT PPP have no problems with their I-modem. > > This is a defense that has traditionally been used by relative newbies > that didn't know the RFC's very well, except that in days of yore > people tested against Cisco instead of Microsoft. It could just as > easily mean that Microsoft has designed their PPP to be very tolerant > of other peoples' bugs. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 01:12:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA25015; Tue, 30 Sep 1997 01:12:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 01:10:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA24949 for ietf-ppp-outgoing; Tue, 30 Sep 1997 01:10:53 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-08.dialip.mich.net [141.211.7.19]) by merit.edu (8.8.7/8.8.5) with SMTP id BAA24937 for ; Tue, 30 Sep 1997 01:10:46 -0400 (EDT) Date: Tue, 30 Sep 97 04:29:16 GMT From: "William Allen Simpson" Message-ID: <6590.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: a TA is a TA Sender: owner-ietf-ppp@merit.edu > From: Mike Thornburg > But I have a device in my office that is a host with internal ISDN > hardware, not a TA, that does V.120 over ISDN and passes the bytes > received directly to its PPP layer without ever going through an async > serial link. Anything that runs V.120 has an R reference interface, and is therefore a TA. Even internal TAs. Heck, the R, S, T, and U interfaces can all be integrated in one device. They are still there.... > As I read RFC 1662, this host is a synchronous serial device > and is therefore allowed to ignore the negotiated ACCM and only escape the > Control Escape and Flag Sequence characters. It does not do that, because > if it did it would never interoperate with ISDN TAs as they are > implemented now. > Bad reading of RFC-1662, which has nothing to do with ISDN or with hosts. If it is not "HDLC-like", then it is not the topic of RFC-1662. > What I am claiming is that a literal reading of RFC 1662 and RFC 1618 > would seem to require that a TA receiving PPP frames over V.120 be > responsible for adding missing escape sequences into the asynchronous > serial stream, yet this is absolutely _not_ industry practice (and is > absurd to require, since it would require adding a rudimentary PPP stack > into a device that otherwise would not need to know PPP). Either I am > misreading the RFCs or they are incompatible with present practice and > need to be revised and reissued. > RFC-1618 requires that V.120 be "deprecated". Therefore, there is no conflict with RFC-1662 or with current practice. Anything that uses V.120 is non-compliant. Heck, V.120 was obsolete in 1991, at least 2 hardware generations ago. There are plenty of nice compliant devices out there. Use one. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 01:12:57 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA25010; Tue, 30 Sep 1997 01:12:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 01:10:56 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA24956 for ietf-ppp-outgoing; Tue, 30 Sep 1997 01:10:56 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-08.dialip.mich.net [141.211.7.19]) by merit.edu (8.8.7/8.8.5) with SMTP id BAA24939 for ; Tue, 30 Sep 1997 01:10:47 -0400 (EDT) Date: Tue, 30 Sep 97 04:43:36 GMT From: "William Allen Simpson" Message-ID: <6591.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: async to sync conversion Sender: owner-ietf-ppp@merit.edu > From: Mike Thornburg > Could someone who knows more than I do about how section 6 of RFC 1662 > came to be written comment on whether or not it was intended to apply > to octet-synchronous links? > Yes, it was. In fact, I did such an implementation in the cellular industry (IS-99) in 1993-1995. The back of the phone is async. The air interface is SONET-like. The next step is bit-sync from the channel selector, so that it looks just like voice. The next step is octet-sync again (over ethernet) to the packet router. And the final step is PPP over SONET to the PSTN. PPP is designed to be self-configuring. Any adapter that changes async to bit or octet-synchronous has to recognize the ACCM as it goes by. That way, we can chain async to octet-sync to bit-sync to async, or any combination thereof. It just works. > Another approach would be to introduce wording into the PPP over ISDN RFC > to the effect that notwithstanding the use of the term "async-sync > conversion" in connection with V.120, that V.120 counts as an asynchronous > link for the purposes of RFC 1662. Of course, we then get into the > problem of how to deal with synchronous V.120, which I understand exists > but have never dealt with myself. > Or we could simply read RFC-1618 as written: V.120 is deprecated. The sync V.120 opens a whole 'nother can of worms, and is not compatible with anything else, including V.110. One of the worst protocols ever designed by a committee, in my not very humble opinion. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 09:24:51 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id JAA28385; Tue, 30 Sep 1997 09:23:44 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 09:17:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA28302 for ietf-ppp-outgoing; Tue, 30 Sep 1997 09:17:25 -0400 (EDT) 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 JAA28298 for ; Tue, 30 Sep 1997 09:17:19 -0400 (EDT) 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 OAA06907 for ; Tue, 30 Sep 1997 14:17:17 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 430fa700; Tue, 30 Sep 97 14:11:12 +0100 Mime-Version: 1.0 Date: Tue, 30 Sep 1997 14:13:51 +0100 Message-ID: <430fa700@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Using default receive ACCM of 0 for LCP negotiation 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 Bill Simpson writes: > If this were a bit-stuffed ISDN sync interface, then of course, the > ACCM is zero (0). See RFC-1662 page 14. As I've said before, saying that the ACCM for bit-stuffed ISDN is zero is misleading. The ACCM simply doesn't apply to bit-stuffed ISDN. If you have a sync/async converting TA at one end of the ISDN link, then the value that the async peer has to use as its TX ACCM could be anything at all, and, depending upon the TA, it is this value that the ISDN peer is negotiating as its RX ACCM. >> In earlier exchanges on this mailing list I've read of implementations >> which retained the negotiated receive ACCM when dropping back to >> re-negotiate LCP options. > > This is evil (bogus, wrong, technically incorrect, however you want to > label it). > > DO _NOT_ do this. It will not interoperate with most vendors. Come off it - it's not as bad as all that: it should interoperate with ALL (unbroken) vendors in most situations. It can only fail to interoperate if some equipment is injecting characters which weren't in the previously negotiated ACCM, and that can only happen :- 1) if the Rx ACCM negotiated the first time was incorrect; 2) if the equipment in the middle of the link has somehow changed or been reconfigured since the first time the ACCM was negotiated, necessitating a change to the ACCM. (Having said that, I'm not suggesting that anyone do it this way.) >> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) >> I suspect there are several implementations which use a default Rx ACCM >> of 0, but it seems that this is broadly in line with the principle of >> "being generous in what you accept". > > Unfortunately, this is bogus. Ok, I should've said it goes beyond the principle and is being "over-generous" in what it accepts. > On receipt, there is a requirement that characters that should have been > escaped are thrown away. This decision was made by the WG after 2 years of > field testing under the PPP WG, and confirmed in a further 2 years of field > testing for the PPPext WG. I'm not disputing that decision, but let's look at this in more detail. If a device is configured to attempt to negotiate the Rx ACCM to zero, then if that configuration is correct, there will be no problems if the ACCM is applied immediately instead of once LCP is open. (Obviously, if the proposed ACCM is configured non-zero, if would be stupid to attempt to start with a default ACCM of zero). Now the local configuration is not necessarily correct - the peer may know that something can inject control characters into the data, in which case it would Nak the proposed ACCM. If the local device isn't discarding these control characters then it may never receive the Nak, but with sufficient retries this is unlikely, unless something injects characters into every single frame. So as long as the local peer adjusts its ACCM when it receives a Nak, communication should be established (eventually). Obviously, this is less efficient and not completely reliable, but it will work most (probably the vast majority) of the time, and it has the advantages of interworking with some broken peers. I'm therefore not surprised if this is what some vendors are implementing in practice, even if I wouldn't recommend it personally. > It will not work without arduous secondary processing (below). I think that would have been better phrased: "It will not work 100% reliably in all situations without..." > >> Of course, if you don't trust your peer to follow the rules, there is a >> way round it: process received frames (before LCP is open) with an Rx >> ACCM of zero, and if the FCS is ok then accept the frame; if anything >> has injected control characters into the frame then it will result in a >> bad FCS, in which case process the frame a second time, this time >> stripping all the control characters (i.e. using an ACCM of 0xFFFFFFFF). > > Have you actually implemented this? No, I haven't (I've followed the standard). > Has anyone actually implemented this? (I've no idea.) > Why not enforce correct standards compliant implementation? That would be very nice. Obviously, it's in the long-term interests of everyone to enforce the standard, but there may be short-term economic penalties for those refusing to interoperate with certain broken peers. --- Jonathan Goodchild - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 10:07:09 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA29194; Tue, 30 Sep 1997 10:07:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 10:05:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA29115 for ietf-ppp-outgoing; Tue, 30 Sep 1997 10:05:30 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-27.dialip.mich.net [141.211.7.163]) by merit.edu (8.8.7/8.8.5) with SMTP id KAA29111 for ; Tue, 30 Sep 1997 10:05:26 -0400 (EDT) Date: Tue, 30 Sep 97 13:38:42 GMT From: "William Allen Simpson" Message-ID: <6594.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: PPP and X.25 Sender: owner-ietf-ppp@merit.edu > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > The value the draft adds is that it defines a mechanism ("protocol" ?) > for a called host to be able to determine that the X.25 call is to carry > octet-oriented (i.e. Async) PPP instead of some other Triple-X session, > and for it to confirm to the caller that it knows it's async PPP. > RFC-1598 already has a mechanism for the called PAD to determine that the X.25 call is carrying PPP -- the CUD. If the PAD changes PPP from sync to async, the PAD is required to do sync-async conversion. OTOH, if the PAD is merely carrying async bytes, the async framing already works just fine. The "host" attached to the destination PAD is going to receive async, and will determine that PPP is arriving by the techniques described by RFC-1662 Appendix B -- Automatic Recognition of PPP Frames. > This mechanism certainly isn't essential, because the caller could > select the host's async-PPP service by means of a configured subaddress > or additional call user data after the PID (after all, it already needs > to be configured with the correct NUA). The confirmation isn't really > needed either - if the wrong number is called, and the remote service > isn't async PPP, then the caller will time out because it won't get any > responses to its LCP Config Requests. > I agree. And I believe there are several vendors supporting PPP over PADs in just this fashion. That's standard HDLC-like behaviour, not PPP in X.25 framing. That X.25 is somewhere in the middle is irrelevant. > Maybe RFC 1598 needs to be updated to include a description of the > operation of octet-oriented PPP over X.25. While we're at it, maybe RFC > 1618 should be updated with a clearer description of PPP over V.120. > It is probably time to update both RFC-1598 and RFC-1618 based on implementation experience. But, async over PSTN is not related to RFC-1598. And, async over V.120 is explicitly deprecated in RFC-1618. The next draft will move the V.120 references to an appendix to make that more clear. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 11:23:32 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA00612; Tue, 30 Sep 1997 11:23:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 11:21:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA00561 for ietf-ppp-outgoing; Tue, 30 Sep 1997 11:21:31 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-03.dialip.mich.net [141.211.7.139]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA00554; Tue, 30 Sep 1997 11:21:20 -0400 (EDT) Date: Tue, 30 Sep 97 14:30:08 GMT From: "William Allen Simpson" Message-ID: <6595.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: [Fwd: [Fwd: Requesting comments on my draft]] Sender: owner-ietf-ppp@merit.edu OK, I'm back home, and I've read it. For the rest of you on the list, I'm sorry to write so many messages in one day. And the remainder of this message is intended to be a bit sarcastic, so if that sort of thing disturbs you, you should probably ignore the rest. > private message from Fred Baker > Date: Thu, 25 Sep 1997 08:41:49 -0700 > At 6:50 PM +0530 9/25/97, Vimal K. Khanna wrote: > >Dear Fred Baker, > >... > >3. Please also inform me as to the procedure I should adapt to push it > >thru with the Working Group. > > > >4. The Working Group involved with the standardisation of RFC 1598 may > >be interested in this work since it also looks at PPP in relation to > >X.25 protocol. Could you send me the e_mail addresses of that WG so that > >I could contact them also to push the draft. > > I believe that you mean to contact Karl Fox as chair and > Bill Simpson as author/editor of RFC 1598. I copied both of these on this > note. You'll note from page 7 of RFC 1598 that I was merely the chair of > the working group. >... > The procedure you should follow is to discuss submission of your draft to > the PPP Working Group with its chair, Karl Fox. > Actually, he sent me several messages, and Karl several messages, and the WG list a couple as well. Rather like spam. Rather impatient. As I don't already get 300 IETF messages a day, and should drop everything to read his draft. And I don't like being "pushed". Every once in awhile we get yet another person who rediscovers old principles, and develops yet another incompatible solution. Not that this reflects on the intelligence of this new person, but with very old protocols like X.3 and X.25, a lot of other intelligent persons might have looked at the problem sometime in the past.... This has nothing to do with RFC-1518, other than the fact that X.25 is involved in the middle, in the same way that V.35, or V.110, or V.120, or ISDN, or SONET, or ATM, may be in the middle. The author does not appear to be knowlegable about the difference between a "packet" and "framing", despite the fact that I put the definitions in the terminology section of several relevant RFCs. He is/was not alone, but not carefully reading the PPP RFCs is inexcusible for an ostensible PPP author. PPP in X.25 framing is bit-sync. This proposal is async over X.3 PADs. That the intervening X.25 terminates in a PAD embedded in a server, rather than a separate box, does not change the fact that the service is still character mode, and the server is operating a PAD. Moreover, there is no new protocol involved. This is just a dialer on one end talking to a terminal server, that wants to add automatic PPP frame detection instead of character mode login. This is already IETF Full Standardized in RFC-1662 Appendix B. This proposal is incompatible with shipping product from Cisco, the old Morningstar cum Progressive Systems, a company in Lansing Michigan (whose name I forget) that did a lot of business in India, and probably a lot of other vendors. It relies on X.3 capabilities that have never been widely deployed. It relies on a proposed revision of X.25 capabilities that have not managed to get out of CCITT committee in 5 years. That's a long time, even for ITU. We are supposedly quite lenient about publishing things in the IETF. But do we really need yet another incompatible way of doing the same thing we've been doing for years? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 12:47:58 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA01950; Tue, 30 Sep 1997 12:47:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 12:46:03 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA01910 for ietf-ppp-outgoing; Tue, 30 Sep 1997 12:46:02 -0400 (EDT) Received: from alpha.shiva.com (eagle-ext.shiva.com [192.80.57.28]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA01905 for ; Tue, 30 Sep 1997 12:45:58 -0400 (EDT) Received: from brill.shiva.com (brill.shiva.com [140.248.193.94]) by alpha.shiva.com (8.8.6/8.8.6) with SMTP id MAA05511 for ; Tue, 30 Sep 1997 12:44:39 -0400 (EDT) Received: by brill.shiva.com (SMI-8.6/SMI-SVR4) id MAA12611; Tue, 30 Sep 1997 12:45:50 -0400 Date: Tue, 30 Sep 1997 12:45:50 -0400 Message-Id: <199709301645.MAA12611@brill.shiva.com> From: John Shriver To: ietf-ppp@merit.edu Subject: Re: ISDN and RFC-1618 and deprecation Sender: owner-ietf-ppp@merit.edu Well, there's a market demand for V.120 support. Customers want it. I don't know _why_, perhaps there are places where V.120 (or V.110) costs less per minute than a plain ISDN data call. (Why do old TA's persist forever, when 14,400 modems are going in the trash can?) We can say that it's not a preferred method, but we really can't "ban" it in the standard. (It would take a cartel to ban it, and that's probably outside our anti-trust exemptions.) It's really obvious what you do, run Async PPP over the R interface point. Let's be sure that we standardize this as the way to do this. Also, while when RFC 1618 was being written, the discussion in section 4 about "out-of-band signalling" was highly relevant in the USA, that's really not so much the case anymore. The requirements for 800 number portability forced rather universal Signalling System 7 deployment in the USA. (Since V.120 is primarily a US affliction, that makes the USA safer for V.120 now.) Portability for ordinary phone numbers (LEC competition) will purge the last US pockets of non-Signalling System 7 soon. While I agree that we don't EVER want a LLC-IE value for PPP, I don't see anything wrong with something that speaks PPP using the LLC-IE to determine that it's Async over V.120, or Async over V.110, or Sync over V.110, or Sync over ISDN. Don't standardize ignoring LLC-IE. Even if you don't get the LLC-IE for V.120, you can always accept calls as Async PPP over V.120 by (in ITU terms) "prior arrangement". The most common method of "prior arrangement" is to dedicate special phone numbers for these strange call types. I think we need to make "PPP over ISDN" admit all the disgusting things people want to do. Certainly, it should point out that the native encapsulation is best for many reasons. Perhaps it should even point out what a PPP-conscious ISDN TA should do. (Maybe that deserves a "best practices" RFC?) Sort of, here's the preferred method, but if you're perverse, see the appendices. Then, a set of appendices: A: Async PPP over V.120 over ISDN B channel. B: Async PPP over V.110 over ISDN B channel. C: Sync PPP over V.110 over ISDN B channel. D: Sync PPP over X.25 over ISDN D channel. etc: Yeah, most of these would just be: use this RFC at the R reference point, etc. Also, each could have an explanation of why it's pessimal. (Slow, auto-detection problems, etc.) But, people may be willing to pay that price, for tarrif reasons, or sunk costs, etc. I'd also say that the "defaults" approach could change. By default, with no LLC IE, assume Sync PPP over ISDN B channel. But, if there is an LLC IE, see the relevant Appendix if it's V.110, V.120, or X.25. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 13:20:44 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA02482; Tue, 30 Sep 1997 13:20:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 13:19:14 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA02434 for ietf-ppp-outgoing; Tue, 30 Sep 1997 13:19:14 -0400 (EDT) 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 NAA02427 for ; Tue, 30 Sep 1997 13:19:08 -0400 (EDT) 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 SAA13635; Tue, 30 Sep 1997 18:18:50 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 431330d0; Tue, 30 Sep 97 18:12:45 +0100 Mime-Version: 1.0 Date: Tue, 30 Sep 1997 18:08:42 +0100 Message-ID: <431330d0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: PPP and X.25 To: "William Allen Simpson" Cc: 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 Bill, Nice to see that we agree about something for a change ! Anyway, if you're revisiting RFC 1598 then I think that section 3 could be improved somewhat. In particular, I have an issue about the requirement not to negotiate Address-and-Control-Field-Compression. Consider the following scenario: Two PPP peers, A and B, talk sync PPP via a leased line. It's then decided to connect them via an X.25 network instead, with two boxes, X and Y, to convert to RFC 1598. +---+ +---+ +---+ +---+ | A |------------| X |----------------| Y |----------| B | +---+ sync PPP +---+ X.25 network +---+ sync PPP +---+ Now, as far as A and B are concerned, nothing has changed, so why should they have to be reconfigured to disable Address-and-Control-Field compression ? (Actually, this also applies equally if it's async PPP, and X and Y are doing sync/async conversion in addition). The truth is that the PPP Address and Control Fields have nothing whatsoever to do with the X.25 frame Address and Control fields. The PPP fields are simply compressed automatically over the X.25 connection, regardless of whether A&FC compression has been negotiated or not. In my diagram above, A&CF compression would govern whether the fields were transmitted on the links between A and X and between Y and B. I think it would be much better not to describe the format of the X.25 header (other than as a single lump) in the Frame Format in section 3.1 - in any case this frame format doesn't take into account the possibility of modulo-128 sequence numbers at either Layer 2 or 3, and completely ignores the use of the M bit (yes, I know it's mentioned in section 5). So, my suggested text for section 3 (although I dare say that you could improve upon the wording) would be: 3. The Data Link Layer This specification uses the principles, terminology, and frame structure described in "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode" [4]. The purpose of this specification is not to document what is already standardized in [4]. Instead, this document attempts to give a concise summary and point out specific options and features used by PPP. 3.1. Frame Format The PPP encapsulation [as described in RFC 1661 section 2], or PDU, is delivered to the X.25 layer as a "complete packet sequence" [see ITU-T X.25 clause 4.3.5 for a definition]. The X.25 layer may divide this up into a number of packets, but the PDU will be delivered as a complete packet sequence to the remote X.25 DTE. Assuming that the PPP packet fits into a single X.25 data packet, the format is as follows: +--------------+--------------+-------------+---------+----------+ | X.25 header | PPP Protocol | Information | Padding | X.25 FCS | | 5/6/7 octets | 8/16 bits | | * | 2 octets | +--------------+--------------+-------------+---------+----------+ The PPP Protocol field and the following Information and Padding fields are described in the Point-to-Point Protocol Encapsulation [1]. The X.25 header may be 5, 6 or 7 octets in length, depending upon whether modulo-8 or modulo-128 sequence numbers are used at layer 2 and layer 3. Note the absence of the PPP Address and Control Fields (although a robust implementation may be advised to be prepared to receive 0xff 0x03 between the X.25 header and the PPP Protocol Field). 3.2. Modification of the Basic Frame The Link Control Protocol can negotiate modifications to the basic frame structure. However, modified frames will always be clearly distinguishable from standard frames. Address-and-Control-Field-Compression The PPP Address and Control field values are completely unrelated to the X.25 Address and Control fields. As these fields are not present in this encapsulation, they are effectively compressed automatically, and thus the result of the negotiation of Address-and-Control-Field-Compression is irrelevant. Address-and- Control-Field-Compression therefore MAY be negotiated. Protocol-Field-Compression Note that unlike the HDLC framing, the X.25 framing does not necessarily align the Information field on a 32-bit boundary, because the X.25 header (not including the flag) may be 5, 6 or 7 octets in length. Alignment to a 16-bit boundary occurs when Protocol field is compressed to a single octet if the X.25 header is an odd length. When this improves throughput, Protocol-Field-Compression SHOULD be negotiated. --- Jonathan Goodchild P.S. Putting V.120 into the appendix of RFC 1618 sounds like a good idea, but it may be useful to include a statement to the effect that all the rules for async PPP apply (i.e. explain it clearly at the same time as deprecating it). - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 13:37:34 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA02744; Tue, 30 Sep 1997 13:37:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 13:35:54 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA02713 for ietf-ppp-outgoing; Tue, 30 Sep 1997 13:35:53 -0400 (EDT) Received: from m3.sprynet.com (m3.sprynet.com [165.121.2.55]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA02709 for ; Tue, 30 Sep 1997 13:35:49 -0400 (EDT) Received: from kmcgrew.inhouse.compuserve.com (sea3271.inhouse.compuserve.com [149.174.32.71]) by m3.sprynet.com (8.6.12/8.6.12) with SMTP id KAA16731; Tue, 30 Sep 1997 10:40:12 -0700 Message-ID: <34313571.5639@sprynet.com> Date: Tue, 30 Sep 1997 10:22:57 -0700 From: Kelly McGrew Reply-To: kmcgrew@sprynet.com X-Mailer: Mozilla 3.0Gold (Win95; I) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: PPP Implementations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu A request for information about various PPP implementations: I'm looking for PPP implementations that are fully compliant with the standards. From what I've read here and elsewhere Microsoft's RAS service isn't fully compliant with the PPP standard(s). I want to scope some connections and compare the traces to illustrate to a class I'm teaching differing levels of compliance. Some questions: 1. Is it true Microsoft's implementation isn't fully complaint? 2. What specific types of config requests can I make to illustrate differences between Microsoft implementation and an implementation which is in complaince with the RFC's? 3. What vendors offer compliant implementations to contrast to the Microsoft implementation? 4. If Cisco isn't one of the fully compliant vendors (I have access to a Cisco-based network) I'd like to find a public rotary to dial into in order to negotiate a session for the trace. What's a public rotary I can dial to for this exercise (unless someone wants to offer their lab or private network!)? I have Windows 95, Windows NT, and Macintosh (MacPPP) clients I can use for the client. Do these clients implement the standards correctly? Thanks in advance for your help! - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 14:01:54 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA03141; Tue, 30 Sep 1997 14:01:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 13:59:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA03071 for ietf-ppp-outgoing; Tue, 30 Sep 1997 13:59:55 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-00.dialip.mich.net [141.211.7.136]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA03063 for ; Tue, 30 Sep 1997 13:59:48 -0400 (EDT) Date: Tue, 30 Sep 97 17:19:16 GMT From: "William Allen Simpson" Message-ID: <6597.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: Using default receive ACCM of 0 for LCP negotiation Sender: owner-ietf-ppp@merit.edu (sigh) Look, so many details are wrong in this message, I find it hard to know where to begin.... PPP was carefully designed to start with non-optimal performance, and negotiate towards improved performance. By definition, in this less optimal state, every packet gets thru successfully. It was deemed that it is better to have _some_ performance than _no_ performance. Now, look at the assumptions you made: > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > If a device is configured to attempt to negotiate the Rx ACCM to zero, > then if that configuration is correct, there will be no problems if the > ACCM is applied immediately instead of once LCP is open. > ... If the local device isn't > discarding these control characters then it may never receive the Nak, > but with sufficient retries this is unlikely, unless something injects > characters into every single frame. ... If the assumption is _incorrect_, then the peers never successfully negotiate. And thus, zero performance. A built-in failure mode! And of course, the second byte of a PPP header just happens to be 0x03, ETX, which just happens to hang up some modems. Every time. Retries don't help. When I say: > > This is evil (bogus, wrong, technically incorrect, however you want to > > label it). > > I r-e-a-l-l-y mean it! > > If this were a bit-stuffed ISDN sync interface, then of course, the > > ACCM is zero (0). See RFC-1662 page 14. > > As I've said before, saying that the ACCM for bit-stuffed ISDN is zero > is misleading. The ACCM simply doesn't apply to bit-stuffed ISDN. > Fascinating. Repetition somehow makes this statement correct? And how exactly does _your_ sync code work without handling the ACCM? When was the last time _you_ tested against an async-sync converter? > If you have a sync/async converting TA at one end of the ISDN link, then > the value that the async peer has to use as its TX ACCM could be anything > at all, and, depending upon the TA, it is this value that the ISDN peer is > negotiating as its RX ACCM. > No, it is not "anything at all". It is 0xffffffff, up to and until something else is negotiated. > > It will not work without arduous secondary processing (below). > > I think that would have been better phrased: "It will not work 100% > reliably in all situations without..." > I am only interested in 100% reliability. I certainly do not design protocols that have built-in failure modes! With this attitude, no wonder the lawyers are trying to change the Uniform Commercial Code so that they have no liability for software failure.... > > Have you actually implemented this? > > No, I haven't (I've followed the standard). > > > Has anyone actually implemented this? > > (I've no idea.) > > > Why not enforce correct standards compliant implementation? > > That would be very nice. Obviously, it's in the long-term interests of > everyone to enforce the standard, but there may be short-term economic > penalties for those refusing to interoperate with certain broken peers. > Some folks "just don't get it" (head buried in hands, weeping). WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 14:01:54 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA03143; Tue, 30 Sep 1997 14:01:50 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 13:59:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA03078 for ietf-ppp-outgoing; Tue, 30 Sep 1997 13:59:56 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-00.dialip.mich.net [141.211.7.136]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA03065 for ; Tue, 30 Sep 1997 13:59:50 -0400 (EDT) Date: Tue, 30 Sep 97 17:51:28 GMT From: "William Allen Simpson" Message-ID: <6598.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: ISDN and RFC-1618 and deprecation Sender: owner-ietf-ppp@merit.edu > From: John Shriver > I think we need to make "PPP over ISDN" admit all the disgusting > things people want to do. Certainly, it should point out that the > native encapsulation is best for many reasons. Perhaps it should even > point out what a PPP-conscious ISDN TA should do. (Maybe that > deserves a "best practices" RFC?) Sort of, here's the preferred > method, but if you're perverse, see the appendices. Then, a set of > appendices: > OK, what you say makes a lot of sense. I'll put together a draft in the next few days. Thanks, John. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 14:19:46 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA03495; Tue, 30 Sep 1997 14:19:45 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 14:18:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA03422 for ietf-ppp-outgoing; Tue, 30 Sep 1997 14:18:16 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA03417 for ; Tue, 30 Sep 1997 14:18:12 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1459.27) id ; Tue, 30 Sep 1997 11:18:12 -0700 Message-ID: From: Gurdeep Singh Pall To: ietf-ppp@merit.edu Subject: RE: MS ACCM considered harmful Date: Tue, 30 Sep 1997 10:41:48 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ietf-ppp@merit.edu Comments like the one below from Mr. Simpson undermine his intelligence and his credibility. He not only lives in the land of the greendragon but has also picked up an annoying habit of generating and spreading lies. I suggest to new members of this list (those unfamiliar with this individual) that they do not make any product decisions based on these lies. Also feel free to drop me a note if you encounter a bug in our PPP implementations. > -----Original Message----- > From: William Allen Simpson [SMTP:wsimpson@greendragon.com] > > Or, this makes it clear that folks at MS never tested against anything > but brand new V.34 modems. And MS has designed their PPP to be very > intolerant of robust implementations from other vendors. > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 21:56:36 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id VAA09587; Tue, 30 Sep 1997 21:53:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 21:52:08 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA09561 for ietf-ppp-outgoing; Tue, 30 Sep 1997 21:52:07 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-24.dialip.mich.net [141.211.7.160]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA09557 for ; Tue, 30 Sep 1997 21:52:03 -0400 (EDT) Date: Wed, 1 Oct 97 01:38:56 GMT From: "William Allen Simpson" Message-ID: <6605.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: MS ACCM considered harmful Sender: owner-ietf-ppp@merit.edu > From: Gurdeep Singh Pall > Date: Tue, 30 Sep 1997 10:41:48 -0700 > Comments like the one below from Mr. Simpson undermine his intelligence > and his credibility. He not only lives in the land of the greendragon > but has also picked up an annoying habit of generating and spreading > lies. I suggest to new members of this list (those unfamiliar with this > individual) that they do not make any product decisions based on these > lies. Also feel free to drop me a note if you encounter a bug in our PPP > implementations. > Wow, that seems to qualify as an "ad hominem" personal attack. Here are a few questions that I expect you to answer in public here on this list: (1) Does the transmit ACCM in 95 and NT4 default to 0xffffffff? (2) Does the receive ACCM in 95 and NT4 default to 0xffffffff? (3) Does the ACCM get reset to default on every LCP packet? (4) Exactly which modem models was the regression tested against? (5) Who is your immediate supervisor at MicroSoft? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 30 22:59:19 1997 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA10253; Tue, 30 Sep 1997 22:57:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 30 Sep 1997 22:57:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA10220 for ietf-ppp-outgoing; Tue, 30 Sep 1997 22:57:30 -0400 (EDT) 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 WAA10216 for ; Tue, 30 Sep 1997 22:57:26 -0400 (EDT) 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 WAA14579; Tue, 30 Sep 1997 22:56:50 -0400 (EDT) Message-ID: <3431BB9A.54F1@cisco.com> Date: Tue, 30 Sep 1997 22:55:23 -0400 From: Chip Sharp Reply-To: chsharp@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 3.0C-CISCOENG (Win95; I) MIME-Version: 1.0 To: William Allen Simpson CC: ietf-ppp@merit.edu Subject: Re: ISDN and RFC-1618 and deprecation References: <6589.wsimpson@greendragon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Perhaps if people don't understand "deprecated", we could provide big buttons that say "Just say no to V.120". V.110 and V.120 were designed circa 1985-1986 to support applications and protocols of the comm market of the early 1980's (remember Cterm, Smartcom, Xtalk, etc.?). We have moved beyond that now. There may be some marginal need for V.120 support in TAs to support old terminal emulation packages, but there is no need to burden PPP with this baggage. Yes it is probably possible to tweak V.120 in TAs to better support PPP, but the better thing to do would be to ditch it for asynch-to-synch ppp conversion. At least V.120 doesn't require special hardware like V.110 which seems to be alive and kicking in some GSM applications (yech). I would support removal of all mention of V.120 from the main text and move it to an appendix for deprecated protocols. Maybe we should deprecate PPP over Bisynch while we're at it. Chip (Editor of V.120 draft in T1D1.3 in 1986. Implemented it in AT&T TAs in 1986-87 and at Teleos. Never want to see it again. ;-) William Allen Simpson wrote: ...snip... > Be that as it may, V.120 was tested as one of the techniques for getting > PPP across ISDN. It was deprecated. Those poor souls who had V.120 TAs > in 1993 should have thrown them away long ago. > > We tested and argued about the best way to do ISDN in 3 IETF WGs over 4 > years. In the end, we discovered by actual testing and comparison that > several methods had inferior performance. V.120 was the worst, but was > closely followed by V.110 and BONDING. > ...snip... > > From: Archie Cobbs > > As I understand it, V.120 simply makes a synchronous link look asynchronous. > > So at TA that did V.120 wouldn't have to know or do anything about PPP. > > This could be an oversimplification though... can anyone confirm/deny? > > > Correct! > ...snip... > > *IMHO* it should say, "These days everybody does PPP over ISDN > > using the `PPP in HDLC-like framing' method, so you don't need > > to bother doing it any other way. If you're a terminal adapter, > > you should do sync-async conversion (eg. a la BitSURFR Pro, > > 3Com Impact IQ, et.al.) as described in this document, to get > > you to PPP in HDLC-like framing over the wire." > > > It _does_ say "you don't need to bother doing it any other way" (that's > what DEPRECATED means). > > I put the "good" and "bad" methods together in the same section for > "comparison". It would probably be better "standardese" to put the > deprecated techniques in Appendices, so that people will ignore them > when reading the main document. > > Now is a good time to update RFC-1618. If any other parts are > confusing, please let me know. ...snip... ------------------------------------------------------- Hascall H. ("Chip") Sharp voice: +1 (919) 851-2085 Consulting Engineer-ISP fax: +1 (919) 472-2177 Cisco Systems email: chsharp@cisco.com 7025 Kit Creek Road http://www.cisco.com/ Research Triangle Park, NC 27709-4987 USA --------------------------------------------------------- - - - - - - - - - - - - - - - - -