From list-admin Mon May 2 10:23:34 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA19670 for ; Mon, 2 May 1994 10:23:33 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05157; 2 May 94 10:15 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-dataencap-02.txt Date: Mon, 02 May 94 10:15:47 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9405021015.aa05157@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP LCP Option for Data Encapsulation Selection Author(s) : J. Halpern Filename : draft-ietf-pppext-dataencap-02.txt Pages : 6 Date : 04/29/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines a method for negotiating the encapsulation to be used for the transfer of data by PPP. It applies only to links for which there exists a "nominal" data encapsulation other than PPP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-dataencap-02.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-dataencap-02.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940429140200.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-dataencap-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-dataencap-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940429140200.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Tue May 3 02:47:18 1994 Received: from fwide.fujitsu.co.jp (fwide.fujitsu.co.jp [133.160.28.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id CAA03785 for ; Tue, 3 May 1994 02:47:04 -0400 From: shin@hodaka.mfd.cs.fujitsu.co.jp Received: from fdm.fujitsu.co.jp by fwide.fujitsu.co.jp (8.6.5+2.3W/3.2W4-MX/Fujitsu Mail Gateway) id PAA05787; Tue, 3 May 1994 15:45:01 +0900 Received: from [133.161.1.84] by fdm.fujitsu.co.jp (5.65/6.4J.6) id AA08914; Tue, 3 May 94 15:41:48 +0900 Received: from hodaka.mfd.cs.fujitsu.co.jp by mfdgw.mfd.cs.fujitsu.co.jp (5.67+1.6W[+alpha]/6.4J[+CSMX]) id AA05640; Tue, 3 May 94 15:41:46 JST Received: from shin (shin.ARPA) by hodaka.mfd.cs.fujitsu.co.jp (4.12/6.4J.5) id AA01020; Tue, 3 May 94 15:42:45 JST Date: Tue, 3 May 94 15:42:45 JST Message-Id: <9405030642.AA01020@hodaka.mfd.cs.fujitsu.co.jp> To: ietf-ppp@merit.edu Cc: tbradley@wellfleet.com Cc: cbrown@wellfleet.com Cc: malis_a@timeplex.com Reply-To: shin@hodaka.mfd.cs.fujitsu.co.jp Subject: iplpdn related spec confirmation X-Mailer: Harada's PC/M [v1.5] Hello. This message is IPLPDN related one. I send this message to PPP list because IPLPDN have already concluded and I can't know IPLPDN list address, and I think many IPLPDN members are also on this list. I would like to confirm some points of 2 IPLPDN related specs, RFC1490 & RFC1293, because a person in my company is implementing them, and waver in his interpretation of those points. Below are details. 1. the pad octet in RFC1490 In RFC1490, an optional pad octet is used for 2-octet boundary alignment. For example, a pad octet is added next to control field in the format of routed frames with Ethertypes. > Format of Routed Frames > with Ethertypes > > +-------------------------------+ > | Q.922 Address | > +---------------+---------------+ > |Control 0x03 | pad 0x00 | > +---------------+---------------+ > | NLPID 0x80 | OUI 0x00 | > +---------------+ --+ > | OUI 0x00-00 | > +-------------------------------+ > | Ethertype | > +-------------------------------+ > | Protocol Data | > +-------------------------------+ And no pad octet is added in the format of routed NLPID protocol. > Format of Routed NLPID Protocol > +-------------------------------+ > | Q.922 Address | > +---------------+---------------+ > |Control 0x03 | NLPID | > +---------------+---------------+ > | Protocol Data | > +-------------------------------+ Is the pad octet is mandated for alignment? , or is it implementation choice? If latter, is the following format permitted? and do we need to be able to receive this? Format of Routed Frames with Ethertypes +-------------------------------+ | Q.922 Address | +---------------+---------------+ |Control 0x03 | NLPID 0x80 | +---------------+---------------+ | OUI 0x00-00 | +-- +---------------+ | OUI 0x00 | Ethertype | +---------------+---------------+ | Ethertype | Protocol Data | +---------------+ + | | +-------------------------------+ 2. Multiprotocol format in RFC1293 There are some obscure points in RFC1293 about multiprotocol format. May be, IETF can not control these issue, but they are important for interoperation. I would like to know if interoperation is possible or not, so I am very much appreciated if anyone could give comments to my suggestion. At least, comments just like "we are same as your suggestion", or "we are not same as you" are very much helpful. 2.1 Protocol Type of IPX, AppleTalk, DECnet RFC1293 says, > Possible values for hardware and protocol types are the same as those > for ARP and may be found in the current Assigned Numbers RFC [2]. And Assigned Numbers(RFC1340) says, > Protocol Type (pro) > > Use the same codes as listed in the section called "Ethernet > Numbers of Interest" (all hardware types use this code set for > the protocol type). However IPX, AppleTalk, and DECnet has multiple Ethernet Type Values. The value which should be used is not clear. I suggest and believe that each reasonable value for them is, IPX=0x8137 AppleTalk=0x809B DECnet=0x6003 2.1 Protocol Address Length of IPX, XNS Protocol Address Length may not clear about IPX and XNS. I believe IPX and XNS has following network layer address format by their definition. Net. Num. = 4octet ; Node Num. = 6octet ; Socket Num. = 2octet However, Socket Number seems to be redundant for RFC1293 operation. I suggest and believe that each reasonable value for their Protocol Address Length is, IPX=10octet (Net. Num. = 4octet ; Node Num. = 6octet) XNS=10octet (Net. Num. = 4octet ; Node Num. = 6octet) And the format in the Source Protocol Address field or Target Protocol Address field is, +-------------------------------+ | Net. Num. | +-------------------------------+ | Net. Num. | +-------------------------------+ | Node Num. | +-------------------------------+ | Node Num. | +-------------------------------+ | Node Num. | +-------------------------------+ Regards, -- Yoshinobu Inoue shin@hodaka.mfd.cs.fujitsu.co.jp Architecture Department Network Division Open Systems Group Fujitsu Limited - - - - - - - - - - - - - - - - - From list-admin Tue May 3 12:07:37 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA18676 for ; Tue, 3 May 1994 12:07:35 -0400 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB13668; Tue, 3 May 94 09:06:46 PDT Message-Id: <9405031606.AB13668@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 May 1994 09:06:46 -0800 To: shin@hodaka.mfd.cs.fujitsu.co.jp From: fbaker@acc.com (Fred Baker) Subject: Re: iplpdn related spec confirmation Cc: cbrown@wellfleet.com, ietf-ppp@merit.edu >I would like to confirm some points of 2 IPLPDN related specs, RFC1490 & >RFC1293, because a person in my company is implementing them, and waver >in his interpretation of those points. Please note that 1490 obsolete's 1293: he should only be looking at 1293 for historical interest. >Below are details. > >1. the pad octet in RFC1490 > > In RFC1490, an optional pad octet is used for 2-octet boundary alignment. > For example, a pad octet is added next to control field in the format of > routed frames with Ethertypes. >Is the pad octet is mandated for alignment? , or is it implementation choice? >If latter, is the following format permitted? and do we need to be able to >receive this? You should always be prepared to receive a message with or without the pad, but I believe that you are to always transmit WITH the pad when necessary to acheive 16 bit alignment of the data field. 16 bit alignment of the frames makes a number of hardware implementations much happier. > However IPX, AppleTalk, and DECnet has multiple Ethernet Type Values. > The value which should be used is not clear. > I suggest and believe that each reasonable value for them is, > > IPX=0x8137 > AppleTalk=0x809B > DECnet=0x6003 These are the values you should be using. BTW, Apple uses their own OUI value on Ethernet, although the PID remains the Ethernet Packet Type. This has to do with some multi-media bridging translation problems. On Frame Relay, at least to my knowledge, all of the vendors are using 00-00-00 for the AppleTalk OUI just as they are with IPX and DECNET. >2.1 Protocol Address Length of IPX, XNS > > Protocol Address Length may not clear about IPX and XNS. > I believe IPX and XNS has following network layer address format by their > definition. > > Net. Num. = 4octet ; Node Num. = 6octet ; Socket Num. = 2octet > > However, Socket Number seems to be redundant for RFC1293 operation. > I suggest and believe that each reasonable value for their Protocol > Address Length is, > > IPX=10octet (Net. Num. = 4octet ; Node Num. = 6octet) > XNS=10octet (Net. Num. = 4octet ; Node Num. = 6octet) > > And the format in the Source Protocol Address field or Target Protocol > Address field is, You must be talking about the use of Inverse ARP here. If so, then I concur. What you describe gives you the IPX corrolary of IP's net and host numbers. If you are talking about munging the IPX header itself in some way, then we need to talk. ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Tue May 3 14:18:39 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA28256 for ; Tue, 3 May 1994 14:18:38 -0400 Received: from ftp.com by ftp.com ; Tue, 3 May 1994 14:18:37 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 3 May 1994 14:18:37 -0400 Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA06831; Tue, 3 May 94 14:17:23 EDT Date: Tue, 3 May 94 14:17:23 EDT Message-Id: <9405031817.AA06831@mailserv-D.ftp.com> To: ietf-ppp@merit.edu Subject: HDLC to full standard From: stev@ftp.com (stev knowles) Sender: stev@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Tue May 3 14:17:03 1994] Originating-Client: d-cell.ftp.com Content-Length: 1462 hello, campers. i am finally out from under the hill of stuff the falls on one when they are out of the office for several weeks. as such, i wish to bring you up to date on your output from the last few weeks: HDLC and LCP shoudl be entering the last call phase. i seem to have the information i need. at the WG meeting in Seattle, i told the group that the IESG expected to see one implementation with everying implemented in it. the idea was that this woudl tend to show up any race conditions that were possible. well, try as we might, neither the secretairiat nor myself have been able to find where this is documented. as such, it seems unreasonable to require it. everything in the RFC seems to have been implemented *somewhere*, so we will just go from there. draft-ietf-pppext-dataencap-02.txt Halpern draft-ietf-pppext-frame-relay-02.txt Simpson i have concerns about these two documents both going to proposed standard. i dont see that we are helping our industry by standardizing two distinct encapsulations of IP over frame relay. your comments woudl be appreciated. draft-ietf-pppext-netbios-fcp-04.txt Dimitri the minutes referenced this, but i havent seen anything . . . bridging and reliable are in the process right now, the last calls are (i blieve) completed, and i am writing up the ballots. your comments, or notes about implementations, for the write up i have to do woudl be appreciated. is there anything else? - - - - - - - - - - - - - - - - - From list-admin Wed May 4 10:38:13 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA15401 for ; Wed, 4 May 1994 10:38:13 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04401; 4 May 94 10:35 EDT To: IETF-Announce:; Cc: IESG cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: The Point-to-Point Protocol (PPP) to Standard Date: Wed, 04 May 94 10:35:07 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9405041035.aa04401@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "The Point-to-Point Protocol (PPP)" for the status of Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by May 17, 1994. IESG Secretary - - - - - - - - - - - - - - - - - From list-admin Wed May 4 10:38:32 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA15423 for ; Wed, 4 May 1994 10:38:31 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04480; 4 May 94 10:36 EDT To: IETF-Announce:; Cc: IESG cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: PPP in HDLC-like Framing to Standard Date: Wed, 04 May 94 10:36:15 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9405041036.aa04480@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "PPP in HDLC-like Framing" for the status of Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by May 17, 1994. IESG Secretary - - - - - - - - - - - - - - - - - From list-admin Thu May 5 06:26:11 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id GAA04742 for ; Thu, 5 May 1994 06:26:10 -0400 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB11416; Thu, 5 May 94 03:26:03 PDT Date: Thu, 5 May 94 03:26:03 PDT Message-Id: <9405051026.AB11416@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: Re: PPP Minutes Cc: stev knowles , topolcic@bbn.com >>>draft-ietf-pppext-dataencap-02.txt Halpern >>>draft-ietf-pppext-frame-relay-03.txt Simpson Last call: two weeks and I ship these to the IESG, barring substantive comment ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Thu May 5 13:02:32 1994 Received: from Shiva.COM (Shiva.COM [192.80.57.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA03701 for ; Thu, 5 May 1994 13:02:30 -0400 Received: by Shiva.COM (1.34b) Thu, 5 May 94 13:02:27 EDT Date: Thu, 5 May 94 13:02:27 EDT From: John Gregg Message-Id: <9405051702.AA23881@Shiva.COM> To: ietf-ppp@merit.edu, jgregg@Shiva.COM, tommyd@microsoft.com Subject: Questions about NBFCP I am implementing NBFCP and have some questions about the current draft of the spec (draft-ietf-pppext-netbios-fcp-04.txt). 1) page 4 - In spite of what the spec says, ("There exists [sic] at least four different MAC header implementations for NBF packets: 802.3 Ethernet, 802.5 Token-Ring, DIX Ethernet, and FDDI.") there is no DIX Ethernet encapsulation of NBF packets, is there? I could find no NBF ethertype value in the assigned numbers RFC. May I assume, then, that in the ethernet and token ring worlds the data field shown in the picture on page 12 begins with ? 2) page 4 -I don't understand why if I negotiate "MAC addresses required" I have to be able to receive NBF packets 12 bytes bigger than my LCP-negotiated MRU. When I negotiate my MRU, am I not saying "Please don't try to send me any packet on this link bigger than *this*."? Shouldn't my peer honor that, no matter what is in the packet, whether higher level data, prepended MAC addresses, or PPP header bytes? I negotiate an MRU of the biggest packet my machine's buffers can accommodate. I can't accept packets 12 bytes larger than that. It seems a waste to negotiate an LCP MRU of 12 bytes less than my actual maximum buffer size just so if/when I open an NBF connection, they'll fit, MAC addresses and all. 3) page 10 - Why are two bytes devoted to the multicast forward period field in the multicast filtering option if the maximum allowable value is 60? 4) pages 10-11: the priority field in the multicast filtering option is shown in the picture as being one octet, and the length of the whole option is given as 5, which also suggests that it is one octet, but the text description of the priority field says that it is two octets. One octet seems like enough since this is a boolean value. 5) I don't quite understand the multicast filtering option in general. Does this assume that some implementations will hold onto multicasts until there are no directed NBF packets to deliver, in which case the forwarding period says how long such implementations will hang onto these multicasts before giving up and dropping them, or am I missing something? The first paragraph of the description of this option is a bit awkward (page 9). Thanks in advance for any answers any of you can give me. -John Gregg Shiva Corporation (617) 270-8495 - - - - - - - - - - - - - - - - - From list-admin Thu May 5 14:33:24 1994 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA11124 for ; Thu, 5 May 1994 14:33:23 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA05432; Thu, 5 May 94 10:34:46 -0700 Message-Id: <9405051734.AA05432@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 05 May 94 10:34:46 PDT X-Msmail-Message-Id: 2F7F147F X-Msmail-Conversation-Id: 2F7F147F From: Thomas Dimitri To: ietf-ppp@merit.edu, jgregg@shiva.com Date: Thu, 5 May 94 11:30:35 TZ Subject: RE: Questions about NBFCP Before I answer John's questions, just a brief note to all those who actually care about NBFCP. I made a mistake in the drafts. I put down 0039 and 8039 as the protocol numbers for NBFCP. It is in fact 003f and 803f as was assigned by IANA. My apologies. This will be corrected in the soon to be updated NBFCP draft. | From: John Gregg | | I am implementing NBFCP and have some questions about the current | draft of the spec (draft-ietf-pppext-netbios-fcp-04.txt). | | 1) page 4 - In spite of what the spec says, ("There exists [sic] at least four | different MAC header implementations for NBF packets: 802.3 Ethernet, | 802.5 Token-Ring, DIX Ethernet, and FDDI.") there is no DIX Ethernet | encapsulation of NBF packets, is there? I could find no NBF ethertype value | in the assigned numbers RFC. May I assume, then, that in the ethernet and | token ring worlds the data field shown in the picture on page 12 begins with | ? DIX Ethernet types is 0x80D5 (IBM SNA I believe). I believe the length field comes immediately after the type field, then DSAP, SSAP, etc. (i.e. the LPDU). It is very rare to find this sort of LAN in existence. | 2) page 4 -I don't understand why if I negotiate "MAC addresses required" I | have to be able to receive NBF packets 12 bytes bigger than my LCP-negotiated | MRU. When I negotiate my MRU, am I not saying "Please don't try to send me any | packet on this link bigger than *this*."? Shouldn't my peer honor that, no | matter what is in the packet, whether higher level data, prepended MAC | addresses, or PPP header bytes? I negotiate an MRU of the biggest packet | my machine's buffers can accommodate. I can't accept packets 12 bytes larger | than that. It seems a waste to negotiate an LCP MRU of 12 bytes less than my | actual maximum buffer size just so if/when I open an NBF connection, they'll | fit, MAC addresses and all. Ok , here's the problem. If a 12 byte IEEE address gets negotiated (and remember this was put in for Shiva), then the data field automagically consumes 12 more bytes, but the transport (NetBEUI) still send 1500 bytes of data. Hence, 12 + 1500 = 1512 (which is ooops! too big). Needless to say, this is a bit of a problem because the LAN side will be transmitting ethernet frames (we'll use ethernet as our example) and it will have 1500 bytes in the data field and will also have a 12 byte IEEE address. So when the Shiva box (we'll use Shiva in this example, I hope you don't mind), attempts to bridge that packet it CANNOT if it can only send 1500 bytes in the PPP data field but it needs to send 1512!!! Also, you CANNOT fragment the frame if you are a bridge (you can if you are a NetBIOS gateway). SO basically, you are screwed (i.e. you WILL not work unless both implementation accept 1512). The other option is to negotiate 1512 as the MRU. But technically, this allows NetBEUI to send 1512 data which won't work when being shipped on the LAN. So then we could say that NetBEUI is fixed to 1500 of data always but that doesn't seems very clean either. Also, LCP doesn't have to accept higher than 1500. Furthermore, many other network protocols *like* 1500 as the data size (they could work with other frame sizes, but every vendor at the bakeoff I saw *liked* 1500). So, what happens if I dial-in an the PPP box rejects 1512 as the MRU. Well, then we back off to 1500 and we cannot do NBFCP if we want the 12 byte IEEE address. Yuck. And what if I want IP, IPX, and NBFCP? Then I try to negotiate a 1512 MRU for IP and IPX just to get my NBFCP to work.... hmmm, sounds like trouble. So instead of trying to negotiate 1512 as the MRU and dealing with a potential slew of interoperability problems, it was much easier to say accept PPP packets 12 bytes larger than the MRU negotiated if you negotiate the 12 byte IEEE address. This way, things work. Believe me, any other path I can think of would be much more of a hassle. I'll answer the multicast stuff later. --Thomas - - - - - - - - - - - - - - - - - From list-admin Thu May 5 15:39:07 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA17281 for ; Thu, 5 May 1994 15:39:06 -0400 Received: by ftp.com ; Thu, 5 May 1994 15:39:01 -0400 Received: by ftp.com ; Thu, 5 May 1994 15:39:01 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405051939.AA17462@ftp.com> Subject: Re: Questions about NBFCP To: tommyd@microsoft.com (Thomas Dimitri) Date: Thu, 5 May 1994 15:39:00 -0400 (EDT) Cc: ietf-ppp@merit.edu, jgregg@shiva.com In-Reply-To: <9405051734.AA05432@netmail2.microsoft.com> from "Thomas Dimitri" at May 5, 94 11:30:35 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2156 >> The other option is to negotiate 1512 as the MRU. But technically, >> this allows NetBEUI to send 1512 data which won't work when being >> shipped on the LAN. I must be missing something fundamental here (since I don't know NetBEUI). If I negotiate to run NBFCP with 12 bytes of header and an MRU of 1512, NetBEUI is only allowed to send 1500 bytes. So where is the problem? Is it that NetBEUI cannot be notified of what size packets to send? Why does doing the math and notifying NetBEUI seem so difficult? >> Also, LCP doesn't have to accept higher than 1500. Furthermore, many >> other network protocols *like* 1500 as the data size (they could work >> with other frame sizes, but every vendor at the bakeoff I saw *liked* >> 1500). So, what happens if I dial-in an the PPP box rejects 1512 as >> the MRU. You either do 1488 byte NetBEUI or don't negotiate to do the 12 byte header. I'm sorry, but this may seem like a major issue to you, but I don't think we should break a near standard specification for one special case. What about if you're running it over Token Ring with source routing? Will we all have to be ready to accept 20k packets just to make NetBEUI happy? >> Well, then we back off to 1500 and we cannot do NBFCP if we want >> the 12 byte IEEE address. Yuck. At least you'd be playing by the rules. >> So instead of trying to negotiate 1512 as the MRU and dealing >> with a potential slew of interoperability problems, it was much easier >> to say accept PPP packets 12 bytes larger than the MRU negotiated >> if you negotiate the 12 byte IEEE address. This way, things work. Well, if you want to throw the definition of MRU out the window, then it works. Me, I like standards that stay standard. If you have a special case (as this sounds like), you should find a way to work around it within your own arena. -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; "i am the bullet in the gun / i am the truth from which you run i am the silencing machine / i am the end of all your dreams" - NIN - - - - - - - - - - - - - - - - - From list-admin Thu May 5 16:38:21 1994 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA22196 for ; Thu, 5 May 1994 16:38:20 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA11249; Thu, 5 May 94 12:39:42 -0700 Message-Id: <9405051939.AA11249@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Thu, 05 May 94 12:39:41 PDT X-Msmail-Message-Id: 55300325 X-Msmail-Conversation-Id: 55300325 From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Thu, 5 May 94 13:35:30 TZ Subject: Re: Questions about NBFCP | >> Also, LCP doesn't have to accept higher than 1500. Furthermore, many | >> other network protocols *like* 1500 as the data size (they could work | >> with other frame sizes, but every vendor at the bakeoff I saw *liked* | >> 1500). So, what happens if I dial-in an the PPP box rejects 1512 as | >> the MRU. | | You either do 1488 byte NetBEUI or don't negotiate to do the 12 byte | header. I'm sorry, but this may seem like a major issue to you, but | I don't think we should break a near standard specification for one | special case. What about if you're running it over Token Ring with | source routing? Will we all have to be ready to accept 20k packets | just to make NetBEUI happy? You can't do 1488 NetBEUI because the LAN side will do 1500 byte NetBEUI so how do you bridge the LAN packets to the PPP client when you need to send a 1512 packet? The only way to do it is that you MUST negotiate a 1512 MRU *or* accept a 1512 MRU. I do not see any other options. | | >> Well, then we back off to 1500 and we cannot do NBFCP if we want | >> the 12 byte IEEE address. Yuck. | | At least you'd be playing by the rules. | | >> So instead of trying to negotiate 1512 as the MRU and dealing | >> with a potential slew of interoperability problems, it was much easier | >> to say accept PPP packets 12 bytes larger than the MRU negotiated | >> if you negotiate the 12 byte IEEE address. This way, things work. | | Well, if you want to throw the definition of MRU out the window, then | it works. Me, I like standards that stay standard. If you have a | special case (as this sounds like), you should find a way to work | around it within your own arena. Forcing a 1512 MRU will be problems when trying to negotiate with boxes because (As far as I know) the majority of PPP implementations do 1500 and don't go any higher. It it much easier to say that... hey, if you NBCP and you support this 12 byte IEEE address thing, just accept those PPP NBF packets with a 1512 data field. Really, is it that hard to do? If you have a simpler solution please offer it. I do not think trying to neogtiate a 1512 MRU is a simpler solution because that 1512 affects all PPP data shipped (from the CPs to the network layers). The other problem is that it is unknown apriori whether or not the other peer wants the 12 byte IEEE address (or even supports NBFCP). So you could negotiate it and not use it. But then by definition that would mean the other end would be technically allowed to send 1512 in the data field which would be a problem because you couldn't ship a 1512 on the LAN side. The way I think it should be done is that if you want this 12 byte address stuck on the beginning the data field (which in my mind, is already a hack because the data field no longer contains just network data) then you are agreeing to accepting a 1512 byte data field for NBF PPP data packets (if you are going to do a hack you might as well take another hack). To me, that is simple and voids potential interoperability problems as well as more complex mechanisms (i.e. what if 1512 MRU fails to negotiate? What if IPX or Appletalk has a 1512 MRU?). As I said before, the only other option I can see is to always try and negotiate a 1512 MRU. To me, that just doesn't sound like a fun exercise. --Thomas - - - - - - - - - - - - - - - - - From list-admin Thu May 5 16:54:45 1994 Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA23643 for ; Thu, 5 May 1994 16:54:40 -0400 Received: from port14.boston.ma.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA14330 for ietf-ppp@merit.edu; Thu, 5 May 94 16:53:57 -0400 Received: from uu9.psi.com by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA08195 for worley; Thu, 5 May 94 16:25:04 -0400 Received: from merit.edu by uu9.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA28552 for ken@funk.com; Thu, 5 May 94 16:06:01 -0400 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA17281 for ; Thu, 5 May 1994 15:39:06 -0400 Received: by ftp.com ; Thu, 5 May 1994 15:39:01 -0400 Received: by ftp.com ; Thu, 5 May 1994 15:39:01 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405051939.AA17462@ftp.com> Subject: Re: Questions about NBFCP To: tommyd@microsoft.com (Thomas Dimitri) Date: Thu, 5 May 1994 15:39:00 -0400 (EDT) Cc: ietf-ppp@merit.edu, jgregg@shiva.com In-Reply-To: <9405051734.AA05432@netmail2.microsoft.com> from "Thomas Dimitri" at May 5, 94 11:30:35 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2156 >> The other option is to negotiate 1512 as the MRU. But technically, >> this allows NetBEUI to send 1512 data which won't work when being >> shipped on the LAN. I must be missing something fundamental here (since I don't know NetBEUI). If I negotiate to run NBFCP with 12 bytes of header and an MRU of 1512, NetBEUI is only allowed to send 1500 bytes. So where is the problem? Is it that NetBEUI cannot be notified of what size packets to send? Why does doing the math and notifying NetBEUI seem so difficult? >> Also, LCP doesn't have to accept higher than 1500. Furthermore, many >> other network protocols *like* 1500 as the data size (they could work >> with other frame sizes, but every vendor at the bakeoff I saw *liked* >> 1500). So, what happens if I dial-in an the PPP box rejects 1512 as >> the MRU. You either do 1488 byte NetBEUI or don't negotiate to do the 12 byte header. I'm sorry, but this may seem like a major issue to you, but I don't think we should break a near standard specification for one special case. What about if you're running it over Token Ring with source routing? Will we all have to be ready to accept 20k packets just to make NetBEUI happy? >> Well, then we back off to 1500 and we cannot do NBFCP if we want >> the 12 byte IEEE address. Yuck. At least you'd be playing by the rules. >> So instead of trying to negotiate 1512 as the MRU and dealing >> with a potential slew of interoperability problems, it was much easier >> to say accept PPP packets 12 bytes larger than the MRU negotiated >> if you negotiate the 12 byte IEEE address. This way, things work. Well, if you want to throw the definition of MRU out the window, then it works. Me, I like standards that stay standard. If you have a special case (as this sounds like), you should find a way to work around it within your own arena. -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; "i am the bullet in the gun / i am the truth from which you run i am the silencing machine / i am the end of all your dreams" - NIN - - - - - - - - - - - - - - - - - From list-admin Thu May 5 18:54:09 1994 Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA02239 for ; Thu, 5 May 1994 18:54:08 -0400 Received: by ftp.com ; Thu, 5 May 1994 18:54:03 -0400 Received: by ftp.com ; Thu, 5 May 1994 18:54:03 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405052254.AA23396@ftp.com> Subject: Re: Questions about NBFCP To: tommyd@microsoft.com (Thomas Dimitri) Date: Thu, 5 May 1994 18:54:02 -0400 (EDT) Cc: ietf-ppp@merit.edu In-Reply-To: <9405051939.AA11249@netmail2.microsoft.com> from "Thomas Dimitri" at May 5, 94 01:35:30 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1567 >> The only way to do it is that you MUST negotiate a 1512 >> MRU *or* accept a 1512 MRU. I do not see any other options. Or you could not take Ethernet headers. Then you have 1500 everywhere. It seems simple to me. Negotiate 1512. If that fails, don't take the headers. If you think negotiating 1512 is going to be a problem, then don't do it. I realize it's a very difficult decision. I'm just saying that breaking the spec for a special case is not such a good idea. >> Forcing a 1512 MRU will be problems when trying to negotiate >> with boxes because (As far as I know) the majority of PPP implementations >> do 1500 and don't go any higher. This is true, but there are not many boxes doing NBFCP yet. I don't know of anyone except Microsoft that currently does it. So, your implementation can do 1512 ... you could certainly put language in the DOC stating that if you want the headers, be prepared to send and receive an MRU of 1512 through negotiation. Straw man: What if a box is on the market that only supports 1500 byte MTUs? Perhaps they are limited in some way by hardware. Now this box wants to do NBFCP. But they can't, because they don't do 1512 byte packets (at least, they can't if they want the headers). What should this box do? -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; "i am the bullet in the gun / i am the truth from which you run i am the silencing machine / i am the end of all your dreams" - NIN - - - - - - - - - - - - - - - - - From list-admin Fri May 6 02:08:06 1994 Received: from sirius.anu.edu.au (sirius.anu.edu.au [150.203.23.88]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id CAA25481 for ; Fri, 6 May 1994 02:08:03 -0400 Received: (from paulus@localhost) by sirius.anu.edu.au (8.6.9/8.6.9) id QAA14061; Fri, 6 May 1994 16:07:58 +1000 Date: Fri, 6 May 1994 16:07:58 +1000 From: Paul Mackerras Message-Id: <199405060607.QAA14061@sirius.anu.edu.au> To: ietf-ppp@merit.edu Subject: PPP option automaton Cc: paulus@cs.anu.edu.au It seems to me that there is a problem with the definition of the "passive" option for the option negotiation automaton as defined in RFC 1548. Specifically, the tlf action (this layer finished) doesn't get invoked if the automaton times out waiting for a response to Conf-reqs, and then a Close event occurs. Without the passive option, a Close event will ultimately generate a tlf action if it (the Close) occurs in any state except Initial, Starting, Closed or Stopped. In Initial and Starting states, the lower layer isn't up so you don't expect a tlf action. And all transitions into Closed or Stopped state from any of Closing through to Opened states has a tlf action. So there is an invariant that once you have started trying to negotiate, you will get a tlf action eventually (when negotiation fails, a Close event occurs, or the other side terminates the link). With the passive option, a timeout (TO- event) in Req-Sent state goes to Stopped state without causing a tlf event. This breaks the invariant - in Stopped state, it is assumed that there a tlf action has already been done. In the ppp daemon that I'm maintaining, I use the tlf action on the LCP automaton to indicate that the link is finished and the daemon should exit. Receipt of a SIGKILL signal causes a Close event on LCP, which ultimately causes the daemon to exit... unless you're using the passive option. I think that the invariant should be maintained, even with the passive option, because the tlf action is the clearest indication that the link is finished. An easy fix is to add the tlf action to the action for the Close event in the Stopped state if the passive option is enabled. This could possibly lead to the tlf action being initiated twice (e.g. if you get a RTA event in Stopping state followed by a Close event). If this is a problem, then a new state would have to be defined. Paul Mackerras Dept. of Computer Science Australian National University - - - - - - - - - - - - - - - - - From list-admin Fri May 6 09:19:20 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA20723 for ; Fri, 6 May 1994 09:19:19 -0400 Received: by ftp.com ; Fri, 6 May 1994 09:19:15 -0400 Received: by ftp.com ; Fri, 6 May 1994 09:19:15 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405061319.AA16003@ftp.com> Subject: Re: Questions about NBFCP To: wilson@ftp.com (Brad Wilson) Date: Fri, 6 May 1994 09:19:15 -0400 (EDT) Cc: tommyd@microsoft.com, ietf-ppp@merit.edu In-Reply-To: <9405052254.AA23396@ftp.com> from "Brad Wilson" at May 5, 94 06:54:02 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 930 >> Or you could not take Ethernet headers. Then you have 1500 everywhere. >> It seems simple to me. Negotiate 1512. If that fails, don't take the >> headers. If you think negotiating 1512 is going to be a problem, then >> don't do it. Actually, a better solution occured to me last night. Since PPP is the king of negotiation ;-), why don't you negotiate the "over-sized packet" option? If negotiated, you are willing to accept packets up to "MRU + Hardware Header Size". At least then the default will be upholding the PPP rules, and a negotiation can be used in your special case (an NBFCP negotiation). How about that? -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; "i am the bullet in the gun / i am the truth from which you run i am the silencing machine / i am the end of all your dreams" - NIN - - - - - - - - - - - - - - - - - From list-admin Fri May 6 14:17:28 1994 Received: from pm002-25.dialip.mich.net (pm002-25.dialip.mich.net [35.1.48.106]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA18121 for ; Fri, 6 May 1994 14:17:25 -0400 Date: Fri, 6 May 94 16:54:03 GMT From: "William Allen Simpson" Message-ID: <2335.bill.simpson@um.cc.umich.edu> To: Paul Mackerras Cc: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: PPP Passive FSA option Thank you for your review during this last call period. > In the ppp daemon that I'm maintaining, I use the tlf action on the > LCP automaton to indicate that the link is finished and the daemon > should exit. Receipt of a SIGKILL signal causes a Close event on LCP, > which ultimately causes the daemon to exit... unless you're using the > passive option. > This seems like a very reasonable thing to do. But you apparently have conflicting desires. Remember, the tlf is (like all parts of the FSA) used for LCP and all of the NCPs. The Passive option has to function the same for all of them. The Passive option _means_ that the link doesn't go away. It waits passively. It will wait passively in the Closed state, too. This is a historically desired feature. It makes sense only on certain kinds of links. > I think that the invariant should be maintained, even with the passive > option, because the tlf action is the clearest indication that the link > is finished. An easy fix is to add the tlf action to the action for the > Close event in the Stopped state if the passive option is enabled. > This could possibly lead to the tlf action being initiated twice > (e.g. if you get a RTA event in Stopping state followed by a Close > event). But this wouldn't make any sense in the NCP (or to other kinds of embedded system LCP). For one thing, in the Closed state, it is supposed to sit there and send RTA in response to RCR. That won't happen with your "fix". Instead, you'll get a black hole. For your case, I suggest that the fix is in your SIGKILL, which would check your "passive" flag, and issue the tlf function when it is true. As it says: "This results of this action are highly implementation dependent." > If this is a problem, then a new state would have to be > defined. > Such major changes to PPP are not warranted. It has been widely fielded, and shown to work well. Any changes must be completely backwardly compatible. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Fri May 6 18:55:08 1994 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA11382 for ; Fri, 6 May 1994 18:55:06 -0400 Received: by netmail2.microsoft.com (5.65/25-eef) id AA23730; Fri, 6 May 94 14:56:36 -0700 Message-Id: <9405062156.AA23730@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Fri, 06 May 94 14:56:36 PDT X-Msmail-Message-Id: 450A9424 X-Msmail-Conversation-Id: 450A9424 From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Fri, 6 May 94 15:52:25 TZ Subject: Re: Questions about NBFCP | Actually, a better solution occured to me last night. Since PPP is the | king of negotiation ;-), why don't you negotiate the "over-sized | packet" option? If negotiated, you are willing to accept packets up | to "MRU + Hardware Header Size". At least then the default will be | upholding the PPP rules, and a negotiation can be used in your special | case (an NBFCP negotiation). | | How about that? Are you suggesting another LCP option? I'd rather just leave it as it stands and not do that. Basically, by successfully negotiating the 12 byte IEEE address option, you are agreeing to the "over-sized packet" option as you put it. I don't think the 12 byte IEEE address is very important and will hardly ever be used in the future. Whatever can be done to ensure it doesn't complicate other parts of PPP (like LCP) is probably in everyone's best interest. --Thomas - - - - - - - - - - - - - - - - - From list-admin Sat May 7 14:58:40 1994 Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA10481 for ; Sat, 7 May 1994 14:58:40 -0400 Received: by ftp.com ; Sat, 7 May 1994 14:58:38 -0400 Received: by ftp.com ; Sat, 7 May 1994 14:58:38 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405071858.AA08786@ftp.com> Subject: Re: Questions about NBFCP To: tommyd@microsoft.com (Thomas Dimitri) Date: Sat, 7 May 1994 14:58:38 -0400 (EDT) Cc: ietf-ppp@merit.edu In-Reply-To: <9405062156.AA23730@netmail2.microsoft.com> from "Thomas Dimitri" at May 6, 94 03:52:25 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 565 >> Are you suggesting another LCP option? After an hour long conversation with your esteemed colleague (Andy Nicholson), who gave me the background behind this ... I will concede that -- given the facts presented to me -- breaking the spec is the best thing to do. -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; "i am the bullet in the gun / i am the truth from which you run i am the silencing machine / i am the end of all your dreams" - NIN - - - - - - - - - - - - - - - - - From list-admin Mon May 9 10:11:15 1994 Received: from adtrn722.adtran.com ([198.51.35.247]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA04218 for ; Mon, 9 May 1994 10:11:08 -0400 Message-Id: <199405091411.KAA04218@merit.edu> Received: by adtrn722.adtran.com (1.37.109.4/16.2) id AA27114; Mon, 9 May 94 09:03:41 -0500 From: Kevin Schneider Subject: Re: Stacker LZS Protocol To: ietf-ppp@merit.edu Date: Mon, 9 May 94 9:03:40 CDT In-Reply-To: <9404272040.AA19312@gefilte.MorningStar.Com>; from "Karl Fox" at Apr 27, 94 4:40 pm Mailer: Elm [revision: 70.85] Karl Fox writes: > > Since I'm pretty sure that we (Morning Star Technologies) have the > only existing implementation, there's no need to try to be backward > compatible. > Does anyone else have an implementation of the Stacker LZS compression under PPP? Does anyone care if the encapsulation format is changed and backward compatibility is not retained? If not, I will proceed to write up Stuart's suggested changes into the Stacker LZS document upon Bob Lutz approval. -- Kevin Schneider Phone: (205) 971-8024 ADTRAN, Inc. FAX: (205) 971-8751 901 Explorer Blvd. Huntsville, AL 35806-2807 email: kevin@adtran.com - - - - - - - - - - - - - - - - - From list-admin Mon May 9 12:38:11 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA17751 for ; Mon, 9 May 1994 12:38:10 -0400 Received: from drawbridge (via drawbridge.ascend.com) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwpdy24958; Mon, 9 May 94 12:38:08 -0400 Received: from spud.Ascend.COM by drawbridge (4.1/SMI-4.1/Drawbridge-GCA-930913-1) id AA04246; Mon, 9 May 94 09:39:08 PDT Received: from dumbcat.sf.ca.us (dumbcat.sf.ca.us.) by spud.Ascend.COM (4.1/Ascend-ext-931229) id AA16837; Mon, 9 May 94 09:38:20 PDT Received: from localhost by dumbcat.sf.ca.us (4.1/smail-24May90) id AA03799; Mon, 9 May 94 09:37:25 PDT To: Kevin Schneider Cc: ietf-ppp@merit.edu Subject: Re: Stacker LZS Protocol In-Reply-To: Your message of "Mon, 09 May 1994 09:03:40 CDT." <199405091411.KAA04218@merit.edu> Date: Mon, 09 May 1994 09:37:12 -0700 Message-Id: <3792.768501432@dumbcat.sf.ca.us> From: Marco S Hyman Kevin Schneider writes: > Karl Fox writes: > > > > Since I'm pretty sure that we (Morning Star Technologies) have the > > only existing implementation, there's no need to try to be backward > > compatible. > > > > Does anyone else have an implementation of the Stacker LZS compression > under PPP? Yes, Recent versions of the Ascend Pipeline use the Stac code. Backward compatibility is important to us. // marc - - - - - - - - - - - - - - - - - From list-admin Mon May 9 13:01:13 1994 Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA19935 for ; Mon, 9 May 1994 13:01:05 -0400 Received: from gefilte.MorningStar.Com by volitans.MorningStar.Com (5.65a/94040804) id AA29678; Mon, 9 May 94 13:00:09 -0400 From: Karl Fox Received: by gefilte.MorningStar.Com (5.65a/94012401) id AA13887; Mon, 9 May 94 13:00:07 -0400 Date: Mon, 9 May 94 13:00:07 -0400 Message-Id: <9405091700.AA13887@gefilte.MorningStar.Com> To: Marco S Hyman Cc: Kevin Schneider , ietf-ppp@merit.edu Subject: Re: Stacker LZS Protocol In-Reply-To: <3792.768501432@dumbcat.sf.ca.us> References: <199405091411.KAA04218@merit.edu> <3792.768501432@dumbcat.sf.ca.us> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Please, let's make simplicity a higher priority that backward compatibility. I have existing code as well, but the existing draft is too ambiguous to guarantee interoperability and has features that have been demonstrated to be unnecessary. It would be preferable for future implementors and we would be taking the moral high ground if we don't restrict ourselves to following the old format. Let's make it as clean as possible, please. Marco S Hyman writes: > Kevin Schneider writes: > > Karl Fox writes: > > > > > > Since I'm pretty sure that we (Morning Star Technologies) have the > > > only existing implementation, there's no need to try to be backward > > > compatible. > > > > > > > Does anyone else have an implementation of the Stacker LZS compression > > under PPP? > > Yes, Recent versions of the Ascend Pipeline use the Stac code. > Backward compatibility is important to us. > > // marc - - - - - - - - - - - - - - - - - From list-admin Mon May 9 14:20:00 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA26822 for ; Mon, 9 May 1994 14:19:59 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21411; 9 May 94 13:50 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-bsd-compress-01.txt Date: Mon, 09 May 94 13:50:12 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9405091350.aa21411@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : PPP BSD Compression Protocol Author(s) : V. Schryver Filename : draft-ietf-pppext-bsd-compress-01.txt Pages : 26 Date : 05/06/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-bsd-compress-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-bsd-compress-01.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940506134006.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-bsd-compress-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bsd-compress-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940506134006.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Mon May 9 15:13:23 1994 Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.130.2]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id PAA01767 for ; Mon, 9 May 1994 15:13:22 -0400 Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.9.Beta4/8.6.9.Beta0) id MAA26296; Mon, 9 May 1994 12:11:49 -0700 Date: Mon, 9 May 1994 12:11:49 -0700 From: Keith Sklower Message-Id: <199405091911.MAA26296@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: this time fer shure (Yet Another Multilink Draft) Cc: fbaker@acc.com This version fixes a few typos, and has the buffering requirements section rewritten as guidelines. I believe this draft is worthy of submission to the IESG and is last-callable. You can get it from vangogh.cs.berkeley.edu:~ftp/pub/ppp-iplpdn/draft-ietf-pppext-multilink-09.txt The version there includes change bars; I will remove the change bars before filing it with internet-drafts. Other than identifying typos, there were 3 substantive comments made on the draft (and despite my genuine encouragement the commentors did not see fit to forward these to the group): 1.) There was a complaint that the multilink protocol was being handle in a privileged way so that it was neither a network protocol nor an LCP extension and the language in the draft was misleading. The commentor did not provide alternative language. Several rounds of mail was exchanged between him, Brian Lloyd and myself. 2.) There was a suggestion that the multilink protocol was incomplete because there was no mechanism in the draft provided for requesting additional member links to be established. The commentor felt strongly that since in a modular environment, the multilink machine might be uniquely able to judge the utilization of the links and the incoming demand, that such requests be issued at the multilink layer, rather than using any other mechanism (such as SNMP). (SNMP was also excluded because there was no guarantee of any particular network level protocol to run it over). My response was that this could be an upwards compatible extension and the draft should not be delayed while this was discussed. I mentioned that somebody else had proposed an LCP call-back request for security reasons which could be adapted to this purpose. 3.) There was dismay expressed that the .8 draft combined the end-point identifier and other independent multilink related parameters as a single LCP option which needed to be parsed as sub-options rather than breaking them apart as separate LCP options. However, the comment specifically did not want to delay forwarding the draft by provoking a lengthy discussion on the topic. On the other hand, I would certainly not mind a "show of hands around the net". - - - - - - - - - - - - - - - - - From list-admin Mon May 9 15:30:27 1994 Received: from ucdavis.ucdavis.edu ([128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id PAA02995 for ; Mon, 9 May 1994 15:30:25 -0400 Received: from ctron.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id MAA21336; Mon, 9 May 1994 12:16:12 -0700 Received: from stealth.ctron.com by ctron.com (4.1/SMI-4.1) id AA08237; Mon, 9 May 94 15:15:23 EDT Received: from express.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA28091; Mon, 9 May 94 15:15:14 EDT Received: from atm-at1.ctron by express.ctron.com (4.1/SMI-4.1) id AA22192; Mon, 9 May 94 15:13:45 EDT Date: Mon, 9 May 94 15:13:44 EDT From: wilder@express.ctron.com (David L. Wilder) Message-Id: <9405091913.AA22192@express.ctron.com> To: ietf-ppp@ucdavis.edu Subject: PPP Is there a basic overview of what PPP is and what it can do for me? I am especially interested in the PPP Link & PPP Bridge groups. Dave Wilder wilder@ctron.com Cabletron Systems Inc. - - - - - - - - - - - - - - - - - From list-admin Mon May 9 16:45:32 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id QAA09596 for ; Mon, 9 May 1994 16:45:31 -0400 Received: from ctron.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id NAA03219; Mon, 9 May 1994 13:30:47 -0700 Received: from stealth.ctron.com by ctron.com (4.1/SMI-4.1) id AA10018; Mon, 9 May 94 16:31:05 EDT Received: from express.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA29966; Mon, 9 May 94 16:30:56 EDT Received: from atm-at1.ctron by express.ctron.com (4.1/SMI-4.1) id AA23611; Mon, 9 May 94 16:29:27 EDT Date: Mon, 9 May 94 16:29:27 EDT From: wilder@express.ctron.com (David L. Wilder) Message-Id: <9405092029.AA23611@express.ctron.com> To: ietf-ppp@ucdavis.edu Subject: PPP Is there a basic overview of what PPP is and what it can do for me? I am especially interested in the PPP Link & PPP Bridge groups. Dave Wilder wilder@ctron.com Cabletron Systems Inc. - - - - - - - - - - - - - - - - - From list-admin Mon May 9 16:50:51 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA10186 for ; Mon, 9 May 1994 16:50:50 -0400 Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA13898; Mon, 9 May 94 13:50:04 PDT Message-Id: <9405092050.AA13898@fennel.acc.com> X-Sender: fbaker@129.192.64.25 (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 May 1994 13:50:05 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: The PPP OSI Network Layer Control Protocol (OSINLCP) Some time has elapsed since RFC 1377 was published, I would like to advance it to Draft Standard. Could you please advise me: who has implemented it? (I know of: Cisco, 3COM, DEC, there must be others...) has it proven interoperable? are there any issues that require it to be updated? ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Mon May 9 17:50:12 1994 Received: from ucdavis.ucdavis.edu ([128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id RAA15142 for ; Mon, 9 May 1994 17:50:10 -0400 Received: from cs.utah.edu by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id OAA13775; Mon, 9 May 1994 14:36:56 -0700 Received: from ee.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA16579; Mon, 9 May 94 15:37:16 -0600 Received: from cts27.cc.utah.edu by ee.utah.edu with SMTP (1.37.109.4/15.6) id AA10011; Mon, 9 May 94 15:37:22 -0600 Date: Mon, 9 May 94 15:37:22 -0600 Message-Id: <9405092137.AA10011@ee.utah.edu> X-Sender: paulsen@ee.utah.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@ucdavis.edu From: paulsen@ee.utah.edu (Keith Paulsen) Subject: How do I subscribe X-Mailer: I want to subscribe to a PPP conference. PLEASE tell me how to subscribe!! Thank you, Keith - - - - - - - - - - - - - - - - - From list-admin Mon May 9 18:26:33 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA17544 for ; Mon, 9 May 1994 18:26:30 -0400 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB16330; Mon, 9 May 94 15:26:16 PDT Message-Id: <9405092226.AB16330@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 May 1994 15:26:16 -0800 To: Keith Sklower From: fbaker@acc.com (Fred Baker) Subject: Re: this time fer shure (Yet Another Multilink Draft) Cc: ietf-ppp@merit.edu >3.) There was dismay expressed that the .8 draft combined the end-point > identifier and other independent multilink related parameters as > a single LCP option which needed to be parsed as sub-options rather > than breaking them apart as separate LCP options. However, the > comment specifically did not want to delay forwarding the draft > by provoking a lengthy discussion on the topic. On the other hand, > I would certainly not mind a "show of hands around the net". I thought we had discussed making the EID a separate option, at the IETF. ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Mon May 9 21:35:30 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA28223 for ; Mon, 9 May 1994 21:35:29 -0400 Received: from drawbridge (via drawbridge.ascend.com) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwpfi12679; Mon, 9 May 94 21:35:27 -0400 Received: from spud.Ascend.COM by drawbridge (4.1/SMI-4.1/Drawbridge-GCA-930913-1) id AA04797; Mon, 9 May 94 18:36:27 PDT Received: from dumbcat.sf.ca.us (dumbcat.sf.ca.us.) by spud.Ascend.COM (4.1/Ascend-ext-931229) id AA26339; Mon, 9 May 94 18:35:40 PDT Received: from localhost by dumbcat.sf.ca.us (4.1/smail-24May90) id AA11193; Mon, 9 May 94 18:34:44 PDT To: Karl Fox Cc: Kevin Schneider , ietf-ppp@merit.edu Subject: Re: Stacker LZS Protocol In-Reply-To: Your message of "Mon, 09 May 1994 13:00:07 EDT." <9405091700.AA13887@gefilte.MorningStar.Com> Date: Mon, 09 May 1994 18:34:31 -0700 Message-Id: <11190.768533671@dumbcat.sf.ca.us> From: Marco S Hyman Karl Fox writes: > Please, let's make simplicity a higher priority that backward > compatibility. Karl, When wearing my software hat I agree with you. But once in a while I play customer service -- and one thing a customer won't except is a new release of a product that doesn't interoperate with the old releases. Just make it so I can detect the difference between old and new and attempt to do the right thing (from the customer's point-of-view) and I'll be happy. // marc - - - - - - - - - - - - - - - - - From list-admin Tue May 10 04:28:17 1994 Received: from fwide.fujitsu.co.jp (fwide.fujitsu.co.jp [133.160.28.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id EAA20183 for ; Tue, 10 May 1994 04:28:05 -0400 From: shin@hodaka.mfd.cs.fujitsu.co.jp Received: from fdm.fujitsu.co.jp by fwide.fujitsu.co.jp (8.6.5+2.3W/3.2W4-MX/Fujitsu Mail Gateway) id RAA12716; Tue, 10 May 1994 17:27:34 +0900 Received: from [133.161.1.84] by fdm.fujitsu.co.jp (5.65/6.4J.6) id AA22221; Tue, 10 May 94 17:19:58 +0900 Received: from hodaka.mfd.cs.fujitsu.co.jp by mfdgw.mfd.cs.fujitsu.co.jp (5.67+1.6W[+alpha]/6.4J[+CSMX]) id AA08490; Tue, 10 May 94 17:19:54 JST Received: from shin (shin.ARPA) by hodaka.mfd.cs.fujitsu.co.jp (4.12/6.4J.5) id AA06957; Tue, 10 May 94 17:20:54 JST Date: Tue, 10 May 94 17:20:54 JST Message-Id: <9405100820.AA06957@hodaka.mfd.cs.fujitsu.co.jp> To: ietf-ppp@merit.edu Subject: Re: iplpdn related spec confirmation X-Mailer: Harada's PC/M [v1.5] Hello all. Several people gave me comments to my message, and I feel very much thankful for it. In my recognition, summary of their comments are the following. 1. the pad octet in RFC1490 $@!&(JWhen sending a frame, we MUST add a pad if it is necessary for 16 bit alignment. However, when receiving a frame, we SHOULD be prepared to receive one which do not conform 16 bit alignment. Concerning RFC1490, there is a remark about OUI. There is a case such that Apple uses their OUI value on ethernet, so we should also care about OUI values over Frame Relay. In the fact, many vendors seem to use OUI "00-00-00" for the AppleTalk, IPX and DECnet over Frame Relay. 2. Multiprotocol format in RFC1293 $@!&(JIn the PVC enviroment, AppleTalk and DECnet doesn't need Inverse ARP. But in SVC enviroment, it might useful. $@!&(JAbout the following Ethernet Type Value and Address Length and format, all comments is in favor. Ethernet Type Value in Inverse ARP IPX=0x8137 AppleTalk=0x809B DECnet=0x6003 Address Length and format of IPX and XNS in Inverse ARP IPX=10octet (Net. Num. = 4octet ; Node Num. = 6octet) XNS=10octet (Net. Num. = 4octet ; Node Num. = 6octet) +-------------------------------+ | Net. Num. | +-------------------------------+ | Net. Num. | +-------------------------------+ | Node Num. | +-------------------------------+ | Node Num. | +-------------------------------+ | Node Num. | +-------------------------------+ $@!&(Jlets get it standardized! (From Caralyn Brown) I am cheered up by last comments, and would like to try to write base text. I supposed two way. First is that, to write new Internet-Draft named "application of Inverse ARP in multiprotocol environment". Secand is that, if Mr.Terry Bradley and Mr.Caralyn Brown would agree with this, adding above information(includes the necessity and application) to Inverse ARP text and updating it. Does these approaches have any serious problem? or is there any better way? I have little experience, so I might be missing some basical and important points. Any comment will be very welcome. Regards, -- Yoshinobu Inoue shin@hodaka.mfd.cs.fujitsu.co.jp Architecture Department Network Division Open Systems Group Fujitsu Limited - - - - - - - - - - - - - - - - - From list-admin Tue May 10 11:34:59 1994 Received: from pm002-21.dialip.mich.net (pm002-21.dialip.mich.net [35.1.48.102]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA16462 for ; Tue, 10 May 1994 11:34:57 -0400 Date: Tue, 10 May 94 14:29:23 GMT From: "William Allen Simpson" Message-ID: <2346.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: The PPP OSI Network Layer Control Protocol (OSINLCP) > are there any issues that require it to be updated? > Yes, I have a small file of nits that have been raised. I expect that Dave Katz does, too. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Tue May 10 15:04:48 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA03191 for ; Tue, 10 May 1994 15:04:46 -0400 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB02129; Tue, 10 May 94 12:04:38 PDT Message-Id: <9405101904.AB02129@fennel.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 May 1994 12:04:41 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: A single multiplexed multilink option vs related LCP options Keith advises me that he has had strong inputs to the effect that (a) all of the Multilink options should be included in a single option with multiple sub-options, (b) sub-options should not exist, or at least should be avoided in this case Specifically in question is the endpoint-id, which one could imagine utility for outside of multi-link, although it was designed with multi-link in mind. Could we please get a show of hands here? Who agrees with (a), and why, and who agrees with (b) and why? ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Tue May 10 15:41:42 1994 Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id PAA06444 for ; Tue, 10 May 1994 15:41:41 -0400 From: Neal_Castagnoli@Novell.COM Received: by ns.Novell.COM (4.1/SMI-4.1) id AA03306; Tue, 10 May 94 13:46:38 MDT Received: by MHS.Novell.COM via $t909461.440 id 10B99C7D81F40170; Tue, 10 May 94 13:46:37 MDT Precedence: first-class X-Notification-Correlator: F2C6CE4D01F40100 X-Date-Posted: 10-May-1994 11:19:31 -0400; at sjf-mail-engr.Novell X-Date-Transferred: 10-May-1994 11:46:21 -0400; at sjf-domain-hub.Novell X-Smf-Version: 70 To: ietf-ppp@merit.edu Message-Id: Subject: Re: The PPP OSI Network Layer C Date: 8 May 1994 12:33:56 X-Importance: Normal X-In-Reply-To: BC1DC83D01F40100 X-Conversation-Id: BC1DC83D02F40100 X-Original-To: INET-1@INETGATE{ietf-ppp@merit.edu} X-Originator: billsimp @ Inetgate.Novell ("William Allen Simpson"){SMTP:bill.simpson@um.cc.umich.edu} O-Dvs-Storeid: F2C6CE4D01F40100 O-Dvs-Trailtype: 0,1 O-Dvs-Trailaddr: billsimp @ Inetgate.Novell ("William Allen Simpson"){SMTP:bill.simpson@um.cc.umich.edu},CAST @ NOVELL O-Dvs-Traildate: 10-May-94 14:29:00, 8-May-94 12:33:56 O-Dvs-Wrapinfo: 3B,3D,84,99,9A,B7,B8,B9,BA,0217,0218,02C8,02C9 X-Via-Host: sjf-engr.Novell > are there any issues that require it to be updated? > Yes, I have a small file of nits that have been raised. I expect that Dave Katz does, too. Bill.Simpson@um.cc.umich.edu While on the subject, there is one thing that mystifies me about CLNP PPP. It is my understanding that it may not be possible to communicate with a system that does not support the CLNP NCP state machine. The reason is that the other side can mandate a certain alignment, that when rejected/ignored, will cause the receiver to throw away packets. It seems to me that there would have to be some really strong reasons why this was done, because it violates some good programing principle/network design principle somewhere. --Neal - - - - - - - - - - - - - - - - - From list-admin Tue May 10 17:10:58 1994 Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id RAA13359 for ; Tue, 10 May 1994 17:10:57 -0400 Received: from ee.utah.edu by cs.utah.edu (5.65/utah-2.21-cs) id AA19096; Tue, 10 May 94 15:10:56 -0600 Received: from cts4.cc.utah.edu by ee.utah.edu with SMTP (1.37.109.4/15.6) id AA15853; Tue, 10 May 94 15:11:02 -0600 Date: Tue, 10 May 94 15:11:02 -0600 Message-Id: <9405102111.AA15853@ee.utah.edu> X-Sender: paulsen@ee.utah.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@merit.edu From: paulsen@ee.utah.edu (Keith Paulsen) Subject: PPP for the PC X-Mailer: I am trying to build a PPP/IPX router using an IBM PC using packet drivers. Is there software available similar to SLIPPER etc, that will let me use PPP in a packet stack. Any help would be greatly appreciated!!! Thanks, Keith - - - - - - - - - - - - - - - - - From list-admin Tue May 10 23:44:21 1994 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id XAA03632 for ; Tue, 10 May 1994 23:44:19 -0400 Received: from [158.222.2.1] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0q15D5-000ERuC; Tue, 10 May 94 20:43 PDT Message-Id: Date: Tue, 10 May 94 20:43 PDT X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: fbaker@acc.com (Fred Baker), ietf-ppp@merit.edu From: brian@lloyd.com (Brian Lloyd) Subject: Re: A single multiplexed multilink option vs related LCP options At 12:04 5/10/94 -0800, Fred Baker wrote: >Keith advises me that he has had strong inputs to the effect that > > (a) all of the Multilink options should be included in a single option with > multiple sub-options, > > (b) sub-options should not exist, or at least should be avoided in this case > >Specifically in question is the endpoint-id, which one could imagine >utility for outside of multi-link, although it was designed with multi-link >in mind. > >Could we please get a show of hands here? Who agrees with (a), and why, and >who agrees with (b) and why? It probably doesn't matter too much but I tend to lean toward (a). [Sub]options that do not make sense separately, e.g. if you are going to do multilink you are going to negotiate MMRU and endpoint ID, are probably best left as suboptions rather than options. You sort of lump them together. On the other hand, you can accomplish the same thing with separate options. Seems to me that this really isn't an important decision. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 - - - - - - - - - - - - - - - - - From list-admin Wed May 11 00:06:13 1994 Received: from pm002-12.dialip.mich.net (pm002-12.dialip.mich.net [35.1.48.93]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id AAA05170 for ; Wed, 11 May 1994 00:06:11 -0400 Date: Tue, 10 May 94 21:55:19 GMT From: "William Allen Simpson" Message-ID: <2353.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: The PPP OSI Network Layer C > While on the subject, there is one thing that mystifies me about CLNP > PPP. It is my understanding that it may not be possible to communicate > with a system that does not support the CLNP NCP state machine. The > reason is that the other side can mandate a certain alignment, that when > rejected/ignored, will cause the receiver to throw away packets. > Neal, network-layer protocols for A-N-Y system that doesn't support the associated NCP state machine will be tossed. No exceptions. That includes IPX. As to alignment, apparently you haven't actually read RFC 1377? Try page 8: The alignment request is advisory, and failure to agree on an alignment MUST NOT prevent the OSINLCP from reaching the Opened state. By default, the alignment is done according to the needs of the sender, and all receivers MUST be capable of accepting packets with any alignment. If that's not clear enough, a vernacular was included: Vernacular: If you don't like this option, you can refuse to negotiate it, and you can send whatever alignment you want. However, if you accept the peer's alignment option, then you MUST transmit packets with the agreed alignment. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Wed May 11 00:27:31 1994 Received: from feta.cisco.com (feta.cisco.com [192.31.7.22]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id AAA06231 for ; Wed, 11 May 1994 00:27:30 -0400 Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id VAA04196; Tue, 10 May 1994 21:26:55 -0700 Date: Tue, 10 May 1994 21:26:55 -0700 From: Dave Katz Message-Id: <199405110426.VAA04196@feta.cisco.com> To: bsimpson@morningstar.com Cc: ietf-ppp@merit.edu In-Reply-To: "William Allen Simpson"'s message of Tue, 10 May 94 21:55:19 GMT <2353.bill.simpson@um.cc.umich.edu> Subject: The PPP OSI Network Layer C The only feedback that I've gotten on the OSINLCP is that people are still confused by the padding and alignment stuff, though I thought it was reasonably clear. I'll try another stab at the language, or perhaps a paragraph that explains how they relate. Date: Tue, 10 May 94 21:55:19 GMT From: "William Allen Simpson" Reply-To: bsimpson@morningstar.com > While on the subject, there is one thing that mystifies me about CLNP > PPP. It is my understanding that it may not be possible to communicate > with a system that does not support the CLNP NCP state machine. The > reason is that the other side can mandate a certain alignment, that when > rejected/ignored, will cause the receiver to throw away packets. > Neal, network-layer protocols for A-N-Y system that doesn't support the associated NCP state machine will be tossed. No exceptions. That includes IPX. As to alignment, apparently you haven't actually read RFC 1377? Try page 8: The alignment request is advisory, and failure to agree on an alignment MUST NOT prevent the OSINLCP from reaching the Opened state. By default, the alignment is done according to the needs of the sender, and all receivers MUST be capable of accepting packets with any alignment. If that's not clear enough, a vernacular was included: Vernacular: If you don't like this option, you can refuse to negotiate it, and you can send whatever alignment you want. However, if you accept the peer's alignment option, then you MUST transmit packets with the agreed alignment. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Wed May 11 10:38:33 1994 Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA08252 for ; Wed, 11 May 1994 10:38:32 -0400 From: Neal_Castagnoli@Novell.COM Received: by ns.Novell.COM (4.1/SMI-4.1) id AA25304; Wed, 11 May 94 08:43:25 MDT Received: by MHS.Novell.COM via $t903011.440 id 6DB99C7D81F40170; Wed, 11 May 94 08:43:25 MDT Precedence: first-class X-Notification-Correlator: 3FD0CF2D01F40100 X-Date-Posted: 11-May-1994 6:15:54 -0400; at sjf-mail-engr.Novell X-Date-Transferred: 11-May-1994 6:42:34 -0400; at sjf-domain-hub.Novell X-Smf-Version: 70 To: dkatz@cisco.com Message-Id: <3FD0CF2D01F40100@MHS.Novell.COM> Subject: Re: The PPP OSI Network Layer C Date: 11 May 1994 07:30:25 X-Importance: Normal X-In-Reply-To: 3CD0CF2D01F40100 X-Conversation-Id: 3CD0CF2D02F40100 X-Original-To: INET-1@INETGATE{dkatz@cisco.com} X-Original-Copies-To: INET-1@INETGATE{ietf-ppp@merit.edu} X-Originator: dkatz @ Inetgate.Novell (Dave Katz){SMTP:dkatz@cisco.com} O-Dvs-Storeid: 3FD0CF2D01F40100 O-Dvs-Trailtype: 0,1 O-Dvs-Trailaddr: dkatz @ Inetgate.Novell (Dave Katz){SMTP:dkatz@cisco.com},CAST @ NOVELL O-Dvs-Traildate: 10-May-94 21:26:00,11-May-94 07:30:25 O-Dvs-Wrapinfo: 4C,92,DA,0104,0105,012B,016C,0193,0194,01E0,022D,0278,02C7,030E,0314,0360,03A7,03B9,03BA,03FE,03FF,040F,0450,0493,04D7,0518,0537,0538,0573,05B6,05F8,063B,0672,0673,0694,0695,0696,0697,0698,0944,0945,09F3,09F4,0A63,0A64,0A65,0A66,0B1E,0B1F,0BED,0BEE X-Via-Host: sjf-engr.Novell Cc: ietf-ppp@merit.edu The only feedback that I've gotten on the OSINLCP is that people are still confused by the padding and alignment stuff, though I thought it was reasonably clear. I'll try another stab at the language, or perhaps a paragraph that explains how they relate. Date: Tue, 10 May 94 21:55:19 GMT From: "William Allen Simpson" Reply-To: bsimpson@morningstar.com > While on the subject, there is one thing that mystifies me about CLNP > PPP. It is my understanding that it may not be possible to communicate > with a system that does not support the CLNP NCP state machine. The > reason is that the other side can mandate a certain alignment, that when > rejected/ignored, will cause the receiver to throw away packets. > Neal, network-layer protocols for A-N-Y system that doesn't support the associated NCP state machine will be tossed. No exceptions. That includes IPX. As to alignment, apparently you haven't actually read RFC 1377? Try page 8: The alignment request is advisory, and failure to agree on an alignment MUST NOT prevent the OSINLCP from reaching the Opened state. By default, the alignment is done according to the needs of the sender, and all receivers MUST be capable of accepting packets with any alignment. If that's not clear enough, a vernacular was included: Vernacular: If you don't like this option, you can refuse to negotiate it, and you can send whatever alignment you want. However, if you accept the peer's alignment option, then you MUST transmit packets with the agreed alignment. Bill.Simpson@um.cc.umich.edu Actually, I did read that particular section of the RFC, and in fact understood the meaning of the RFC. I found out about this particular section in the RFC because someone in the UK was doing interoperability testing with CLNP PPP for some article. Since our implemenation predates the RFC, and supports only a NULL NCP layer, it did not interoperate with one implementation. (Adding anything other than a NULL NCP is actually work for us, and so we would either need to add in illegal CLNP code for PPP, which could fail under some really obscure circumstances, or just not interoperate with implemenations that insist on sending these packets, even if the option is rejected.) Rather than "By default, the alignment is done according to the needs of the sender, and all receivers MUST be capable of accepting packets with any alignment.", how about: "By default, no alignment is done. It is only done when both the sender and receiver agree to an alignment." Anyway, I must admit to being really confused (there must have been some kind of politics associated with this one, is my guess) as to how this behavior could be written into the RFC. Are some implementations incapable of sending "correctly" aligned packets? Or is this needed only for some performance reason? It seems to me that such an implemenation would have other problems as well. --Neal - - - - - - - - - - - - - - - - - From list-admin Wed May 11 14:31:03 1994 Received: from feta.cisco.com (feta.cisco.com [192.31.7.22]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id OAA27667 for ; Wed, 11 May 1994 14:31:03 -0400 Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA03361; Wed, 11 May 1994 11:30:27 -0700 Date: Wed, 11 May 1994 11:30:27 -0700 From: Dave Katz Message-Id: <199405111830.LAA03361@feta.cisco.com> To: Neal_Castagnoli@novell.com Cc: ietf-ppp@merit.edu In-Reply-To: Neal_Castagnoli@Novell.COM's message of 11 May 1994 07:30:25 <3FD0CF2D01F40100@MHS.Novell.COM> Subject: The PPP OSI Network Layer C There are boxes out there with serial controllers that cannot start sending on odd boundaries. Since 802-encapsulated CLNP packets tend to end up on odd boundaries, the ability to use arbitrary padding (and require receivers to accept it) was added. The alignment option was added for symmetry; if the sender isn't picky about alignment, the receiver can try to influence it to align packets in particular ways. Note that this is distinct from padding; the sender can use any combination of padding and compression to achieve the requested alignment (so the receiver must continue to accept arbitrary padding). Requiring padding to be negotiated (and thus rejectable) would tend to result in scads of buffer copies in the senders; the consensus at the time was that the burden on the receiver to accept arbitrary padding was less onerous than the burden on the sender to move the data around. I'll see if I can make the rationale a little clearer. Actually, I did read that particular section of the RFC, and in fact understood the meaning of the RFC. I found out about this particular section in the RFC because someone in the UK was doing interoperability testing with CLNP PPP for some article. Since our implemenation predates the RFC, and supports only a NULL NCP layer, it did not interoperate with one implementation. (Adding anything other than a NULL NCP is actually work for us, and so we would either need to add in illegal CLNP code for PPP, which could fail under some really obscure circumstances, or just not interoperate with implemenations that insist on sending these packets, even if the option is rejected.) Rather than "By default, the alignment is done according to the needs of the sender, and all receivers MUST be capable of accepting packets with any alignment.", how about: "By default, no alignment is done. It is only done when both the sender and receiver agree to an alignment." Anyway, I must admit to being really confused (there must have been some kind of politics associated with this one, is my guess) as to how this behavior could be written into the RFC. Are some implementations incapable of sending "correctly" aligned packets? Or is this needed only for some performance reason? It seems to me that such an implemenation would have other problems as well. --Neal - - - - - - - - - - - - - - - - - From list-admin Wed May 11 14:44:04 1994 Received: from Bill.Simpson.DialUp.Merit.edu (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA28528 for ; Wed, 11 May 1994 14:44:00 -0400 Date: Wed, 11 May 94 16:53:40 GMT From: "William Allen Simpson" Message-ID: <2369.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: The PPP OSI Network Layer C > From: Neal_Castagnoli@Novell.COM > Since our implemenation > predates the RFC, and supports only a NULL NCP layer, it did not > interoperate with one implementation. A NULL NCP is always supported. How could this not work in your implementation? What product was this that predated the RFC? The draft was there since May 1990. Also, since your implementation admittedly predates the Proposed Standard RFC, you CERTAINLY should update your implementation. And again at Draft Standard. And again at Full Standard. > (Adding anything other than a NULL > NCP is actually work for us, and so we would either need to add in > illegal CLNP code for PPP, which could fail under some really obscure > circumstances, or just not interoperate with implemenations that insist > on sending these packets, even if the option is rejected.) > This statement makes no sense. A NULL NCP is always supported. Since you don't want to advertise the only option that currently exists, a NULL NCP seems like just the thing for you. And of course, we wouldn't want a tiny company with no staff like Novell to actually have to do any work.... > Anyway, I must admit to being really confused (there must have been some > kind of politics associated with this one, is my guess) as to how this > behavior could be written into the RFC. > Politics? Bullshit! Implementation experience. The leading zeroes were being added in different amounts by different vendors, and it seemed useful (at least 2 vendors requested) to be able to advertise which alignment was best FOR THE RECEIVER (the bottleneck). Implementation experience also showed that packets coming in from different kinds of links had different alignments. So, when they go out another link without packet copying, they won't be aligned the same. That's why the amount of padding sent still has to be variable, and the receiver has to accept any amount of padding. > Are some implementations incapable of sending "correctly" aligned > packets? Or is this needed only for some performance reason? It seems > to me that such an implemenation would have other problems as well. > It sounds to me like the problem isn't of some _other_ (unidentified) implementation, but rather of yours! Do you accept leading zero padding? Since you are required to accept one or more leading zeroes (an ISO Zero NLPID), it seems like _you_ are not ISO compliant. That RFC is over a year and a half old. Why haven't you updated your implementation? Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Wed May 11 16:09:47 1994 Received: from ns.Novell.COM (ns.Novell.COM [137.65.1.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA04809 for ; Wed, 11 May 1994 16:09:44 -0400 From: Neal_Castagnoli@Novell.COM Received: by ns.Novell.COM (4.1/SMI-4.1) id AA10396; Wed, 11 May 94 14:14:42 MDT Received: by MHS.Novell.COM via $t905062.440 id C3B99C7D81F40170; Wed, 11 May 94 14:14:41 MDT Precedence: first-class X-Notification-Correlator: 6F02D13D01F40100 X-Date-Posted: 11-May-1994 11:46:56 -0400; at sjf-mail-engr.Novell X-Date-Transferred: 11-May-1994 12:14:04 -0400; at sjf-domain-hub.Novell X-Smf-Version: 70 To: ietf-ppp@merit.edu Message-Id: <6F02D13D01F40100@MHS.Novell.COM> Subject: Re: The PPP OSI Network Layer C Date: 11 May 1994 13:02:29 X-Importance: Normal X-In-Reply-To: 6C02D13D01F40100 X-Conversation-Id: 6C02D13D02F40100 X-Original-To: inet-1@inetgate {ietf-ppp@merit.edu} X-Originator: billsimp @ Inetgate.Novell ("William Allen Simpson"){SMTP:bill.simpson@um.cc.umich.edu} O-Dvs-Storeid: 6F02D13D01F40100 O-Dvs-Trailtype: 0,1 O-Dvs-Trailaddr: billsimp @ Inetgate.Novell ("William Allen Simpson"){SMTP:bill.simpson@um.cc.umich.edu},CAST @ NOVELL O-Dvs-Traildate: 11-May-94 16:53:00,11-May-94 13:02:29 O-Dvs-Wrapinfo: 23,24,69,B4,FB,FE,0145,0187,01CE,020F,0210,0211,035E,035F,03A6,03B7,03B8,03FA,03FB,0420,0421,042C,042D X-Via-Host: sjf-engr.Novell > From: Neal_Castagnoli@Novell.COM > Are some implementations incapable of sending "correctly" aligned > packets? Or is this needed only for some performance reason? It seems > to me that such an implemenation would have other problems as well. > It sounds to me like the problem isn't of some _other_ (unidentified) implementation, but rather of yours! Do you accept leading zero padding? Since you are required to accept one or more leading zeroes (an ISO Zero NLPID), it seems like _you_ are not ISO compliant. So, are you suggesting that we treat this as an inactive packet? I personally think transport would get confused trying to deal with network layer packets. And, FYI, the inactive layer is *NOT* mandatory in US GOSIP (what profile are you talking about anyway?). And yes, Novell's implementation was certified US GOSIP compliant. That RFC is over a year and a half old. Why haven't you updated your implementation? What business is it of yours when Novell updates implementations? I'm really sorry I asked about this. --Neal P.S. Any other flames directly to me. - - - - - - - - - - - - - - - - - From list-admin Thu May 12 10:42:22 1994 Received: from pm002-06.dialip.mich.net (pm002-06.dialip.mich.net [35.1.48.87]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA12375 for ; Thu, 12 May 1994 10:42:19 -0400 Date: Thu, 12 May 94 14:07:16 GMT From: "William Allen Simpson" Message-ID: <2380.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: The PPP OSI Network Layer C > From: Neal_Castagnoli@Novell.COM > GOSIP (what profile are you talking about anyway?). And yes, Novell's > implementation was certified US GOSIP compliant. > Which goes to show why FIRP decided this year that cerified profile compliance was a waste of time and money. Interoperability testing is what counts. > That RFC is over a year and a half old. Why haven't you updated your > implementation? > > What business is it of yours when Novell updates implementations? > If Novell builds a bad implementation, and then comes to us and asks for changes to match their bad implementation (all the while blaming unspecified others), Novell has made it my business. It is important to our community and the computer press to know that Novell is years behind on standards compliance, and doesn't provide timely updates to their product lines. Note that other companies that make mistakes update their products. For example, Shiva sent out (tens of?) thousands of bad PPP checksum implementations. They didn't come to us and ask for a change in the PPP checksum. They quietly upgraded the product (and I added more explanation about checksum calculation). Note also that other companies didn't conclude that the specification was from "some kind of politics", because "it violates some good programing principle/network design principle somewhere" [sic]. That was a direct attack on our process. Which makes it my business as well. > I'm really sorry I asked about this. > I wish you were sorrier that you hadn't updated your product; and for your attack on the OSINLCP process, and by inference, the PPP WG and the IETF. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Thu May 12 19:11:41 1994 Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.130.2]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id TAA25629 for ; Thu, 12 May 1994 19:11:41 -0400 Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.9.Beta4/8.6.9.Beta0) id QAA02834 for ietf-ppp@merit.edu; Thu, 12 May 1994 16:10:07 -0700 Date: Thu, 12 May 1994 16:10:07 -0700 From: Keith Sklower Message-Id: <199405122310.QAA02834@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: draft-ietf-pppext-multilink-08.95.txt Is now available via anonymous ftp from vangogh.cs.berkeley.edu:~ftp/pub/ppp-iplpdn This version has change bars against draft 8; was rewritten so that the Multilink MRRU, Multilink Short Headers, and the Endpoint Descriminator are separate LCP options, and has yet further typographical corrections. Pending no further comments, it will be posted to internet drafts as draft 9, and after a short interval and the agreement of the committee chair, submitted to the IESG as proposed standard. - - - - - - - - - - - - - - - - - From list-admin Fri May 13 09:17:16 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA09785 for ; Fri, 13 May 1994 09:17:16 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03040; 13 May 94 9:09 EDT To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu Cc: The Internet Engineering Steering Group From: IESG Secretary Subject: Protocol Action: PPP Bridging Control Protocol (BCP) to Proposed Standard Date: Fri, 13 May 94 09:09:51 -0400 Sender: jstewart@CNRI.Reston.VA.US Message-ID: <9405130909.aa03040@IETF.CNRI.Reston.VA.US> The IESG has approved the Internet-Draft "PPP Bridging Control Protocol (BCP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons is Stev Knowles. Technical Summary The protocol defined in this document allows for vendors to provide bridging technologies across point-to-point links using PPP. The protocol as defined allows for the exchange of necessary information for this activity to occur. Working Group Summary The PPP working group has expended some effort in helping the authors of this document bring it to a finely crafted sheen. Protocol Quality This document, while not short, is an extremely readable explanation of the considered technologies and goes into some detail about how various actions will effect the stability of one's network as a whole. The I-D takes the time to explain to the reader bridging technologies, which the reviewing AD feels is an appropriate matter, since one cannot assume that IP centric readers will be as familiar with bridging as one needs to be to implement bridging between two PPP endpoints. The I-D avoids the religious pitfalls one may expect to find in a document about a subject which most knowledgeable readers will have very strong opinions about. There seem to be multiple implementations of this document. This review was done by Stev Knowles, one of the Internet Area Directors, for the IESG. - - - - - - - - - - - - - - - - - From list-admin Fri May 13 12:01:34 1994 Received: from ucdavis.ucdavis.edu (ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id MAA23122 for ; Fri, 13 May 1994 12:01:32 -0400 Received: from newton.jsc.nasa.gov by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id IAA15964; Fri, 13 May 1994 08:54:39 -0700 Message-Id: <199405131554.IAA15964@ucdavis.ucdavis.edu> Received: from spmail.jsc.nasa.gov by newton.jsc.nasa.gov with SMTP; Fri, 13 May 1994 10:57:37 -0500 (CDT) Date: 13 May 1994 10:55:36 U From: "McCullough, John" Subject: Learning about PPP Return-receipt-to: "McCullough, John" To: "IETF PPP Working Group" I work for Lockheed at the Johnson Space Center in Houston, Texas. I have been tasked with researching remote dial in capabilities for our division and making recommendations based on this reasearch. Our current requirements are for individual remote users working out of their homes or from business trips. We are not trying to link networks together. We currently use AppleTalk Remote Access, however we find it very limiting. Initially, PPP seems to be a very promising capability, however I don't think I fully understand it capabilities, nor do I know where vendors stand on getting PPP products to market. I am currently reading rfc 1171. It recommends referring to the current edition of the IAB Official Protocol Working Group of the IETF, but I can't find this document. Of the many questions that I have, maybe someone could answer one of my technical questions, using PPP can you make a connection to a PPP server and initiate multiple session with more than one protocol? Ideally, we are looking for an environment in which we could run TCP/IP, AppleTalk, and Decnet simultaneously. Of course even with the latest modems on the market, this would be a slow network connection, but possibly with the V.Fast standard coming out we might realize a respectable connection rate. Any help on these and more issues is greatly appreciated! - - - - - - - - - - - - - - - - - From list-admin Fri May 13 14:33:02 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id OAA04696 for ; Fri, 13 May 1994 14:33:01 -0400 Received: from fennel.acc.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id LAA10697; Fri, 13 May 1994 11:29:20 -0700 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB01650; Fri, 13 May 94 11:29:22 PDT Message-Id: <9405131829.AB01650@fennel.acc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 May 1994 11:29:20 -0800 To: "McCullough, John" From: fbaker@acc.com (Fred Baker) Subject: Re: Learning about PPP Cc: "IETF PPP Working Group" At 10:55 AM 5/13/1994 +0000, McCullough, John wrote: >I work for Lockheed at the Johnson Space Center in Houston, Texas. I have been >tasked with researching remote dial in capabilities for our division and making > recommendations based on this reasearch. Our current requirements are for >individual remote users working out of their homes or from business trips. We >are not trying to link networks together. We currently use AppleTalk Remote >Access, however we find it very limiting. Initially, PPP seems to be a very >promising capability, however I don't think I fully understand it capabilities, >nor do I know where vendors stand on getting PPP products to market. I am >currently reading rfc 1171. It recommends referring to the current edition of >the IAB Official Protocol Working Group of the IETF, but I can't find this >document. Of the many questions that I have, maybe someone could answer one >of my technical questions, using PPP can you make a connection to a PPP server >and initiate multiple session with more than one protocol? Ideally, we are >looking for an environment in which we could run TCP/IP, AppleTalk, and Decnet >simultaneously. Of course even with the latest modems on the market, this >would be a slow network connection, but possibly with the V.Fast standard >coming out we might realize a respectable connection rate. Any help on these >and more issues is greatly appreciated! I would suggest that you look at the more recent versions of the PPP documents. As noted in the recent Data Communications article on the subject, there are a number of vendors who have various AppleTalk offerings; you should contact them to find out how their products mesh with your needs. ============================================================================= "In sound wisdom there are two sides" Zophar, Job 11:6 - - - - - - - - - - - - - - - - - From list-admin Fri May 13 20:19:31 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.1.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id UAA26763 for ; Fri, 13 May 1994 20:19:31 -0400 Received: from isi.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id RAA00439; Fri, 13 May 1994 17:06:43 -0700 Received: from chief.isi.com by isi.com (4.1/Ultrix3.0-C) id AA01620; Fri, 13 May 94 17:09:52 PDT Received: from kafka.universe (kafka.isi.com) by chief.isi.com (4.1/inc/isi-1.6s) id AA25402; Fri, 13 May 94 17:09:46 PDT Date: Fri, 13 May 94 17:09:46 PDT From: mz@isi.com (Michael Zheng x517) Message-Id: <9405140009.AA25402@chief.isi.com> Received: by kafka.universe (4.1/SMI-4.1) id AA01749; Fri, 13 May 94 17:08:37 PDT To: ietf-ppp@ucdavis.edu Cc: mz@isi.com Subject: unsubscribe Please unsubscribe me (long vacation). Thanks. -mz mz@isi.com - - - - - - - - - - - - - - - - - From list-admin Fri May 13 22:00:29 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.1.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id WAA02543 for ; Fri, 13 May 1994 22:00:28 -0400 Received: from netcom.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id SAA13169; Fri, 13 May 1994 18:46:28 -0700 Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id SAA05258; Fri, 13 May 1994 18:46:51 -0700 Date: Fri, 13 May 1994 18:46:51 -0700 From: earlc@netcom.com (Earl Caustin) Message-Id: <199405140146.SAA05258@netcom.com> To: ietf-ppp@ucdavis.edu Subject: unsubscribe unsubscribe - - - - - - - - - - - - - - - - - From list-admin Mon May 16 11:44:42 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA04878 for ; Mon, 16 May 1994 11:44:41 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06924; 16 May 94 11:34 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-magnalink-01.txt Date: Mon, 16 May 94 11:34:19 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9405161134.aa06924@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Magnalink Variable Resource Compression Author(s) : D. Schremp, J. Black, J. Weiss Filename : draft-ietf-pppext-magnalink-01.txt Pages : 6 Date : 05/13/1994 The Point-to-Point Protocol (PPP) provides a standard method of encapsulating multiple protocol datagrams over point-to-point links. The PPP Compression Control Protocol provides a method for negotiating data compression over PPP links. The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-magnalink-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-magnalink-01.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940513105929.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-magnalink-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-magnalink-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940513105929.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Wed May 18 14:49:16 1994 Received: from apache.telebit.com (apache.telebit.com [143.191.3.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA03600 for ; Wed, 18 May 1994 14:49:11 -0400 Received: from america.Sunnyvale.Telebit.CO (america-bb.sunnyvale.telebit.com) by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA07108 to ietf-ppp@merit.edu; Wed, 18 May 94 11:48:56 PDT Received: from yoyo.telebit.com by america.Sunnyvale.Telebit.COM (4.0/america.telebit.com-DBC-930718) id AA01064 to ietf-ppp@merit.edu; Wed, 18 May 94 11:48:18 PDT Date: Wed, 18 May 94 11:48:18 PDT From: mlewis@Telebit.COM (Mark S. Lewis) Message-Id: <9405181848.AA01064@america.Sunnyvale.Telebit.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA01217; Wed, 18 May 94 11:48:50 PDT To: ietf-ppp@merit.edu Subject: PPP Consortium Interoperability Survey Reply-To: Mark.S.Lewis@Telebit.COM Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII PPP Consortium Interoperability Testing April 18-22, 1994 The 3rd meeting of the PPP Consortium was completed in Redmond at host Microsoft. Twenty-eight (28) vendors met for an intensive week of interoperability testing. The full suite of PPP protocols was tested including IP, IPX, AppleTalk, and bridging. Almost all vendors were able to connect over dial-up async lines, sync leased-lines, and ISDN lines. Vendors made significant progress towards improving interoperability. They all found ways to improve their implementations like determining the best configuration options, adding authentication scripts, and fixing product bugs. Many vendors made corrections during the week and were able to confirm problem resolution. Survey Results -------------- Included below is a survey of PPP options implemented among the participating vendors. The data is reasonably accurate but a few disclaimers apply. This data describes implementations in various states of completion. Some implementations are being developed and are not yet in production. Some of the entries in the no options categories might not be correct, since there was not always enough information to determine which options were implemented for a given network protocol. Async PPP Options Implemented (25 total tested) Protocol Option Count -------- -------------------------------------------- ----- LCP Maximum-Receive-Unit (MRU) 25 LCP Async-Control-Character-Map (ACCM) 25 LCP Authentication-Protocol 20 LCP Quality-Protocol 4 LCP Magic-Number 25 LCP Protocol-Field-Compression (PFC) 25 LCP Address-and-Control-Field-Compression (ACFC) 24 LCP Identification 1 LCP Time-Remaining 0 PAP 18 CHAP 13 IPCP No Options 0 IPCP IP-Addresses (1) 11 IPCP IP-Compression-Protocol 21 IPCP IP-Address (3) 25 IPXCP No Options 3 IPXCP IPX-Network-Number 8 IPXCP IPX-Node-Number 8 IPXCP IPX-Compression-Protocol 5 IPXCP IPX-Routing-Protocol 2 IPXCP IPX-Router-Name 2 IPXCP IPX-Configuration-Complete 3 CIPX 5 IPXWAN 3 ATCP No Options 1 ATCP AppleTalk-Address 2 ATCP Routing-Protocol 2 ATCP Suppress-Broadcasts 2 ATCP AT-Compression-Protocol 1 ATCP Zone-Information 2 ATCP Default-Router-Address 2 Bridging 0 BCP 1 DNCP 0 OSINLCP 0 CCP 1 XNS 0 NBFCP 2 Sync PPP Implementations (10 total tested) Protocol Option Count -------- -------------------------------------------- ----- LCP Maximum-Receive-Unit (MRU) 10 LCP Authentication-Protocol 7 LCP Quality-Protocol 4 LCP Magic-Number 10 LCP Protocol-Field-Compression (PFC) 3 LCP Address-and-Control-Field-Compression (ACFC) 3 LCP Identification 0 LCP Time-Remaining 0 PAP 6 CHAP 4 IPCP No Options 2 IPCP IP-Addresses (1) 6 IPCP IP-Compression-Protocol 4 IPCP IP-Address (3) 8 IPXCP No Options 8 IPXCP IPX-Network-Number 1 IPXCP IPX-Node-Number 1 IPXCP IPX-Compression-Protocol 2 IPXCP IPX-Routing-Protocol 0 IPXCP IPX-Router-Name 0 IPXCP IPX-Configuration-Complete 0 CIPX 2 IPXWAN 4 ATCP No Options 4 ATCP AppleTalk-Address 0 ATCP Routing-Protocol 0 ATCP Suppress-Broadcasts 0 ATCP AT-Compression-Protocol 0 ATCP Zone-Information 0 ATCP Default-Router-Address 0 Bridging 3 BCP 3 DNCP 4 OSINLCP 2 CCP 1 XNS 1 Vines 2 PPP Reference Documents ----------------------- Baker, F., "Point-to-Point Protocol extensions for bridging", RFC 1220, April 1991 McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992 Simpson, W., "PPP Link Quality Monitoring" RFC 1333, May 1992 Lloyd, B., Simpson, W., "PPP Authentication Protocols" RFC 1334, October 1992 Senum, S., "The PPP DECnet Phase IV Control Protocol (DNCP)", RFC 1376, November 1992 Katz, D., "The PPP OSI Network Layer Control Protocol (OSINLCP)", RFC 1377, November 1992 Parker, B., "The PPP AppleTalk Control Protocol (ATCP)", RFC 1378, November 1992 Perkins, D., "Requirements for an Internet Standard Point-to-Point Protocol", RFC 1547 December 1993 Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1548, December 1993 Simpson, W., "PPP in HDLC Framing", RFC 1549, December 1993 Allen, M., "Novell IPX Over Various WAN Media (IPXWAN)", RFC 1551, December 1993 Simpson, W., "The PPP Internetworking Packet Exchange Control Protocol (IPXCP)", RFC 1552, December 1993 Mathur, S., Lewis, M., "Compressing IPX Headers Over WAN Media (CIPX)", RFC 1553, December 1993 Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994 (Updates RFC 1548) Dimitri, T., "The PPP NetBIOS Frames Control Protocol (NBFCP)", work in progress, February 1994 Rand, D., "The PPP Contression Control Protocol (CCP)", work in process, March 1994 Baker, F., Bowen, R., "PPP Bridging Control Protocol (BCP)", work in progress, March 1994 PPP Consortium Participants --------------------------- Advanded Computer Commmunications 3Com Corporation Cayman Systems Cisco Systems Computone Corporation Digital Equipment Corporation FTP Software, Incorporated IBM Corporation Institute for Information Industry Taipei, Taiwan Klos Technologies Lachman Technologies Lantronics, Incorporated NEC America, Incorporated NetManage, Incorporated Network Application Technology Network Systems, Incorporated Networks Northwest, Incorporated Novell Microsoft Corporation Morning Star Technologies Proteon Shiva Corporation Spry, Incorporated SunSoft Telebit Corporation Wellfleet Communications Xylogics Xyplex Incorporated ... Mark ==========-------------- Mark S. Lewis ----------========== Mark.S.Lewis@Telebit.com Telebit Corp. Voice (408) 745-3232 - - - - - - - - - - - - - - - - - From list-admin Thu May 19 06:31:34 1994 Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.4]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id GAA28981 for ; Thu, 19 May 1994 06:31:34 -0400 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <13640-0@relay1.pipex.net>; Thu, 19 May 1994 11:30:47 +0100 Received: by widow.spider.co.uk; Thu, 19 May 94 11:29:33 +0100 From: Gerry Meyer Date: Thu, 19 May 94 11:28:16 +0100 Message-Id: <1592.9405191028@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Thu, 19 May 94 11:28:16 +0100 To: ietf-ppp@merit.edu Subject: PPP CCP Cc: gerry@spider.co.uk The most recent PPP Compression Control Protocol draft I have, draft-ieft-pppext-compression-04.txt, no longer contains the following text (which appeared in an earlier draft): Compression algorithm options are listed in the order of their desireableness to the receiver. If the sender chooses to implement only one compression algorithm on the line (for example), he first determines what subset of the receiver's algorithms he can use, and among them chooses the most desireable - the first option listed. He must reject all others with a configure reject, and subsequently ACK the configure request for the single algorithm chosen. Has this mechanism been dropped? Gerry - - - - - - - - - - - - - - - - - From list-admin Thu May 19 10:56:54 1994 Received: from pm002-24.dialip.mich.net (pm002-24.dialip.mich.net [35.1.48.105]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA15498 for ; Thu, 19 May 1994 10:56:52 -0400 Date: Thu, 19 May 94 14:18:19 GMT From: "William Allen Simpson" Message-ID: <2442.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: PPP CCP > Has this mechanism been dropped? > No, just made more standardly PPP-like. Now, you get a request. You Reject only those options you don't understand. You Nak all of the ones you do understand. Then, the _sender_ sends a new request with only one option in it. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Thu May 19 14:13:58 1994 Received: from csisdn.com (THELMA.CSISDN.COM [192.135.47.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA29872 for ; Thu, 19 May 1994 14:13:56 -0400 Received: by csisdn.com (4.1/4.2) id AA04031; Thu, 19 May 94 11:13:32 PDT Date: Thu, 19 May 94 11:13:32 PDT From: srinath@csisdn.com (Nina Srinath) Message-Id: <9405191813.AA04031@csisdn.com> To: ietf-ppp@merit.edu SIGNOFF srinath@csisdn.com - - - - - - - - - - - - - - - - - From list-admin Thu May 19 20:26:33 1994 Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.130.2]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id UAA25213 for ; Thu, 19 May 1994 20:26:33 -0400 Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.9.Beta4/8.6.9.Beta0) id RAA14444 for ietf-ppp@merit.edu; Thu, 19 May 1994 17:24:50 -0700 Date: Thu, 19 May 1994 17:24:50 -0700 From: Keith Sklower Message-Id: <199405200024.RAA14444@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: Minorly revised multilink 08.95 -> 09.txt is available via anonymous ftp from vangogh.cs.berkeley.edu It fixes a couple of typos, ups the expiration date, and incorporates the following: From: jkrey@ISI.EDU Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 19 May 1994 16:50:13 -0700 Date: Thu, 19 May 1994 16:50:27 -0700 Posted-Date: Thu, 19 May 1994 16:50:27 -0700 Message-Id: <199405192350.AA04396@akamai.isi.edu> Received: by akamai.isi.edu (5.65c/4.0.3-4) id ; Thu, 19 May 1994 16:50:27 -0700 To: sklower@vangogh.CS.Berkeley.EDU Subject: Re: need 3 LCP option numbers ... Cc: iana@ISI.EDU Keith, Per your reqeust, we have assigned the following LCP option numbers: Multilink MMRU = 17 Short Sequence Number Header Format = 18 Endpoint Discriminator Option = 19 Joyce - - - - - - - - - - - - - - - - - From list-admin Fri May 20 10:09:09 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.1.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id KAA09834 for ; Fri, 20 May 1994 10:09:09 -0400 Received: from pcsl.demon.co.uk by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id HAA24370; Fri, 20 May 1994 07:08:51 -0700 Date: Fri, 20 May 94 15:05:26 GMT Message-Id: <1114191@pcsl.demon.co.uk> From: davel@pcsl.demon.co.uk (David Ll. Lewis) Reply-To: davel@pcsl.demon.co.uk To: ietf-ppp@ucdavis.edu Subject: PPP/HDLC in Async X-Organisation: Pinacl Communication Systems Ltd. X-Mailer: PCElm 1.08 Lines: 25 Hi, I'm reading RFC 1549 and about to implement PPP/HDLC on UK ISDN, X.21 and RS-232-C. I'm clear about the method for ISDN - it's just simply throwing the HDLC encapsulated PPP frame at the ISDN controller - right? - however, over X.21 I'm not sure at all and over Async RS-232-C, section 4 of the RFC describes the method, however, I'm a little confused as to what it's actually saying. Do you have any sample C code which you let me see to understand how this works (particularly the bit about ACCMs). Oh, yes, what does this statement mean:? "An octet stuffing procedure is used. The Control Escape octet is defined as binary 01111101 (hexadecimal 0x7d) where the bit positions are numbered 87654321 (not 76543210, BEWARE)." Thanks in advance for any help, -- /========================================================\ | David Lewis Pinacl Communication Systems Limited | | davel@pcsl.demon.co.uk 100113.2352@compuserve.com | | tel +44 745 589 279 fax +44 745 584 780 | | PGP2.x Public Key Available | \========================================================/ - - - - - - - - - - - - - - - - - From list-admin Fri May 20 21:33:42 1994 Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.128.4]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA28670 for ; Fri, 20 May 1994 21:33:41 -0400 Received: from himagiri.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA09451 (5.65c/IDA-1.4.4nsd for ); Fri, 20 May 1994 18:33:38 -0700 Received: from localhost.NSD.3Com.COM by himagiri.NSD.3Com.COM with SMTP id AA22376 (5.65c/IDA-1.4.4-910725 for ); Fri, 20 May 1994 18:33:32 -0700 Message-Id: <199405210133.AA22376@himagiri.NSD.3Com.COM> To: ietf-ppp@merit.edu Cc: vsp@nsd.3com.com Subject: Calgary Corpus Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) Date: Fri, 20 May 94 18:33:31 -0700 From: Venkat Prasad Dave Carr had posted this.. >The 14 files used in the comparison are from the standard Calgary >Text Compression Corpus, available by ftp on ftp.cpsc.ucalgary.ca >[136.159.7.18] in /pub/text.compression.corpus/text.compression.corpus.tar.Z. I cannot seem to find these files at the ftp site. Has anyone been able to get them ? Is there an alternate site ? thanks for your help /Prasad - - - - - - - - - - - - - - - - - From list-admin Sat May 21 18:09:06 1994 Received: from pm002-26.dialip.mich.net (pm002-26.dialip.mich.net [35.1.48.107]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id SAA24988; Sat, 21 May 1994 18:09:01 -0400 Date: Sat, 21 May 94 21:17:50 GMT From: "William Allen Simpson" Message-ID: <2479.bill.simpson@um.cc.umich.edu> To: davel@pcsl.demon.co.uk Cc: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: PPP/HDLC in Async > I'm clear about the method for ISDN - it's just simply throwing the HDLC > encapsulated PPP frame at the ISDN controller - right? Well, there are several choices to be made. Please read RFC 1618. > - however, > over X.21 I'm not sure at all I'm not terribly familiar with X.21 (at least by that name). It's just a serial link, right? Just use the same framing/escaping as RS-232. > and over Async RS-232-C, section 4 of the > RFC describes the method, however, I'm a little confused as to what it's > actually saying. Do you have any sample C code which you let me see to > understand how this works (particularly the bit about ACCMs). > Thank you for your timely questions. This was the "last call" period for comments. Based on your (and two others) confusion about ACCMs after splitting into 2 documents, and several suggestions, I have moved the ACCM entirely into its own section (which I have appended below). Please let me know if this clears up your confusion. > Oh, yes, what does this statement mean:? > "An octet stuffing procedure is used. The Control Escape octet is > defined as binary 01111101 (hexadecimal 0x7d) where the bit > positions are numbered 87654321 (not 76543210, BEWARE)." > I have re-written this section as follows: 4.2. Transparency An octet stuffing procedure is used. The Control Escape octet is defined as binary 01111101 (hexadecimal 0x7d), most significant bit first. As a minimum, sending implementations MUST escape the Flag Sequence and Control Escape octets. After FCS computation, the transmitter examines the entire frame between the two Flag Sequences. Each Flag Sequence, Control Escape octet, and any octet which is flagged in the sending Async-Control- Character-Map (ACCM), is replaced by a two octet sequence consisting of the Control Escape octet followed by the original octet exclusive-or'd with hexadecimal 0x20. This is bit 5 complemented, where the bit positions are numbered 76543210 (the 6th bit as used in ISO numbered 87654321 -- BEWARE when comparing documents). Receiving implementations MUST correctly process all Control Escape sequences. On reception, prior to FCS computation, each octet with value less than hexadecimal 0x20 is checked. If it is flagged in the receiving ACCM, it is simply removed (it may have been inserted by intervening data communications equipment). Each Control Escape octet is also removed, and the following octet is exclusive-or'd with hexadecimal 0x20, unless it is the Flag Sequence (which aborts a frame). A few examples may make this more clear. Escaped data is transmitted on the link as follows: 0x7e is encoded as 0x7d, 0x5e. (Flag Sequence) 0x7d is encoded as 0x7d, 0x5d. (Control Escape) 0x03 is encoded as 0x7d, 0x23. (ETX) Some modems with software flow control may intercept outgoing DC1 and DC3 ignoring the 8th (parity) bit. This data would be transmitted on the link as follows: 0x11 is encoded as 0x7d, 0x31. (XON) 0x13 is encoded as 0x7d, 0x33. (XOFF) 0x91 is encoded as 0x7d, 0xb1. (XON with parity set) 0x93 is encoded as 0x7d, 0xb3. (XOFF with parity set) ---- 7.1. Async-Control-Character-Map (ACCM) Description This Configuration Option provides a method to negotiate the use of control character transparency on asynchronous links. Each end of the asynchronous link maintains two Async-Control- Character-Maps. The receiving ACCM is 32 bits, but the sending ACCM may be up to 256 bits. This results in four distinct ACCMs, two in each direction of the link. 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. The default inclusion of all octets less than hexadecimal 0x20 allows all ASCII control characters [6] excluding DEL (Delete) to be transparently communicated through all known data communications equipment. The transmitter MAY also send octets with values in the range 0x40 through 0xff (except 0x5e) in Control Escape format. Since these octet values are not negotiable, this does not solve the problem of receivers which cannot handle all non-control characters. Also, since the technique does not affect the 8th bit, this does not solve problems for communications links that can send only 7- bit characters. Simpson expires in six months [Page 14] DRAFT HDLC-like Framing May 1994 Note that this specification differs in detail from later amendments, such as 3309:1991/Amendment 2 [3]. However, such "extended transparency" is applied only by "prior agreement". Use of the transparency methods in this specification constitute a prior agreement with respect to PPP. For compatibility with 3309:1991/Amendment 2, the transmitter MAY escape DEL and ACCM equivalents with the 8th (most significant) bit set. No change is required in the receiving algorithm. Following ACCM negotiation, the transmitter SHOULD cease escaping DEL. However, it is rarely necessary to map all control characters, and often it is unnecessary to map any control characters. The Configuration Option is used to inform the peer which control characters MUST remain mapped when the peer sends them. The peer MAY still send any other octets in mapped format, if it is necessary because of constraints known to the peer. The peer SHOULD Configure-Nak with the logical union of the sets of mapped octets, so that when such octets are spuriously introduced they can be ignored on receipt. A summary of the Async-Control-Character-Map Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ACCM +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACCM (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length 6 Simpson expires in six months [Page 15] DRAFT HDLC-like Framing May 1994 ACCM The ACCM field is four octets, and indicates the set of control characters to be mapped. The map is sent most significant octet first. Each numbered bit corresponds to the octet of the same value. If the bit is cleared to zero, then that octet need not be mapped. If the bit is set to one, then that octet MUST remain mapped. For example, if bit 19 is set to zero, then the ASCII control character 19 (DC3, Control-S) MAY be sent in the clear. Note: The least significant bit of the least significant octet (the final octet transmitted) is numbered bit 0, and would map to the ASCII control character NUL. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Mon May 23 09:22:48 1994 Received: from uu2.psi.com (uu2.psi.com [128.145.228.2]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA12401 for ; Mon, 23 May 1994 09:22:47 -0400 Received: from port21.boston.ma.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA00601 for ietf-ppp@merit.edu; Mon, 23 May 94 09:22:40 -0400 Received: from merit.edu by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA29618 for worley; Fri, 20 May 94 21:52:06 -0400 Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.128.4]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id VAA28670 for ; Fri, 20 May 1994 21:33:41 -0400 Received: from himagiri.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA09451 (5.65c/IDA-1.4.4nsd for ); Fri, 20 May 1994 18:33:38 -0700 Received: from localhost.NSD.3Com.COM by himagiri.NSD.3Com.COM with SMTP id AA22376 (5.65c/IDA-1.4.4-910725 for ); Fri, 20 May 1994 18:33:32 -0700 Message-Id: <199405210133.AA22376@himagiri.NSD.3Com.COM> To: ietf-ppp@merit.edu Cc: vsp@nsd.3com.com Subject: Calgary Corpus Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) Date: Fri, 20 May 94 18:33:31 -0700 From: Venkat Prasad Dave Carr had posted this.. >The 14 files used in the comparison are from the standard Calgary >Text Compression Corpus, available by ftp on ftp.cpsc.ucalgary.ca >[136.159.7.18] in /pub/text.compression.corpus/text.compression.corpus.tar.Z. I cannot seem to find these files at the ftp site. Has anyone been able to get them ? Is there an alternate site ? thanks for your help /Prasad - - - - - - - - - - - - - - - - - From list-admin Mon May 23 11:00:39 1994 Received: from adtrn722.adtran.com (adtrn722.adtran.com [198.51.35.247]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA19782 for ; Mon, 23 May 1994 11:00:35 -0400 Message-Id: <199405231500.LAA19782@merit.edu> Received: by adtrn722.adtran.com (1.37.109.4/16.2) id AA06624; Mon, 23 May 94 09:52:46 -0500 From: Kevin Schneider Subject: Re: Calgary Corpus To: vsp@nsd.3com.com Date: Mon, 23 May 94 9:52:46 CDT Cc: ietf-ppp@merit.edu In-Reply-To: <199405210133.AA22376@himagiri.NSD.3Com.COM>; from "Venkat Prasad" at May 20, 94 6:33 pm Mailer: Elm [revision: 70.85] > >The 14 files used in the comparison are from the standard Calgary > >Text Compression Corpus, available by ftp on ftp.cpsc.ucalgary.ca > >[136.159.7.18] in /pub/text.compression.corpus/text.compression.corpus.tar.Z. > > > I cannot seem to find these files at the ftp site. Has anyone been > able to get them ? Is there an alternate site ? > > thanks for your help the README file at ftp.cpsc.ucalgary.ca says that text.compression.corpus has been moved to projects/text.compression.corpus (and indeed it has been) so the path name of the file is: /pub/projects/text.compression.corpus/text.compression.corpus.tar.Z hope this helps. -- Kevin Schneider Phone: (205) 971-8024 ADTRAN, Inc. FAX: (205) 971-8751 901 Explorer Blvd. Huntsville, AL 35806-2807 email: kevin@adtran.com - - - - - - - - - - - - - - - - - From list-admin Mon May 23 11:31:28 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA22718 for ; Mon, 23 May 1994 11:31:27 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05921; 23 May 94 11:24 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-multilink-09.txt Date: Mon, 23 May 94 11:24:57 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9405231124.aa05921@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The PPP Multilink Protocol (MP) Author(s) : K. Sklower, B. Lloyd, G. McGregor, D. Carr Filename : draft-ietf-pppext-multilink-09.txt Pages : 20 Date : 05/20/1994 This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two system, including async links. This is accomplished by means of new PPP options and protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-multilink-09.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-multilink-09.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940520111010.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-multilink-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-multilink-09.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940520111010.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Tue May 24 12:04:00 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA27113 for ; Tue, 24 May 1994 12:03:57 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06541; 24 May 94 11:09 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-lcp-fs-02.txt Date: Tue, 24 May 94 11:09:34 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9405241109.aa06541@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : The Point-to-Point Protocol (PPP) Author(s) : W. Simpson Filename : draft-ietf-pppext-lcp-fs-02.txt Pages : 52 Date : 05/23/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating multi-protocol datagrams. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-lcp-fs-02.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-lcp-fs-02.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940523143615.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-lcp-fs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lcp-fs-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940523143615.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Tue May 24 12:26:28 1994 Received: from technet1.shl.com (technet1.shl.com [192.75.61.2]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA28972 for ; Tue, 24 May 1994 12:26:25 -0400 Received: from mm-gw.shl.com by technet1.shl.com (4.1/SMI-4.1.8) id AA22153; Tue, 24 May 94 09:22:32 PDT Received: by mm-gw.shl.com with Microsoft Mail id <2DE2281C@mm-gw.shl.com>; Tue, 24 May 94 09:15:24 PDT From: "FERLATTE John (SHINET01)" To: Bill Simpson - PPP Author , IETF PPP Commitee Subject: I know this may sound crazy but.. PPP over X.25 Async Date: Sat, 21 May 94 12:05:00 PDT Message-Id: <2DE2281C@mm-gw.shl.com> Encoding: 35 TEXT X-Mailer: Microsoft Mail V3.0 Hi there, I working on a project that requires the use of a PPP stack to communication over X.25 PDN's to a Terminal Server. I've been banging my head around with X.3 parm's and bit level traces for about 3 weeks now, and I'm sending in the plea for help. The scenario is as follows: 1. PC running chamelian (tried Novell and Distinct too) calls PDN (Async) 2. Script types in X.25 address to host PAD and directly connects to Terminal Server. 3. I see PPP frames arriving and LCP negotiation starts. 4. PPP should go active right ? NOT. I've traced the conversation and the same information seems to be exchanged as it would in a direct connect situation. ie. the terminal server sends 7E FF 7D 23 C0 21 7D ....and the PC stack respondes with FF 7D 23 C0 21 7D ..... I have had these to systems talking directly and over a local X.25 switch. I believe that timing may be the problem but I can't find any documentation on this. Please help !!! Regards, John Ferlatte (jferlatte@shl.com) PS: I can be reached ofter at 609 520 5403 - - - - - - - - - - - - - - - - - From list-admin Tue May 24 14:34:30 1994 Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.128.4]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA10008 for ; Tue, 24 May 1994 14:34:21 -0400 Received: from himagiri.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA23508 (5.65c/IDA-1.4.4nsd for ); Tue, 24 May 1994 11:33:57 -0700 Received: from localhost.NSD.3Com.COM by himagiri.NSD.3Com.COM with SMTP id AA24099 (5.65c/IDA-1.4.4-910725); Tue, 24 May 1994 11:33:52 -0700 Message-Id: <199405241833.AA24099@himagiri.NSD.3Com.COM> To: Kevin Schneider Cc: ietf-ppp@merit.edu Subject: Re: Calgary Corpus Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) In-Reply-To: Mail from Kevin Schneider dated Mon, 23 May 94 09:52:46 CDT <199405231500.AA12983@bridge2.NSD.3Com.COM> Date: Tue, 24 May 94 11:33:50 -0700 From: Venkat Prasad Thank you. I was able to get all the files from the ftp site. In my previous attempt I used the IP address in the message below and it took me to the wrong ftp site. If I use the alias I get to the right place. A few people asked me to let them know when I suceeded in getting the files and how. 1. ftp to the site 2. Login as anonymous with your email address as password. 3. cd to the directory /pub/projects/text.compression.corpus/text.compression.corpus.tar.Z 4. get the file 5. get the README file as well when you are at it. 6. quit ftp on your unix machine.. 7. uncompress text.compression.corpus.tar.Z 8. tar -xvf text.compression.corpus.tar /Prasad > >The 14 files used in the comparison are from the standard Calgary > >Text Compression Corpus, available by ftp on ftp.cpsc.ucalgary.ca > >[136.159.7.18] in /pub/text.compression.corpus/text.compression.corpus.tar.Z. > > > I cannot seem to find these files at the ftp site. Has anyone been > able to get them ? Is there an alternate site ? > > thanks for your help >> the README file at ftp.cpsc.ucalgary.ca says that text.compression.corpus >> has been moved to projects/text.compression.corpus (and indeed it has been) >> so the path name of the file is: >> /pub/projects/text.compression.corpus/text.compression.corpus.tar.Z >> hope this helps. >> -- >> Kevin Schneider Phone: (205) 971-8024 >> ADTRAN, Inc. FAX: (205) 971-8751 >> 901 Explorer Blvd. >> Huntsville, AL 35806-2807 email: kevin@adtran.com - - - - - - - - - - - - - - - - - From list-admin Tue May 24 19:14:50 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id TAA01206 for ; Tue, 24 May 1994 19:14:50 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (940519.SGI.8.6.9/910110.SGI) id QAA06971; Tue, 24 May 1994 16:14:38 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:dlr@daver.bungi.com id AA27501; Tue, 24 May 94 17:14:05 -0600 Date: Tue, 24 May 94 17:14:05 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9405242314.AA27501@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: CCP and multiple protocols ] From: Gerry Meyer ] Date: Thu, 19 May 1994 11:03:00 GMT ] ] The most recent PPP Compression Control Protocol draft I have, ] draft-ieft-pppext-compression-04.txt, no longer contains the ] following text (which appeared in an earlier draft): ] ] Compression algorithm options are listed in the order of their ] desireableness to the receiver. If the sender chooses to implement only ] one compression algorithm on the line (for example), he first determines ] what subset of the receiver's algorithms he can use, and among them ] chooses the most desireable - the first option listed. He must reject ] all others with a configure reject, and subsequently ACK the configure ] request for the single algorithm chosen. ] ]Has this mechanism been dropped? > From: "William Allen Simpson" > Date: Thu, 19 May 1994 15:24:58 GMT > > > Has this mechanism been dropped? > > > No, just made more standardly PPP-like. > > Now, you get a request. You Reject only those options you don't understand. > You Nak all of the ones you do understand. > > Then, the _sender_ sends a new request with only one option in it. > > Bill.Simpson@um.cc.umich.edu Is this the consensus? 1. What if the peer ACK's with the previous scheme, an ACK with only one option? Why not continue to make that legal? 2. If your receive a configure request containing 2 protocols, and they are both acceptible and have acceptible parameters? Why can't you ACK them both, and expect the peer to understand that the first is chosen? Why waste an entire complete packet exchange? 3. Doesn't it seem like an obnoxious pain to have NAK mean both "the parameters for these compression protocols must be changed before I'll take them" as well as "all of these protocols are peachy; pick one"? I think in the name of backward compatibility and speed, words like the following should be added: When a Configure-Request is received containing more than one protocol and all of the protocols are acceptible and have acceptible parameters, then the response MAY be a Configure-Ack containing only the single option for the first protocol. In this case, that single protocol is the one negotiated. Instead of a Configure-Ack containing only the first option from a Configure-Request listing several acceptible protocols with acceptible parameters, a Configure-Ack containing all of the options in exactly the same order as in the Configure-Request MAY be sent, and in this case the first protocol is the one negotiated. Instead of a Configure-Ack, a Configure-Nak MAY be sent, and in this case the peer MUST respond with a new Configure-Request containing a single protocol. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Tue May 24 19:43:53 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id TAA02651 for ; Tue, 24 May 1994 19:43:53 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (940519.SGI.8.6.9/910110.SGI) id QAA11951; Tue, 24 May 1994 16:43:42 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:dlr@daver.bungi.com id AA27592; Tue, 24 May 94 17:43:08 -0600 Date: Tue, 24 May 94 17:43:08 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9405242343.AA27592@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: CCP and multiple protocols On 2nd thought, I realize this does not make any sense: > > Now, you get a request. You Reject only those options you don't understand. > > You Nak all of the ones you do understand. > > > > Then, the _sender_ sends a new request with only one option in it. If you get a configure Request with several compression options, what does Nak'ing them mean? Should you Nak all of them or just some? If you Nak all of them, which single one should the peer respond with? Any of them? If you Nak all of them, is that a violation of the the PPP RFC that says "All acceptable Configuration Options from the Configure- Request are filtered out of the Configure-Nak ..." That says that if you like all of the offered protocols, you should respond with an empty Configure-Nak. According to the PPP RFC, if you get a boolean option you don't like, you Configure-Reject it. Should those compression options that are boolean (e.g. Predictor) be Configure-Rejected or Configure-Nak'ed? I think the previous scheme was better: If you find an option you like, Ack it and it alone. Otherwise, either Reject or Nak what you don't like or don't understand. This scheme is simple, clear, and fast. It is also as close to being standard PPP as we are going to get. vjs - - - - - - - - - - - - - - - - - From list-admin Wed May 25 11:54:32 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA00998 for ; Wed, 25 May 1994 11:54:31 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03569; 25 May 94 11:06 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-hdlc-fs-02.txt Date: Wed, 25 May 94 11:06:46 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9405251106.aa03569@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : PPP in HDLC-like Framing Author(s) : W. Simpson Filename : draft-ietf-pppext-hdlc-fs-02.txt Pages : 25 Date : 05/24/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of HDLC-like framing for PPP encapsulated packets. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-hdlc-fs-02.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-hdlc-fs-02.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940524141125.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-hdlc-fs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-hdlc-fs-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940524141125.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Wed May 25 14:38:49 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id OAA15297 for ; Wed, 25 May 1994 14:38:48 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (940519.SGI.8.6.9/910110.SGI) id LAA11541; Wed, 25 May 1994 11:36:51 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:tomc@digibd.com id AA00743; Wed, 25 May 94 12:35:54 -0600 Date: Wed, 25 May 94 12:35:54 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9405251835.AA00743@rhyolite.wpd.sgi.com> To: tomc@digibd.com (Tom Coradetti) Subject: Re: ppp nak Cc: ietf-ppp@merit.edu > From: tomc@digibd.com (Tom Coradetti) > Subject: ppp nak > To: vjs@sgi.sgi.com > > I think you read the PPP RFC wrong. The words are deceiving. > When constructing a PPP NAK from an PPP request > 'filled with the unacceptable options from the config-request' > means the option VALUES were unacceptable, not the option types. > 'acceptable options are filtered out' means, the NAK does not > waste time on options which could be ACKED since the option type > and value are both OK. > > Thus the NAK ends up containing new acceptable values to replace > old unacceptable values for option types which were always > acceptable. It can also contain additional option types or values > which the NAKing side considers acceptable. Yes, that is how I understand ordinary PPP Acks, Naks, and Rejects. > It thus makes no sense as you suggest to NAK a list of acceptable > values with an empty list. Ok. As you say, it's wierd to NAK options that are acceptible. So what should I do when my code gets a configure request containing 2 CCP options, and A. I do not recognize one of the protocols. B. I have no preference, and am willing to send packets compressed with either of the protocols. C. I prefer to send packets compressed with one of the two specified protocols. D. Either of the protocols would be acceptible, but only if the parameters of one of them are changed (e.g. a Configure-Req with Predictor and 15-bit BSD Compress, but I can only handle Predictor and 12-bit BSD Compress). I understand what to do in case A. I should send a Configure-Reject for the unrecognized protocol, although it is a waste of time and bandwidth if I like the other protocol. What about the other cases? I see the following choices: 1. Except in case D, NAK an empty list since all of the parameters and options are fine with me but I can't decide, and hope the peer will respond with a new Configure-Request with a single choice. It is unlike the rest of PPP to use an empty Configure-Nak. 2. In case D, NAK with only the not-quite acceptible protocol (e.g. 12-bit BSD Compress) and hope the peer understands that if it really wants the other one (e.g. Predictor) I'm happy to oblige. 3. send a NAK with both protocols (and in case D change the parameters) and hope the peer will send an Configure-Request with only one choice. Since the protocols are acceptible, this use of Configure-Nak is not like other uses of COnfigure-Nak in PPP. 4. send an ACK with a single choice and immediately start sending compressed packets, and do not bother to reject any unrecognized protocols as long as one is acceptible. 5. send an ACK with both choices and immediately start sending compressed packets using the first algorithm in the original Configure-Request As far as I understand, Mr. Simpson proposed either (1) or (3), but I don't know which. (4) was how I understood the old CCP Protocol. Note that all choices except (4) and (5) involve an extra, unnecessary exchange of packets and extra delay. Note that if both peers would really prefer one of the two protocols (e.g. BSD Compress or STAC), but the receiver initially Configure- Requests unacceptible parameters (e.g. 15-bits or history), then there is no way for the peers to pick that prefered protocol. I have recollections that the CCP draft said that the first usable protocol listed in the Configure-Request must be the choice. I cannot find those words in the new draft. Vernon Schryver, vjs@sgi.com P.S. I hope I am not making a mistake by including your privately addressed text in this message to the mailing list. - - - - - - - - - - - - - - - - - From list-admin Thu May 26 09:24:26 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA21432 for ; Thu, 26 May 1994 09:24:25 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02547; 26 May 94 8:56 EDT To: IETF-Announce:; Cc: IESG cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call2: The Point-to-Point Protocol (PPP) to Standard Date: Thu, 26 May 1994 08:56:08 -0400 Sender: jstewart@IETF.CNRI.Reston.VA.US Message-ID: <9405260856.aa02547@IETF.CNRI.Reston.VA.US> Note: This is the second Last Call for this document. The new version of the Internet-Draft reflects minor changes made as a result of comments received during the Last Call period. Another Last Call is being initiated because the document is up for the status of Internet Standard. The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "The Point-to-Point Protocol (PPP)" for the status of Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by 9 June 1994. IESG Secretary - - - - - - - - - - - - - - - - - From list-admin Thu May 26 09:36:59 1994 Received: from ucdavis.ucdavis.edu ([128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id JAA22441 for ; Thu, 26 May 1994 09:36:58 -0400 Received: from door.netcs.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id GAA02473; Thu, 26 May 1994 06:36:52 -0700 Received: from keks.netcs.com by door.netcs.com with SMTP (5.67a8+/25-eef) id AA16054; Thu, 26 May 1994 15:36:43 +0200 Received: by keks.netcs.com (5.67a8+/1.2-eef) id AA12747; Thu, 26 May 1994 15:36:40 +0200 Message-Id: <199405261336.AA12747@keks.netcs.com> Subject: PPP/PAP id question To: ietf-ppp@ucdavis.edu Date: Thu, 26 May 1994 15:36:39 +0200 (MEST) From: Oliver Korfmacher X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 798 X-Charset: LATIN1 X-Char-Esc: 29 Hi -- Can somebody comment on this behaviour using PAP: PPP: ppp_snd: PAP AuthReq (id 0xa9) we send an AuthReq with id field $A9 PAP: Starting -> ReqSent (wg. Up) PPP: ppp_rcv: PAP AuthReq (id 0x7) an AuthReq is receied with id field $07 PAP: code AuthReq gives event RCRplus id/pwd matches.. PPP: ppp_snd: PAP AuthAck (id 0x7) so we send an Ack, using the received id $07 PAP: ReqSent -> AckSent (wg. RCRplus) PPP: ppp_rcv: PAP AuthAck (id 0x7) BUT -- we receive an Ack to our own AuthReq with 7 NOT A9 PAP: AuthAck: id (is: 0x7, expecting 0xa9) mismatch -- packet ignored PPP: ppp_rcv: IPCP ConfReq (id 0x9) Do I misunderstand the specs? Or the remote site? Gruesse, Oliver Oliver Korfmacher (okorf@netcs.com, whois OK11 WWW: http://www.netcs.com/PEOPLE/okorf.html) - - - - - - - - - - - - - - - - - From list-admin Thu May 26 09:24:24 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA21430 for ; Thu, 26 May 1994 09:24:24 -0400 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02534; 26 May 94 8:55 EDT To: IETF-Announce:; Cc: IESG cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call2: PPP in HDLC-like Framing to Standard Date: Thu, 26 May 1994 08:55:07 -0400 Sender: jstewart@IETF.CNRI.Reston.VA.US Message-ID: <9405260855.aa02534@IETF.CNRI.Reston.VA.US> Note: This is the second Last Call for this document. The new version of the Internet-Draft reflects minor changes made as a result of comments received during the Last Call period. Another Last Call is being initiated because the document is up for the status of Internet Standard. The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "PPP in HDLC-like Framing" for the status of Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by 9 June 1994. IESG Secretary - - - - - - - - - - - - - - - - - From list-admin Thu May 26 11:36:27 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id LAA02957 for ; Thu, 26 May 1994 11:36:26 -0400 Received: from ftp.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id IAA16381; Thu, 26 May 1994 08:36:20 -0700 Received: by ftp.com ; Thu, 26 May 1994 11:34:51 -0400 Received: by ftp.com ; Thu, 26 May 1994 11:34:51 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405261534.AA15153@ftp.com> Subject: Re: PPP/PAP id question To: okorf@netcs.com (Oliver Korfmacher) Date: Thu, 26 May 1994 11:34:51 -0400 (EDT) Cc: ietf-ppp@ucdavis.edu In-Reply-To: <199405261336.AA12747@keks.netcs.com> from "Oliver Korfmacher" at May 26, 94 03:36:39 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 666 >> Can somebody comment on this behaviour using PAP: PAP Authenticate-Ack packets should contain the same ID as the Authenticate- Request packets contained. >> Do I misunderstand the specs? Or the remote site? You appear to understand it correctly. The reason for this (as well as all the other "match the ID" rules) is so that you don't listen to responses from older packets, which could potentially cause problems (though the number of problems you'd encounter in the PAP case is pretty limited ;-). -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; - - - - - - - - - - - - - - - - - From list-admin Thu May 26 11:46:43 1994 Received: from cayman.Cayman.COM (cayman.Cayman.COM [143.137.137.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id LAA03872 for ; Thu, 26 May 1994 11:46:43 -0400 Received: from cuba.Cayman.COM (cuba.Cayman.COM [143.137.50.12]) by cayman.Cayman.COM (8.6.4/ECB-1.3) with SMTP id LAA01190; Thu, 26 May 1994 11:46:04 -0400 Received: from inagua.Cayman.COM by cuba.Cayman.COM (4.1/SMI-4.1) id AA07928; Thu, 26 May 94 11:46:02 EDT From: scott@Cayman.COM (Scott Adams) Message-Id: <9405261546.AA07928@cuba.Cayman.COM> Subject: A question about CHAP and RFC1334... To: ietf-ppp@merit.edu Date: Thu, 26 May 1994 11:46:01 -0400 (EDT) Cc: alan@midnight.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1777 Cayman has been using a PPP test tool set just developed by a company named Midnight Networks (midnight@midnight.com) to unit and QA test our soon-to-be-release implementation of PPP. During testing of CHAP we encountered an ambiguity in RFC1334 that I'm hoping someone can help clear up for us: In RFC1334 section 3.2.1, the paragraph describing the Value field on page 13 states: The Response Value is the one-way hash calculated over a stream of octets consisting of the Identifier, followed by (concatenated with) the "secret", followed by (concatenated with) the Challenge Value. The length of the Response Value depends upon the hash algorithm used (16 octets for MD5). What isn't clear is which "secret" this is. Is it the "secret" of/for the peer being authenticated, or the "secret" of/for the authenticator? I read it as being the secret of the peer being authenticated (ie: both the name and secret in the Response packet are for the same machine). This is consistent with PAP where the authenticated peer sends an Authentication request with its name and password. From my discussions with Alan Steele of Midnight, implementations from different vedors interpret this differently. At least one implementation returns the "secret" associated with the name in the CHAP Challenge packet (ie: the authenticator's "secret"). Another implementation avoids the ambiguity by requiring both PPP peers to have the same "secret." This issue may have been clarified earlier, but because it isn't in the RFC and I haven't been on the ietf-ppp mailing list very long, I haven't seen the resolution. If the ambiguity still exists, then this will undoubtably impact interoperability. Scott Adams Cayman Systems, Inc. scott@cayman.com - - - - - - - - - - - - - - - - - From list-admin Thu May 26 11:59:59 1994 Received: from ucdavis.ucdavis.edu ([128.120.250.250]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id LAA04949 for ; Thu, 26 May 1994 11:59:59 -0400 Received: from fennel.acc.com by ucdavis.ucdavis.edu (8.6.8/UCD2.50) id IAA19079; Thu, 26 May 1994 08:59:54 -0700 Received: from opal.acc.com by fennel.acc.com (4.1/SMI-4.1) id AA05221; Thu, 26 May 94 08:27:02 PDT Date: Thu, 26 May 94 08:27:02 PDT From: art@acc.com (Art Berggreen) Message-Id: <9405261527.AA05221@fennel.acc.com> To: ietf-ppp@ucdavis.edu, okorf@netcs.com Subject: Re: PPP/PAP id question > >Can somebody comment on this behaviour using PAP: > > >PPP: ppp_snd: PAP AuthReq (id 0xa9) > we send an AuthReq with id field $A9 > >PAP: Starting -> ReqSent (wg. Up) >PPP: ppp_rcv: PAP AuthReq (id 0x7) > an AuthReq is receied with id field $07 > >PAP: code AuthReq gives event RCRplus > id/pwd matches.. > >PPP: ppp_snd: PAP AuthAck (id 0x7) > so we send an Ack, using the received id $07 > >PAP: ReqSent -> AckSent (wg. RCRplus) >PPP: ppp_rcv: PAP AuthAck (id 0x7) > BUT -- we receive an Ack to our own AuthReq with 7 NOT A9 > >PAP: AuthAck: id (is: 0x7, expecting 0xa9) mismatch -- packet ignored >PPP: ppp_rcv: IPCP ConfReq (id 0x9) > >Do I misunderstand the specs? Or the remote site? From RFC1334: Code 2 for Authenticate-Ack; 3 for Authenticate-Nak. Identifier The Identifier field is one octet and aids in matching requests and replies. The Identifier field MUST be copied from the Identifier field of the Authenticate-Request which caused this reply. I'd say that the remote implementation has a bug. I wonder if it's using a single variable to maintain the Authentication packet ID for both directions. Art - - - - - - - - - - - - - - - - - From list-admin Thu May 26 14:05:12 1994 Received: from Shiva.COM (Shiva.COM [192.80.57.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA15798 for ; Thu, 26 May 1994 14:05:06 -0400 Received: by Shiva.COM (1.34b) Thu, 26 May 94 14:04:47 EDT Date: Thu, 26 May 94 14:04:47 EDT From: John Gregg Message-Id: <9405261804.AA26775@Shiva.COM> To: scott@cayman.com, wilson@ftp.com Subject: Re: A question about CHAP and RFC1334... Cc: alan@midnight.com, ietf-ppp@merit.edu I guess I don't understand. In order for CHAP to work, each side must perform the hash on the same secret, known to each but never transmitted over the link except in the form of the hash of the secret, the ID, and the challenge value. Where is the ambiguity? There is the provision for the Name field distinguishing between different peer or user records, I suppose. That is, if I send a Challenge, you send a Response with your name "fred" in the Name field, I look up "fred" in my list of peer records to find what secret you used to perform your hash. I then perform the hash on that secret, with the ID and value I sent you and compare the result to that in your Response. Does this square with other peoples' understanding of CHAP and the Name field? It seems to me that the bottom line is this: if I challenge you, at some point I have to know for certain what secret you used to compute the value in your Response, whether we call that "my secret", "your secret", or "our little secret". -JRG3 "I do not claim that universes like ours occur frequently, merely that the expected frequency is non-zero." -Edward Tyron - - - - - - - - - - - - - - - - - From list-admin Thu May 26 12:37:05 1994 Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA08601 for ; Thu, 26 May 1994 12:37:04 -0400 Received: by ftp.com ; Thu, 26 May 1994 12:36:58 -0400 Received: by ftp.com ; Thu, 26 May 1994 12:36:58 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405261636.AA18135@ftp.com> Subject: Re: A question about CHAP and RFC1334... To: scott@cayman.com (Scott Adams) Date: Thu, 26 May 1994 12:36:58 -0400 (EDT) Cc: ietf-ppp@merit.edu, alan@midnight.com In-Reply-To: <9405261546.AA07928@cuba.Cayman.COM> from "Scott Adams" at May 26, 94 11:46:01 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1006 >> In RFC1334 section 3.2.1, the paragraph describing the Value field on >> page 13 states: >> >> The Response Value is the one-way hash calculated over a stream of >> octets consisting of the Identifier, followed by (concatenated >> with) the "secret", followed by (concatenated with) the Challenge >> Value. The length of the Response Value depends upon the hash >> algorithm used (16 octets for MD5). Our CHAP implementation for Windows uses the secret of the authenticated. We interoperated with everybody at PPPathon with this CHAP (I don't recall you guys doing CHAP then, though I could be wrong). When you think about it, this makes sense ... any number of users could call in at any time, and if their CHAP responses were always using the remote side's secret, I could spoof myself to be anybody at all. -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; - - - - - - - - - - - - - - - - - From list-admin Thu May 26 14:52:14 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA20185 for ; Thu, 26 May 1994 14:51:55 -0400 Received: by ftp.com ; Thu, 26 May 1994 14:51:25 -0400 Received: by ftp.com ; Thu, 26 May 1994 14:51:25 -0400 From: wilson@ftp.com (Brad Wilson) Message-Id: <9405261851.AA23079@ftp.com> Subject: Re: A question about CHAP and RFC1334... To: jgregg@shiva.com (John Gregg) Date: Thu, 26 May 1994 14:51:25 -0400 (EDT) Cc: scott@cayman.com, wilson@ftp.com, alan@midnight.com, ietf-ppp@merit.edu In-Reply-To: <9405261804.AA26775@Shiva.COM> from "John Gregg" at May 26, 94 02:04:47 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 485 >> It seems to me that the bottom >> line is this: if I challenge you, at some point I have to know for certain >> what secret you used to compute the value in your Response, whether we >> call that "my secret", "your secret", or "our little secret". A much better explanation than mine. ;-) And entirely right. -- Brad Wilson Share and Enjoy! Voice: (800)282-4FTP Fax: (508)659-6297 Not speaking for FTP Software, Inc. Internet: wilson@ftp.com msg++; - - - - - - - - - - - - - - - - - From list-admin Thu May 26 16:41:32 1994 Received: from Shiva.COM (Shiva.COM [192.80.57.1]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id QAA00971 for ; Thu, 26 May 1994 16:41:30 -0400 Received: by Shiva.COM (1.34b) Thu, 26 May 94 16:41:28 EDT Date: Thu, 26 May 94 16:41:28 EDT From: John Gregg Message-Id: <9405262041.AA09369@Shiva.COM> To: ietf-ppp@merit.edu Subject: Re: A question about CHAP and RFC1334... I understand more now. The ambiguity is this: If I ("John") Challenge you ("fred"), a) do I have a single secret which I use and I expect you to use, in which case you have a list of secrets of all the peers which might Challenge you (you look up "John" to get the right secret to use), or b) do you have one secret that you always use, and I know which one that is by looking up "fred" (from the Name field in your Response) in *my* list of secrets? Indeed, the spec is silent on this point. Option b seems somehow more appealing to me, as it maps more directly to other authentication models, i.e. lots of different people trying to log into a single device which has a list of username/password pairs. Option b would certainly make CHAP authentication more analogous to PAP, and thus make things a lot easier for us, since we have user records with a bunch of information associated with each user (permissions and such). Its nice to know who is logging into you. Also, presumably if they called you, they already know who you are (althogh there is no requirement that the callee does the authenticating, but I bet it works out that way most often). -JRG3 - - - - - - - - - - - - - - - - - From list-admin Fri May 27 13:36:14 1994 Received: from cayman.Cayman.COM (cayman.Cayman.COM [143.137.137.1]) by merit.edu (8.6.8.1/merit-1.0) with ESMTP id NAA22219 for ; Fri, 27 May 1994 13:36:13 -0400 Received: from cuba.Cayman.COM (cuba.Cayman.COM [143.137.50.12]) by cayman.Cayman.COM (8.6.4/ECB-1.3) with SMTP id NAA13348; Fri, 27 May 1994 13:35:40 -0400 Received: from inagua.Cayman.COM by cuba.Cayman.COM (4.1/SMI-4.1) id AA13207; Fri, 27 May 94 13:35:38 EDT From: scott@cayman.com (Scott Adams) Message-Id: <9405271735.AA13207@cuba.Cayman.COM> Subject: Re: A question about CHAP and RFC1334... To: jgregg@shiva.com (John Gregg) Date: Fri, 27 May 1994 13:35:37 -0400 (EDT) Cc: ietf-ppp@merit.edu In-Reply-To: <9405262041.AA09369@Shiva.COM> from "John Gregg" at May 26, 94 04:41:28 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1788 Yes, you've stated it well... > > > I understand more now. The ambiguity is this: If I ("John") > Challenge you ("fred"), a) do I have a single secret which I use and I > expect you to use, in which case you have a list of secrets of all the > peers which might Challenge you (you look up "John" to get the right > secret to use), or b) do you have one secret that you always use, and I know > which one that is by looking up "fred" (from the Name field in your Response) > in *my* list of secrets? Indeed, the spec is silent on this point. Option Exactly my concern...in the interests of interoperability it would be nice to have this clarified. > b seems somehow more appealing to me, as it maps more directly to other > authentication models, i.e. lots of different people trying to log into a > single device which has a list of username/password pairs. Option b would > certainly make CHAP authentication more analogous to PAP, and thus make > things a lot easier for us, since we have user records with a bunch of > information associated with each user (permissions and such). Its nice to That's my feeling, and I suspect most of the other implementor's out there agree as well (the limited response I've gotten certainly indicates so). > know who is logging into you. Also, presumably if they called you, they > already know who you are (althogh there is no requirement that the callee > does the authenticating, but I bet it works out that way most often). This is true in a "client/server" type situation, but what about router/router (which seems less obvious)? Between two routers that can call each other, it seems to make more sense to de-couple authentication roles (authenticator/authenticatee) from initiator/initiatee roles. Scott > > > -JRG3 > - - - - - - - - - - - - - - - - -