From ietf-ppp-request@MERIT.EDU Wed Nov 1 10:21:31 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA26338; Wed, 1 Nov 1995 10:21:31 -0500 Resent-Date: Wed, 1 Nov 1995 10:21:31 -0500 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-ipcp-network-00.txt Date: Wed, 01 Nov 95 09:30:11 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9511010930.aa11023@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"6pxhE2.0.6R6.K1vbm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/794 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The PPP Internet Protocol Control Protocol (IPCP) Author(s) : G. McGregor, G. Pall Filename : draft-ietf-pppext-ipcp-network-00.txt Pages : 13 Date : 10/31/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring the Internet Protocol [2] over PPP, and a method to negotiate and use Van Jacobson TCP/IP header compression [3] with PPP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-ipcp-network-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-ipcp-network-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-ipcp-network-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19951031091203.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ipcp-network-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ipcp-network-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951031091203.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 12:23:26 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA29887; Wed, 1 Nov 1995 12:23:26 -0500 Resent-Date: Wed, 1 Nov 1995 12:23:26 -0500 Date: Wed, 1 Nov 1995 10:22:30 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511011722.KAA20481@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: new IPCP draft and Address option Resent-Message-ID: <"AhDPk2.0.mI7.Aqwbm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/795 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU As I read the new IPCP draft, a Configure-Reject for an Address option can mean two different things: Configure-Rej to indicate that the responding peer does not implement this option. and only a few lines later: Configure-Rej implying that the responding peer is not configured to assign an IP-address or that the responding peer does not implement this option. If the Configure-Request was for 0.0.0.0, how do you tell whether a Configure-Reject means "don't do Addresses at all" or "don't do address assignment"? When you get a Configure-Reject of a Request for 0.0.0.0, must you stop sending all Address requests or can you fall back on an IP address? This is not an academic question. My code tries to be (too?) smart about the IP addresses. The default configuration is happy to use the IP address found on the primary network interface (typically Ethernet) for its end of the PPP link, but is also willing to accept the peer's preference. I'm not sure, but I think the new language at best confuses what I can do. By the way, I think "Configure-Rej" is an undesirable abreviation for "Configure-Reject" in a standards document. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 13:05:38 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA01200; Wed, 1 Nov 1995 13:05:38 -0500 Resent-Date: Wed, 1 Nov 1995 13:05:38 -0500 Date: Wed, 1 Nov 1995 11:05:00 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511011805.LAA20579@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: IPCP and address options Resent-Message-ID: <"fo88E.0.VI.lRxbm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/796 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU (I appologize for being so scatter-brained as to require 2 messages to say what I should have said in 1.) I think that Configure-Reject should be reserved only for meaning "don't send me any more Address Options", and that something else should be done as a negative response to a -Request asking for 0.0.0.0. Nak for 0.0.0.0 seems to me to mean "gee, I don't know either; are you sure you don't have some idea?" as a response to a Configure-Request asking for 0.0.0.0. Yes, there is a danger if unthinking implementors persist in sending Requests for 0.0.0.0 after receiving a Nak for 0.0.0.0. So fix that by saying something like "you MUST NOT send a Request for 0.0.0.0 after receiving a Nak for 0.0.0.0. If you cannot allocate your own adddress, stop sending -Requests". (I think that also handles all cases of lost packets.) Or since if neither peer knows a good IP address (and if you're not doing un-numbered links), you're dead, don't fix it and just wait until the retry timer kills the link. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 13:15:56 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA01509; Wed, 1 Nov 1995 13:15:56 -0500 Resent-Date: Wed, 1 Nov 1995 13:15:56 -0500 From: "Al Longyear" Message-Id: <199511011815.KAA00535@sii-4-30.sii.com> Subject: Re: new IPCP draft and Address option To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Wed, 1 Nov 1995 10:15:43 -0800 (PST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199511011722.KAA20481@mica.denver.sgi.com> from "Vernon Schryver" at Nov 1, 95 10:22:30 am Reply-To: "Al Longyear" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"reVYb.0.MN.Pbxbm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/797 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver wrote: > > As I read the new IPCP draft, a Configure-Reject for an Address option > can mean two different things: > > Configure-Rej to indicate that the responding peer does not > implement this option. > > and only a few lines later: > > Configure-Rej implying that the responding peer is not > configured to assign an IP-address or that the responding > peer does not implement this option. > > If the Configure-Request was for 0.0.0.0, how do you tell whether a > Configure-Reject means "don't do Addresses at all" or "don't do address > assignment"? When you get a Configure-Reject of a Request for 0.0.0.0, > must you stop sending all Address requests or can you fall back on an > IP address? (Sorry if I state what you may feel is the obvious. I am only trying to be complete. It helps me since I may have the wrong understanding as well.) Of course, this implies that the PPP sender understands the CI for the IP address. If the CI is not understood then a Conf-REJect is proper. However, I contend that the end result will be the same. The side sending the configure request (and now receiving the Conf-REJect) will not be successful in bringing up routing for the IP layer. I would take it to mean that a Conf-Req of 0.0.0.0 has responses of the following: Configure-Conf-NAK of 0.0.0.0 This is clearly broken. If it doesn't like 0.0.0.0 now then how will it accept 0.0.0.0 the next time that it is requested? Configure-Conf-NAK of non-zero This is the common response. Configure-ACK of 0.0.0.0 This means that the IP address is not significant. You need some other form of routing to deliver the frames to the PPP link. Possibly you have two systems which have nothing but PPP and this is not important to negotiate an IP address. Configure-Conf-REJ of 0.0.0.0 This means that you don't have a suitable replacement for the IP address. However, you need to have an IP address or you would have answered with an ACK message. The Conf-REJ is just a way of stopping the previous alternate of sending an ACK with 0.0.0.0 and then taking down the IP layer once it goes up since you don't have the required IP address. As to whether or not the Conf-REJ frame means "I don't understand the CI for the IP address" or "I don't have a value for your IP address" then the answer really belongs on the Conf-REJ sender's perspective. To the receiver of the Conf-REJ frame, it means one thing "Don't send an IP address of 0.0.0.0. I don't have an IP address for you. Quit asking. However, I won't accept the connection because I too need the IP address and since you can't supply one, we will be in trouble." > This is not an academic question. My code tries to be (too?) smart > about the IP addresses. The default configuration is happy to use the > IP address found on the primary network interface (typically Ethernet) > for its end of the PPP link, but is also willing to accept the peer's > preference. I'm not sure, but I think the new language at best > confuses what I can do. You seem to indicate that you 'seed' the IP address with the IP address of the ethernet but will accept the peer's Conf-NAK of your address for the IP address of the PPP link. I see nothing wrong with this. You should NEVER see a Conf-NAK with 0.0.0.0 as that would be from a broken implementation. In your implementation, you should never see a Conf-REJ with 0.0.0.0 since you didn't send a Conf-Req with 0.0.0.0. (This is, of course, unless your ethernet address is 0.0.0.0. In that case, you will have other problems. :) ) -- Al Longyear longyear@sii.com The above opinions do not necessarily represent those of the Management of System Integrators nor any of its subsidiaries. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 13:36:16 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA02257; Wed, 1 Nov 1995 13:36:16 -0500 Resent-Date: Wed, 1 Nov 1995 13:36:16 -0500 Date: Wed, 1 Nov 1995 11:33:59 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511011833.LAA20685@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: new IPCP draft and Address option Resent-Message-ID: <"i9tmj1.0.2Z.Uuxbm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/799 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Al Longyear" > To: vjs (Vernon Schryver) > Cc: ietf-ppp@merit.edu > > As I read the new IPCP draft, a Configure-Reject for an Address option > > can mean two different things: > > > > Configure-Rej to indicate that the responding peer does not > > implement this option. > > > > and only a few lines later: > > > > Configure-Rej implying that the responding peer is not > > configured to assign an IP-address or that the responding > > peer does not implement this option. > > > > If the Configure-Request was for 0.0.0.0, how do you tell whether a > > Configure-Reject means "don't do Addresses at all" or "don't do address > > assignment"? When you get a Configure-Reject of a Request for 0.0.0.0, > > must you stop sending all Address requests or can you fall back on an > > IP address? > Of course, this implies that the PPP sender understands the CI for the > IP address. What is a "CI"? An IPCP Configure-Request option of type 3? > If the CI is not understood then a Conf-REJect is > proper. However, I contend that the end result will be the same. The > side sending the configure request (and now receiving the Conf-REJect) > will not be successful in bringing up routing for the IP layer. Not so, at least in the cases I mean. > I would take it to mean that a Conf-Req of 0.0.0.0 has responses of > the following: > > Configure-Conf-NAK of 0.0.0.0 > This is clearly broken. If it doesn't like 0.0.0.0 now then how will > it accept 0.0.0.0 the next time that it is requested? What is a "Configure-Conf-NAK"? If it is an IPCP Configure-Nak containing an option of type 3, then Consider this case: Configure-Request 0.0.0.0 ---> (hey, server, what do you think?) <--- Nak 0.0.0.0 (gee, I don't know) Configure-Requst 1.2.3.4 ---> (well, we could always my addr) <--- Ack (well, ok) > Configure-Conf-NAK of non-zero > This is the common response. > > Configure-ACK of 0.0.0.0 > This means that the IP address is not significant. You need some > other form of routing to deliver the frames to the PPP link. Possibly > you have two systems which have nothing but PPP and this is not > important to negotiate an IP address. > > Configure-Conf-REJ of 0.0.0.0 > This means that you don't have a suitable replacement for the IP > address. However, you need to have an IP address or you would have > answered with an ACK message. > > The Conf-REJ is just a way of stopping the previous alternate of > sending an ACK with 0.0.0.0 and then taking down the IP layer once it > goes up since you don't have the required IP address. That is not what Configure-Rejects mean in general, nor what the previous paragraph in the draft says. In general, a Configure-Reject means "we don't do option X at all; stop bugging me with it." > As to whether or not the Conf-REJ frame means "I don't understand the CI > for the IP address" or "I don't have a value for your IP address" then > the answer really belongs on the Conf-REJ sender's perspective. > > To the receiver of the Conf-REJ frame, it means one thing "Don't send an > IP address of 0.0.0.0. I don't have an IP address for you. Quit > asking. However, I won't accept the connection because I too need the > IP address and since you can't supply one, we will be in trouble." Not so. In general, a Configure-Reject means don't send that option ever again no matter what value you might put in it. > > This is not an academic question. My code tries to be (too?) smart > > about the IP addresses. The default configuration is happy to use the > > IP address found on the primary network interface (typically Ethernet) > > for its end of the PPP link, but is also willing to accept the peer's > > preference. I'm not sure, but I think the new language at best > > confuses what I can do. > > You seem to indicate that you 'seed' the IP address with the IP address > of the ethernet but will accept the peer's Conf-NAK of your address for the > IP address of the PPP link. > > I see nothing wrong with this. > > You should NEVER see a Conf-NAK with 0.0.0.0 as that would be from a broken > implementation. I do not think so. > In your implementation, you should never see a Conf-REJ with 0.0.0.0 > since you didn't send a Conf-Req with 0.0.0.0. (This is, of course, unless > your ethernet address is 0.0.0.0. In that case, you will have other > problems. :) ) That makes no sense to me. If you send a Configure-Requests with 0.0.0.0, you can expect to encounter systems that do not do the Address option and so can expect to receive Configure-Rejects with 0.0.0.0 that mean the peer doesn't do Address options. If you overload Configure-Reject to also mean "I don't do dynamic assignment," then how do you tell the difference? How do you fall back on static addresses? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 13:32:46 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA02158; Wed, 1 Nov 1995 13:32:46 -0500 Resent-Date: Wed, 1 Nov 1995 13:32:46 -0500 Date: Wed, 1 Nov 95 10:37:11 PST From: roger@flowpoint.com (Philippe Roger) Message-Id: <9511011837.AA12091@flowpoint.com> To: ietf-ppp@MERIT.EDU Subject: Re: IPCP and address options Resent-Message-ID: <"UlZgN2.0.SX.Brxbm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/798 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > (I appologize for being so scatter-brained as to require 2 messages to > say what I should have said in 1.) > > I think that Configure-Reject should be reserved only for meaning "don't > send me any more Address Options", and that something else should > be done as a negative response to a -Request asking for 0.0.0.0. > > Nak for 0.0.0.0 seems to me to mean "gee, I don't know either; are you > sure you don't have some idea?" as a response to a Configure-Request > asking for 0.0.0.0. > > Yes, there is a danger if unthinking implementors persist in sending > Requests for 0.0.0.0 after receiving a Nak for 0.0.0.0. So fix that by > saying something like "you MUST NOT send a Request for 0.0.0.0 after > receiving a Nak for 0.0.0.0. If you cannot allocate your own adddress, > stop sending -Requests". (I think that also handles all cases of lost > packets.) > > Or since if neither peer knows a good IP address (and if you're not > doing un-numbered links), you're dead, don't fix it and just wait > until the retry timer kills the link. > > > Vernon Schryver, vjs@sgi.com > I too was bothered by the wording of the new IPCP draft, and as Vernon suggests, I support the idea of sending a NAK with 0.0.0.0 when I don't have an address to assign to my peer. In fact, I had it implemented that way already... I haven't seen any case where this causes trouble (other than my peer not getting its IP address). At any rate, even if the sender of the Configure-Request keeps trying with 0.0.0.0 instead of giving up, the retry count and timer will kick in and drop the link, as Vernon points out. The other thought was to also allow unnumbered links by using an address of 0.0.0.0 (really meaning "No Address") as some implementations are not happy at all when they don't get the IP Address option. In that case, sending a Configure-Ack with 0.0.0.0 would indicate that there is no address on the remote side of the link. This implies that the receiver of the Configure-Ack does not blindly apply the IP address returned to it to its interface, but checks for validity first (it should check anyway!). Philippe Roger, roger@flowpoint.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 14:14:03 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA03659; Wed, 1 Nov 1995 14:14:03 -0500 Resent-Date: Wed, 1 Nov 1995 14:14:03 -0500 From: Karl Fox Date: Wed, 1 Nov 95 14:13:22 -0500 Message-Id: <9511011913.AA00650@gefilte.MorningStar.Com> To: ietf-ppp@MERIT.EDU Subject: Re: IPCP and address options In-Reply-To: <9511011837.AA12091@flowpoint.com> References: <9511011837.AA12091@flowpoint.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"FAV761.0.wu.uRybm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/801 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hey folks, please don't go breaking things that already work. It would also be nice if IPCP continued to follow the state machine rules laid out in RFC 1661. Remember that a Configure-Request doesn't contain requests for performance by the peer, but rather a statement of capabilities of the sender. Here's what I understand various IPCP messages to mean: IPCP Configure-Request with a non-zero IP-Address: `This is what I think my IP address should be' IPCP Configure-Nak with a non-zero IP-Address: `This is what I think your IP address should be' Note that the above Nak could be in response to a zero IP-Address, a non-zero IP-Address, or in response to a Configure-Request with no IP-Address option at all. IPCP Configure-Ack with a non-zero IP-address: `I agree, this is what your IP address should be' IPCP Configure-Request with a zero IP-Address: `I don't know what my IP address should be' IPCP Configure-Ack with a zero IP-address: `I agree; you don't know what your IP address should be, and neither do I' Here's a weird one: IPCP Configure-Nak with a zero IP-Address: `I think you don't know what your IP address should be' unless the Nak is in response to a Configure-Request with no IP-Address option, in which case it would mean `I sure wish I knew what you think your IP address should be' otherwise it probably means `I am a broken implementation' Last, of course, is IPCP Configure-Reject for any IP-Address: `What the hell is this option 3 nonsense?' Let's please not redefine the semantics of these messages. It would probably cause many people (including me) a lot of interoperability headaches. Thanks! -- Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 14:13:27 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA03617; Wed, 1 Nov 1995 14:13:27 -0500 Resent-Date: Wed, 1 Nov 1995 14:13:27 -0500 From: "Al Longyear" Message-Id: <199511011913.LAA00598@sii-4-30.sii.com> Subject: Re: new IPCP draft and Address option To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Wed, 1 Nov 1995 11:13:17 -0800 (PST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199511011833.LAA20685@mica.denver.sgi.com> from "Vernon Schryver" at Nov 1, 95 11:33:59 am Reply-To: "Al Longyear" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Okj6w2.0.Hu.KRybm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/800 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver wrote: > > > Of course, this implies that the PPP sender understands the CI for the > > IP address. > > What is a "CI"? An IPCP Configure-Request option of type 3? For the IP address, it would be 3. > > If the CI is not understood then a Conf-REJect is > > proper. However, I contend that the end result will be the same. The > > side sending the configure request (and now receiving the Conf-REJect) > > will not be successful in bringing up routing for the IP layer. > > Not so, at least in the cases I mean. > > > > I would take it to mean that a Conf-Req of 0.0.0.0 has responses of > > the following: > > > > Configure-Conf-NAK of 0.0.0.0 > > This is clearly broken. If it doesn't like 0.0.0.0 now then how will > > it accept 0.0.0.0 the next time that it is requested? > > What is a "Configure-Conf-NAK"? If it is an IPCP Configure-Nak > containing an option of type 3, then Consider this case: It was my editor which messed things up when I changed "NAK" to "Conf-NAK". I missed this bug-a-boo. Sorry. > Configure-Request 0.0.0.0 ---> > (hey, server, what do you think?) > <--- Nak 0.0.0.0 > (gee, I don't know) No. This is something, in my understanding, should not happen. It means that "I don't like 0.0.0.0 however if you send the request again with 0.0.0.0, I will accept it." The NAK is a suggested value. If you don't want the option at all then it is a REJect condition, not a NAK. > Configure-Requst 1.2.3.4 ---> > (well, we could always my addr) > <--- Ack > (well, ok) Ok. This is normal. > > > Configure-Conf-NAK of non-zero > > This is the common response. > > > > Configure-ACK of 0.0.0.0 > > This means that the IP address is not significant. You need some > > other form of routing to deliver the frames to the PPP link. Possibly > > you have two systems which have nothing but PPP and this is not > > important to negotiate an IP address. > > > > Configure-Conf-REJ of 0.0.0.0 > > This means that you don't have a suitable replacement for the IP > > address. However, you need to have an IP address or you would have > > answered with an ACK message. > > > > The Conf-REJ is just a way of stopping the previous alternate of > > sending an ACK with 0.0.0.0 and then taking down the IP layer once it > > goes up since you don't have the required IP address. > > That is not what Configure-Rejects mean in general, nor what the > previous paragraph in the draft says. In general, a Configure-Reject > means "we don't do option X at all; stop bugging me with it." I agree. We both are saying the same thing. "Don't bother me with this option since I can't accept it." Since the side can not accept "IP address 0.0.0.0" and it can not generate a suitable NAK and the ACK of 0.0.0.0 (which is the only suitable IP address for an ACK, given the request of 0.0.0.0) would be in-appropriate then the only condition left is REJ. It means the same disasterous thing to the receiver. > > As to whether or not the Conf-REJ frame means "I don't understand the CI > > for the IP address" or "I don't have a value for your IP address" then > > the answer really belongs on the Conf-REJ sender's perspective. > > > > To the receiver of the Conf-REJ frame, it means one thing "Don't send an > > IP address of 0.0.0.0. I don't have an IP address for you. Quit > > asking. However, I won't accept the connection because I too need the > > IP address and since you can't supply one, we will be in trouble." > > Not so. In general, a Configure-Reject means don't send that option > ever again no matter what value you might put in it. I agree. However, that is not any different than "I don't have any replacement value for your option." You are still left with the question of wether or not the receiver of the configure-request frame understood the option 3 for the IP address or not. If it did understand the option, then it means that it has no suitable IP address for the NAK frame. I contend that the ACK is not appropriate if you need an IP address. I contend that the NAK is not appropriate unless you are able to supply a different value for the IP address. > > You seem to indicate that you 'seed' the IP address with the IP address > > of the ethernet but will accept the peer's Conf-NAK of your address for the > > IP address of the PPP link. > > > > I see nothing wrong with this. > > > > You should NEVER see a Conf-NAK with 0.0.0.0 as that would be from a broken > > implementation. > > I do not think so. > > > In your implementation, you should never see a Conf-REJ with 0.0.0.0 > > since you didn't send a Conf-Req with 0.0.0.0. (This is, of course, unless > > your ethernet address is 0.0.0.0. In that case, you will have other > > problems. :) ) > > That makes no sense to me. > If you send a Configure-Requests with 0.0.0.0, you can expect to > encounter systems that do not do the Address option and so can expect > to receive Configure-Rejects with 0.0.0.0 that mean the peer doesn't do > Address options. > > If you overload Configure-Reject to also mean "I don't do dynamic > assignment," then how do you tell the difference? To the receiver of the REJ frame, it doesn't matter. It only means "don't put this option into the configure-request frame again". It is not important whether or not the configuration identifier is understood or not. It only means that the entry is not to be negotiated. > How do you fall back on static addresses? "fall back" . . . . You don't "fall back". You start with static addresses which are NAKed with the proper dynamic address. It is then up to the receiver of the NAK frame to decided wether the value in the NAK is acceptable or not. It should go as follows: Configure-Req IP 1.2.3.4 ----------------> <--------------- NAK IP 2.3.4.5 Configure-Req ----------------> IP 2.3.4.5 <---------------- ACK IP 2.3.4.5 The other possibility is that the peer does not have an IP address for you and will accept your static values. These go as follows: Configure-Req IP 1.2.3.4 ----------------> <--------------- ACK IP 2.3.4.5 Since you never have an IP address of 0.0.0.0 then you don't send a Configure-Req of 0.0.0.0. This should not generate a NAK of 0.0.0.0 nor a REJ of 0.0.0.0. The only time that you should see, in your implementation, a REJ is when the peer does not understand the identifier for the IP address in the configure-request frame. -- Al Longyear longyear@sii.com The above opinions do not necessarily represent those of the Management of System Integrators nor any of its subsidiaries. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 14:36:51 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA04547; Wed, 1 Nov 1995 14:36:51 -0500 Resent-Date: Wed, 1 Nov 1995 14:36:51 -0500 From: Karl Fox Date: Wed, 1 Nov 95 14:36:09 -0500 Message-Id: <9511011936.AA00669@gefilte.MorningStar.Com> To: ietf-ppp@MERIT.EDU Subject: Re: new IPCP draft and Address option In-Reply-To: <199511011913.LAA00598@sii-4-30.sii.com> References: <199511011833.LAA20685@mica.denver.sgi.com> <199511011913.LAA00598@sii-4-30.sii.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"EeX15.0.k61.Dnybm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/802 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Al Longyear writes: > The other possibility is that the peer does not have an IP address for you > and will accept your static values. These go as follows: > > Configure-Req > IP 1.2.3.4 ----------------> > <--------------- ACK > IP 2.3.4.5 The above Configure-Ack is illegal. A conformant system will ignore it. -- Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 15:11:15 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA05588; Wed, 1 Nov 1995 15:11:15 -0500 Resent-Date: Wed, 1 Nov 1995 15:11:15 -0500 Date: Wed, 1 Nov 95 19:40:28 GMT From: "William Allen Simpson" Message-ID: <1963.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: IPCP and address options Resent-Message-ID: <"Tu8Ug1.0.2N1.WHzbm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/803 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Karl Fox > Hey folks, please don't go breaking things that already work. It > would also be nice if IPCP continued to follow the state machine rules > laid out in RFC 1661. Remember that a Configure-Request doesn't > contain requests for performance by the peer, but rather a statement > of capabilities of the sender. > I agree whole heartedly with Karl. His analysis of the exchanges is correct, except: > Here's a weird one: > > IPCP Configure-Nak with a zero IP-Address: > `I think you don't know what your IP address should be' > > unless the Nak is in response to a Configure-Request with no > IP-Address option, in which case it would mean > > `I sure wish I knew what you think your IP address should be' > > otherwise it probably means > > `I am a broken implementation' > Since a -Nak MUST _always_ contain a value which is acceptable in the next -Request, this final interpretation is the only correct meaning. Don't send a -Nak with a zero IP-Address value. > Last, of course, is > > IPCP Configure-Reject for any IP-Address: > `What the hell is this option 3 nonsense?' > > Let's please not redefine the semantics of these messages. It would > probably cause many people (including me) a lot of interoperability > headaches. Thanks! > Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 15:55:46 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA06915; Wed, 1 Nov 1995 15:55:46 -0500 Resent-Date: Wed, 1 Nov 1995 15:55:46 -0500 Message-Id: Date: Wed, 1 Nov 95 15:55 EST From: shilling@symplex.com (Jim Shillington) To: ietf-ppp@MERIT.EDU Subject: Re: IPCP and address options Resent-Message-ID: <"bfteV1.0.mh1.Cxzbm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/804 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "William Allen Simpson" > > Here's a weird one: > > > > IPCP Configure-Nak with a zero IP-Address: > > `I think you don't know what your IP address should be' > > > > unless the Nak is in response to a Configure-Request with no > > IP-Address option, in which case it would mean > > > > `I sure wish I knew what you think your IP address should be' > > > > otherwise it probably means > > > > `I am a broken implementation' > > > Since a -Nak MUST _always_ contain a value which is acceptable in the > next -Request, this final interpretation is the only correct meaning. > > Don't send a -Nak with a zero IP-Address value. I guess I am missing something here. I don't see what is wrong with a Cfg-Nak with a zero IP-Address value. If you have an implementation that doesn't assign IP addresses but wants to know what the peer's IP address is then how can you accomplish this? A non-zero value will end up setting the peer's IP address rather than prompting him to give you its current value. =========================================================================== James E. Shillington Internet: shilling@symplex.com Symplex Communications Corporation Phone: (313) 995-1555 5 Research Drive FAX: (313) 995-3350 Ann Arbor, MI 48103 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 17:03:01 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA08899; Wed, 1 Nov 1995 17:03:01 -0500 Resent-Date: Wed, 1 Nov 1995 17:03:01 -0500 X-Received: from RED-01-MSG by xmtp3 with recvsmtp ; Wed, 1 Nov 1995 21:17:54 GMT Message-Id: From: Gurdeep Singh Pall To: "'ietf-ppp@MERIT.EDU'" Subject: RE: new IPCP draft and Address option Date: Wed, 1 Nov 1995 11:03:45 -0800 Encoding: 55 TEXT X-Msxmtid: xmtp3951101211754RECVSMTP[01.51.01]000000db-14213 Resent-Message-ID: <"w5acN3.0.qA2.Fw-bm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/805 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >From: vjs@mica.denver.sgi.com (Vernon Schryver) > >As I read the new IPCP draft, a Configure-Reject for an Address option >can mean two different things: > > Configure-Rej to indicate that the responding peer does not > implement this option. > >and only a few lines later: > > Configure-Rej implying that the responding peer is not > configured to assign an IP-address or that the responding > peer does not implement this option. > >If the Configure-Request was for 0.0.0.0, how do you tell whether a >Configure-Reject means "don't do Addresses at all" or "don't do address >assignment"? When you get a Configure-Reject of a Request for 0.0.0.0, >must you stop sending all Address requests or can you fall back on an >IP address? gurdeep> The first reference is when a valid IP Address is sent in the Configure-Request and the second reference is for a 0.0.0.0 Address sent in the Configure-Request. The difference is important since in the first case the sender can treat this as "I have an address and the other end doesnt care - no problem" and in the second case the sender can treat this as "I dont have an address and the other end can either not give me an address or it doesnt care". In the latter case, the sender can assume an IP-Address (ideally send a Configure-Request with the assumed IP-Address and use it when the address is Rejected or Acked), OR choose to operate without an IP-Address. The dilemma you bring out is caused by the limitation that Configure-Request with 0.0.0.0 cannot be responded to with a Configure-Nak with 0.0.0.0. >This is not an academic question. My code tries to be (too?) smart >about the IP addresses. The default configuration is happy to use the >IP address found on the primary network interface (typically Ethernet) >for its end of the PPP link, but is also willing to accept the peer's >preference. I'm not sure, but I think the new language at best >confuses what I can do. gurdeep> In this case, you could first send a Configure-Request with 0.0.0.0, if this gets Rejected, you can send a Configure-Request with your primary NIC's IP address and use this address if this is Acked or Rejected. If it is useful, we can add a blurb outlining the implementation's options when 0.0.0.0 is Rejected with 0.0.0.0. Gurdeep ------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 17:27:09 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA09526; Wed, 1 Nov 1995 17:27:09 -0500 Resent-Date: Wed, 1 Nov 1995 17:27:09 -0500 From: Karl Fox Date: Wed, 1 Nov 95 17:26:31 -0500 Message-Id: <9511012226.AA02629@gefilte.MorningStar.Com> To: Gurdeep Singh Pall Cc: "'ietf-ppp@MERIT.EDU'" Subject: RE: new IPCP draft and Address option In-Reply-To: References: Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"IqCCj2.0.dK2.wG_bm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/806 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Gurdeep Singh Pall writes: > gurdeep> In this case, you could first send a Configure-Request with 0.0.0.0, > if this gets Rejected, you can send a Configure-Request with your primary NIC's > IP address and use this address if this is Acked or Rejected. > > If it is useful, we can add a blurb outlining the implementation's options when > 0.0.0.0 is Rejected with 0.0.0.0. This is totally broken (see RFC 1661). I sincerely hope this is changed before it gets an RFC number assigned. -- Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 17:50:28 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA10254; Wed, 1 Nov 1995 17:50:28 -0500 Resent-Date: Wed, 1 Nov 1995 17:50:28 -0500 From: Archie Cobbs Message-Id: <199511012249.OAA24833@bubba.tribe.com> Subject: STAC LZS draft question To: ietf-ppp@MERIT.EDU Date: Wed, 1 Nov 1995 14:49:46 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1018 Resent-Message-ID: <"NrqMc2.0._V2.nc_bm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/807 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Just want to clear something up after reading the latest STAC compression draft (the draft number is draft-ietf-pppext-stacker-03.txt). From section two: Exactly one LZS datagram is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 4021 (Stacker | LZS). | When LZS is negotiated as the primary compression algorithm, the PPP | Protocol field indicates type hex 00FB (link compressed datagram), or type hex 00FD (compressed datagram). If read literally, these two sentences seem to be from different planets. Does this mean that you can send packets in either of two different ways? Why was 0x4021 added? There's no other mention of it in the draft. I apologize in advance if I'm missing something obvious. Thanks, -Archie _______________________________________________________________________________ Archie L. Cobbs, archie@tribe.com * Tribe Computer Works http://www.tribe.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 18:20:47 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA11202; Wed, 1 Nov 1995 18:20:47 -0500 Resent-Date: Wed, 1 Nov 1995 18:20:47 -0500 X-Received: from RED-70-MSG by xmtp1 with recvsmtp ; Wed, 1 Nov 1995 22:58:08 GMT Message-Id: From: Gurdeep Singh Pall To: "'ietf-ppp@MERIT.EDU'" , "'vjs@mica.denver.sgi.com'" Subject: FW: new IPCP draft and Address option Date: Wed, 1 Nov 1995 14:54:03 -0800 Encoding: 56 TEXT X-Msxmtid: xmtp1951101225809RECVSMTP[01.51.01]00000030-1233 Resent-Message-ID: <"PdbkR2.0.ok2.B30cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/808 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: vjs@mica.denver.sgi.com (Vernon Schryver) > >As I read the new IPCP draft, a Configure-Reject for an Address option >can mean two different things: > > Configure-Rej to indicate that the responding peer does not > implement this option. > >and only a few lines later: > > Configure-Rej implying that the responding peer is not > configured to assign an IP-address or that the responding > peer does not implement this option. > >If the Configure-Request was for 0.0.0.0, how do you tell whether a >Configure-Reject means "don't do Addresses at all" or "don't do address >assignment"? When you get a Configure-Reject of a Request for 0.0.0.0, >must you stop sending all Address requests or can you fall back on an >IP address? gurdeep> The first reference is when a valid IP Address is sent in the Configure-Request and the second reference is for a 0.0.0.0 Address sent in the Configure-Request. The difference is important since in the first case the sender can treat this as "I have an address and the other end doesnt care - no problem" and in the second case the sender can treat this as "I dont have an address and the other end can either not give me an address or it doesnt care". In the latter case, the sender can assume an IP-Address (ideally send a Configure-Request with the assumed IP-Address and use it when the address is Rejected or Acked), OR choose to operate without an IP-Address. The dilemma you bring out is caused by the limitation that Configure-Request with 0.0.0.0 cannot be responded to with a Configure-Nak with 0.0.0.0. >This is not an academic question. My code tries to be (too?) smart >about the IP addresses. The default configuration is happy to use the >IP address found on the primary network interface (typically Ethernet) >for its end of the PPP link, but is also willing to accept the peer's >preference. I'm not sure, but I think the new language at best >confuses what I can do. gurdeep> In this case, you could first send a Configure-Request with 0.0.0.0, if this gets Rejected you can send a Configure-Request with your primary NIC's IP address and use this address if the request is Acked or Rejected. If it is useful, we can add a blurb outlining the implementation's options when 0.0.0.0 is Rejected with 0.0.0.0. Gurdeep ------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 18:49:18 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA12051; Wed, 1 Nov 1995 18:49:18 -0500 Resent-Date: Wed, 1 Nov 1995 18:49:18 -0500 From: Rob Friend To: ietf-ppp Subject: RE: STAC LZS draft question Date: Wed, 01 Nov 95 15:47:00 PST Message-Id: <309815DD@smtpgateway.stac.com> Encoding: 44 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"n_EZa1.0.1y2.xT0cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/809 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi Archie, > Just want to clear something up after reading the latest STAC compression > draft (the draft number is draft-ietf-pppext-stacker-03.txt). > > From section two: > > Exactly one LZS datagram is encapsulated in the PPP Information > field, where the PPP Protocol field indicates type hex 4021 (Stacker | > LZS). | > > When LZS is negotiated as the primary compression algorithm, the PPP | > Protocol field indicates type hex 00FB (link compressed datagram), or > type hex 00FD (compressed datagram). > > If read literally, these two sentences seem to be from different planets. > Does this mean that you can send packets in either of two different ways? > Why was 0x4021 added? There's no other mention of it in the draft. My understanding is that Bill Simpson added the 0x4021 as a header that does not need CCP negotiation. It is particular to the Stac LZS (Option 17) format. You just send a datagram with this header and if you don't get a protocol-reject, then you keep sending datagrams with 0x4021 headers. My understanding is that the 0x4021 was added to allow sending datagrams with multiple compression algorithms, although I don't know why anyone would want to do that on a single logical (or physical) link. Although I am new to the PPP group here. The 0x00FD (and 0x00FB) are the "normal" datagram headers following CCP negotiation. > I apologize in advance if I'm missing something obvious. I had to be educated on this also. Regards, Robert C. Friend Stac Electronics Applications Engineering 12636 High Bluff Dr (619)794-4542 (voice) San Diego, CA 92130 (619)794-4577(FAX) Email:rfriend@stac.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 19:49:05 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA13849; Wed, 1 Nov 1995 19:49:05 -0500 Resent-Date: Wed, 1 Nov 1995 19:49:05 -0500 From: Archie Cobbs Message-Id: <199511020048.QAA25075@bubba.tribe.com> Subject: Re: STAC LZS draft question To: RFRIEND@stac.com (Rob Friend) Date: Wed, 1 Nov 1995 16:48:15 -0800 (PST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <309815DD@smtpgateway.stac.com> from "Rob Friend" at Nov 1, 95 03:47:00 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1896 Resent-Message-ID: <"AWKKi3.0.7O3.xL1cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/810 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > From section two: > > > > Exactly one LZS datagram is encapsulated in the PPP Information > > field, where the PPP Protocol field indicates type hex 4021 (Stacker > > LZS). > > > > When LZS is negotiated as the primary compression algorithm, the PPP > > Protocol field indicates type hex 00FB (link compressed datagram), or > > type hex 00FD (compressed datagram). > > > > If read literally, these two sentences seem to be from different planets. > > Does this mean that you can send packets in either of two different ways? > > Why was 0x4021 added? There's no other mention of it in the draft. > > My understanding is that Bill Simpson added the 0x4021 as a header that does > not need CCP negotiation. It is particular to the Stac LZS (Option 17) > format. You just send a datagram with this header and if you don't get a > protocol-reject, then you keep sending datagrams with 0x4021 headers. > > My understanding is that the 0x4021 was added to allow sending datagrams > with multiple compression algorithms, although I don't know why anyone would > want to do that on a single logical (or physical) link. Although I am new OK. Then there should be more of an explanation in the draft. For example, if someone just starts firing off 0x4021 packets without having gone through the CCP negotiation, what does the peer expect for history and check mode? In my own personal opinion, I don't think the 0x4021 addition is necessary, useful, or prudent. If multiple compression types are wanted, then CCP should be extended to have an additional option which adds a one byte compression type field to outgoing CCP data packets. This could be done without breaking existing implementations. -Archie _______________________________________________________________________________ Archie L. Cobbs, archie@tribe.com * Tribe Computer Works http://www.tribe.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 20:15:03 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA14702; Wed, 1 Nov 1995 20:15:03 -0500 Resent-Date: Wed, 1 Nov 1995 20:15:03 -0500 X-Received: from RED-01-MSG by xmtp1 with recvsmtp ; Thu, 2 Nov 1995 00:41:22 GMT Message-Id: From: Gurdeep Singh Pall To: "'William Allen Simpson'" , "ietf-ppp@MERIT.EDU" Subject: RE: IPCP and address options Date: Wed, 1 Nov 1995 14:58:13 -0800 Encoding: 25 TEXT X-Msxmtid: xmtp1951102004123RECVSMTP[01.51.01]00000030-4018 Resent-Message-ID: <"L9QWz.0.Tb3.Kk1cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/811 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ---------- From: William Allen Simpson[SMTP:bsimpson@morningstar.com] Since a -Nak MUST _always_ contain a value which is acceptable in the next -Request, this final interpretation is the only correct meaning. Don't send a -Nak with a zero IP-Address value. gurdeep> I strongly agree with Karl and Bill on this. For these very reasons Nak with 0.0.0.0 has been explicity omitted as a valid response. As Karl points out, this limitation does lead to fuzziness when Configure-Request of 0.0.0.0 address is responded to with a Configure-Reject. Peer's behavior when it receives this Reject was not specified in the draft - based on Vernon's comments I'd like to add the following blurb: If a peer responds to a zero IP-address Configure-Request with a Configure-Reject, the sender of the Configure-Request should assume that the peer cannot assign an IP-address. In this case, it can either send a Configure-Request with a valid IP-address it wishes to use OR it can treat the link as un-numbered. If either of these options are not possible in the peer implementation it should send a Terminate-Request. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 20:18:02 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA14830; Wed, 1 Nov 1995 20:18:02 -0500 Resent-Date: Wed, 1 Nov 1995 20:18:02 -0500 Date: Wed, 1 Nov 95 23:56:56 GMT From: "William Allen Simpson" Message-ID: <1966.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: STAC LZS draft question Resent-Message-ID: <"4kph82.0.Gd3.3n1cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/813 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Archie Cobbs > Exactly one LZS datagram is encapsulated in the PPP Information > field, where the PPP Protocol field indicates type hex 4021 (Stacker | > LZS). | > Note that no mention is made of "negotiating" here. That is, no CCP. > When LZS is negotiated as the primary compression algorithm, the PPP | > Protocol field indicates type hex 00FB (link compressed datagram), or > type hex 00FD (compressed datagram). > Note the qualifier "When". > If read literally, these two sentences seem to be from different planets. > Does this mean that you can send packets in either of two different ways? Actually, 3, depending on the negotiation. But only one at a time! > Why was 0x4021 added? There's no other mention of it in the draft. > Because CCP isn't always used. Because of legal issues. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 20:17:59 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA14819; Wed, 1 Nov 1995 20:17:59 -0500 Resent-Date: Wed, 1 Nov 1995 20:17:59 -0500 Date: Wed, 1 Nov 95 23:51:08 GMT From: "William Allen Simpson" Message-ID: <1965.bsimpson@morningstar.com> To: "'ietf-ppp@MERIT.EDU'" Subject: Re: new IPCP draft and Address option Resent-Message-ID: <"1UHCw2.0.-c3.1n1cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/812 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Gurdeep Singh Pall > >This is not an academic question. My code tries to be (too?) smart > >about the IP addresses. The default configuration is happy to use the > >IP address found on the primary network interface (typically Ethernet) > >for its end of the PPP link, but is also willing to accept the peer's > >preference. I'm not sure, but I think the new language at best > >confuses what I can do. > > gurdeep> In this case, you could first send a Configure-Request with 0.0.0.0, > if this gets Rejected, you can send a Configure-Request with your primary NIC's > IP address and use this address if this is Acked or Rejected. > Gurdeep, this is unacceptable! The proper technique is for the IPCP to first -Request the Ethernet address. If that is -Nak'd with another address, that other address is used instead. A -Reject means DO NOT SEND Code 3 IP_Address AGAIN! You have badly confused Reject and Nak!!! > If it is useful, we can add a blurb outlining the implementation's options when > 0.0.0.0 is Rejected with 0.0.0.0. > A -Reject of a -Request will _ALWAYS_ have the same value, zero in this case. And there is something wrong with your mailer. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 20:35:11 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA15343; Wed, 1 Nov 1995 20:35:11 -0500 Resent-Date: Wed, 1 Nov 1995 20:35:11 -0500 X-Received: from RED-70-MSG by xmtp1 with recvsmtp ; Thu, 2 Nov 1995 01:16:18 GMT Message-Id: From: Gurdeep Singh Pall To: "'ietf-ppp@MERIT.EDU'" , "'karl@MorningStar.Com'" , "'vjs@rhyolite.denver.sgi.com'" Subject: RE: new IPCP draft and Address option Date: Wed, 1 Nov 1995 17:15:28 -0800 Encoding: 21 TEXT X-Msxmtid: xmtp1951102011618RECVSMTP[01.51.01]00000030-5159 Resent-Message-ID: <"rLiPi3.0.Pl3.B12cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/814 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Thanks for the correction Karl. Sending the IP-Address option again (after its been Rejected) would be against 1661. This text was a half-baked suggestion and is not part of the current draft. Vernon, coming back to your scenario would it be better for your implementation to send a Terminate-Request when an attempt to acquire an IP-Address gets Rejected, and bring IPCP up again - this time Requesting the NIC's IP-address? Gurdeep --------- From: Karl Fox[SMTP:karl@MorningStar.Com] > If it is useful, we can add a blurb outlining the implementation's options when > 0.0.0.0 is Rejected with 0.0.0.0. This is totally broken (see RFC 1661). I sincerely hope this is changed before it gets an RFC number assigned. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 21:14:45 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA16338; Wed, 1 Nov 1995 21:14:45 -0500 Resent-Date: Wed, 1 Nov 1995 21:14:45 -0500 Date: Wed, 1 Nov 1995 19:14:01 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511020214.TAA21678@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: new IPCP draft and Address option Resent-Message-ID: <"QPMN51.0.1_3.Ic2cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/815 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From gurdeep@microsoft.com Wed Nov 1 18:36:27 1995 > Received: from momserv.denver.sgi.com by mica.denver.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) > for id SAA21565; Wed, 1 Nov 1995 18:36:15 -0700 > Received: from sgi.sgi.com by momserv.denver.sgi.com via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) > for id SAA22504; Wed, 1 Nov 1995 18:35:51 -0700 > Received: from netmail2.microsoft.com by sgi.sgi.com via SMTP (950405.SGI.8.6.12/910110.SGI) > for id RAA25958; Wed, 1 Nov 1995 17:35:48 -0800 > Received: by netmail2.microsoft.com (5.65/25-eef) > id AA21742; Wed, 1 Nov 95 19:51:08 -0800 > Received: by netmail2 using fxenixd 1.0 Wed, 01 Nov 95 19:51:08 PST > X-Received: from RED-01-MSG by xmtp1 with recvsmtp ; Thu, 2 Nov 1995 01:18:49 GMT > Received: by RED-01-MSG with Microsoft Mail > id <01BAA87D.FC633B50@RED-01-MSG>; Wed, 1 Nov 1995 17:17:56 -0800 > Message-Id: > From: Gurdeep Singh Pall > To: "'ietf-ppp@MERIT.EDU'" , > "'karl@MorningStar.Com'" , > "'vjs@rhyolite.denver.sgi.com'" > Subject: RE: new IPCP draft and Address option > Date: Wed, 1 Nov 1995 17:15:28 -0800 > Encoding: 21 TEXT > X-Msxmtid: xmtp1951102011849RECVSMTP[01.51.01]00000030-5224 I've quoted all of the headers because that To: line looks a little unusual. Also, is that Message-ID legal? I've forgotten what RFC 822 says about it. > ... >Vernon, coming back to your scenario would it be better for your implementation > to send a Terminate-Request when an attempt to acquire an IP-Address gets > Rejected, and bring IPCP up again - this time Requesting the NIC's IP-address? I think that after a Terminate-Request, if you come back up, you should try to start out with very nearly the same state as the very first time. It would be a bad idea to save more than absolutely minimal state accross a Terminate-Request/Ack. Regardless of that, since my code supports only IP, when I get an IPCP Terminate-Request, I do as RFC-1661 says you should do when the last NCP is turned off, and shut down the entire link. When the phone is next dialed or answered, of course everything must start from scratch. I'd go along with a consensus that says that it is not permitted to Configure-Nak for 0.0.0.0 in response to a Configure-Request for 0.0.0.0. I think it is an unnecessary restriction, but it would make things simpler and I'm always in favor of simplicity. In any case, the words currently in the draft should be changed. The second reason for sending a Configure-Reject are misleading and should be removed or improved. -Nak of 0.0.0.0 in response to -Request of 0.0.0.0 is to be prohibited, then say that. Also in any case, tt would also be good to put something like Karl Fox's litany of the meanings of the various combinations into the draft--of course translated from the vernacular into Standardese. Of course with the addition of the case where we all agree (I hope) that -Nak of 0.0.0.0 is desirable. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 1 21:22:56 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA16607; Wed, 1 Nov 1995 21:22:56 -0500 Resent-Date: Wed, 1 Nov 1995 21:22:56 -0500 Date: Wed, 1 Nov 95 18:27:11 PST From: roger@flowpoint.com (Philippe Roger) Message-Id: <9511020227.AA15508@flowpoint.com> To: ietf-ppp@MERIT.EDU Subject: Re: new IPCP draft and Address option Resent-Message-ID: <"Lh4yT3.0.G34.zj2cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/816 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> gurdeep> In this case, you could first send a Configure-Request with >> 0.0.0.0, if this gets Rejected, you can send a Configure-Request with >> your primary NIC's IP address and use this address if this is Acked or >> Rejected. >> >Gurdeep, this is unacceptable! > >The proper technique is for the IPCP to first -Request the Ethernet address. >If that is -Nak'd with another address, that other address is used instead. > >A -Reject means DO NOT SEND Code 3 IP_Address AGAIN! > >You have badly confused Reject and Nak!!! > > >> If it is useful, we can add a blurb outlining the implementation's options >> when 0.0.0.0 is Rejected with 0.0.0.0. >> >A -Reject of a -Request will _ALWAYS_ have the same value, zero in this case. > >And there is something wrong with your mailer. > >Bill.Simpson@um.cc.umich.edu > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 > Bill, This make sense except for one minor detail: if you want (as Vernon said earlier) to be "smart" and automatically determine unnumbered links versus numbered links, something is missing. Say that I start my negotiation with no option 3 (meaning unnumbered), and I get rejected (as some real-word implementations do), I am now sending a Configure-Req with option 3 and and IP address of 0.0.0.0. If this gets accepted, we are using an unumbered link. If this gets nak'ed (with something other than 0.0.0.0), it means I should use this IP address assigned to me: but I MAY NOT want to have an IP address assigned to me (because this would mean create an IP interface with this address, which may not be a valid one, in my context or I don't want a foreign dial-up system change my routing table). All I know now is that I do need an IP address on my side of the link (because the two possible unnumbered methods have failed) so I send a Configure-Req with my Ethernet address filled in and hopefully this will get accepted. You are argueing that I should have offered my Ethernet address the first time I used option 3 in a Configure-Req, but this would have definitely prevented me from establishing a link in unnumbered mode by EXPLICITELY exchanging addresses of 0.0.0.0, as opposed to NOT send Option 3. Since I believe that unnumbered links are desirable and should be used whenever possible, we have a problem with this spec... Best regards, Philippe Roger, roger@flowpoint.com PS: A good reason for not letting a dial-up system assign me my IP address is that it might be a PC used by someone not too knowledgeable about how to set things up... PPS: If a -Reject always mean that an option should not be proposed again, how come that options that are booleans (i.e. no parameter associated with the option) are rejected, not NACK'ed ? They cannot be negotiated: it's a case of "take it or leave it", not my idea of negotiation... Even in the "illegal" case of sending another Configure-Req after receiving a Configure-Reject, the retry count and timer prevent from continuing a negotiation which does not converge. However, assuming an implementation is "brave" enough to continue the negotiation of a rejected option, it may choose different initial values, that may end up being accepted, don't you think ? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 05:17:20 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id FAA27800; Thu, 2 Nov 1995 05:17:20 -0500 Resent-Date: Thu, 2 Nov 1995 05:17:20 -0500 Date: Thu, 2 Nov 95 10:17:03 GMT Message-Id: <9511021017.AA17020@queenbee.spider.co.uk> From: Malcolm Campbell Subject: RE: new IPCP draft and Address option To: vjs@mica.denver.sgi.com (Vernon Schryver) In-Reply-To: Vernon Schryver's message of Wed, 1 Nov 1995 19:14:01 -0700 X-Mailer: Sendmail/Ream v5.1.23 (Vorsprung Dourish Technik) Phone: +44 131 554 9424 (Work) Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"fD2q92.0.7o6.Zg9cm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/817 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I'd go along with a consensus that says that it is not permitted to > Configure-Nak for 0.0.0.0 in response to a Configure-Request for > 0.0.0.0. I think it is an unnecessary restriction, but it would make > things simpler and I'm always in favor of simplicity. There's two situations here... 1) Sending a Conf-NAK of 0.0.0.0 in response to a Configure-Request which didn't contain an IP Address option. I think this is valid. You're saying that you want to negotiate the IP address but you don't know what it should be. I think this is a useful mechanism. I do understand that this is at varience with the usual meaning of a Configure-NAK, but I think its a useful one - and the Configure-Request of 0.0.0.0 is a varience from the usual meaning in the first place. It's a special value with a special meaning. 2) Sending a Conf-NAK of 0.0.0.0 in response to a Configure-Request of 0.0.0.0. This is the situation which I think has been largely discussed. I agree with Vernon in that I think its useful, but must admit Ive never actually seen it converge from here anyway - so in the interests of simplicity I'd be happy to see it ruled as illegal. --- Malcolm - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 09:12:36 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA03266; Thu, 2 Nov 1995 09:12:36 -0500 Resent-Date: Thu, 2 Nov 1995 09:12:36 -0500 From: Karl Fox Date: Thu, 2 Nov 95 09:11:51 -0500 Message-Id: <9511021411.AA03192@gefilte.MorningStar.Com> To: Malcolm Campbell Cc: ietf-ppp@MERIT.EDU Subject: RE: new IPCP draft and Address option In-Reply-To: <9511021017.AA17020@queenbee.spider.co.uk> References: <9511021017.AA17020@queenbee.spider.co.uk> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"p1JD1.0.lo.C7Dcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/818 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Malcolm Campbell writes: > There's two situations here... > > 1) Sending a Conf-NAK of 0.0.0.0 in response to a Configure-Request which > didn't contain an IP Address option. I think this is valid. You're > saying that you want to negotiate the IP address but you don't know what > it should be. I think this is a useful mechanism. From RFC 1661: 5.3. Configure-Nak ... Finally, an implementation may be configured to request the negotiation of a specific Configuration Option. If that option is not listed, then that option MAY be appended to the list of Nak'd Configuration Options, in order to prompt the peer to include that option in its next Configure-Request packet. Any value fields for the option MUST indicate values acceptable to the Configure-Nak sender. ... Reception of a valid Configure-Nak indicates that when a new Configure-Request is sent, the Configuration Options MAY be modified as specified in the Configure-Nak. Note that you must be prepared to *accept* a value of 0.0.0.0 in the next Configure-Request. That's what a Configure-Nak means; it is saying `I would Configure-Ack a Configure-Request containing *this* value'. > I do understand that this is at varience with the usual meaning of a > Configure-NAK, but I think its a useful one - and the Configure-Request of > 0.0.0.0 is a varience from the usual meaning in the first place. It's a > special value with a special meaning. Special, perhaps, or even a little unusual, but it's always been part of the PPP design. > 2) Sending a Conf-NAK of 0.0.0.0 in response to a Configure-Request of > 0.0.0.0. This is the situation which I think has been largely discussed. > I agree with Vernon in that I think its useful, but must admit Ive never > actually seen it converge from here anyway - so in the interests of > simplicity I'd be happy to see it ruled as illegal. I agree completely. It clearly violates the documented behavior of Configure-Nak. A Configure-Nak MUST contain a value acceptable to the sender of the Configure-Nak. If it contains the value that *was* in the previous Configure-Request, this is obviously not the case. -- Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 09:36:30 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA03979; Thu, 2 Nov 1995 09:36:30 -0500 Resent-Date: Thu, 2 Nov 1995 09:36:30 -0500 From: Karl Fox Date: Thu, 2 Nov 95 09:35:48 -0500 Message-Id: <9511021435.AA03199@gefilte.MorningStar.Com> To: roger@flowpoint.com (Philippe Roger) Cc: ietf-ppp@MERIT.EDU Subject: Re: new IPCP draft and Address option In-Reply-To: <9511020227.AA15508@flowpoint.com> References: <9511020227.AA15508@flowpoint.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"Gyzy13.0.yz.eTDcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/819 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Philippe Roger writes: > This make sense except for one minor detail: if you want (as Vernon said > earlier) to be "smart" and automatically determine unnumbered links versus > numbered links, something is missing. Not so. You're under no obligation to actually use the values included in either the peer's Configure-Requests or their Configure-Naks. Keep in mind that, generally, a Configure-Request is a statement by the peer as to their abilities. The peer can't force you to do anything different from the default values. > Say that I start my negotiation with no option 3 (meaning unnumbered), and > I get rejected (as some real-word implementations do), What is it that got rejected? It can't be option 3; you never sent it. > I am now sending a Configure-Req with option 3 and and IP address of > 0.0.0.0. If this gets accepted, we are using an unumbered link. That's up to the implementation. What is *really* means is that both of you agree that neither of you know what IP address should be assigned to your end of the link. It may mean that the link is unnumbered, or, more commonly, it means the network administrator has screwed up the configuration. > If this gets nak'ed (with something other than 0.0.0.0), it means I > should use this IP address assigned to me: No, it means that the peer would accept that value if you sent it in your next Configure-Request. > but I MAY NOT want to have an IP address assigned to me (because > this would mean create an IP interface with this address, which may > not be a valid one, in my context or I don't want a foreign dial-up > system change my routing table). All I know now is that I do need an > IP address on my side of the link (because the two possible > unnumbered methods have failed) so I send a Configure-Req with my > Ethernet address filled in and hopefully this will get accepted. That would be fine, but I don't understand your explanation about needing an IP address but not wanting one. If you don't want an IP address, don't include option 3 in your Configure-Request. If the peer sends you a Configure-Nak with 0.0.0.0, either ignore it or include option 3 with 0.0.0.0 in your next Configure-Request. If the peer then Naks that with a non-zero address, then it is broken and you should ignore the value in the Nak. It should have Acked the 0.0.0.0. > You are argueing that I should have offered my Ethernet address the first > time I used option 3 in a Configure-Req, but this would have definitely > prevented me from establishing a link in unnumbered mode by EXPLICITELY > exchanging addresses of 0.0.0.0, as opposed to NOT send Option 3. Since I > believe that unnumbered links are desirable and should be used whenever > possible, we have a problem with this spec... No, we just have a problem understanding how to negotiate an unnumbered link. Keep in mind that the vast majority of PPP implementations in existence do not even support unnumbered links. > Best regards, > > Philippe Roger, roger@flowpoint.com > > > PS: A good reason for not letting a dial-up system assign me my IP address > is that it might be a PC used by someone not too knowledgeable about > how to set things up... No kidding! > PPS: If a -Reject always mean that an option should not be proposed again, > how come that options that are booleans (i.e. no parameter associated > with the option) are rejected, not NACK'ed ? They cannot be negotiated: > it's a case of "take it or leave it", not my idea of negotiation... I don't understand. It seems to me that boolean values MUST be `take it or leave it'. They can't be `half on'. In any case, it's been that way since PPP began. Here's what RFC 1661 says about it: 5.3. Configure-Nak ... Options which have no value fields (boolean options) MUST use the Configure-Reject reply instead. > Even in the "illegal" case of sending another Configure-Req after > receiving a Configure-Reject, the retry count and timer prevent from > continuing a negotiation which does not converge. Why would you intentionally write code that explicitly violates the RFC and is guaranteed to run out the Restart counter? Do you not understand that there are broken implementations out there that will *never* converge? Hopefully, your code will. > However, assuming an implementation is "brave" enough to > continue the negotiation of a rejected option, it may choose > different initial values, that may end up being accepted, don't > you think ? Brave? A different work comes to my mind. And no, I doubt it will ever be accepted, unless the peer is also broken. -- Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 09:42:32 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA04232; Thu, 2 Nov 1995 09:42:32 -0500 Resent-Date: Thu, 2 Nov 1995 09:42:32 -0500 Date: Thu, 2 Nov 95 14:42:24 GMT Message-Id: <9511021442.AA22238@queenbee.spider.co.uk> From: Malcolm Campbell Subject: RE: new IPCP draft and Address option To: Karl Fox In-Reply-To: Karl Fox's message of Thu, 2 Nov 95 09:11:51 -0500 X-Mailer: Sendmail/Ream v5.1.23 (Vorsprung Dourish Technik) Phone: +44 131 554 9424 (Work) Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"MSuTB1.0.v11.GZDcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/820 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Malcolm Campbell writes: > > 1) Sending a Conf-NAK of 0.0.0.0 in response to a Configure-Request which > > didn't contain an IP Address option. I think this is valid. You're > > saying that you want to negotiate the IP address but you don't know what > > it should be. I think this is a useful mechanism. Karl writes.. >From RFC 1661: > > 5.3. Configure-Nak > ... Ok, so RFC1661 doesnt say you can do this. I shouldnt have used the word valid. Let me put this another way. It's useful to be able to tell your peer that you insist on negotiating IP addresses, but dont know what its address is - given that it has sent you a Request with no address in it. Without sending a NAK with 0.0.0.0, how do you do this? > Note that you must be prepared to *accept* a value of 0.0.0.0 in the > next Configure-Request. That's what a Configure-Nak means; it is > saying `I would Configure-Ack a Configure-Request containing *this* > value'. And a Configure-Request says "I want to use this value". This option already has a special case for a request of 0.0.0.0, I see no reason it cant have a special case for a NAK of 0.0.0.0 --- Malcolm - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 09:49:43 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA04436; Thu, 2 Nov 1995 09:49:43 -0500 Resent-Date: Thu, 2 Nov 1995 09:49:43 -0500 From: Karl Fox Date: Thu, 2 Nov 95 09:48:28 -0500 Message-Id: <9511021448.AA03215@gefilte.MorningStar.Com> To: Malcolm Campbell Cc: ietf-ppp@MERIT.EDU Subject: RE: new IPCP draft and Address option In-Reply-To: <9511021442.AA22238@queenbee.spider.co.uk> References: <9511021442.AA22238@queenbee.spider.co.uk> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"GrUUl1.0.351.1gDcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/821 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Malcolm Campbell writes: > It's useful to be able to tell your peer that you insist on negotiating > IP addresses, but dont know what its address is - given that it has > sent you a Request with no address in it. Without sending a NAK with 0.0.0.0, > how do you do this? If the peer doesn't know it's IP address, it can't! If you send a Configure-Nak with 0.0.0.0 and the peer sends a Configure-Request with 0.0.0.0, it is saying that it doesn't know its IP address. If it does know its IP address, it should put that in the Configure-Request instead. At least that's what *I* think should happen. :-) > > Note that you must be prepared to *accept* a value of 0.0.0.0 in the > > next Configure-Request. That's what a Configure-Nak means; it is > > saying `I would Configure-Ack a Configure-Request containing *this* > > value'. > > And a Configure-Request says "I want to use this value". This option already > has a special case for a request of 0.0.0.0, I see no reason it cant have > a special case for a NAK of 0.0.0.0 Because RFC 1661 already defines its meaning. -- Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 10:09:33 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA05267; Thu, 2 Nov 1995 10:09:33 -0500 Resent-Date: Thu, 2 Nov 1995 10:09:33 -0500 Date: Thu, 2 Nov 1995 10:08:36 -0500 From: John Shriver Message-Id: <199511021508.KAA11691@shiva-dev.shiva.com> To: bsimpson@morningstar.com CC: ietf-ppp@MERIT.EDU In-reply-to: <1966.bsimpson@morningstar.com> Subject: Re: STAC LZS draft question Resent-Message-ID: <"Bk4WN1.0.wH1.byDcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/822 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Resent-Date: Wed, 1 Nov 1995 20:17:56 -0500 Date: Wed, 1 Nov 95 23:56:56 GMT From: "William Allen Simpson" To: ietf-ppp@MERIT.EDU Subject: Re: STAC LZS draft question Resent-From: ietf-ppp@MERIT.EDU Resent-Sender: ietf-ppp-request@MERIT.EDU > Why was 0x4021 added? There's no other mention of it in the draft. > Because CCP isn't always used. Because of legal issues. Gee, Bill, engaging in self-revisionism? As I remember it (and I have archives of the list to fall back on), you realized that nobody had understood your intent for there to be primary and secondary compression algorithms in CCP. (Eg, more than one option in the Config-Request/Config-ACK.) So, when you finally explained (on the list, which you hadn't sucessfully done in the CCP Internet-Draft), how secondaries were meant to be used, when you next revised the stacker I-D, you added the 0x4021 to be used when it is a secondary compression protocol. However, certainly as I understand your explanation at that time, you could only use 0x4021 if Stac had been sucessfully negotiated as a secondary CCP compression algorithm. It would certainly be against "your" PPP rules to send something without having negotiated to see that the other end is willing to receive it! - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 12:32:50 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA10142; Thu, 2 Nov 1995 12:32:50 -0500 Resent-Date: Thu, 2 Nov 1995 12:32:50 -0500 Date: Thu, 2 Nov 1995 10:31:45 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511021731.KAA22572@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: new IPCP draft and Address option Resent-Message-ID: <"UkglE3.0.BU2.l2Gcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/823 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I do not understand the last 6 message between Philippe Roger and Karl Fox. They seem self-contradictory. I'm not sure, but they might make sense if sometimes "0.0.0.0" means "unnumbered" and sometimes "0.0.0.0" means "please suggest a good IP address." Whatever they are saying, whether they now agree or not (I really can't tell, but their tones suggest disagreement), they've made clear that the meanings of all 8 combinations of {(Request, Nak, Ack, Reject), (0.0.0.0, valid number)} must be listed and defined. Any sub-cases that are affected by context (e.g. Ack-0.0.0.0 after Request-0.0.0.0 meaning "use unnumbered links") must be listed and defined as well. Until we have a list of all cases, including the cases that are not permitted (possibly such as Nak-0.0.0.0 after Request-0.0.0.0), the replacement for RFC 1332 will remain ambiguous. Yes, it the current and previous versions are ambiguous no matter how much one might point to RFC 1661, 1331, or any other document. That fact is proven because so many of us have read it so many different ways over the years. Ambiguity is in the mind of the reader regardless of the intentions of the authors. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 12:41:48 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA10540; Thu, 2 Nov 1995 12:41:48 -0500 Resent-Date: Thu, 2 Nov 1995 12:41:48 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Nov 1995 09:41:07 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: putting together Dallas agenda Resent-Message-ID: <"AtAZ01.0.Qa2.PBGcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/824 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU People that want agenda time need also to have a draft up. Since the last IETF, the following have been posted: draft-ietf-pppext-eap-auth-01.txt draft-ietf-pppext-des-encrypt-01.txt draft-ietf-pppext-deflate-00.txt draft-ietf-pppext-bsd-compress-05.txt draft-ietf-pppext-ipcp-network-00.txt I have currently scheduled time for Keith Mader Gurdeep Singh Paul Keth Sklower and would like a draft posted for each of those. Anyone else who wants time, please contact me. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ...Every morning is the dawn of a new error... - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 12:41:54 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA10572; Thu, 2 Nov 1995 12:41:54 -0500 Resent-Date: Thu, 2 Nov 1995 12:41:54 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 2 Nov 1995 09:41:17 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Six months has elapsed Resent-Message-ID: <"Yhcsk1.0.ra2.UBGcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/825 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The DECNET RFC has been at Draft Standard for at least six months; would someone representing each implementation please contact me (copy the author) and advise me whether or not you think it is ready to become a Full Standard? 1762 DS S. Senum, "The PPP DECnet Phase IV Control Protocol (DNCP)", 03/01/1995. (Pages=7) (Format=.txt) (Obsoletes RFC1376) These documents have been at Proposed Standard for at least 6 months (for some, that merits a smiley), and so have met the minimum requirements to be advanced to Draft Standard. Would someone representing each implementation please contact me (copy the author) and advise me: (a) what changes would you suggest? (b) specifically what out of the draft have you implemented? (c) do you feel that it is sufficiently stable to advance to Draft Standard? 1764 PS S. Senum, "The PPP XNS IDP Control Protocol (XNSCP)", 03/01/1995. (Pages=5) (Format=.txt) 1763 PS S. Senum, "The PPP Banyan Vines Control Protocol (BVCP)", 03/01/1995. (Pages=10) (Format=.txt) 1663 PS D. Rand, "PPP Reliable Transmission", 07/21/1994. (Pages=7) (Format=.txt) 1638 PS F. Baker, R. Bowen, "PPP Bridging Control Protocol (BCP)", 06/09/1994. (Pages=28) (Format=.txt) (Obsoletes RFC1220) 1619 PS W. Simpson, "PPP over SONET/SDH", 05/13/1994. (Pages=5) (Format=.txt) 1618 PS W. Simpson, "PPP over ISDN", 05/13/1994. (Pages=7) (Format=.txt) 1598 PS W. Simpson, "PPP in X.25", 03/17/1994. (Pages=8) (Format=.txt) 1570 PS W. Simpson, "PPP LCP Extensions", 01/11/1994. (Pages=22) (Format=.txt) (Updates RFC1548) 1552 PS W. Simpson, "The PPP Internetwork Packet Exchange Control Protocol (IPXCP)", 12/09/1993. (Pages=19) (Format=.txt) 1474 PS F. Kastenholz, "The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol", 06/08/1993. (Pages=15) (Format=.txt) 1473 PS F. Kastenholz, "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol", 06/08/1993. (Pages=9) (Format=.txt) 1472 PS F. Kastenholz, "The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol", 06/08/1993. (Pages=11) (Format=.txt) 1471 PS F. Kastenholz, "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol", 06/08/1993. (Pages=25) (Format=.txt) 1378 PS B. Parker, "The PPP AppleTalk Control Protocol (ATCP)", 11/05/1992. (Pages=16) (Format=.txt) 1377 PS D. Katz, "The PPP OSI Network Layer Control Protocol (OSINLCP)", 11/05/1992. (Pages=10) (Format=.txt) 1334 PS B. Lloyd, W. Simpson, "PPP Authentication Protocols", 10/20/1992. (Pages=16) (Format=.txt) 1333 PS W. Simpson, "PPP Link Quality Monitoring", 05/26/1992. (Pages=17) (Format=.txt) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ...Every morning is the dawn of a new error... - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 2 13:30:55 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA12200; Thu, 2 Nov 1995 13:30:55 -0500 Resent-Date: Thu, 2 Nov 1995 13:30:55 -0500 Date: Thu, 2 Nov 95 10:35:20 PST From: roger@flowpoint.com (Philippe Roger) Message-Id: <9511021835.AA16086@flowpoint.com> To: ietf-ppp@MERIT.EDU Subject: Re: new IPCP draft and Address option Resent-Message-ID: <"Dh1DO1.0.P-2.SvGcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/826 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Vernon Schryver: > I do not understand the last 6 message between Philippe Roger and Karl Fox. > They seem self-contradictory. I'm not sure, but they might make sense > if sometimes "0.0.0.0" means "unnumbered" and sometimes "0.0.0.0" means > "please suggest a good IP address." > I would say that I generally agree with Karl but I also contend that there is a problem with negotiating unnumbered links, particularly if an implementation tries to automatically adjust to whatever mode (numbered or unnumbered) the peer supports. This means not having to set a configuration parameter that tells me to stick to unnumbered links or to only negotiate numbered links: I'd like to make that decision dynamically based on the capabilities of my peers, favoring unnumbered links where possible. In that regards, the value 0.0.0.0 plays an ambiguous role. > Whatever they are saying, whether they now agree or not (I really can't tell, > but their tones suggest disagreement), they've made clear that the > meanings of all 8 combinations of > {(Request, Nak, Ack, Reject), (0.0.0.0, valid number)} > must be listed and defined. Any sub-cases that are affected by context > (e.g. Ack-0.0.0.0 after Request-0.0.0.0 meaning "use unnumbered links") > must be listed and defined as well. > > Until we have a list of all cases, including the cases that are not > permitted (possibly such as Nak-0.0.0.0 after Request-0.0.0.0), the > replacement for RFC 1332 will remain ambiguous. > > Yes, it the current and previous versions are ambiguous no matter how > much one might point to RFC 1661, 1331, or any other document. That > fact is proven because so many of us have read it so many different > ways over the years. Ambiguity is in the mind of the reader regardless > of the intentions of the authors. > > > Vernon Schryver, vjs@sgi.com > Absolutely! The less possible interpretation left to the implementors, the greater interoperability is likely to be achieved. I also agree that some implementations (maybe including mine :-) are broken... The question is then: do we try to work around those flaws or politely ask them to go back to the drawing board. I guess the answer depends on one's position in the marketplace. I'd favor pure conformance to stricts standards, but it might be only wishful thinking... Philippe Roger, roger@flowpoint.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 3 08:57:22 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id IAA12386; Fri, 3 Nov 1995 08:57:22 -0500 Resent-Date: Fri, 3 Nov 1995 08:57:22 -0500 Message-ID: <01BAA9CA.642A6D60@ppp-pm01-dy-22.opr.oakland.edu> From: Brad Wilson To: "ietf-ppp@MERIT.EDU" , "'Vernon Schryver'" Subject: RE: new IPCP draft and Address option Date: Fri, 3 Nov 1995 08:53:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"rM22M1.0.J13.w-Xcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/827 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU As near as I can remember, 0.0.0.0 means "please suggest an IP address for me", whereas not asking for the option means there is a desire to work in an unnumbered state. I am sure we went round on this at the Danvers mtg. -- Brad Wilson Internet: wilson@cps.cmich.edu Voice: +1 810 620-9803 VP Software Engineering Crucial Software Data: +1 810 625-1484 Engineering services available in C++ for Windows 95 and Windows NT For PGP 2.6.2 public key: "finger -l wilson@cps.cmich.edu" "Money is the living power that dies without its root. Money will not serve the mind that cannot match it." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 3 10:10:44 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA14838; Fri, 3 Nov 1995 10:10:44 -0500 Resent-Date: Fri, 3 Nov 1995 10:10:44 -0500 Date: Fri, 3 Nov 1995 08:10:01 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511031510.IAA24216@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: new IPCP draft and Address option Resent-Message-ID: <"PbBeh1.0.Xd3.j3Zcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/828 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Brad Wilson > To: "ietf-ppp@MERIT.EDU" , "'Vernon Schryver'" > > > As near as I can remember, 0.0.0.0 means "please suggest an IP address for > me", whereas not asking for the option means there is a desire to work in > an unnumbered state. That sounds nice to me, except: - I bet there are many systems that have chosen to not bother to implement IPCP option #3. My recollection is that this whole PPP negotiation ediface was driven wanting to avoid the problems in SLIP from not negotiation the MTU and IP addresses, but that did not stop major vendors from not bothering to implement the LCP MTU negotiation. - what happens if option #3 is negotiated in one direction but not the other? Is one end of the link unnumbered or is the negogiated address applied to both ends of the link? - what are current systems that support unnumbered links doing? As I wrote privately yesterday, I think Ack-0.0.0.0 cannot be used to mean "unnumbered," because in real life, that is already universally used to mean "broken implementation and/or misconfiguration." For negotiation unnumbered links I favor not using option 3 at all, or picking a new, invalid token such as 127.0. > I am sure we went round on this at the Danvers mtg. Things that are not written down are inadmissible. If the absense of option #3's means "unnumbered," the standard must say so. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 3 13:08:34 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA20446; Fri, 3 Nov 1995 13:08:34 -0500 Resent-Date: Fri, 3 Nov 1995 13:08:34 -0500 Message-ID: <01BAA9ED.65D7E160@ppp-pm01-dy-16.opr.oakland.edu> From: Brad Wilson To: "ietf-ppp@MERIT.EDU" , "'Vernon Schryver'" Subject: RE: new IPCP draft and Address option Date: Fri, 3 Nov 1995 13:05:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"PLxaB.0.u-4.Dgbcm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/829 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > - I bet there are many systems that have chosen to not bother to > implement IPCP option #3. My recollection is that this whole > PPP negotiation ediface was driven wanting to avoid the > problems in SLIP from not negotiation the MTU and IP addresses, > but that did not stop major vendors from not bothering to > implement the LCP MTU negotiation. My experience at PPPathon was that everyone who did IPCP IP address negotiation was doing option 3, and fell back to option 1 only when needed. I don't recall anyone telling me that they did 1 but not 3. > - what happens if option #3 is negotiated in one direction but not > the other? Is one end of the link unnumbered or is the > negogiated address applied to both ends of the link? This could be a common scenario for dialup endpoints, since most dialups are simply "throw everything I have down the pipe". It is really needed to know what the IP address of the other side is? I don't see the problem with saying that one (the end point) node is running numbered, since he's a host, but the other (NAS, for example) is running unnumbered because they are proxying on the Ethernet (again, for example). > Things that are not written down are inadmissible. If the absense of > option #3's means "unnumbered," the standard must say so. I was trying to be helpful in pointing someone to the minutes from Danvers for our discussion on the subject. I was NOT trying to point to the Danvers discussion as a statement of fact or law. If you choose not to consider others' opinions are important, then please disregard my suggestion. -- Brad Wilson Internet: wilson@cps.cmich.edu Voice: +1 810 620-9803 VP Software Engineering Crucial Software Data: +1 810 625-1484 Engineering services available in C++ for Windows 95 and Windows NT For PGP 2.6.2 public key: "finger -l wilson@cps.cmich.edu" "Money is the living power that dies without its root. Money will not serve the mind that cannot match it." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 6 21:10:40 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA08184; Mon, 6 Nov 1995 21:10:40 -0500 Resent-Date: Mon, 6 Nov 1995 21:10:40 -0500 From: "Al Longyear" Message-Id: <199511070209.SAA00941@sii-4-30.sii.com> Subject: Cisco 2509 PPP problems To: ietf-ppp@MERIT.EDU Date: Mon, 6 Nov 1995 18:09:53 -0800 (PST) Reply-To: "Al Longyear" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8xraI1.0.7-1.w_hdm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/830 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have had a few people complain to me about problems trying to connect to a Cisco 2509 (and probably the entire 2500 family since it seems that they all use the same code) PPP software. The problem is that when I send an LCP Configure-request frame with the option for the 'MRU', the Cisco product rejects _ALL_ of the options in the LCP Configure-request frame. They don't just reject the MRU setting. This, in turn is followed by my sending a LCP configure-request frame with no options (since all of the options were rejected, it is the only thing which is permissible). The Cisco product ACKs the frame and at that point, it ceases to process the IPCP protocol sequence. It just dumps all of the IPCP Configure request frames into the big bit bucket in the sky. If I start a new session with them and don't send the LCP Configure- request frame with the MRU, the Cisco product properly ACKs the frame and life is sweet for IPCP. Does anyone have any contacts with Cisco so that I can open a dialog and have this problem resolved? I would be happy to forward the trace to the appropriate party at Cisco. -- Al Longyear longyear@sii.com The above opinions do not necessarily represent those of the Management of System Integrators nor any of its subsidiaries. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 6 21:27:38 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA08507; Mon, 6 Nov 1995 21:27:38 -0500 Resent-Date: Mon, 6 Nov 1995 21:27:38 -0500 From: Bill Miskovetz Message-Id: <199511070225.SAA10202@stilton.cisco.com> Subject: Re: Cisco 2509 PPP problems To: longyear@netcom.com Date: Mon, 6 Nov 95 18:25:47 PST Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199511070209.SAA00941@sii-4-30.sii.com>; from "Al Longyear" at Nov 6, 95 6:09 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"QzYnW1.0.i42.NGidm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/831 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > I have had a few people complain to me about problems trying to connect > to a Cisco 2509 (and probably the entire 2500 family since it seems that > they all use the same code) PPP software. > > The problem is that when I send an LCP Configure-request frame with the > option for the 'MRU', the Cisco product rejects _ALL_ of the options in the > LCP Configure-request frame. They don't just reject the MRU setting. What version of code are you running? This particular problem was fixed probably 4 months ago if not 6. For those who care, the bug id was CSCdi20562, fixed in 9.21(4.4), 10.2(2.1), 10.0(7.1). Never appeared in 10.3. > > This, in turn is followed by my sending a LCP configure-request frame > with no options (since all of the options were rejected, it is the only > thing which is permissible). The Cisco product ACKs the frame and at that > point, it ceases to process the IPCP protocol sequence. > > It just dumps all of the IPCP Configure request frames into the big bit > bucket in the sky. Can I get a debug ppp packet, debug ppp error, and debug ppp negotiation output of this? I've not seen this behavior. > > If I start a new session with them and don't send the LCP Configure- > request frame with the MRU, the Cisco product properly ACKs the frame > and life is sweet for IPCP. > > Does anyone have any contacts with Cisco so that I can open a dialog and > have this problem resolved? > > I would be happy to forward the trace to the appropriate party at Cisco. > > -- > Al Longyear longyear@sii.com > The above opinions do not necessarily represent those of the Management > of System Integrators nor any of its subsidiaries. > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 6 22:19:12 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id WAA09649; Mon, 6 Nov 1995 22:19:12 -0500 Resent-Date: Mon, 6 Nov 1995 22:19:12 -0500 From: "Al Longyear" Message-Id: <199511070319.TAA00992@sii-4-30.sii.com> Subject: Re: Cisco 2509 PPP problems To: misko@cisco.com (Bill Miskovetz) Date: Mon, 6 Nov 1995 19:19:02 -0800 (PST) Cc: longyear@netcom.com, ietf-ppp@MERIT.EDU In-Reply-To: <199511070225.SAA10202@stilton.cisco.com> from "Bill Miskovetz" at Nov 6, 95 06:25:47 pm Reply-To: "Al Longyear" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-XYtF.0.WM2.i0jdm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/832 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Bill Miskovetz wrote: >> I have had a few people complain to me about problems trying to connect >> to a Cisco 2509 (and probably the entire 2500 family since it seems that >> they all use the same code) PPP software. >> >> The problem is that when I send an LCP Configure-request frame with the >> option for the 'MRU', the Cisco product rejects _ALL_ of the options in the >> LCP Configure-request frame. They don't just reject the MRU setting. > > What version of code are you running? This particular problem was fixed > probably 4 months ago if not 6. For those who care, the bug id was CSCdi20562, > fixed in 9.21(4.4), 10.2(2.1), 10.0(7.1). Never appeared in 10.3. That's the rub. When I asked them "what version" all that I received was "It is a Cisco 2509." I will inform the people involved that they need to get the firmware upgrade and will let it go at that. Thank you for your help. >> This, in turn is followed by my sending a LCP configure-request frame >> with no options (since all of the options were rejected, it is the only >> thing which is permissible). The Cisco product ACKs the frame and at that >> point, it ceases to process the IPCP protocol sequence. >> >> It just dumps all of the IPCP Configure request frames into the big bit >> bucket in the sky. > > Can I get a debug ppp packet, debug ppp error, and debug ppp negotiation > output of this? I've not seen this behavior. I will send you the trace log from my side and put you in contact with the person who diagnosed what was wrong with the protocol. The others simply said "It doesn't work" and would proably not be as good. From my side, the IPCP configure-request frames are simply ignored. They would go out and no ACK would be received. No IPCP configure-request frames were received. It was as if it was totally silent on your transmitter. -- Al Longyear longyear@sii.com The above opinions do not necessarily represent those of the Management of System Integrators nor any of its subsidiaries. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 7 14:21:20 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA02275; Tue, 7 Nov 1995 14:21:20 -0500 Resent-Date: Tue, 7 Nov 1995 14:21:20 -0500 From: orozco@toshiro Message-Id: <9511071925.AA18281@toshiro.ctron> To: "Al Longyear" Cc: ietf-ppp@MERIT.EDU, orozco@toshiro Subject: Re: Cisco 2509 PPP problems In-Reply-To: Your message of "Mon, 06 Nov 95 18:09:53 PST." <199511070209.SAA00941@sii-4-30.sii.com> Date: Tue, 07 Nov 95 14:24:59 -0500 Resent-Message-ID: <"r28Gx3.0.EZ.I6xdm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/833 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Salutations All, Learning to be a diplomat. Commentary concerning product specific problem(s) messages or in general messages that are not specific PPP standard issues/questions/etc. Is it correct to enquire/publicize product specific problems in this forum? I question this because in addition to being a member of this forum I'm as well a member of several other forums. As Im' sure many of us are. Given, this I'm sure everyone can appreciate it takes unnecessary time to read/discard messages that are not germane to the forum - specially product specific problems. Best regards Adrian Orozco (603-337-1629, email:orozco@ctron.com) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 7 15:52:56 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA05169; Tue, 7 Nov 1995 15:52:56 -0500 Resent-Date: Tue, 7 Nov 1995 15:52:56 -0500 Date: Tue, 7 Nov 95 20:14:06 GMT From: "William Allen Simpson" Message-ID: <2001.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: Cisco 2509 PPP problems Resent-Message-ID: <"uc2tk3.0.RG1.YSydm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/834 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: orozco (unknown domain) > Is it correct to enquire/publicize product specific problems in this forum? Yes! These are detailed "what packets are exchanged" style problems. Not "how do I configure the frotz", nor "what product should I buy". > I > question this because in addition to being a member of this forum I'm as well > a member of several other forums. This isn't a "forum". This is a designers and implementors working group. There are some places where it is forbidden to mention the names of specific products. The IETF isn't one of them. Note that the report generated good exchanges of information (traces) helpful to the developer, and demonstrated an interoperability problem. Interoperability is what we are about. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 8 09:17:49 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA00367; Wed, 8 Nov 1995 09:17:49 -0500 Resent-Date: Wed, 8 Nov 1995 09:17:49 -0500 Date: Wed, 8 Nov 1995 07:16:31 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511081416.HAA08313@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Cisco 2509 PPP problems Resent-Message-ID: <"A-oQL2.0.W5.xlBem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/835 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "William Allen Simpson" > >> From: orozco (unknown domain) >> Is it correct to enquire/publicize product specific problems in this forum? > > Yes! > > These are detailed "what packets are exchanged" style problems. > > Not "how do I configure the frotz", nor "what product should I buy". > >> I >> question this because in addition to being a member of this forum I'm as well >> a member of several other forums. > > This isn't a "forum". This is a designers and implementors working group. > > There are some places where it is forbidden to mention the names of > specific products. The IETF isn't one of them. > > Note that the report generated good exchanges of information (traces) > helpful to the developer, and demonstrated an interoperability problem. > Interoperability is what we are about. No! Bugs are no more than bugs, even if they involve interoperability. This is a mailing list of "a designers and implementors working group." It is not an arena for beating each other up just for the sport of it. Leave that for netnews and salescritter talk. As a prolific bug reporter for decades, I leared public bug reporting by strangers is viewed as a hostile action by the people working on the product. You can say that is bad or talk about "egoless programming," but you cannot change it. Even insiders must be careful. Also, people generally use public bug reporting to beat up the vendor. So like most people, I avoid castigating other people's products, except when the resulting hostility is compensated for by other goals. (Yes, that's only the theory. I very often get sloppy, or let my emotions take over.) Al Longyear would have received as much or more information if he had checked contributors to this list looking for user@cisco.com, and sent private mail to Fred Baker, or looked farther and mailed to Tony Li. I know of bugs, some serious, in other vendor's PPP implementations. I, collegues, or customers have tried to communicate them to the relevant vendors. There is value in publishing them except when there are common themes or public statements contrary to fact, and then I prefer not to name names. Almost all of the nominally public interoperability tests that I've heard of have had non-disclosure agreements (not just PPP). We've been doing a bunch of private PPP testing, but I will not name participants, not to mention bugs. I know blabbermouths don't get invited to the next party. Vernon Schryver, vjs@sgi.com P.S. I wonder if Al Longyear correctly interpreted what happened. Could it be that Cisco was ignoring the IPCP packets because it legitmately thought the link was still in Establish Phase? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 8 09:45:57 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA01220; Wed, 8 Nov 1995 09:45:57 -0500 Resent-Date: Wed, 8 Nov 1995 09:45:57 -0500 From: sgw Message-Id: <9511081443.AA13334@sgw.xyplex.com> Subject: Re: Cisco 2509 PPP problems To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Wed, 8 Nov 95 9:43:51 EST Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199511081416.HAA08313@mica.denver.sgi.com>; from "Vernon Schryver" at Nov 8, 95 7:16 am X-Mailer: ELM [version 2.3 PL8] Resent-Message-ID: <"jU-aX3.0.rI.VACem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/836 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU According to Vernon Schryver: > > > From: "William Allen Simpson" > > > >> From: orozco (unknown domain) > >> Is it correct to enquire/publicize product specific problems in this forum? > > > > Yes! > > > > No! Bugs are no more than bugs, even if they involve interoperability. > This is a mailing list of "a designers and implementors working group." > It is not an arena for beating each other up just for the sport of it. > Leave that for netnews and salescritter talk. > You're right, this isn't a forum for verbal abuse and flame-throwing. Of course that never happens. :-) My opinion is that if a message generates positive results, then it was worthwhile. The intent of his original message was to solve a problem. Not to bash anyone. If everyone could distinguish the difference and not take it personally, then the stencil on my 'D' key wouldn't be so worn off as it is now. +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 9 19:34:08 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA20348; Thu, 9 Nov 1995 19:34:08 -0500 Resent-Date: Thu, 9 Nov 1995 19:34:08 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Nov 1995 16:33:02 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Use of PPP NCPs on Frame Relay Cc: inads@research.ftp.com Resent-Message-ID: <"qq_bM2.0.bz4.Ztfem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/837 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I need to know how to advise my Area Director. You will all remember (all too well) the discussions between PPP WG and IPLPDN WG about the drafts draft-ietf-pppext-dataencap-03.txt and draft-ietf-pppext-frame-relay-03.txt Now, the last recommendation I gave the IESG, from the working group, was that IPLPDN wanted draft-ietf-pppext-dataencap-03.txt to become a Proposed Standard, and PPP wanted draft-ietf-pppext-frame-relay-03.txt to become a Proposed Standard. It would be *very*good* if we could select exactly one, especially if we could do so based on deployment experience. Please give me your experience, your analysis, and your recommendation. And please be gentle :^) Fred >Date: Thu, 9 Nov 95 13:21:37 EST >To: fred@cisco.com, bsimpson@morningstar.com >Subject: ppp/fr >From: kasten@ftp.com (Frank Kastenholz) >Cc: set@bellcore.com, iesg@cnri.reston.va.us > >I'm on the iesg teleconference right now. We just discussed this. >the history is 'interesting' > >anyway here's what's happening >1. the ppp working group owns the entire fr issue as far as running IP over it >2. the ppp working group may submit a single document defining how to do ppp > over frame relay. >3. the ppp working group may submit two documents. If so, they must > cross-reference each other. >4. the ppp wg could do nothing if it so desires :-) > >so, fred, as ppp wg chair, the ball is in your court. You should figure >out what the WG wants to do and make the right submission to me, including >a pointer to the relevant internet draft(s). > >and if you get back to me within 10 minutes I'll still be on the call :-) >-- > >Frank Kastenholz =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 12:59:55 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA14449; Fri, 10 Nov 1995 12:59:55 -0500 Resent-Date: Fri, 10 Nov 1995 12:59:55 -0500 X-Mailer: SuperHighway Access 2 for Windows Version 95.11 (Mailer Version 1.02) Message-ID: <30A3930A-00000001@allen.onramp.net> From: allen@onramp.net Date: Fri, 10 Nov 1995 11:59:35 cst To: ietf-ppp@MERIT.EDU MIME-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII Resent-Message-ID: <"J4L-R.0.RX3.3Cvem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU Subject: Unidentified subject! X-Mailing-List: archive/latest/838 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I would like to confirm the operation of the ACCM. Recently I discovered a service provider that has a ppp implementation that doesn't accept the value NAKed to it. It is my understanding that peer1 should take the ACCM from peer2 and bitwise or it in with its own ACCM and put that value in the Nak, peer 2 should then take the Naked value and use it in its next Config Req. The following is what I see on the link. peer1 peer2 Config Req 1 ACCM FFFFFFFF Config Req 1 ACCM 00020000 Config Ack 1 Config Nak 1 ACCM FFFFFFFF Config Req 2 ACCM 00020000 Config Nak 2 ACCM FFFFFFFF Config Req 3 ACCM 00020000 Config Nak 3 ACCM FFFFFFFF This goes on until peer 2 gives up. The following is what I believe should be happening: peer1 peer2 Config Req 1 ACCM FFFFFFFF Config Req 1 ACCM 00020000 Config Ack 1 Config Nak 1 ACCM FFFFFFFF Config Req 2 ACCM FFFFFFFF Config Ack 2 ACCM FFFFFFFF - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 13:08:23 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA14823; Fri, 10 Nov 1995 13:08:23 -0500 Resent-Date: Fri, 10 Nov 1995 13:08:23 -0500 Message-Id: <199511101807.NAA15318@phish.nexen.com> To: fred@cisco.com (Fred Baker) cc: ietf-ppp@MERIT.EDU, inads@research.ftp.com, malis@nexen.com Subject: Re: Use of PPP NCPs on Frame Relay In-reply-to: Your message of "Thu, 09 Nov 1995 16:33:02 PST." Date: Fri, 10 Nov 1995 13:07:21 -0500 From: "Andrew G. Malis" Resent-Message-ID: <"SjSnU3.0.Ed3.3Kvem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/839 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Fred, > Now, the last recommendation I gave the IESG, from the working group, was > that IPLPDN wanted draft-ietf-pppext-dataencap-03.txt to become a Proposed > Standard, and PPP wanted draft-ietf-pppext-frame-relay-03.txt to become a > Proposed Standard. It would be *very*good* if we could select exactly one, > especially if we could do so based on deployment experience. > > Please give me your experience, your analysis, and your recommendation. And > please be gentle :^) Here's my as-gentle-as-possible take on where things stand: As I recall (and to all of you out there, please feel as free as always to correct my possibly rusty memory :-), both of these drafts were the result of a perceived requirement to add end-to-end negotiations to RFC 1490, in particular, to allow the use of compression and/or encryption when sending IP over FR. I reread the two drafts this morning to refresh my memory, and the differences between the two can be summarized as: * dataencap wants to use PPP negotiation mechanisms only, and retain RFC 1490 encapsulations for data, while ppp-in-fr wants to run PPP as natively as possible, including PPP data encapsulations where they exist, and use 1490 encapsulations only where PPP encapsulations do not exist. There are some other major differences: * dataencap is incompatible with the Compression CP. This is unfortunate, given the initial requirement that started this work. * dataencap can lose state for any encapsulated protocol. ppp-in-fr can lose state for any encapsulated protocol that doesn't have a native PPP encapsulation. * dataencap allows FR interfaces to be run in "multi-access" mode or "lots-of-point-to-point-lines" mode. ppp-in-fr requires the latter mode, which may require implementations to configure a virtual PPP interface for each FR connection. I am not personally aware of any implementations of either draft, although I would not be surprised if Bill has implemented ppp-in-fr. Since these drafts were written, work has been proceeding in an alternate universe (aka the Frame Relay Forum) on compression over FR. This work was originally closely aligned with the CCP work, until the PPP WG made the decision to require CCP to run over reliable links. The FRF instead agreed to Motorola's patent licensing terms, and has now somewhat diverged from CCP. The FRF work has turned into a complete Data Compression Protocol (DCP), to negotiate the use of compression when using RFC 1490 encapsulation. It has its own assigned NLPID, 0xB0. If you read the document, you'll see a lot that still looks very familiar; in particular, like the dataencaps I-D, it uses RFC1661-standard LCP to negotiate options, but encapsulated within 0xB0 rather than 0xCF, so that it can be distinguished from PPP. Like CCP, it has a list of option code points to define the compression type, but it uses the list defined in TIA/EIA 655 rather than the list in the CCP I-D (the code points don't conflict, and need never conflict as long as CCP remains aligned with TIA/EIA 655, which is a good idea in any case). For interoperability, there is one compression type that MUST be in every implementation, ANSI X3.241-1994 (LZS). Like CCP, the OUI code point (0) is used to identify proprietary compression algorithms. There has been a lot of support in the FRF for this work, and I fully expect it to be widely implemented in FR end devices. There is also no reason why it can't be extended (or an extremely similar protocol used) to cover encryption over FR as well, and I expect this to occur once the compression work completes (which is itself Real Soon Now). To conclude this diatribe: The PPP WG has to reach consensus on the purpose of this work. There are three alternatives: 1. These drafts were really only going to be used to support compression and/or encryption over FR. 2. There are other good uses for PPP negotiation over FR, and it's important to retain FR's multi-access properties as well. 3. We really see a market requirement to run full PPP over FR. If the WG agrees to 1., then given the expectation of FRF DCP being widely adopted and implemented, it makes little sense, especially for interoperability, to have multiple means for performing compression and/or encryption over FR. In this case, neither should be advanced. If the WG agrees to 2., then using FRF DCP in conjunction with dataencap makes sense (especially since dataencap isn't compatible with CCP anyway). If the WG agrees to 3., then fr-in-ppp should be advanced. However, this will give the industry two competing, and incompatible, methods of doing compression and/or encryption over FR. Given that FR is the FRF's home turf, I expect that FRF DCP would be preferred over ppp-in-fr, and it would be important to amend the fr-in-ppp spec to specify that CCP and ECP should not be used over FR. Best regards, Andy P.S. In the message you forwarded from Frank, I was amused :-) by the following statement: > >1. the ppp working group owns the entire fr issue as far as running > > IP over it Have we transferred 1490 to the PPP WG? :-) P.P.S. Before people start asking me for copies of the FRF DCP doc: it is currently a draft document of the FRF Technical Committee, and as such it is currently restricted to FRF members. Check internally; you may be a FRF member and not even realize it. Meanwhile, I'll see it if is possible to make a postscript or PDF copy, clearly marked as a draft, available for public distribution, but I can't promise anything. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 14:47:20 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA18102; Fri, 10 Nov 1995 14:47:20 -0500 Resent-Date: Fri, 10 Nov 1995 14:47:20 -0500 Message-ID: <01BAAF7B.6A5E19A0@ppp-pm01-dy-20.opr.oakland.edu> From: Brad Wilson To: "'allen@onramp.net'" , "ietf-ppp@MERIT.EDU" Subject: ACCM NAKs (was Unidentified subject!) Date: Fri, 10 Nov 1995 14:38:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jYmoT.0.dQ4.-mwem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/840 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU What you've described sounds like a misunderstanding on the part of the other implementation. In this scenario (believe me, ACCM is the one that always seems to be a little different from vendor to vendor), I would reject the ACCM, thus forcing it into a safe state (this presumes you're working on Async, where FFFFFFFF is the default ACCM). I'm a little curious about your desire to send an ACCM of all F's ... why send the configuration option to begin with? -- Brad Wilson Software Engineering Express Technologies Corporation mailto://bradw@exptech.com http://www.exptech.com +1 810 620-9803 Microsoft Exchange Rich Text Format mail accepted and appreciated! "Money is the living power that dies without its root. Money will not serve the mind that cannot match it." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 15:23:11 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA19480; Fri, 10 Nov 1995 15:23:11 -0500 Resent-Date: Fri, 10 Nov 1995 15:23:11 -0500 Date: Fri, 10 Nov 1995 13:21:41 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511102021.NAA17571@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Use of PPP NCPs on Frame Relay Cc: inads@research.ftp.com Resent-Message-ID: <"Cm34N2.0.vl4.zHxem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/841 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > To: fred@cisco.com (Fred Baker) > cc: ietf-ppp@MERIT.EDU, inads@research.ftp.com, malis@nexen.com > Subject: Re: Use of PPP NCPs on Frame Relay > From: "Andrew G. Malis" > ... the > PPP WG made the decision to require CCP to run over reliable links. > ... The PPP working group emphatically never decided any such thing! There was a proposal in that direction, but as I recall, it was withdrawn. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 15:55:46 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA20473; Fri, 10 Nov 1995 15:55:46 -0500 Resent-Date: Fri, 10 Nov 1995 15:55:46 -0500 Message-Id: <199511102054.PAA17998@phish.nexen.com> To: vjs@mica.denver.sgi.com (Vernon Schryver) cc: ietf-ppp@MERIT.EDU, inads@research.ftp.com, malis@nexen.com Subject: Re: Use of PPP NCPs on Frame Relay In-reply-to: Your message of "Fri, 10 Nov 1995 13:21:41 MST." <199511102021.NAA17571@mica.denver.sgi.com> Date: Fri, 10 Nov 1995 15:54:50 -0500 From: "Andrew G. Malis" Resent-Message-ID: <"fENrx3.0.f_4.Enxem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/842 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon, > > ... the > > PPP WG made the decision to require CCP to run over reliable links. > > ... > > The PPP working group emphatically never decided any such thing! > There was a proposal in that direction, but as I recall, it was withdrawn. It's on p. 179 of the Stockholm proceedings, unless it was later recinded over the list (which I don't recall seeing). Cheers, Andy - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 17:24:22 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA23344; Fri, 10 Nov 1995 17:24:22 -0500 Resent-Date: Fri, 10 Nov 1995 17:24:22 -0500 Date: Fri, 10 Nov 1995 15:19:30 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511102219.PAA18073@mica.denver.sgi.com> To: "Andrew G. Malis" Subject: Re: Use of PPP NCPs on Frame Relay Cc: inads@research.ftp.com, ietf-ppp@MERIT.EDU Resent-Message-ID: <"owPuU1.0.Xi5.F4zem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/843 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > To: vjs (Vernon Schryver) > cc: ietf-ppp@MERIT.EDU, inads@research.ftp.com, malis@nexen.com > Subject: Re: Use of PPP NCPs on Frame Relay > From: "Andrew G. Malis" > > Vernon, > > > > ... the > > > PPP WG made the decision to require CCP to run over reliable links. > > > ... > > > > The PPP working group emphatically never decided any such thing! > > There was a proposal in that direction, but as I recall, it was withdrawn. > > It's on p. 179 of the Stockholm proceedings, unless it was later > recinded over the list (which I don't recall seeing). Are we talking about the same thing? The abortive (!) proposal to deal with the Motorola patents by forgetting all of the existing compression protocol drafts and switching to something else? I think that was subsequently squashed and withdrawn. Even if the IETF wanted to follow that path, it is too late. Look at packet traces of systems in the field, and notice that many of them are doing CCP, and not with PPP-LAPB but with the same thing we've been talking about for 2+ years. What reliability is required is handled by the compression protocols themselves. There are a lot of boxes doing Stac's LZS. There are also a lot of PC's running NetBSD, FreeBSD, or Linux doing BSD Compress. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 17:57:43 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA24537; Fri, 10 Nov 1995 17:57:43 -0500 Resent-Date: Fri, 10 Nov 1995 17:57:43 -0500 X-Sender: stadler@mailhost.catapent.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Nov 1995 14:56:41 -0800 To: ietf-ppp@MERIT.EDU From: stadler@catapent.com (Andy Stadler) Subject: IPCP negotiation of router, DNS? Resent-Message-ID: <"kgu0d1.0.5_5.ZZzem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/844 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello all, I am fairly new to the PPP world so I apologize if this is old rehashed stuff. I'm wondering if there has ever been any discussion or movement, either positive or negative, with respect to higher-level negotiations at the IPCP level. Specifically, I interested in the ability to dynamically assign (along with the IP address) the default router(s), default domain name server(s), and default local domain name information. These are items which would simplify user configuration of a dialup TCP/IP link. ATCP makes a few stabs in this general direction (although much of that auto-configuration is intrisic to AppleTalk). But as far as I've ever seen no additional options for IPCP were ever defined beyond 1, 2 and 3. Any pointers to previous documentation or discussions would be appreciated. Thanks, Andy Stadler Catapult Entertainment, Inc. stadler@catapent.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 18:15:37 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA25059; Fri, 10 Nov 1995 18:15:37 -0500 Resent-Date: Fri, 10 Nov 1995 18:15:37 -0500 Date: Fri, 10 Nov 1995 15:14:19 -0800 (PST) From: Kory Hamzeh To: Andy Stadler cc: ietf-ppp@MERIT.EDU Subject: Re: IPCP negotiation of router, DNS? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"7lvU61.0.K76.Mqzem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/845 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Fri, 10 Nov 1995, Andy Stadler wrote: > > I'm wondering if there has ever been any discussion or movement, either > positive or negative, with respect to higher-level negotiations at the IPCP > level. > > Specifically, I interested in the ability to dynamically assign (along with > the IP address) the default router(s), default domain name server(s), and > default local domain name information. These are items which would > simplify user configuration of a dialup TCP/IP link. > Hi Andy, Microsoft proposed a series of IPCP option to do this, but it was shot down because it was felt that it was a higher level issue than PPP. Once the connection comes up, you can use DHCP to get all that information. Kory - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 18:23:08 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA25311; Fri, 10 Nov 1995 18:23:08 -0500 Resent-Date: Fri, 10 Nov 1995 18:23:08 -0500 From: Craig Fox Message-Id: <199511102314.PAA13126@greatdane.cisco.com> Subject: Re: IPCP negotiation of router, DNS? To: stadler@catapent.com (Andy Stadler) Date: Fri, 10 Nov 95 15:14:04 PST Cc: ietf-ppp@MERIT.EDU In-Reply-To: ; from "Andy Stadler" at Nov 10, 95 2:56 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"jN4l72.0.GB6.Nxzem"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/846 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > Hello all, > > I am fairly new to the PPP world so I apologize if this is old rehashed stuff. > > I'm wondering if there has ever been any discussion or movement, either > positive or negative, with respect to higher-level negotiations at the IPCP > level. > Yes. > Specifically, I interested in the ability to dynamically assign (along with > the IP address) the default router(s), default domain name server(s), and > default local domain name information. These are items which would > simplify user configuration of a dialup TCP/IP link. > The default router(s) is irrelevant. On dialup link, everything that is not for your own host address is forwarded on the link. The peer is in effect the default router. It is responsible for forwarding it to the destination address in the IP packet. Often times, it will have a default router on the LAN(s) it is connected too, but the dial-up client does not need to know where the peer will forward it to next. Microsoft has proposed extensions to negotiate up to two DNS addresses. There is currently an internet-draft out. I expect that it will become an informational RFC as it is used by Windows 95 and Windows NT already. There has been no discussion, that I can remember, about negotiatiing the domain info. The consensus of the IETF PPP Working Group in the past is that DHCP should be used to determine the DNS and domain info as well as other high-level information. > ATCP makes a few stabs in this general direction (although much of that > auto-configuration is intrisic to AppleTalk). But as far as I've ever seen > no additional options for IPCP were ever defined beyond 1, 2 and 3. > Microsoft has chosen 128-131. These will probably be assigned to them by IANA in the near future if it is not already done. The weight of 10 million copies can not be ignored. :-( The Microsoft draft is the internet-draft directory of your favorite IETF repository. You may also find it and other interesting material at ftp.microsoft.com. I forget the path, just explore. > > Any pointers to previous documentation or discussions would be appreciated. > > Thanks, > > Andy Stadler > Catapult Entertainment, Inc. > stadler@catapent.com > > > Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 23:28:30 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id XAA02871; Fri, 10 Nov 1995 23:28:30 -0500 Resent-Date: Fri, 10 Nov 1995 23:28:30 -0500 Date: Sat, 11 Nov 95 02:26:58 GMT From: "William Allen Simpson" Message-ID: <2010.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: Unidentified subject! Resent-Message-ID: <"bJOvD.0.3i.aP2fm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/848 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: allen@onramp.net > peer1 peer2 > Config Req 1 > ACCM FFFFFFFF > Peer1 has made a mistake here. RFC-1661 page 28: Configuration Options SHOULD NOT be included with default values. > Config Req 1 > ACCM 00020000 > Reasonable. > Config Ack 1 > Reasonable. > Config Nak 1 > ACCM FFFFFFFF This is a mistake. If peer1 does not implement ACCM except as a default, it should -Reject, not -Nak. > Config Req 2 > ACCM 00020000 > This is also a mistake. RFC-1662 page 15 explicitly allows: 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. It would be rather hard to get this to work if peer2 fails to use the -Nak bits in its next request. And since the bits are the default, peer2 should not include an ACCM in its -Request. > This goes on until peer 2 gives up. > That's another mistake. Peer1 should stop sending the -Nak long before peer2 gives up. RFC-1661 page 25: Max-Failure A related counter is recommended for Configure-Nak. Max-Failure indicates the number of Configure-Nak packets sent without sending a Configure-Ack before assuming that configuration is not converging. Any further Configure-Nak packets for peer requested options are converted to Configure-Reject packets, and locally desired options are no longer appended. Max-Failure MUST be configurable, but SHOULD default to five (5) transmissions. Again, peer1 should -Reject. Peer2 should send 5 more attempts (Max-Configure defaults to 10). Too bad you didn't tell us the vendors.... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 10 23:28:27 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id XAA02851; Fri, 10 Nov 1995 23:28:27 -0500 Resent-Date: Fri, 10 Nov 1995 23:28:27 -0500 Date: Sat, 11 Nov 95 02:06:19 GMT From: "William Allen Simpson" Message-ID: <2009.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: Use of PPP NCPs on Frame Relay Resent-Message-ID: <"TAgrE.0.rh.YP2fm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/847 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Andrew G. Malis" > * dataencap wants to use PPP negotiation mechanisms only, and retain > RFC 1490 encapsulations for data, while ppp-in-fr wants to run PPP > as natively as possible, including PPP data encapsulations where > they exist, and use 1490 encapsulations only where PPP > encapsulations do not exist. > Actually, the latter is slightly different: use PPP encapsulations only when PPP NCPs are run. If not run, no PPP encap for that protocol, use RFC-1490 (mostly SNAP) instead. And of course, I will also note that PPP in FR is _strict_ RFC-1490 (NLPID 0xCF)! > There are some other major differences: > > * dataencap is incompatible with the Compression CP. This is > unfortunate, given the initial requirement that started this work. > Dataencap is even incompatible with IPCP! (address assignment, VJ negotiation). > * dataencap can lose state for any encapsulated protocol. ppp-in-fr > can lose state for any encapsulated protocol that doesn't have a > native PPP encapsulation. > The latter is not true. Any protocol not using PPP encapsulation is not PPP in FR. More correct to say: dataencap loses PPP NCP state, and has all the failings of RFC-1490, while PPP in FR maintains state negotiated by PPP NCPs. > * dataencap allows FR interfaces to be run in "multi-access" mode or > "lots-of-point-to-point-lines" mode. ppp-in-fr requires the latter > mode, which may require implementations to configure a virtual > PPP interface for each FR connection. > The _former_ is not true! There is no capability in dataencap to run in multi-access mode. > This work was originally closely aligned with the CCP work, until the > PPP WG made the decision to require CCP to run over reliable links. WHAT??? We made _no_ such decision!!! > The FRF instead agreed to Motorola's patent licensing terms, and has > now somewhat diverged from CCP. > No big surprise.... > To conclude this diatribe: > > The PPP WG has to reach consensus on the purpose of this work. There > are three alternatives: > > 1. These drafts were really only going to be used to support > compression and/or encryption over FR. > Huh? Not so! I certainly wanted ATCP, IPCP and IPXCP among others. Big potential market here in Michigan. A lot of inter-LATA traffic with FR, but NetWare spoofing won't run correctly, needs IPXCP. > 2. There are other good uses for PPP negotiation over FR, and it's > important to retain FR's multi-access properties as well. > It is not important to retain FR's multi-access properties. Indeed, they have proved unusable, at least for inter-LATA here in Michigan. > 3. We really see a market requirement to run full PPP over FR. > I agree with this statement. > > >1. the ppp working group owns the entire fr issue as far as running > > > IP over it > > Have we transferred 1490 to the PPP WG? :-) > That's my current understanding. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Nov 11 12:16:13 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA20522; Sat, 11 Nov 1995 12:16:13 -0500 Resent-Date: Sat, 11 Nov 1995 12:16:13 -0500 Message-ID: <01BAB02F.7BC576C0@ppp-pm01-dy-12.opr.oakland.edu> From: Brad Wilson To: "'Kory Hamzeh'" , Andy Stadler Cc: "ietf-ppp@MERIT.EDU" Subject: RE: IPCP negotiation of router, DNS? Date: Sat, 11 Nov 1995 11:56:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"zqWRA3.0.R05.NfDfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/849 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Microsoft proposed a series of IPCP option to do this, but it was shot >> down because it was felt that it was a higher level issue than PPP. It's worth stating that Microsoft actually DOES use these things, but they're done as a "vendor extension" to the PPP protocol. If found this incredibly odd since they also have DHCP support on all their platforms. I suspect they wanted to have a serial server without having a DHCP server under Win95. BTW, I agree, it's a DHCP issue. -- Brad Wilson Software Engineering Express Technologies Corporation mailto://bradw@exptech.com http://www.exptech.com +1 810 620-9803 Microsoft Exchange Rich Text Format mail accepted and appreciated! "Money is the living power that dies without its root. Money will not serve the mind that cannot match it." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Nov 11 20:57:56 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA02717; Sat, 11 Nov 1995 20:57:56 -0500 Resent-Date: Sat, 11 Nov 1995 20:57:56 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 11 Nov 1995 17:54:00 -0800 To: "Andrew G. Malis" From: fred@cisco.com (Fred Baker) Subject: Re: Use of PPP NCPs on Frame Relay Cc: ietf-ppp@MERIT.EDU, inads@research.ftp.com, malis@nexen.com Resent-Message-ID: <"IMUK33.0.Eg.HILfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/850 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 1:07 PM 11/10/95, Andrew G. Malis wrote: >If the WG agrees to 3., then fr-in-ppp should be advanced. However, >this will give the industry two competing, and incompatible, methods >of doing compression and/or encryption over FR. Given that FR is the >FRF's home turf, I expect that FRF DCP would be preferred over >ppp-in-fr, and it would be important to amend the fr-in-ppp spec to >specify that CCP and ECP should not be used over FR. for the record, I thought I heard mention of a desire to run Van Jacobsen Header compression and other mechanisms over Frame Relay. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 04:45:32 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id EAA08705; Mon, 13 Nov 1995 04:45:32 -0500 Resent-Date: Mon, 13 Nov 1995 04:45:32 -0500 Date: Mon, 13 Nov 1995 10:40:12 +0100 From: Christophe Vermeulen Message-Id: <199511130940.KAA06595@btmph4.se.bel.alcatel.be> To: bsimpson@morningstar.com Subject: Re: PPP on IDSN and PSTN : what are the frames ? Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"HNQb-.0.j72.IEnfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/851 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ->From bsimpson@morningstar.com Sat Nov 11 05:32:01 1995 First of all, Thank you very much for your answer. I was a bit lost "looking for frames and you helped me a lot with your mail. As you were so friendly to remind me of the normal way to send comments, I send a copy of this meme on the mailing list. Please all readers, send me a copy of your thoughts about this, as I'm not on the distribution list. ->> [looking at RFC 1661, ] ->> I was quite puzzled when I saw that only the protocol differentiation is ->> described, and no framing as in SLIP. [ that was left to ] unreferenced ->> companion documents. ->> ->Are you sure you are reading PPP? RFC-1661 clearly says -> -> The PPP encapsulation is used to disambiguate multiprotocol -> datagrams. This encapsulation requires framing to indicate the -> beginning and end of the encapsulation. Methods of providing framing -> are specified in companion documents. ^^^^^^^^^^^^^^^^^^^^^^ These are the ones I looked for, and no one said it was for PSTN. I understand now PSTN and X.25 are using the same specs. Simply a pity it's written nowhere. ->> So where's the standard [for PSTN] ? -> ->Why not try RFC-1662? Thanks for that : I'm currently looking at it. I already discovered very interesting things I didn't know byte-aligned HDLC existed. I only knew the bit-stuffing flavor. ->PSTN is an extremely small fraction of PPP use. See RFC-1598. That is not so clear to me : I understand X.25 can be used between hosts, but what I'm interested in is the access. Isn't it so that most people accessing the Net do that through a modem, using their telephone ? A lot of them still use SLIP, but migration to PPP is under way. Of course there are lucky guys like you and me that have access through Ethernet at their office, but that's not residential use. ->What you need is the RFC index, and the protocol status RFCs. I have those. Still none focuses on PSTN. Is it so that only RFC1662 is used ? Which of the flavors ? Octet-aligned, or all of them depending on the service/access provider ? Or depending of the LCP negotiation ? ->> I would like to transmit ATM cells on this line, as well. The ATM overhead ->> is made in software. Can I request a number to iana for supporting ATM as ->> just another protocol, near DECnet, Vines or IP ? ->> ->That would be strange. ATM is a layer (1) protocol. PPP is layer (2). Oh no ! ATM conveys routing information, and is typically a layer 3 protocol. So it makes sense. You can find ATM on top of SDH/SONET as layer 1, and for residential use, I'd like to use PPP to let it coexist with other protocols (e.g. IP) Typically, one ATM cell would be one packet encapsulated in PPP. Of course, it may be interesting to create bigger frames for efficiency reason. Also ATM header compression would make sense, but this is still too early to think of. -> ->> Is there a newsgroup where this is discussed ? I tried comp.protocols.tcp-ip ->> but I found nothing really about that. ->> ->(sigh) What does it say in the RFC? -> -> This document is the product of the Point-to-Point Protocol Working -> Group of the Internet Engineering Task Force (IETF). Comments should -> be submitted to the ietf-ppp@merit.edu mailing list. Thanks. I looked at a newsgroup so as not to hinder specialists unnecessarily. Another drawback of mailing lists is that it's a "closed group". ->Bill.Simpson@um.cc.umich.edu -> Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 -> - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 10:58:49 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA17255; Mon, 13 Nov 1995 10:58:49 -0500 Resent-Date: Mon, 13 Nov 1995 10:58:49 -0500 Date: Mon, 13 Nov 95 10:55:35 EST Message-Id: <9511131555.AA07285@mailserv-D.ftp.com> To: ietf-ppp@MERIT.EDU Subject: CCP (was Re: Use of PPP NCPs on Frame Relay) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon Nov 13 10:55:20 1995] Originating-Client: d-cell.ftp.com Content-Length: 900 Resent-Message-ID: <"LXCPx1.0.JD4.disfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/852 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU speaking as the relevant area director... our current strategy is to pursue the original ccp/ecp documents by getting the variance procedure out and then doing a variance to allow us to accept the offer made by motorola. the 're-do ccp/ecp to use reliable links' ran into rather vocal opposition by the wg. > > To: fred@cisco.com (Fred Baker) > > cc: ietf-ppp@MERIT.EDU, inads@research.ftp.com, malis@nexen.com > > Subject: Re: Use of PPP NCPs on Frame Relay > > From: "Andrew G. Malis" > > > ... the > > PPP WG made the decision to require CCP to run over reliable links. > > ... > > The PPP working group emphatically never decided any such thing! > > There was a proposal in that direction, but as I recall, it was withdrawn. > > > Vernon Schryver, vjs@sgi.com -- Frank Kastenholz - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 11:01:25 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA17436; Mon, 13 Nov 1995 11:01:25 -0500 Resent-Date: Mon, 13 Nov 1995 11:01:25 -0500 Date: Mon, 13 Nov 95 15:47:36 GMT From: "William Allen Simpson" Message-ID: <2026.bsimpson@morningstar.com> To: Christophe Vermeulen Cc: ietf-ppp@MERIT.EDU Subject: Re: PPP on IDSN and PSTN : what are the frames ? Resent-Message-ID: <"fX4cN1.0.DG4.Glsfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/853 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Christophe Vermeulen > I send a copy of this meme on the mailing list. Please all readers, > send me a copy of your thoughts about this, as I'm not on the distribution > list. > > Thanks. I looked at a newsgroup so as not to hinder specialists unnecessarily. > Another drawback of mailing lists is that it's a "closed group". > If you are an implementor, you are a specialist. The mailing list is "open". Please join the mailing list by sending to the usual '-request'. You will learn much more about PPP than you ever wanted to know. ISDN is a current topic. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 12:18:44 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA20189; Mon, 13 Nov 1995 12:18:44 -0500 Resent-Date: Mon, 13 Nov 1995 12:18:44 -0500 From: marty@shiva.com Date: Mon, 13 Nov 95 12:11:57 PST Subject: IPCP negotiation of router, DNS? To: ietf-ppp@MERIT.EDU X-Mailer: Chameleon ARM_55, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"TQgwB2.0.Ax4.dttfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/854 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I resent the way the use of the word "consensus" by Craig Fox in the following paragraph: >The consensus of the IETF PPP Working Group in the past is that DHCP >should be used to determine the DNS and domain info as well as other >high-level information. Shiva and Microsoft both believe that there is much value in having one peer give this information to the other peer. Well, who am I kidding; there is much value in having the dial-in server give this information to a dial-in client. Yeah, DHCP is great and everything, but I'm trying to solve a customer problem, and DHCP isn't always there to help. In addition, most of the TCP/IP stacks available for PCs (including Macs) aren't smart enough to DHCP at the right time. The majority of the PPP working group basically decided that, if there exists a tool that "should" be able to solve your problem (DHCP), then we won't allow the problem to be solved in any other way (IPCP). Microsoft and Shiva believe that IPCP is perfectly appropriate for solving this problem. Microsoft went ahead and stole some IPCP option numbers, and Shiva supports them. So you can say that most PPP working group members see it that way, but please don't say there was a consensus. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 12:50:13 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA21317; Mon, 13 Nov 1995 12:50:13 -0500 Resent-Date: Mon, 13 Nov 1995 12:50:13 -0500 From: Craig Fox Message-Id: <199511131748.JAA27858@greatdane.cisco.com> Subject: Re: IPCP negotiation of router, DNS? To: marty@shiva.com Date: Mon, 13 Nov 95 9:48:45 PST Cc: ietf-ppp@MERIT.EDU In-Reply-To: ; from "marty@shiva.com" at Nov 13, 95 12:11 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"nojP33.0.-A5.4Lufm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/855 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > I resent the way the use of the word "consensus" by Craig Fox > in the following paragraph: > > >The consensus of the IETF PPP Working Group in the past is that DHCP > >should be used to determine the DNS and domain info as well as other > >high-level information. > > Shiva and Microsoft both believe that there is much value in > having one peer give this information to the other peer. Well, who > am I kidding; there is much value in having the dial-in server give > this information to a dial-in client. > Then every single piece of information that a client might need will eventually have an option #, right? Why did you stop with primary and secondary DNS addresses? Or more to the point. If the server has this information, why not build a DHCP implementation in the server. > Yeah, DHCP is great and everything, but I'm trying to solve a > customer problem, and DHCP isn't always there to help. In addition, > most of the TCP/IP stacks available for PCs (including Macs) aren't > smart enough to DHCP at the right time. > And most don't do the Microsoft IPCP extensions although that may change for market reasons. If Microsoft and Shiva had thrown their support behind doing DHCP over PPP, then I think most clients would soon have this feature. The DNS may not be there for your solution either, perhaps we can implement it in IPCP. :-) > The majority of the PPP working group basically decided that, if there > exists a tool that "should" be able to solve your problem (DHCP), then > we won't allow the problem to be solved in any other way (IPCP). > No. We said we wouldn't bless another way. I can not prevent you or anyone else from creating a private protocol (Shiva PAP for example) and implementing it. Since Shiva PAP does not have a PPP WG draft or RFC, have you been prevented from implementing or shipping it? Over the years, the WG has filtered out a series of lame and almost lame suggestions for PPP features. I do not feel that Microsoft's solution falls into either of these categories. It is however, a duplication of effort, since now clients have been implemented both ways. > Microsoft and Shiva believe that IPCP is perfectly appropriate for > solving this problem. Microsoft went ahead and stole some IPCP option > numbers, and Shiva supports them. > The stealing of the numbers is inappropriate at best. Fortunately, few vendors do this or at least few implementations are seen with these assigned values. If nothing else, it makes it very difficult for Patrick Klos, Karl Fox, or the FTP Software LanWatch folks to decode the unknown values. > So you can say that most PPP working group members see it that way, > but please don't say there was a consensus. > I am sorry that I left out the word 'rough'. As in 'rough consensus and working code'. In any event, the choice of the wording is irrelevant. The PPP Working Group does not own PPP. There are methods in the protocol and the community for extending the protocol suite with vendor proprietary solutions. I applaud Microsoft in there willingness to document these extensions, first as suggestions to the working group, and when rejected by the working group, as informational internet drafts. I only wish every vendor was so concientious (sp?). You need only look at the assigned numbers to see several proprietary protocols, and options to standard protocols. Microsoft made this information available to the community a year prior to their common use in Windows 95. It is up to each implementor whether they wish to support the option. > > Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 13:17:09 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA22350; Mon, 13 Nov 1995 13:17:09 -0500 Resent-Date: Mon, 13 Nov 1995 13:17:09 -0500 Date: Mon, 13 Nov 1995 13:15:55 -0500 From: Jonathan Wenocur Message-Id: <199511131815.NAA11559@shiva-dev.shiva.com> To: ietf-ppp@MERIT.EDU Subject: Re: IPCP negotiation of router, DNS? Resent-Message-ID: <"g3WTL3.0.yS5.Lkufm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/856 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The usability of PPP and DHCP together has been an issue for a while which only recently has really been resolved I think. The current approved method for passing these kinds of parameters to the dial-in client is using DHCPINFORM, which, in all fairness didn't exist a year ago when Microsoft first started using these options. INFORM asks the DHCP server for config info minus the client IP address (since IPCP must already be up and running before DHCP can be used -- which has been the basic issue with PPP and DHCP working together -- you can't use DHCP until IPCP is up, and you can't bring up IPCP until you've obtained an address via DHCP -- I believe the "approved" way from the DHCP WG now let's IPCP handle the IP address and just uses DHCPINFORM to get the config params). - Jonathan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 13:31:50 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA23229; Mon, 13 Nov 1995 13:31:50 -0500 Resent-Date: Mon, 13 Nov 1995 13:31:50 -0500 Message-Id: <199511131831.NAA14892@phish.nexen.com> To: kasten@ftp.com cc: ietf-ppp@MERIT.EDU, malis@nexen.com Subject: Re: CCP (was Re: Use of PPP NCPs on Frame Relay) In-reply-to: Your message of "Mon, 13 Nov 1995 10:55:35 EST." <9511131555.AA07285@mailserv-D.ftp.com> Date: Mon, 13 Nov 1995 13:31:04 -0500 From: "Andrew G. Malis" Resent-Message-ID: <"3HTpY3.0.kg5.Dyufm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/857 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Frank, > our current strategy is to pursue the original ccp/ecp documents > by getting the variance procedure out and then doing a variance > to allow us to accept the offer made by motorola. > the 're-do ccp/ecp to use reliable links' ran into rather vocal > opposition by the wg. Much thanks for the clarification. Cheers, Andy - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 13:39:35 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA23399; Mon, 13 Nov 1995 13:39:35 -0500 Resent-Date: Mon, 13 Nov 1995 13:39:35 -0500 Date: 13 Nov 95 13:36:30 EST From: Tom Coradetti <70761.1664@compuserve.com> To: ppp Subject: No room for new multilink bundle Message-ID: <951113183629_70761.1664_EHM137-1@CompuServe.COM> Resent-Message-ID: <"4xP5Q3.0.Bj5.V3vfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/858 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I would like to suggest a change in draft-ietf-pppext-multilink-11.txt, the most recent draft I have of RFC 1717, The PPP Multilink Protocol (MP). When I wrote up the description of the Endpoint Discriminator Option, I did not adequately address the situation where the peer receiving an LCP Configure Request containing multilink options does not have sufficient resources to open an ADDITIONAL bundle, although it may have one or more open already. In the original text reproduced below, it states that a new bundle MUST be established if the Endpoint Discriminator in a Configure Request does not match one for an existing bundle. However, this is not possible if there is no capacity to add a bundle. My proposal is to do the following: If the Configure Request contains an ED option which would have forced a new bundle, reject the option. If no ED option is in the request, but a new bundle would have been forced because other links did open with an ED option and thus the implied class 0 address 0 ED option does not match, terminate the link. The receiving side could choose to terminate the link immediately, rather than rejecting the ED, but it seems that there is a slight problem resolution advantage to rejecting the option first. If the peer behaves properly and removes the option on the next request, the receiver will terminate the link due to the implied mismatch. If the peer does not remove the request, the request retry count will run out and the link will terminate that way. I propose the text below to resolve the problem. Original text: The Endpoint Discriminator Option represents identification of the system transmitting the packet. This option advises a system that the peer on this link could be the same as the peer on another existing link. If the option distinguishes this peer from all others, a new bundle MUST be established from the link being negotiated. If this option matches the class and address of some other peer of an existing link, the new link MUST be joined to the bundle containing the link to the matching peer or MUST establish a new bundle, depending on the decision tree shown in (1) through (4) below. Added text to same paragraph: If the system can not establish a new bundle it MUST reject the option if present, or else terminate the link. For the requesting side, I also propose the text below. Original text: This option is not required to be supported either by the system or the peer. If the option is not present in a Configure-Request, the system MUST NOT generate a Configure-Nak of this option for any reason; instead it SHOULD behave as if it had received the option with Class = 0, Address = 0. If a system receives a Configure-Nak or Configure-Reject of this option, it MUST remove it from any additional Configure-Request. Added text to new paragraph: If a Configure-Reject is received on a link which was to be added to an existing bundle, and the option was not rejected for the other open links in the bundle, the link SHOULD be terminated. -------------------------------------------------------- Tom Coradetti Sidewalk Software Phone: (612) 490 7856 1190 Josephine Road Email: 70761.1664@compuserve.com Roseville, MN 55113 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 14:06:28 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA24498; Mon, 13 Nov 1995 14:06:28 -0500 Resent-Date: Mon, 13 Nov 1995 14:06:28 -0500 Date: Mon, 13 Nov 1995 12:05:17 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511131905.MAA25968@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: stealing numbers Resent-Message-ID: <"xCM092.0.Y-5.eSvfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/859 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Craig Fox > > Microsoft and Shiva believe that IPCP is perfectly appropriate for > > solving this problem. Microsoft went ahead and stole some IPCP option > > numbers, and Shiva supports them. > > > The stealing of the numbers is inappropriate at best. Fortunately, few > vendors do this or at least few implementations are seen with these > assigned values. ... Besides Microsoft and Shiva (PAP and CHAP) and Ascend (LCP option #0), what other vendors have done that? Speaking of LCP option #0, shouldn't the PPP working group decided what to do about that? Ascend is doing an incredible amount of drum-beating for their "MP+" (previously called "MPPP", or maybe it was "MPP"). I've been thinking about it and have questions: - if MP+ is a desirable set of features, is it tolerable to allocate LCP option #0 to the set? - how do you make such features actually work? -- if the peer is too stupid to keep list of phone numbers, then will it not be smart enough to deal with MP+, and conversely. -- MP+ is supposed to let a system "manage" the numbers in use. As such, it provides the "mechanism." How do you implement the policy behind deciding which numbers should be used? If the policy is fixed, with each client allowed to use a fixed set of phone numbers, with predicable changes in the set such as some based on time of day, then you do not need MP+. The client can know the policy and comply without any bits on the wire. If the policy varies due to load on the server, then what is the difference between getting a busy signal from the second phone number in an MP bundle and getting a busy on the first phone number? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 14:16:29 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA24966; Mon, 13 Nov 1995 14:16:29 -0500 Resent-Date: Mon, 13 Nov 1995 14:16:29 -0500 From: Karl Fox Date: Mon, 13 Nov 95 14:15:48 -0500 Message-Id: <9511131915.AA23373@gefilte.MorningStar.Com> To: marty@shiva.com Cc: ietf-ppp@MERIT.EDU Subject: IPCP negotiation of router, DNS? In-Reply-To: References: Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"VFVlK1.0.q56.7cvfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/860 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU marty@shiva.com writes: > Shiva and Microsoft both believe that there is much value in > having one peer give this information to the other peer. Well, who > am I kidding; there is much value in having the dial-in server give > this information to a dial-in client. I haven't seen any disagreement with this. The issue is whether it should be done via an existing protocol, DHCP, or via extensions to IPCP. > Yeah, DHCP is great and everything, but I'm trying to solve a > customer problem, and DHCP isn't always there to help. In addition, > most of the TCP/IP stacks available for PCs (including Macs) aren't > smart enough to DHCP at the right time. I'm sorry, but I don't understand your argument. If the client TCP/IP stack doesn't support either DHCP or proprietary IPCP extensions, I can't see any reason whatever to choose the proprietary solution over the standard solution. After all, no solution currently exists in the client, so code must be written. Why not write to existing standards? > The majority of the PPP working group basically decided that, if there > exists a tool that "should" be able to solve your problem (DHCP), then > we won't allow the problem to be solved in any other way (IPCP). No, we're just baffled why, when starting with a clean slate, you'd want to avoid implementing existing standards. Can you explain this to us, please? > So you can say that most PPP working group members see it that way, > but please don't say there was a consensus. Consensus doesn't mean unanimity. There was not unanimity; there certainly was consensus. -- Karl Fox, servant of God, employee of Morning Star Technologies +1 800 558 7827 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 451 1883 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 14:46:21 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA25891; Mon, 13 Nov 1995 14:46:21 -0500 Resent-Date: Mon, 13 Nov 1995 14:46:21 -0500 Message-ID: <01BAB1D6.61E930E0@ppp-pm01-dy-28.opr.oakland.edu> From: Brad Wilson To: "ietf-ppp@MERIT.EDU" , "'Jonathan Wenocur'" Subject: RE: IPCP negotiation of router, DNS? Date: Mon, 13 Nov 1995 14:36:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"N5AUi2.0.eJ6.q_vfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/861 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> (since IPCP >> must already be up and running before DHCP can be used -- which has >> been the basic issue with PPP and DHCP working together -- you can't >> use DHCP until IPCP is up, and you can't bring up IPCP until you've >> obtained an address via DHCP I have to take issue with this ... there was never any requirement that IP addresses be negotiated before the link was used. You can bring IPCP up without issuing an IP address. Admittedly, it's not entirely useful for general traffic, but it would suffice for, say, DHCP traffic. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 15:40:26 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA28255; Mon, 13 Nov 1995 15:40:26 -0500 Resent-Date: Mon, 13 Nov 1995 15:40:26 -0500 From: marty@shiva.com Date: Mon, 13 Nov 95 15:26:36 PST Subject: RE: IPCP negotiation of router, DNS? To: ietf-ppp@MERIT.EDU X-Mailer: Chameleon ARM_55, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"D-COp1.0.4t6.Gqwfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/862 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I said: >> Yeah, DHCP is great and everything, but I'm trying to solve a >> customer problem, and DHCP isn't always there to help. In addition, >> most of the TCP/IP stacks available for PCs (including Macs) aren't >> smart enough to DHCP at the right time. > >Karl said: >I'm sorry, but I don't understand your argument. If the client TCP/IP >stack doesn't support either DHCP or proprietary IPCP extensions, I >can't see any reason whatever to choose the proprietary solution over >the standard solution. After all, no solution currently exists in the >client, so code must be written. Why not write to existing standards? A solution to this problem does exist; most TCP/IP stacks for the PC that we deal with have an API that lets me set this information for the stack. If I have an IP address and a DNS address to give, there is a place to put it. I said: >> The majority of the PPP working group basically decided that, if there >> exists a tool that "should" be able to solve your problem (DHCP), then >> we won't allow the problem to be solved in any other way (IPCP). > >Karl said: >No, we're just baffled why, when starting with a clean slate, you'd >want to avoid implementing existing standards. Can you explain this >to us, please? This is my point exactly; there is no clean slate! We have to work with existing TCP/IP stacks to get them to work as well as possible; in some cases, we are dealing with millions of customers. Future versions of these stacks might to DHCP, and might even do DHCP to the extent that it is a better solution for us than IPCP. However, I am attempting to solve the problem with existing tools, and IPCP works. I didn't intend to start one of those never-ending mail threads, and I'm not complaining about DHCP or IPCP. I was just objecting to the use of the word "consensus". So let this be my last word, and we can get back to the important issues of the day! - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 16:10:12 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA29709; Mon, 13 Nov 1995 16:10:12 -0500 Resent-Date: Mon, 13 Nov 1995 16:10:12 -0500 Date: Mon, 13 Nov 1995 16:09:00 -0500 From: Jonathan Wenocur Message-Id: <199511132109.QAA22714@shiva-dev.shiva.com> To: bradw@netnet.net, ietf-ppp@MERIT.EDU, jhw@shiva.com Subject: RE: IPCP negotiation of router, DNS? Resent-Message-ID: <"rLhil1.0.-F7.nGxfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/863 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> >> (since IPCP >> >> must already be up and running before DHCP can be used -- which has >> >> been the basic issue with PPP and DHCP working together -- you can't >> >> use DHCP until IPCP is up, and you can't bring up IPCP until you've >> >> obtained an address via DHCP >> >> I have to take issue with this ... there was never any requirement that >> IP addresses be negotiated before the link was used. You can bring IPCP >> up without issuing an IP address. Admittedly, it's not entirely useful >> for general traffic, but it would suffice for, say, DHCP traffic. The problem, as Marty pointed out in his latest mail, is that you have to give some IP stacks the address before they can come up, or once they're up there's no easy way to change it. Either way, it prevents negotiating IPCP and then changing the address. Maybe newer versions of the stacks don't have this problem, but we're talking about work done a year ago (which is when the Microsoft options were being worked on). And at the time DHCPINFORM didn't exist so you had to get the IP address via DHCP. -- Jonathan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 16:25:06 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA00328; Mon, 13 Nov 1995 16:25:06 -0500 Resent-Date: Mon, 13 Nov 1995 16:25:06 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Nov 1995 13:24:29 -0800 To: inads@research.ftp.com From: fred@cisco.com (Fred Baker) Subject: Re: Use of PPP NCPs on Frame Relay Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"orS1c.0.o4.lUxfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/864 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Frank: Here's the response that I have so far to your question. There is one implementation of PPP/FR deployed: Xyplex. There is another in progress, which declines to be identified. No-one has reported an implementation of Data Encaps either deployed or in progress. The argument presented for doing PPP/FR by the implementation in progress is interesting. >> I need to know how to advise my Area Director. You will all remember (all >> too well) the discussions between PPP WG and IPLPDN WG about the drafts >> >> draft-ietf-pppext-dataencap-03.txt >> and draft-ietf-pppext-frame-relay-03.txt > >I would strongly encourage using the second method. Reason is that >we don't want to implement a new protocol; just using PPP as-is >without changes over frame relay seems to be more appropriate and >much simpler to implement for me. Also, I do not want to have to support >a second method for data compression, encryption and whatever. >PPP solves everything, so why not use it ? Andy Malis made some comments, and there has been a bit of a dust-up on the list about it, which I presume you saw. His summary of the options is: At 1:07 PM 11/10/95, Andrew G. Malis wrote: >The PPP WG has to reach consensus on the purpose of this work. There >are three alternatives: > >1. These drafts were really only going to be used to support > compression and/or encryption over FR. > >2. There are other good uses for PPP negotiation over FR, and it's > important to retain FR's multi-access properties as well. > >3. We really see a market requirement to run full PPP over FR. > >If the WG agrees to 1., then given the expectation of FRF DCP being >widely adopted and implemented, it makes little sense, especially for >interoperability, to have multiple means for performing compression >and/or encryption over FR. In this case, neither should be advanced. > >If the WG agrees to 2., then using FRF DCP in conjunction with >dataencap makes sense (especially since dataencap isn't compatible >with CCP anyway). > >If the WG agrees to 3., then fr-in-ppp should be advanced. However, >this will give the industry two competing, and incompatible, methods >of doing compression and/or encryption over FR. Given that FR is the >FRF's home turf, I expect that FRF DCP would be preferred over >ppp-in-fr, and it would be important to amend the fr-in-ppp spec to >specify that CCP and ECP should not be used over FR. The mailing list commentary appears to address the second conclusion. It says that Frame Relay multi-access properties are not greatly impinged upon by treating a DLC as a point to point line, and so any mechanism that enables the use of PPP's negotiation schemes is important. The argument does not support either Data Encaps or PPP/FR specifically, but rather argues that the type of service that a pairwise negotiation enables are considered important. The discussion then goes on to other subjects, such as the viability of PPP compression. It seems to me that at least two companies have decided to deploy PPP/FR, and their reasoning appears to been that they would rather deploy something proven and in hand rather than something not proven and not in hand. Doing so is not perceived to result in a loss of service to their customers, and perhaps enables the use of some technologies (Header Compression come to mind quickly, as well as auto-detection of protocol neighbors and perhaps more importantly detection of non-neighbors, plus provably correct work-arounds for cases where Frame Relay is not correctly modelled as a LAN) in PPP that are not provided by FRF protocols. The question of a marketplace for PPP/FR is an interesting one; my perception is that there is rarely a marketplace for an implementation approach, but rather a marketplace for the service the implementations offers. There is indeed a wide marketplace for the set of services PPP offers on Frame Relay interfaces, the proof of which is the number of proprietary implementations of compression, header compression, and other PPP-like services on Frame Relay. As far as the negotiation of data stream types, I would suggest that there is not a market there, there is rather a perception that the lack of negotiation is an implementation or protocol bug. I know it has been reported as such to both companies I have worked for since 1990. I don't care to comment on the "turf" issues. I know of no one body that can be accurately said to "control" Frame Relay protocols any more than I can say that there is one body that controls Ethernet protocols. The Frame Relay Forum makes inputs, the ITU makes inputs, and the IETF makes inputs. Ultimately, what is implemented and deployed on Frame Relay is a mixture of the various inputs driven by the vendors' willingnes to invest, which is in turn driven by market forces. Market forces are at the moment apparently pushing in the direction of providing the same set of services on Frame Relay that exist on leased lines, which vendors can reasonably be expected to do in the simplest and most cost-efficient way. Therefore, I conclude that companies are willing to put $$$ behind PPP/FR and not behind Data Encaps. They may or may not be willing to put $$$ behind FRF DCP; time will tell. This is consistent with commentary from key working group participants in the past, and what I would have to report as the working consensus of the working group. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 13 19:16:13 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA06066; Mon, 13 Nov 1995 19:16:13 -0500 Resent-Date: Mon, 13 Nov 1995 19:16:13 -0500 To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: Re: stealing numbers In-Reply-To: Your message of "Mon, 13 Nov 1995 12:05:17 MST." <199511131905.MAA25968@mica.denver.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 13 Nov 1995 16:15:20 -0800 Message-Id: <25735.816308120@dumbcat.sf.ca.us> From: Marco S Hyman Resent-Message-ID: <"5K43G3.0.ZU1.A_zfm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/865 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > I've been thinking about it and have questions: > > - if MP+ is a desirable set of features, is it tolerable to > allocate LCP option #0 to the set? Speaking for myself, no. Speaking for Ascend, LCP option 22 has been assigned to MP+ (nee MPP) by the IANA. Speaking for myself, again, I assume that Ascend will start using option 22 in place of option 0 in some future release. // marc - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 14 03:17:14 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id DAA18864; Tue, 14 Nov 1995 03:17:14 -0500 Resent-Date: Tue, 14 Nov 1995 03:17:14 -0500 To: ietf-ppp@MERIT.EDU Subject: Re: stealing numbers In-Reply-To: Your message of "Mon, 13 Nov 1995 12:05:17 MST." <199511131905.MAA25968@mica.denver.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Nov 1995 00:16:34 -0800 Message-Id: <5009.816336994@dumbcat.sf.ca.us> From: Marco S Hyman Resent-Message-ID: <"asJ3I.0.Xc4.625gm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/866 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > - if MP+ is a desirable set of features, is it tolerable to > allocate LCP option #0 to the set? My earlier reply was a bit ambiguous. Yes, in my biased opinion MP+ is a desirable set of features. No, using option 0 is not a good thing. Note: an option has been obtained for the features. > -- MP+ is supposed to let a system "manage" the numbers in use. > As such, it provides the "mechanism." How do you implement > the policy behind deciding which numbers should be used? Policy is all to often set by whim and tarrifs. It is up to each vendor to select some set of features that will allow users of their product to select the users desired policy. > If the policy is fixed, with each client allowed to use a > fixed set of phone numbers, with predicable changes in the > set such as some based on time of day, then you do not need > MP+. The client can know the policy and comply without any > bits on the wire. A "caller" could be assigned a set of phone numbers. Providing no other caller is given the same phone numbers, no management protocol is needed. If phone numbers are shared, the caller would have to know the state of every other caller to determine the state of the answerer. Why not just ask the answerer? > If the policy varies due to load on the server, then what > is the difference between getting a busy signal from the > second phone number in an MP bundle and getting a busy > on the first phone number? If the lines are busy, nothing. But there may be policy reasons where there are channels available -- but not for the caller. Possibilities include minimizing the number of channels any one caller can use, reserving bandwidth for new callers instead of allowing existing callers to use higher bandwidth, or reserving some number of channels for outdial (instead of preempting an active call). Channel availability is better if the caller knows not to call, instead of calling, possibly doing a modem handshake, negotiating PPP, then being hung up on because of some policy decision by the answerer. // marc - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 14 04:36:38 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id EAA20353; Tue, 14 Nov 1995 04:36:38 -0500 Resent-Date: Tue, 14 Nov 1995 04:36:38 -0500 Date: Tue, 14 Nov 1995 10:27:50 +0100 From: Christophe Vermeulen Message-Id: <199511140927.KAA07175@btmph4.se.bel.alcatel.be> To: fred@cisco.com Subject: Re: ATM over PPP : feasible ? How to get a number ? Cc: iana@ISI.EDU, ietf-ppp@MERIT.EDU Resent-Message-ID: <"FaNDC3.0.oz4.VC6gm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/867 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ->From fred@cisco.com Mon Nov 13 18:49:16 1995 ->Date: Mon, 13 Nov 1995 09:44:48 -0800 ->To: meulenc@se.bel.alcatel.be ->From: fred@cisco.com (Fred Baker) ->Subject: ATM over PPP : feasible ? How to get a number ? ->>I send the following mail to Fred Baker, but his address has become unvalid. -> ->Yes, for about the past year I have been fred@cisco.com. -> ->>Basically, I would like to know how, as a representative of the DAVIC ->>organisation, I may ask to : ->> ->> - Add a number for transporting ATM on PPP ->> for example 0x0051 ->> ->> - Add numbers for UDP/TCP sockets we use in the DAVIC specification ->> ideally a range of about 20 numbers. We currently use some ->> in the 0x2000-0x2100 range ->> ->>My DAVIC appointment is quite recent, so I requested some information on ->>how I should treat this internally, too. -> ->It seems to me that there is something of a disconnect here, perhaps at ->my end. OK, let's send a reconnect :-) ->PPP is designed for use in datagram networks, while ATM is itself a ->cell-gram network. OK. In some sense, you're right : you can carry IP on PPP, and you can do that also on ATM. You can carry PPP on SDH/SONET, you can carry ATM the same way. So the same protocols may look at the same layer. The big difference is that PPP is point-to-point, and ATM is not ? Well, not exactly. ATM has also, just like PPP, the need for a physical medium. They share some (eg. SDH), and some differ (eg. PSTN/ISDN). Now a big difference, PPP is only used on a link, and then there may be a IP router or something. In that respect, ATM looks very much like IP : you carry ATM on SDH between switches. ATM also carries the routing information (VPI/VCI) to go to the next stage. In other words, if a router would typically terminate PPP and send IP packets further, an ATM cell has a longer lifespan. It is not address-based like IP, but is also layer 3. ->It seems that in carrying H.310 data from ATM in a ->datagram internet, one would not carry it a single hop on a datagram link ->only to lack a carrier on the Ethernet etc beyond, but would gateway it ->into an H.323 stream on the datagram internet. This is an encapsulation in ->RTP/UDP/IP, and would therefore already be passable on any PPP links it ->encountered. Such a gateway is currently under discussion, and is expected ->to be put out to Study Group 15 ballot in June. Sorry I didn't follow this one. I got some informtation from SG15 myself, but it is not generic at all ! H.323 is service-related. What does it have to do with ATM, IP or PPP I don't see ! In other words, you can use that, but it''s at another layer (service). ->Could you please discuss your application with me? -> Very simple : Video-on-Demand and associates (Home Shopping, ...) The DAVIC reference model is as follow : Content Delivery Service Delivery Service Provider ------- System ------ Provider ----- System ----- User System A11 A10 System A9 A1 System Aii are the reference points. Further split of the delivery system is made in Access Network and Core Network, with the A4 reference pointas interface. The Service User System (Set-Top Box) is also split in Network Interface Unit and Set-Top Unit (with A0 as interface, typ. an internal connector) Typically, you would have an ATM switching network as core, HFC or ADSL as access technology, and that's covered by DAVIC 1.0 Now there is question on how to cope with an access network that may be ... a satellite channel and a dish. Currently, most DVB satellite decoders have no return channel. One obvious possiblity is to use the PSTN/ISDN network, and use PPP. Now the control information should already be in the form of an ATM cell on the A0 interface, and I would like to transmit it on the PSTN/ISDN network. More clear now ? ->>[... So] can I request a number to iana for supporting ATM as ->>just another protocol [on PPP], near DECnet, Vines or IP ? -> ->You may ask, I suppose; they bring me into the loop as a courtesy, and I ->try to maintain some degree of consistency of architecture and non-overlap ->in specifications. One question in this context: is this an Alcatel ->proprietary protocol, or is this something you would be willing to ->contribute to the community? Some thing as generic at ATM-on-PPP would, I ->should think, be of interest to many vendors if it is of interest to one. It is not proprietary at all, we intend to contribute this to DAVIC. It may come in the 1.0 specification that will be published next month, but I wouldn't be confident to use a non-iana-approved number for that. It would allow to have an integrated solution independent of the access network technology that is used. ->>Is there a newsgroup where this is discussed ? I tried comp.protocols.tcp-ip ->>but I found nothing really about that. -> ->Anything regarding PPP is discussed on ietf-ppp@merit.edu So I copy it there also. Regards. Christophe. ------------------------------------------------------------------------------ _ Christophe Vermeulen V System Engineer Third Party Products ------------------- Alcatel Bell Telephone SE275 | A L C A T E L | Fr. Wellesplein 1 - B-2018 Antwerp - Belgium ------------------- Phone: +32 3 240 8942 - Fax: +32 3 240 9920 Full Service Networks Email: meulenc@se.bel.alcatel.be Alcanet: BTMX.MEULENC ------------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 14 10:20:22 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA28586; Tue, 14 Nov 1995 10:20:22 -0500 Resent-Date: Tue, 14 Nov 1995 10:20:22 -0500 Date: Tue, 14 Nov 1995 08:19:34 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511141519.IAA28277@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: MP+ Resent-Message-ID: <"vG1os2.0.G-6.hEBgm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/868 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Marco S Hyman > ... > > -- MP+ is supposed to let a system "manage" the numbers in use. > > As such, it provides the "mechanism." How do you implement > > the policy behind deciding which numbers should be used? > > Policy is all to often set by whim and tarrifs. It is up to each vendor > to select some set of features that will allow users of their product > to select the users desired policy. That is other than convincing. At least one way to implement a useful policy must be exhibited. By "policy", I do not mean something written in a telco tariff or a memo from one human to another. I mean the computer notion, as in the "mechanism vs. policy" distinction. > > If the policy is fixed, with each client allowed to use a > > fixed set of phone numbers, with predicable changes in the > > set such as some based on time of day, then you do not need > > MP+. The client can know the policy and comply without any > > bits on the wire. > > A "caller" could be assigned a set of phone numbers. Providing no other > caller is given the same phone numbers, no management protocol is needed. > If phone numbers are shared, the caller would have to know the state of > every other caller to determine the state of the answerer. Why not > just ask the answerer? If the phone numbers are shared, every other caller need only dial the hunt group(s) of the numbers and let the telco tell the caller the state of the answerer with a busy signal. For example, have non-circular hunt-group, and require that second channels be dialed into a number near the end of the hunt group. > > If the policy varies due to load on the server, then what > > is the difference between getting a busy signal from the > > second phone number in an MP bundle and getting a busy > > on the first phone number? > > If the lines are busy, nothing. But there may be policy reasons where > there are channels available -- but not for the caller. Possibilities > include minimizing the number of channels any one caller can use, limiting? > reserving bandwidth for new callers instead of allowing existing callers > to use higher bandwidth, or reserving some number of channels for outdial > (instead of preempting an active call). Channel availability is better > if the caller knows not to call, instead of calling, possibly doing a > modem handshake, negotiating PPP, then being hung up on because of some > policy decision by the answerer. I've heard that before, but when I recently started thinking about it, I realized I do not see a way to implement it. In real life, a dumb computer is going to have great difficulties deciding to make such choices. First, mechanism issues. How does MP+ tell clients that are not currently connected? In real bandwidth-on-demand situations, the clients are not connected with even one link most of the time. I use symmetric demand-dialing for my only network connections. My link is down most of the time. If a caller is not allowed to use more than X channels at once, you don't need to use a protocol tell the caller. That's going to be spelled out in the terms and conditions, and encoded into the caller's software if the rules are predictable. If the rules are not predictable (e.g. not a simple function of time or day of the week), then what is the hub going to do? If some callers have 2 lines when they are guaranteed only one but have been using 2 because the hub was busy, when the hub gets busy, it might tell them so with MP+ and then disconnect. That half might work technically, although it has intolterable human effects--people don't take kindly to such things. In real life, politics would probably force the hub to wait until the client's bandwidth-on-demand machinery had dropped a line. Besides, you do not need a protocol to implement this, with hunt group and other games. I have greater questions concerning the opposite, telling the client that a restriction has been lifted. How many clients does the hub tell to consider adding a line? Do clients continually send MP+ packets while they think they could use another line? Continually re-entering a lottery? If so, what happens if they don't get dialed in time? How long do they have? Now consider policy issues. How does the hub decide how when to invoke the mechanisms? I cannot think of any plausible policies except variations and combinations of: - some clients cannot use more than 1 link during some hours if there is contention for the links Such policies can be put into the clients, obviating at least most of the need for a protocol. In real life, where there are more potential clients than ports on the hub, I don't see why a protocol works better than - don't expect to connect if you get a busy signal. Do not try again for a while after you get a busy signal. - if you get rudely disconnected, do not try again again for a while. - do not try at times or on days you are not allowed to connect. Notice that those rules are necessary even in the presense of something like MP+ to handle clients which had completely disconnected for lack of traffic--unless you propose to use D-channel signalling for MP+. Speaking of which, why not use the ISDN calling number to reject callers? That works even for clients that do not have even one link alive. (Again, most of the time the number of potential clients vastly excedes the number of ports.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 14 17:07:27 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA10799; Tue, 14 Nov 1995 17:07:27 -0500 Resent-Date: Tue, 14 Nov 1995 17:07:27 -0500 Date: Tue, 14 Nov 95 15:32:08 CST From: "Kenneth Peirce" Message-Id: <9510148163.AA816393963@robogate.usr.com> To: ietf-ppp@MERIT.EDU Subject: Re: MP+ Resent-Message-ID: <"D0dTW3.0.Ne2.eBHgm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/869 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does anyone know where/how to get a hold of the MP+ spec.? Ascend supposedly made it public but I couldn't find it on their webserver. kpeirce@usr.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 15 09:05:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA02157; Wed, 15 Nov 1995 09:05:58 -0500 Resent-Date: Wed, 15 Nov 1995 09:05:58 -0500 From: gmd@proteon.com (Gina DePlanche) Message-Id: <9511151405.AA07155@columbo.proteon.com> Subject: Re: MP+ To: kpeirce@usr.com (Kenneth Peirce) Date: Wed, 15 Nov 1995 09:05:07 -0500 (EST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9510148163.AA816393963@robogate.usr.com> from "Kenneth Peirce" at Nov 14, 95 03:32:08 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 938 Resent-Message-ID: <"HrtIk.0.UX.-EVgm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/870 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi! At the Internet Show in Boston a few weeks back, I got a number for Ascend. The person I have been in contact with is Paul Slous # (510) 769-6001. He can give you information on how to become a licensee, which is a requirement to getting the MP+ spec. He also has a package of information (press release, Q&A, slides) which gives some good information regarding the benefits of MP+ over MP. This package can be obtains without becoming a licensee. Regards, Gina According to Kenneth Peirce ... -> -> Does anyone know where/how to get a hold of the MP+ spec.? Ascend -> supposedly made it public but I couldn't find it on their webserver. -> -> kpeirce@usr.com -> -> -- Gina M. DePlanche | Proteon gmd@proteon.com | MailStop #23 (508) 898-2800 x2541 | 9 Technology Drive, Westborough, MA Fax: (508) 898-2547 | 01581-1799 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 15 17:07:05 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA16321; Wed, 15 Nov 1995 17:07:05 -0500 Resent-Date: Wed, 15 Nov 1995 17:07:05 -0500 From: Archie Cobbs Message-Id: <199511152206.OAA04792@bubba.tribe.com> Subject: Re: MP+ To: gmd@proteon.com (Gina DePlanche) Date: Wed, 15 Nov 1995 14:06:05 -0800 (PST) Cc: kpeirce@usr.com, ietf-ppp@MERIT.EDU In-Reply-To: <9511151405.AA07155@columbo.proteon.com> from "Gina DePlanche" at Nov 15, 95 09:05:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1030 Resent-Message-ID: <"165q71.0.n-3.pHcgm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/871 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU gmd@proteon.com (Gina DePlanche) writes: > At the Internet Show in Boston a few weeks back, I got a number > for Ascend. The person I have been in contact with is Paul Slous > # (510) 769-6001. He can give you information on how to become a > licensee, which is a requirement to getting the MP+ spec. He also has a > package of information (press release, Q&A, slides) which gives some > good information regarding the benefits of MP+ over MP. This package > can be obtains without becoming a licensee. Don't hold your breath. We already did this over a month ago, and so far have received some material, basically useless promo stuff, everything except the spec itself. They claim it's "not ready" yet. I also heard from one major ISDN vendor that Ascend denied them a license. So much for "industry wide interoperability." I'm, er, underwhelmed. -Archie _______________________________________________________________________________ Archie L. Cobbs, archie@tribe.com * Tribe Computer Works http://www.tribe.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 16 11:41:32 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA14481; Thu, 16 Nov 1995 11:41:32 -0500 Resent-Date: Thu, 16 Nov 1995 11:41:32 -0500 Message-Id: <9511161641.AA09251@titan.engeast> To: ietf-ppp@MERIT.EDU Cc: jzarkowe@pobox.BayNetworks.com, miller@pobox.BayNetworks.com, pstreile@pobox.BayNetworks.com Subject: draft-ietf-pppext-wcp-00.txt Reply-To: kmader@BayNetworks.com X-Face: &""q.a|BtO0Cwe^tf=~y3jCN'x@i&c,^,{-:'eq\cz{83KS#U9Peh#Bm[FC821xO85-|to0 cf/O@O[LHhQ"zklKa0Bjm0av(`]'8gQ?Z{I~b(Q!nKIgoDJYNB$67pS?i32H.H_ND::8$G`o"p]>Y* 6|5G+34v5GuwQ=daZ4 Resent-Message-ID: <"rexOE1.0.6Y3.mcsgm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/872 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU -------- I submitted this draft yesterday, so it should be showing up in a couple of days. I've attached a copy of the draft so that anyone interested can get a jump on reviewing it. Any and all comments are welcome. Thanks, Keith _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ _/ _/ Keith Mader Voice: 508-436-8052 _/ _/ Bay Networks, Inc. E-mail: kmader@baynetworks.com _/ _/ 2 Federal Street _/ _/ Billerica, MA 01821 _/ _/ _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ --------- Network Working Group Wing Lam Internet Draft Keith Mader Bay Networks November 1995 PPP WAN Compression Protocol draft-ietf-pppext-wcp-00.txt Status of this Memo This document is a submission to the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet Draft, please check the ``1id-abstracts.txt'' listing contained in the internet- drafts Shadow Directories on on nic.ddn.mil, ds.internic.net, venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current status of any Internet Draft. Lam, Mader Expires in Six Months [Page i] Internet Draft WAN Compression Protocol November 1995 Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method for negotiating data compression over PPP links. This document describes the use of the WAN Compression Protocol (WCP) to provide an algorithm independent transport for compressed datagrams over point-to-point links. Lam, Mader Expires in Six Months [Page ii] Internet Draft WAN Compression Protocol November 1995 1. Conventions The following language conventions are used in the items of specification in this document: o Must, Shall or Mandatory -- the item is an absolute requirement of the specification. o Should or Recommended -- the item should generally be followed for all but exceptional circumstances. o May or Optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor. All drawings in this document are drawn with the left-most bit as the high order bit for transmission. For example: 0 1 2 3 4 5 6 7 bits +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+ | flag (7E hexadecimal) | +---+---+---+---+---+---+---+---+ | address 0x'FF' | +---+---+---+---+---+---+---+---+ : : : : +---+---+---+---+---+---+---+---+ Drawings that would be too large to fit into one page if each octet were presented on a single line are drawn with two octets per line. These are also drawn with the left-most bit as the high order bit for transmission. There will be a "|" to distinguish between octets as shown in the following example. Lam, Mader Expires in Six Months [Page 1] Internet Draft WAN Compression Protocol November 1995 |--- octet one ---|--- octet two ---| 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | flag 0x'7E' | address 0x'FF' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ : : : : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2. Introduction This document describes the WAN Compression Protocol (WCP), which is a transport protocol designed specifically for carrying compressed packets across WAN links. The primary features of WCP include the negotiation of compression algorithms and parameters, the transport of compressed packets, and the detection and retransmission of lost or corrupted packets. The negotiation feature of WCP allows various compression algorithms to be used. It also allows for the various algorithm specific compression parameters (such as dictionary size, compression mode) to be negotiated. The transport mechanism of WCP provides the means for transporting compressed packets, as well as non compressed packets. Compressed packets are sent when the compressed version of a packet is smaller than the original non compressed packet. However, when the compressed version of a packet is larger than the original non compressed packet, WCP transports the original packet instead. The transport mechanism also provides unique identification of packets compressed using continuous or per packet compression methods. WCP is a sequenced, non-windowed protocol that does not rely on positive acknowledgments. In transporting packets across the network, WCP employs a 12-bit sequence number to detect packet loss. Upon detection of packet loss, WCP selectively requests the retransmission of the lost packets thus avoiding a reset of the compression dictionary. Lam, Mader Expires in Six Months [Page 2] Internet Draft WAN Compression Protocol November 1995 3. WCP Frame Format Before any WCP packets may be communicated, PPP must reach the Network-Layer Protocol phase [1], and the Compression Control Protocol must reach the Opened state. When WCP is negotiated as the compression algorithm, the PPP protocol field indicates type 0x'00FD' (compressed datagram). Exactly one WCP datagram is encapsulated in the PPP Information field. The compressed form of the original PPP datagram starting with the PPP Protocol field is carried in the data portion of the WCP frame. The format shall be as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | address 0x'FF' | control 0x'03' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PPP Protocol 0x'00FD' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | WCP header | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | FCS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4. WCP Procedures All WCP procedures involve a WCP connection. A WCP connection is the association of two ends of a point-to-point link. A WCP connection consists of two rather independent sub-connections. Each of these sub-connections define the association of the compressor on one side of the connection and the decompressor on the other side of the connection. These sub-connections are independent in that operations on one of the sub-connections, for example the compression algorithm used, does not imply the same for the other. With the various procedures of WCP, the decompressor side of a sub-connection behaves as the master by initiating requests to the compressor, while the compressor side Lam, Mader Expires in Six Months [Page 3] Internet Draft WAN Compression Protocol November 1995 of a sub-connection behaves as the slave by responding to requests made by the decompressor. During the process of transporting compressed data over a connection, WCP transitions through several distinct phases. Each of these phases, and the conditions and WCP packets associated with each phase are described in the following sections. 4.1. Connection Phase WCP begins its operation in the connection phase. This phase is initiated with a connect request message being sent on the PPP link. The format of this message and appropriate responses are as follows: Connect Request Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 0 1 0 0| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | WCP Revision | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Initiator | Sequence Size | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Algorithm Count | Algorithm 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ : | : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Algorithm n | +--+--+--+--+--+--+--+--+ Lam, Mader Expires in Six Months [Page 4] Internet Draft WAN Compression Protocol November 1995 Connect Acknowledge Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 0 1 0 1| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | WCP Revision | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Sequence Size | Algorithm | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ReXmit Enable | +--+--+--+--+--+--+--+--+ Connect NAK Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 1 1 0 | +---+---+---+---+---+---+---+---+ Connect Request messages, as well as other WCP control messages, use a 16 bit transaction identifier (TID). Each side of the WCP connection should initialize the TID to zero and increment its value by one for each subsequent control message request. There are 5 fields defined in a connect request message. These fields are as follows: o Revision -- this field specifies the supported revision of the WCP protocol being used. The current value is 2. Future revisions to WCP shall append any changes to the end of the existing message format and increment the revision number by one. If the receiver of a connect message supports a version lower than the specified revision, it should process the message using its current lower version. The sender of a connect acknowledge should respond with the version that is currently being supported. The receiver of a connect request message may send a connect nak message if it can not support the requested version. o Initiator -- this field specifies whether the sender of the connect request has initiated the request on its own or as a result of a connect request from the other half of the WCP Lam, Mader Expires in Six Months [Page 5] Internet Draft WAN Compression Protocol November 1995 connection. When the compressor of one side receives a connect request message with this field set, the decompressor must also enter the connection phase and generate a connect request with the initiator field clear. This is useful when configuration has changed on one side of the WCP connection that may effect the negotiated values on the other side of the WCP connection. Support of this field is optional. Implementations not supporting the initiator field must set the field to zero. o Sequence Size -- this field specifies the size of the sequence number used in WCP data packets. The current value of 1, indicating a 12 bit sequence number, must be supported. If the receiver of a connect request message supports a value lower than indicated in the request, the receiver should reply with a connect acknowledge message indicating the supported value. The receiver may send a connect nak if it can not support the requested sequence size. o Number of Algorithms -- this field specifies the number of algorithms contained in the connect request message. o Algorithms -- these fields specify the various compression algorithms supported in order of preference, by the sender of the connect request message. The receiver of this message should choose among these algorithms and indicate it preference in the connect acknowledgment. The receiver of the connect request must reply with a connect nak if it can not support any of the requested algorithms. The values of the various algorithms is listed in the appendix. There are 4 fields defined in a connect acknowledge message. These fields are as follows: o Revision -- this field specifies the supported revision of the WCP protocol being used. o Sequence Size -- this field specifies the supported sequence size being used. o Algorithm -- this field specifies the negotiated compression algorithm being used. Lam, Mader Expires in Six Months [Page 6] Internet Draft WAN Compression Protocol November 1995 o ReXmit Enable -- this field specifies whether the sender of this message maintains a transmission history. The receiver of a connect acknowledge message with this field set should request retransmission of lost or corrupted packets. The receiver of a connect acknowledge message with this field set to zero must not generate retransmit request messages. The sender of the connect request message should retry if neither a connect acknowledge or a connect nak is received. It should stop retrying after a period of time T1. A recommended retry interval is n seconds for the nth retry, where n is less than 30, and then 30 thereafter. A recommended value for T1 is 10 minutes. The receiver of a connect acknowledgment may choose to initiate a disconnect sequence if any of the values specified are not acceptable. It must also ignore any connect acknowledgment received with a TID that does not match the expected TID. 4.2. Initialization Phase The decompressor, upon entering the initialization phase, sends an initialization request message to the compressor on the other end of the WCP connection. The compressor should respond with an initialization acknowledgment message containing the acceptable parameters. When an initialization ack message is not received in time T2, a new initialization request must be sent. If the maximum retry count N2 is reached, the decompressor enters the disconnect phase. The recommended value to T2 is 2 seconds, and the recommended value for N2 is 10. The exact format of the initialization request and acknowledgment messages are algorithm specific, but must follow the general structure. Specifically, each initialization request message must minimally contain a TID. Each initialization acknowledgment message must minimally contain a TID. The format of initialization request and acknowledge messages for various compression algorithms are described in the appendix. The format of the initialization request and initialization acknowledgment for the MagnaLink compression algorithm are as Lam, Mader Expires in Six Months [Page 7] Internet Draft WAN Compression Protocol November 1995 follows: Init Request Message Format (MagnaLink example) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 1 0 0 1| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | Algorithm Revision | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Initiator | Dictionary Size | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PPC Enable | PIB Enable | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Init Acknowledge Message Format (MagnaLink Example) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 1 0 1 0| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | Algorithm Revision | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Dictionary Size | PPC Enable | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | PIB Enable | +--+--+--+--+--+--+--+--+ The fields of the MagnaLink initialization request message are as follows: o Algorithm Revision -- this field specifies the version of the compression algorithm being supported. The current value of this field is one. o Dictionary Size -- this field specifies the size of the compression/decompression dictionary. A one in this field indicates the use of an 8K dictionary, and a two in this field specifies a 32K dictionary. All other values are reserved. An 8K dictionary must be supported. The receiver of the initialization request may set the dictionary size field in Lam, Mader Expires in Six Months [Page 8] Internet Draft WAN Compression Protocol November 1995 the initialization acknowledgment message to one if a 32K dictionary is not supported. o PPC Enable -- this field specifies if the sender of the initialization request message wishes to perform packet by packet compression for this WCP connection. A one in this field indicates packet by packet compression mode. This mode must be supported. A zero in this field identifies continuous compression mode. The receiver of the initialization request must set this field in the initialization ack message if this field is set in the request message. o PIB Enable -- this field specifies if the sender of the initialization request wishes to perform protocol integrity byte checking. A zero in this field indicates that no PIB checking should be performed. This mode must be supported. A one in this field indicates that PIB checking should be performed. The receiver of the initialization request must set this field in the initialization ack message to zero if this field is clear in the request message. The initialization phase may be re-entered if either side of the WCP connection wishes to re-negotiate any of all of the initialization values. For example, if the decompressor on one side of the WCP connection is running in CPC mode and detects a high level of packet loss over time, it may choose to enter PPC mode by re-entering the initialization phase. 4.3. Data Transfer Phase The data transfer phase is entered when the initialization phase has completed. There are eight messages defined for carrying compressed data. These messages are formed by the combination of the following three attributes: o CPC/PPC -- indicates if the compressed data was generated using continuous packet compression (CPC) or packet by packet compression (PPC). The CPC mode compression maintains dictionary information across packet boundaries whereas the Lam, Mader Expires in Six Months [Page 9] Internet Draft WAN Compression Protocol November 1995 PPC mode re-initializes the dictionary for each new packet. o Compressed/Non-Compressed -- indicates if the packet contains compressed or original data. If the packet is non-compressed and CPC mode is indicated, the decompressor must update the dictionary to include the non-compressed data in order to maintain dictionary synchronization. o TPPC -- indicates a request to enter transient packet by packet compression (TPPC) mode. This signals to the receiver, that subsequent packets should be compressed using PPC mode. Support for TPPC is optional however implementations not supporting TPPC must be able to receive and process packets indicated as TPPC. The format of packets sent during the data transfer phase are as follows: CPC Compressed Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 0 0 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ CPC Non-Compressed Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 0 0 1 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Lam, Mader Expires in Six Months [Page 10] Internet Draft WAN Compression Protocol November 1995 CPC Compressed TPPC Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 0 1 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ CPC Non-Compressed TPPC Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 0 1 1 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ PPC Compressed Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 0 0 0 | +---+---+---+---+---+---+---+---+ | Data | : . : : . : +---+---+---+---+---+---+---+---+ Lam, Mader Expires in Six Months [Page 11] Internet Draft WAN Compression Protocol November 1995 PPC Non-Compressed Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 0 0 1 | +---+---+---+---+---+---+---+---+ | Data | : . : : . : +---+---+---+---+---+---+---+---+ PPC Compressed TPPC Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 0 1 0 | +---+---+---+---+---+---+---+---+ | Data | : . : : . : +---+---+---+---+---+---+---+---+ PPC Non-Compressed TPPC Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 0 1 1 | +---+---+---+---+---+---+---+---+ | Data | : . : : . : +---+---+---+---+---+---+---+---+ Each CPC outbound data packet is submitted to the compressor and a sequence number is assigned to it. The sequence number is initialized to zero and wraps at the maximum value. It is incremented by one for each packet packet transmitted on the WCP connection. When a packet is compressed successfully (i.e. compression does not expand the packet) it is sent out as a CPC compressed packet. The receiver examines each CPC packet for proper sequencing. Correctly sequenced packets are decompressed. If an out of Lam, Mader Expires in Six Months [Page 12] Internet Draft WAN Compression Protocol November 1995 sequence packet is received, a retransmit request is sent for each missing packet and the decompressor enters the retransmit phase. If retransmission is not possible, a reset request may be sent instead. The corresponding compressor at the end of the WCP connection which enters the retransmit or reset phase should signal the remote compressor to temporarily enter packet by packet mode by setting the TPPC flags in transmitted data packets. This signal should persist until the data phase is re-entered. 4.4. Retransmit Phase There are 4 message types defined for carrying retransmitted compressed data. These messages are formed by the combination of the following two attributes: o Compressed/Non-Compressed -- this field indicates if the packet is in a compressed or non-compressed form. o Aged -- this field indicates if the packet is an aged packet and as such is only transmitted to maintain synchronization of the compression dictionary. The format of the messages sent during the retransmission phase are as follows: Retransmit Compressed Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 1 0 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Lam, Mader Expires in Six Months [Page 13] Internet Draft WAN Compression Protocol November 1995 Retransmit Non-Compressed Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 1 0 1 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Retransmit Compressed Aged Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 1 1 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Retransmit Non-Compressed Aged Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 0 1 1 1 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : . : : . : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Retransmit Request Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 0 0 0 Sequence Number | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Lam, Mader Expires in Six Months [Page 14] Internet Draft WAN Compression Protocol November 1995 Retransmit NAK Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 1 0 1 | +---+---+---+---+---+---+---+---+ When an out of sequence packet is received, the decompressor should send a retransmit request message for each packet missing between the expected sequence number and the out of sequence packet received. The receiver should send a reset request instead, if the out of sequence packet is greater than K from the expected value. A recommended value for K is 127. The decompressor, upon entering the retransmit state, must hold all incoming packets and expects the correct sequence of retransmitted packets. If an out of sequence retransmitted packet is received, or the desired sequence number is not received in a period of T3, an implementation may choose to retry, or enter the reset phase. If the number of retries exceeds N3, the decompressor must enter the reset phase. The recommended value for T3 is 2 seconds. The recommended value for N3 is 2. When a retransmit request is received, the transmission history is searched for the requested packet. If the desired packet is found, the packet is retransmitted. If the desired packet is not found in the transmission history, a retransmit NAK message is returned. When the last packets of a packet stream are lost and the compressor subsequently remains idle, the decompressor will not be able to detect that packets are missing. When the decompressor eventually is able to detect the packet loss, the retransmit request might result in the transmission of stale packets. To avoid this problem, an aging mechanism is defined. When a packet is saved in the transmission history, the packet should be time stamped. When a packet is retrieved from the transmission history for the purpose of retransmission, the time stamp should be checked. If the time stamp is older than a period of T4, the packet should be sent as being aged. The decompressor processes aged packets similarly to normal retransmitted packets to allow the dictionary to remain synchronized. However the packet should be dropped after it has been decompressed. A recommended value for T4 is 7 seconds. Lam, Mader Expires in Six Months [Page 15] Internet Draft WAN Compression Protocol November 1995 4.5. Reset Phase Only the decompressor may send a reset request and enter the reset phase. The decompressor may send a reset request when it is unable to synchronize with the compressor, such as when N3 is exceeded, or when a retransmit NAK is received. While waiting for the reset acknowledge message, the decompressor discards all CPC mode packets. If a reset acknowledge does not arrive in period T2, a new reset request should be transmitted. If the maximum retry count N2 is reached, the disconnect phase is entered. The format of messages sent during the reset phase are as follows: Reset Request Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 1 0 1 1| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | +--+--+--+--+--+--+--+--+ Reset Acknowledge Message Format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 1 1 1 1 1 1 0 0| TID octet 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TID octet 2 | +--+--+--+--+--+--+--+--+ 4.6. Disconnect Phase The disconnect request and disconnect acknowledge are used to disconnect a WCP connection. The sender of a disconnect request should use the same retry mechanism described for the connection phase. In addition, the sender of a disconnect request message may attempt to restart the PPP connection if it is not successful in receiving a disconnect acknowledge within the retry period. Lam, Mader Expires in Six Months [Page 16] Internet Draft WAN Compression Protocol November 1995 The format of the disconnect request and disconnect acknowledge messages are as follows: Disconnect Request Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 0 1 1 1 | +---+---+---+---+---+---+---+---+ Disconnect Acknowledge Message Format +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 0 0 0 | +---+---+---+---+---+---+---+---+ 5. WCP Frame Relay Encapsulation It is intended that all of the concepts discussed earlier in this document apply when WCP is run over other link types. When WCP is utilized over frame relay links, the compression NLPID of Lam, Mader Expires in Six Months [Page 17] Internet Draft WAN Compression Protocol November 1995 X'B0' is used to identify WCP. The format shall be as follows: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | flag 0x'7E' | Q.922 address* | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Q.922 address | Control X'03' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Optional Pad X'00' | NLPID X'B0' | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | WCP Header | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Data | : : : : +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | FCS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ * Q.922 addresses, as presently defined, are two octets and contain a 10-bit DLCI. In some networks Q.922 addresses may optionally be increased to three or four octets. 6. Security Considerations Security issues are not discussed in this memo. 7. References [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC1548, December 1993. [2] Rand, D., "The PPP Compression Control Protocol(CCP)", work in progress, draft-ieft-pppext-compression-03.txt. Lam, Mader Expires in Six Months [Page 18] Internet Draft WAN Compression Protocol November 1995 8. Appendix 8.1. WCP Recommended Values Parameter Recommended Value Description --------- ----------------- ----------- T1 10 minutes Connect retry period T2 2 seconds Init, Reset timer N2 10 Init, Reset retry counter T3 2 seconds Retransmit timer N3 2 Retransmit retry counter T4 7 seconds Stale packet timer K 127 Sequence range value 8.2. Initialization Phase Messages For Other Algorithms *** Add other algorithms here... *** Lam, Mader Expires in Six Months [Page 19] Internet Draft WAN Compression Protocol November 1995 Chair's Address The working group can be contacted via the current chair: Fred Baker Cisco Systems 519 Lado Drive Santa Barbara, California 93111 EMail: fred@cisco.com Author's Address Questions about this memo can also be directed to: Wing Lam Bay Networks, Inc. 2 Federal Street Billerica, Massachusetts 01821 Email: wlam@baynetworks.com Keith Mader Bay Networks, Inc. 2 Federal Street Billerica, Massachusetts 01821 Email: kmader@baynetworks.com Lam, Mader Expires in Six Months [Page 20] - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 16 14:33:49 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA20582; Thu, 16 Nov 1995 14:33:49 -0500 Resent-Date: Thu, 16 Nov 1995 14:33:49 -0500 Date: Thu, 16 Nov 1995 11:33:31 -0800 Message-Id: <199511161933.LAA26920@anik.skylinetech.com> X-Sender: raouf@anik.skylinetech.com (Unverified) X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@MERIT.EDU From: raouf@anik.skylinetech.com (Raouf Eldeeb) Subject: WCP and MOTOROLA patent Resent-Message-ID: <"5jp7a.0.M15.H8vgm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/873 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I just went over the draft rfc for WCP (the new compression protocol). I appreciate the effort that went into it and the expediency with which it was done. I would like some clarification on a couple of items: I- from page 9 of the WCP draft: > o PPC Enable -- this field specifies if the sender of the > initialization request message wishes to perform packet by > packet compression for this WCP connection. A one in this > field indicates packet by packet compression mode. This mode > must be supported. A zero in this field identifies continuous > compression mode. What is meant by continuous compression mode ? If it means resetting of the compression history after each frame sent, then we have a problem a different section of the same Motorola patent that shot down CCP. Here is a quote from US patent 5,130,993 > What is claimed is: ..... (items 1-14 are about restting history based on information obtained from the decompressed data) > 15. A method of transmitting encoded data across unreliable networks, > said encoding being of a type in which encoding and decoding are > synchronized, said method comprising the steps of: > encoding said data using a data encoding method; > transmitting said encoded data across said unreliable network; > receiving and decoding said data; and at intervals, > resynchronizing said encoding method wherein the resynchronization of > said encoding method occurs periodically at frame boundaries. > > 16. The method of claim 15 wherein the resynchronization of > said encoding method occurs at every frame boundary. It seems to me that this a direct claim on the method of continuous resets. II- In case compression is run over MPP frames, which comes first the MPP encpsulation 00FD or the WCP encapsulation 003D ? Raouf Eldeeb Skyline Technology raouf@skylinetech.com Phone (415) 377-0199 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 16 18:03:01 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA26968; Thu, 16 Nov 1995 18:03:01 -0500 Resent-Date: Thu, 16 Nov 1995 18:03:01 -0500 Date: Thu, 16 Nov 1995 15:42:16 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511162242.PAA06116@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: WCP and MOTOROLA patent Resent-Message-ID: <"HFR8u3.0.1b6.5Cygm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/874 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: raouf@anik.skylinetech.com (Raouf Eldeeb) > ... > What is meant by continuous compression mode ? > > If it means resetting of the compression history after each frame > sent, then we have a problem a different section of the same > Motorola patent that shot down CCP Who says the Motorola patent "shot down CCP"? Beside Motorola and the IESG? > Here is a quote from US patent 5,130,993 > > > What is claimed is: > > ..... (items 1-14 are about restting history based on information > obtained from the decompressed data) > > > 15. A method of transmitting encoded data across unreliable networks, > > said encoding being of a type in which encoding and decoding are > > synchronized, said method comprising the steps of: > > encoding said data using a data encoding method; > > transmitting said encoded data across said unreliable network; > > receiving and decoding said data; and at intervals, > > resynchronizing said encoding method wherein the resynchronization of > > said encoding method occurs periodically at frame boundaries. > > > > 16. The method of claim 15 wherein the resynchronization of > > said encoding method occurs at every frame boundary. > > It seems to me that this a direct claim on the method of continuous resets. Aren't all of the claims in that patent dependent on the previous claims? Especially: ] 2. The method of claim 1 wherein error detection information ] is added to said data prior to encoding said data, and said error ] detection information is used, following decoding, to detect any ] errors introduced by said unreliable network. Notice that the error detecting is done after the decoding, which is handy, given things like compressed netnews over the UUCP 'g' protocol. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 16 19:15:21 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA29007; Thu, 16 Nov 1995 19:15:21 -0500 Resent-Date: Thu, 16 Nov 1995 19:15:21 -0500 Message-Id: <9511170015.AA13351@titan.engeast> To: raouf@anik.skylinetech.com (Raouf Eldeeb) Cc: ietf-ppp@MERIT.EDU Subject: Re: WCP and MOTOROLA patent In-Reply-To: Your message of "Thu, 16 Nov 1995 11:33:31 PST." <199511161933.LAA26920@anik.skylinetech.com> X-Face: &""q.a|BtO0Cwe^tf=~y3jCN'x@i&c,^,{-:'eq\cz{83KS#U9Peh#Bm[FC821xO85-|to0 cf/O@O[LHhQ"zklKa0Bjm0av(`]'8gQ?Z{I~b(Q!nKIgoDJYNB$67pS?i32H.H_ND::8$G`o"p]>Y* 6|5G+34v5GuwQ=daZ4 Resent-Message-ID: <"lXWUK2.0.z47.IGzgm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/875 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU -------- On Thu, 16 Nov 1995 11:33:31 -0800, Raouf Eldeeb wrote: > > I just went over the draft rfc for WCP (the new compression protocol). > I appreciate the effort that went into it and the expediency with which it w > as > done. I would like some clarification on a couple of items: > > I- from page 9 of the WCP draft: > > > o PPC Enable -- this field specifies if the sender of the > > initialization request message wishes to perform packet by > > packet compression for this WCP connection. A one in this > > field indicates packet by packet compression mode. This mode > > must be supported. A zero in this field identifies continuous > > compression mode. > > What is meant by continuous compression mode ? > Continous compression mode refers to when the compression histories are maintained across packet boundaries (i.e. information learned from a previous packets may be used to generate compressed data for this packet). This is the preferred method since it typically yields much higher compression ratios. > If it means resetting of the compression history after each frame sent, t > hen > we have a problem a different section of the same Motorola patent that sh > ot > down CCP. Here is a quote from US patent 5,130,993 > > > What is claimed is: > > ..... (items 1-14 are about restting history based on information > obtained from the decompressed data) > > > 15. A method of transmitting encoded data across unreliable networks, > > said encoding being of a type in which encoding and decoding are > > synchronized, said method comprising the steps of: > > encoding said data using a data encoding method; > > transmitting said encoded data across said unreliable network; > > receiving and decoding said data; and at intervals, > > resynchronizing said encoding method wherein the resynchronization of > > said encoding method occurs periodically at frame boundaries. > > > > 16. The method of claim 15 wherein the resynchronization of > > said encoding method occurs at every frame boundary. > > It seems to me that this a direct claim on the method of continuous reset > s. > > > II- In case compression is run over MPP frames, which comes first the > MPP encpsulation 00FD or the WCP encapsulation 003D ? > > > > Raouf Eldeeb Skyline Technology > raouf@skylinetech.com Phone (415) 377-0199 > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 17 09:53:52 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA19086; Fri, 17 Nov 1995 09:53:52 -0500 Resent-Date: Fri, 17 Nov 1995 09:53:52 -0500 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-wcp-00.txt Date: Fri, 17 Nov 95 09:38:13 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9511170938.aa13452@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"VkeMx1.0.rf4.p7Ahm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/876 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP WAN Compression Protocol Author(s) : W. Lam, K. Mader Filename : draft-ietf-pppext-wcp-00.txt Pages : 20 Date : 11/16/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method for negotiating data compression over PPP links. This document describes the use of the WAN Compression Protocol (WCP) to provide an algorithm independent transport for compressed datagrams over point-to-point links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-wcp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-wcp-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-wcp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19951116095946.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-wcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-wcp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951116095946.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 21 10:00:45 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA07191; Tue, 21 Nov 1995 10:00:45 -0500 Resent-Date: Tue, 21 Nov 1995 10:00:45 -0500 Date: Tue, 21 Nov 1995 07:59:37 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511211459.HAA01152@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: old archives Resent-Message-ID: <"UgsyS2.0.wl1.ybUim"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/877 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Are there archives of the PPP working group mailing list from 1989 and before somewhere? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 22 11:37:24 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA14570; Wed, 22 Nov 1995 11:37:24 -0500 Resent-Date: Wed, 22 Nov 1995 11:37:24 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Nov 1995 08:36:21 -0800 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: deadline for internet drafts Resent-Message-ID: <"4LqYF1.0.LZ3.c6rim"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/878 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU those of you that were going to post drafts for the IETF should take note that there is a deadline this afternoon. You should email then to internet-drafts@cnri.reston.va.us, or post them for anonymous FTP and email an note with the URL to the same address. I would suggest the latter approach, and copy the PPP list. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 22 14:13:17 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA18921; Wed, 22 Nov 1995 14:13:17 -0500 Resent-Date: Wed, 22 Nov 1995 14:13:17 -0500 Date: Wed, 22 Nov 95 18:58:57 GMT From: "William Allen Simpson" Message-ID: <2055.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: deadline for internet drafts Resent-Message-ID: <"JZhDz2.0.Nd4.bOtim"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/879 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I already sent off the drafts for LZS, CHAP (DS), and LQM (DS). Should show up soon, if they aren't there now. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 22 15:02:56 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA20153; Wed, 22 Nov 1995 15:02:56 -0500 Resent-Date: Wed, 22 Nov 1995 15:02:56 -0500 Date: Wed, 22 Nov 1995 20:58:52 +0100 From: Christophe Vermeulen Message-Id: <199511221958.UAA15014@btmph4.se.bel.alcatel.be> To: fred@cisco.com Subject: ATM on PPP (was Re: PPP on IDSN and PSTN : what are the frames ? Cc: ietf-ppp@MERIT.EDU, iana@isi.edu Resent-Message-ID: <"BFXpn3.0.gw4.j7uim"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/880 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi Fred, and all PPP experts, ->From fred@cisco.com Wed Nov 22 18:42:19 1995 ->Date: Wed, 22 Nov 1995 09:37:38 -0800 ->To: Christophe Vermeulen ->From: fred@cisco.com (Fred Baker) ->Subject: PPP on IDSN and PSTN : what are the frames ? ->Cc: iana@isi.edu ->Content-Length: 1571 ->X-Lines: 32 ->Status: RO -> ->I have discussed your application with several members of the IAB and the ->IESG, in an effort to determine how best to advise you. I honestly don't ->believe that ATM over PPP in the literal sense is the best way to implement ->your application, Maybe I should elaborate a bit more, but I don't know how familiar you are with DAVIC, or with ATM, and I'm not sure how far I'm allowed to disclose this non-DAVIC members. ->and I don't think ATM on PPP provides a viable networking ->solution in the general case at all. That's actually what I positively think. ->However, I want to give you a good alternative. Thanks for that, it gives some enlightment, but it won't work. ->The best I have come up with is this. -> ->At 8:59 AM 11/15/95, Joel Halpern wrote: ->>I will observe that for the scenario you describe, if he is only concerned ->>about the signalling channel, Unfortunately not. Imagine you have a terminal (Set-top-Unit) connected to an access network (MPEG-2 via Satellite downstream, PPP/ISDN bidirectional for "all the rest". This access network is connected to an ATM core network (at the sending station for the satellite part, and at an ISDN/ATM Inter Working Unit at the other part). DAVIC defines five information flows S1 to S5. S1 is the principal service interface (high-bandwidth downstream), and will use the satellite channel and the ATM core network. S2-S5 are low-bandwidth bi-directional flows, using the ISDN channel and the ATM backbone. S2 is the Application Service Interface (end-to-end control) that will carry interactive command (like pause of rewind for Video-on-Demand) S3 is the Session Service Interface (session control) that will manage all session-related communication (typ. DSM-CC U-N) S4 is the Network Service Interface (connection control) that will manage connection-related communication (typ. Q.2931) S5 is the Management Interface (CMISE or SNMP based) So different type of connections have to be supported on the PPP link. SSCOP would indeed solve the problem for S4 (signalling), but it stops there. How to solve it for S3 and S2 ? Note that the STU is already formatting ATM internally before passing it to the Network Interface. What I don't want to do is to encapsulate these ATM cells in something before putting it on the PPP layer. ->>then the thing to define is either AAL5 ->>over PPP, or even better and more implementable, SSCOP over PPP. SSCOP ->>assumes a frame based service which PPP can provide. That works. ->>ATM cells over PPP is a confusing effort which is unlikely to provide the ->>general service that it would be understood to define. I'd like to understand that more completely. I aggree that SSCOP is better than AAL5, as the AAL5 functions are not needed anymore (framing is provided without that. But why couldn't you provide this "general service" ? It is not unlikely, we want to implement it ! ->Implementing SSCOP on PPP (which is a rather natural signalling protocol; ->you would open an NCP to negotiate the use of SSCOP on the ISDN connection ->into the home, and then send SSCOP messages as the payload of the ->associated data protocol) would permit you to negotiate with the home as to ->what is to be delivered on the high bandwidth channel; the high bandwidth ->channel could in turn be ATM, analog broadcast, or anything else. Not true. It is not enough to have signalling, this only allows you to negotiate bandwidth. But if your access is unidirectional, you need to use the PPP connection also for the control streams ! ->If you wish to implement SSCOP/PPP, I will ask IANA to give you numbers for ->that. That's not enough, unfortunately. Can you give me real reasons to think this is "unlikely" ? Thanks in advance. Regards. Christophe. ------------------------------------------------------------------------------ Statutory Disclaimer: The above is not necessarily an Alcatel position. ------------------------------------------------------------------------------ _ Christophe Vermeulen V System Engineer Third Party Products ------------------- Alcatel Bell Telephone SE275 | A L C A T E L | Fr. Wellesplein 1 - B-2018 Antwerp - Belgium ------------------- Phone: +32 3 240 8942 - Fax: +32 3 240 9920 Full Service Networks Email: meulenc@se.bel.alcatel.be Alcanet: BTMX.MEULENC ------------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 22 16:15:02 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA22214; Wed, 22 Nov 1995 16:15:02 -0500 Resent-Date: Wed, 22 Nov 1995 16:15:02 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Nov 1995 13:11:10 -0800 To: Christophe Vermeulen From: fred@cisco.com (Fred Baker) Subject: Re: ATM on PPP (was Re: PPP on IDSN and PSTN : what are the frames ? Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"0Zmd4.0.aQ5.GBvim"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/881 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 8:58 PM 11/22/95, Christophe Vermeulen wrote: >Maybe I should elaborate a bit more, but I don't know how familiar you are >with DAVIC, or with ATM, and I'm not sure how far I'm allowed to disclose >this non-DAVIC members. That does pose a problem. Perhaps you could make a presentation on the subject at the Dallas IETF? I know very little about DAVIC; I have certainly heard of ATM :^) >Unfortunately not. Imagine you have a terminal (Set-top-Unit) connected >to an access network (MPEG-2 via Satellite downstream, PPP/ISDN bidirectional >for "all the rest". This access network is connected to an ATM core network >(at the sending station for the satellite part, and at an ISDN/ATM Inter >Working Unit at the other part). >S2-S5 are low-bandwidth bi-directional flows, using the ISDN channel and the >ATM backbone. The key question is: what protocol do these flows use? Yes, I'm certain that they package the bits in bursts of ATM cells when attached to an ATM network, but I seriously doubt that these are literally ATM encapsulated. S5/SNMP, for example, will be UDP/IP encapsulated, and when attached to an ATM network will use IP/ATM's AAL5 encapsulation. When attached to a PPP link, why would it not use the existing standard IP/PPP encapsulation? If you have packet services, I would suggest that the right translation to PPP is packet-on-PPP, not packet-in-some-other-data-link-on-PPP. If you think about it carefully, you will not be limited to an ISDN point of attachment, but will be able to use someone's home network, which may in turn be ISDN attached. For example, if you brought this service to MY home (which already has a Frame Relay link and two ISDN services), I would be unwilling to install another $50/month ISDN service just so that I could use fancy cable TV. I would insist that you use one of my existing network services and carry the data across the Ethernet draped around my home. >S2 is the Application Service Interface (end-to-end control) that will carry >interactive command (like pause of rewind for Video-on-Demand) > >S3 is the Session Service Interface (session control) that will manage all >session-related communication (typ. DSM-CC U-N) > >S4 is the Network Service Interface (connection control) that will manage >connection-related communication (typ. Q.2931) > >S5 is the Management Interface (CMISE or SNMP based) > >So different type of connections have to be supported on the PPP link. >SSCOP would indeed solve the problem for S4 (signalling), but it stops >there. How to solve it for S3 and S2 ? Note that the STU is already >formatting ATM internally before passing it to the Network Interface. > >What I don't want to do is to encapsulate these ATM cells in something >before putting it on the PPP layer. No, I am not suggesting that you collect the ATM cells, package them in something else, and put that in PPP. I am suggesting that you don't have ATM cells at all on the ISDN link. You receive the entire packet, be it SNMP/UDP/IP (S5), or SSCOP (S4), or whatever, remove it from its ATM-specific wrapper, and re-encapsulate onto the PPP link. You do the same thing that every other such application does. >I'd like to understand that more completely. I aggree that SSCOP is better >than AAL5, as the AAL5 functions are not needed anymore (framing is provided >without that. >But why couldn't you provide this "general service" ? It is not unlikely, >we want to implement it ! >Can you give me real reasons to think this is "unlikely" ? The "real" reasons that this is unlikely is because it makes for an unextendable architecture. Consider how to make the problem of my home, proposed above, work well, and I think you'll see the issues involved. You might further consider that my home is not the only network you will have to deal with - there is very likely to be a similar network at the broadcast site, and by the way, there's more to the internet than either of those. You might strongly consider reading ftp://ds.internic.net/internet-drafts/draft-iab-principles-00.txt, which is a summary of the principles under which the protocols used in the Internet are designed. Principles that apply here are mentioned in sections 2.1, 2.2, and 2.3. Briefly, they are that: connectivity is its own reward you want to design your protocol so that it is useful in an internet of arbitrary topology; this makes your service available to the maximum possible user base and preserves your architecture as changing technology presents new data link options and obsoletes old ones. there is one common internet protocol and to end and that protocol is independent of data link layer functionality end-to-end functions can best be realised by end-to-end protocols. In your case, network management (SNMP or CMIP) is an example of a protocol that communicates between a network management system at the broadcast site and the desktop box. The protocols involved run end to end, and are realized by a set of layered protocols that run end to end within the domain to which they are appropriate. ATM runs end to end in the ATM network, which does not include the ISDN line. If it included the ISDN line, you wouldn't be making this request. Similarly, PPP runs end to end through the path that the ISDN call runs, and doesn't concern itself with the underlying telephone network topology, which might be as simple as an ISDN switch or as complex as you care to make it. But the protocol that is the lowest common denominator there is neither ATM nor PPP; it is IP. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 24 04:32:07 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id EAA04210; Fri, 24 Nov 1995 04:32:07 -0500 Resent-Date: Fri, 24 Nov 1995 04:32:07 -0500 From: meulenc@se.bel.alcatel.be Date: Fri, 24 Nov 1995 10:32:27 +0100 Message-Id: <199511240932.KAA19613@btmplq.god.bel.alcatel.be> To: ietf-ppp@MERIT.EDU, fred@cisco.com Subject: Re: ATM on PPP X-Sun-Charset: US-ASCII Resent-Message-ID: <"FNCBD.0.V11.94Pjm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/882 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ->From fred@cisco.com Wed Nov 22 22:15:32 1995 ->At 8:58 PM 11/22/95, Christophe Vermeulen wrote: ->>Maybe I should elaborate a bit more, but I don't know how familiar you are ->>with DAVIC, or with ATM, and I'm not sure how far I'm allowed to disclose ->>this non-DAVIC members. -> ->That does pose a problem. Perhaps you could make a presentation on the ->subject at the Dallas IETF? I know very little about DAVIC; I have ->certainly heard of ATM :^) Not sure that can happen. When is it ? I guess I should first get aggreement from DAVIC authorities to do that. I'll check that. ->The key question is: what protocol do these flows use? Yes, I'm certain ->that they package the bits in bursts of ATM cells when attached to an ATM ->network, but I seriously doubt that these are literally ATM encapsulated. What do you exactly mean ? Actually, there are two choices : transport a set of 4 different protocols (eg S2 on IP, S5 on IP (SNMP) or ISO (CMIP), S4 or SSCOP and S3 on ??? (DSM-CC UN). The other solution is to allow all these to be multiplexed already on ATM level in the STB, which is a function already available. Then the other side of the connection, let's call it the "ATM IWU" will only have to remap VPI/VCI and send that to the ATM network. The first solution requires a very high burden on the IWU as all protocols have to be understood, as compared to only ATM. ->S5/SNMP, for example, will be UDP/IP encapsulated, and when attached to an ->ATM network will use IP/ATM's AAL5 encapsulation. When attached to a PPP ->link, why would it not use the existing standard IP/PPP encapsulation? As I said before this is _possible_, but extra work for everybody : the ATM termination is available in the Set-top, and it will have to be bypassed and replicated in the Network. That's what we precisely don't want. Perhaps the only solution for us is not to use PPP, but directly ATM on the line. The advantage we see in PPP is that it allows us also to send IP datagrams as well, if the IWU would allow a connection to the Internet, and for its Data Link features. ATM has no real data link functions in my view : it uses separate cells for AIS (F4), for setting up links(Q.2931), etc. I know this may seem quite unorthodox, but you may look at it again, it is so. Don't be mistaken, when I say "no real", I don't mean they don't exist, but as they use cells, these functions don't map on the OSI model (as ATM provides also Layer 3 functions) Given the access network may be non-ATM (eg. ISDN), the data link functions cannot use the ATM way. Therefore, the PPP way looks great, and we want to use it. ->If you have packet services, I would suggest that the right translation to ->PPP is packet-on-PPP, not packet-in-some-other-data-link-on-PPP. If you ->think about it carefully, you will not be limited to an ISDN point of ->attachment, but will be able to use someone's home network, which may in ->turn be ISDN attached. Right, that's just my point. I want to use ATM as packets here, ATM is not a layer 2 protocol. (It's part of 1, part of 2 and part of 3). Don't forget ATM contains routing information is the header ! ->For example, if you brought this service to MY home (which already has a ->Frame Relay link and two ISDN services), I would be unwilling to install ->another $50/month ISDN service just so that I could use fancy cable TV. I ->would insist that you use one of my existing network services and carry the ->data across the Ethernet draped around my home. ATM over Ethernet ? Why not. The only problem I see is that you can't reserve bandwidth on the Ethernet. Maybe we may use UBR or ABR is the future. But BTW, does your ISDN traffic pass on your Ethernet ? If you have ISDN service, let's use it. ->No, I am not suggesting that you collect the ATM cells, package them in ->something else, and put that in PPP. I am suggesting that you don't have ->ATM cells at all on the ISDN link. Why not, give me one real argument against it. If you carry IP, IPX, and other packets, why no ATM ? ->You receive the entire packet, be it ->SNMP/UDP/IP (S5), or SSCOP (S4), or whatever, remove it from its ->ATM-specific wrapper, and re-encapsulate onto the PPP link. You do the same ->thing that every other such application does. And at the other end, I have to do the opposite : recreate ATM encapsulation for each of these streams, though I had it already in my terminal ! That's more than contra-productive ! ->>But why couldn't you provide this "general service" ? It is not unlikely, ->>we want to implement it ! -> ->>Can you give me real reasons to think this is "unlikely" ? -> ->The "real" reasons that this is unlikely is because it makes for an ->unextendable architecture. Consider how to make the problem of my home, ->proposed above, work well, and I think you'll see the issues involved. Your home network connects to ISDN, and allows for transport of packets. The only thing I want to add is another sort of packets, namely ATM cells. ->You ->might further consider that my home is not the only network you will have ->to deal with - there is very likely to be a similar network at the ->broadcast site, and by the way, there's more to the internet than either of ->those. Right. But our first purpose is to provide service like Video-on-Demand and Home Shopping, while providing for later Internet access. What we want is to choose the right technologies and protocols to achieve our purposes. We may as well define a kind of ATM on SLIP, or whatever, but we don't want that to be future-safe. ->You might strongly consider reading ->ftp://ds.internic.net/internet-drafts/draft-iab-principles-00.txt, which is ->a summary of the principles under which the protocols used in the Internet ->are designed. Principles that apply here are mentioned in sections 2.1, ->2.2, and 2.3. Briefly, they are that: -> -> connectivity is its own reward -> -> you want to design your protocol so that it is useful in an -> internet of arbitrary topology; this makes your service available -> to the maximum possible user base and preserves your architecture -> as changing technology presents new data link options and obsoletes -> old ones. -> -> there is one common internet protocol and to end I suppose you mean IP -> and that protocol is independent of data link layer functionality Right. But then, when are ther 100 other protocols supported on PPP, and for example IPX, DECnet or Appletalk ? So I believe that PPP has a broader span than the Internet Protocol itself. Am I wrong ? -> end-to-end functions can best be realised by end-to-end protocols. 100% aggree. That's why I want the ATM termination to be used in the terminal, and not in the ATM <-> ISDN gateway. -> ATM runs end to end in the ATM network, Sorry, but this is wrong : end-to-end is between terminals (a server and a STB in this case), so end-to-end in the ATM network makes no sense. -> which does not include -> the ISDN line. If it included the ISDN line, you wouldn't be -> making this request. This request is precisely to allow us including the ISDN line transparently in the network, so that we can use ATM end-to-end, like in pure ATM networks. -> Similarly, PPP runs end to end through the -> path that the ISDN call runs, and doesn't concern itself with the -> underlying telephone network topology, which might be as simple -> as an ISDN switch or as complex as you care to make it. But the -> protocol that is the lowest common denominator there is neither -> ATM nor PPP; it is IP. Not at all. IP is just one of the protocols you can carry on PPP RFC1700 lists them all. What I want is to add ATM in the official list, instead of "picking" a number at random. Hope I clarified it a bit more. Regards. Christophe. ------------------------------------------------------------------------------ Statutory Disclaimer: The above is not necessarily an Alcatel position. ------------------------------------------------------------------------------ _ Christophe Vermeulen V System Engineer Third Party Products ------------------- Alcatel Bell Telephone SE275 | A L C A T E L | Fr. Wellesplein 1 - B-2018 Antwerp - Belgium ------------------- Phone: +32 3 240 8942 - Fax: +32 3 240 9920 Full Service Networks Email: meulenc@se.bel.alcatel.be Alcanet: BTMX.MEULENC ------------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Nov 24 12:51:55 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA13930; Fri, 24 Nov 1995 12:51:55 -0500 Resent-Date: Fri, 24 Nov 1995 12:51:55 -0500 Message-ID: <01BABA6B.588FDC40@ppp-pm01-dy-17.opr.oakland.edu> From: Brad Wilson To: "'meulenc@se.bel.alcatel.be'" Cc: "'ietf-ppp@merit.edu'" Subject: RE: ATM on PPP Date: Fri, 24 Nov 1995 12:49:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"39QGm1.0.RP3.nOWjm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/883 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Right. But our first purpose is to provide service like Video-on-Demand and Home >> Shopping, while providing for later Internet access. Then you should thing long and hard before locking yourself into a specific media type. If you do plan on providing internet traffic, it's vital to be media independent. >> Right. But then, when are ther 100 other protocols supported on PPP, and >> for example IPX, DECnet or Appletalk ? Do you mean, "why"? Because PPP is just like IP ... it's designed to be multi-protocol. IPX is a protocol that exists, and needs to be transported over a hardware connection. One of the major reasons PPP exists is multi-protocol support. SLIP was precisely the opposite ... employing a "make it work now" solution instead of taking a look at the bigger picture. >> So I believe that PPP has a broader span than the Internet Protocol itself. PPP was designed to be the official method of transporting IP datagrams over a peer-to-peer connection (please note that there are still many SLIP connections in use). PPP was also designed to be "multi-protocol friendly", even though the IETF has nothing to do with IPX, Appletalk and the rest. The reason is, most of the Apple people, Novell people, DEC people, etc., are all a part of the IETF. It is a wise move for the community to have a single protocol running on peer-to-peer connections to support a variety of different networking protocols. >> Sorry, but this is wrong : end-to-end is between terminals (a server and a STB in >> this case), so end-to-end in the ATM network makes no sense. No, end-to-end does not necessarily mean between terminals. End-to-end in the ethernet world is from my box to the other box that gets the packet. Once that packets comes off our piece of ethernet, that "layer" is stripped away. A good example, obviously, is a serial router to the Internet from an ethernet network. The same should apply for ATM: when that packet comes off of ATM, that "layer" should be stripped away. >> This request is precisely to allow us including the ISDN line transparently >> in the network, so that we can use ATM end-to-end, like in pure ATM networks. I think you're missing the point. The ATM wire is not end-to-end, so the use of the ATM protocols is not end-to-end. You are coming here, asking for a way to encapsulate ATM into ISDN (via PPP). What happens when the wire inbetween is ethernet? Will you then go ask for a type to encapsulate ATM packets into the ethernet? And when do you stop? When network topologies stop existing? And where do you get routers that do this for you? Are you building them yourself (or having them custom made), paying exorbitant amounts because the cost isn't amortized over all the customers? Or, should you use the methodology that is ALREADY in place (and, to no small benefit, highly tested) and guaranteed to work without upsetting the apple cart? >> Not at all. IP is just one of the protocols you can carry on PPP >> RFC1700 lists them all. What I want is to add ATM in the official list, It is unlikely that the group would want to provide ATM-over-PPP, any more than they would want to provide Ethernet-over-PPP, FDDI-over-PPP, etc. Why do you INSIST of having ATM be the end-to-end protocol, instead of something more logical like IP? When you said: >> transport a >> set of 4 different protocols (eg S2 on IP, S5 on IP (SNMP) or ISO (CMIP), >> S4 or SSCOP and S3 on ??? (DSM-CC UN). I thought, "that's exactly what PPP is made for". Have you considered something else: PPP packets are not fragmentable. What will you do if your protocol packet(s) are too large to go onto the intended media? >> instead of "picking" a number at random. You will DEFINITELY not make any friends doing this. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 27 13:18:39 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA06145; Mon, 27 Nov 1995 13:18:39 -0500 Resent-Date: Mon, 27 Nov 1995 13:18:39 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Nov 1995 10:13:50 -0800 To: meulenc@se.bel.alcatel.be From: fred@cisco.com (Fred Baker) Subject: Re: ATM on PPP Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"J36bT2.0.bV1.P3Wkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/884 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 10:32 AM 11/24/95, meulenc@se.bel.alcatel.be wrote: >->That does pose a problem. Perhaps you could make a presentation on the >->subject at the Dallas IETF? I know very little about DAVIC; I have >->certainly heard of ATM :^) >Not sure that can happen. When is it ? I guess I should first get >agreement from DAVIC authorities to do that. I'll check that. The meeting is a week from today; details are available from http://www.ietf.cnri.reston.va.us/meetings/Dallas.html >->The key question is: what protocol do these flows use? Yes, I'm certain >->that they package the bits in bursts of ATM cells when attached to an ATM >->network, but I seriously doubt that these are literally ATM encapsulated. >What do you exactly mean ? Actually, there are two choices : transport >a set of 4 different protocols (eg S2 on IP, S5 on IP (SNMP) or ISO >(CMIP), S4 or SSCOP and S3 on ??? (DSM-CC UN). The other solution is >to allow all these to be multiplexed already on ATM level in the STB, >which is a function already available. Then the other side of the >connection, let's call it the "ATM IWU" will only have to remap >VPI/VCI and send that to the ATM network. The first solution requires >a very high burden on the IWU as all protocols have to be understood, >as compared to only ATM. This "very high burden" is presumably small enough that you can put it in a TV-top device that you can either sell for what a consumer will pay for it, or install for "free," right? >Right, that's just my point. I want to use ATM as packets here, ATM is not >a layer 2 protocol. (It's part of 1, part of 2 and part of 3). Don't forget >ATM contains routing information is the header ! yes, VCI/VPI identification. It is as much a network layer protocol as is Ethernet, Frame Relay, X.25, SMDS, and IBM Bisync, all of which contain the address of a system or a virtual circuit in their header. All of which are generally considered to be "link layer networks" as opposed to generalized network layers. All of them except, I suppose, X.25; in your part of the world it is considered a network layer. But let me point out to you that services like those offered on France's X.25 network are available to you on the internet, but you are not able to offer them to me on X.25. The reason, simply, is that X.25 never caught on in the US. So by positing your services on X.25, you have reduced your marketplace to a few countries. I submit that positing the services on ATM is to repeat the mistake. You can provide a service to a large part of the world if you use the architecture that is there and working, and you limit yourself when you try to make ATM "be" the network. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 27 16:08:53 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA11870; Mon, 27 Nov 1995 16:08:53 -0500 Resent-Date: Mon, 27 Nov 1995 16:08:53 -0500 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-stacker-04.txt Date: Mon, 27 Nov 95 09:21:12 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9511270921.aa13159@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"jgjG73.0.6v2.zYYkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/885 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --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 Stacker LZS Compression Protocol Author(s) : R. Lutz, W. Simpson Filename : draft-ietf-pppext-stacker-04.txt Pages : 10 Date : 11/22/1995 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 Stacker LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-stacker-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-stacker-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-stacker-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19951122200201.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-stacker-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-stacker-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122200201.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 27 16:34:29 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA12895; Mon, 27 Nov 1995 16:34:29 -0500 Resent-Date: Mon, 27 Nov 1995 16:34:29 -0500 Date: Mon, 27 Nov 1995 16:33:49 -0500 From: John Shriver Message-Id: <199511272133.QAA22979@shiva-dev.shiva.com> To: ietf-ppp@MERIT.EDU In-reply-to: <9511270921.aa13159@IETF.CNRI.Reston.VA.US> (Internet-Drafts@CNRI.Reston.VA.US) Subject: Re: I-D ACTION:draft-ietf-pppext-stacker-04.txt Resent-Message-ID: <"HvZZ8.0.D93.XxYkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/886 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Just why, pray tell, was the check mode value for Sequence Number changed from 3 to 4 with no discussion at all on this list? I don't see any mention of this in the minutes of the latest IETF meeting, either. This doesn't seem to be based on any consensus, and it is going to break SHIPPING implementations. I wonder what the real motive is? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 27 16:38:01 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA12972; Mon, 27 Nov 1995 16:38:01 -0500 Resent-Date: Mon, 27 Nov 1995 16:38:01 -0500 Date: Mon, 27 Nov 1995 16:37:24 -0500 From: John Shriver Message-Id: <199511272137.QAA23034@shiva-dev.shiva.com> To: ietf-ppp@MERIT.EDU In-reply-to: <9511270921.aa13159@IETF.CNRI.Reston.VA.US> (Internet-Drafts@CNRI.Reston.VA.US) Subject: Re: I-D ACTION:draft-ietf-pppext-stacker-04.txt (histories) Resent-Message-ID: <"f83xQ1.0.TA3.s-Ykm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/887 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The History Count now explains that every implmentation MUST support at least one history. Well, that helps understand the minimum requirements. Must an implementation also support 0 histories? (Yes, one can definitely read it that way, but it's not highly obvious.) Also, what is the default? That remains unspecified. 0? 1? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 27 16:49:16 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA13313; Mon, 27 Nov 1995 16:49:16 -0500 Resent-Date: Mon, 27 Nov 1995 16:49:16 -0500 Date: Mon, 27 Nov 1995 16:48:38 -0500 From: John Shriver Message-Id: <199511272148.QAA23431@shiva-dev.shiva.com> To: ietf-ppp@MERIT.EDU In-reply-to: <9511270921.aa13159@IETF.CNRI.Reston.VA.US> (Internet-Drafts@CNRI.Reston.VA.US) Subject: Re: I-D ACTION:draft-ietf-pppext-stacker-04.txt (check type) Resent-Message-ID: <"8-JK63.0.cF3.O9Zkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/888 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Oh, I didn't read carefully enough. The check type is to be bit coded. That makes a lot of sense, it explains questions I had a long time ago. It really improves the protocol, I'd always thought it was crazy that the damn things weren't bit coded. (Having compared it with other CCP option negotiations like Microsoft CCP that are bit coded.) Again, the problem remains, that the values 0, 1, 2, and 3 are interpreted by many existing implementations as a "choice". This is a major change in interpretation at this late date. I don't think that the escape of "accept 3 in ACK/NAK" handles all cases. I think that we'd be better off introducing a different CCP option type for CCP with bit-oriented negotiation. That's a big change to make on an already-fielded option. Yes, this is still an Internet Draft, and is therefor allowed to make changes with major compatability implications. However, it is only an Internet Draft due to the efforts of an outside party. Without Motorola, this would certainly be a DS or PS RFC by now, and it would be too late to make such a change with impunity. It would probably also be less confusing (description-wise) if the values were OR'd, not XOR'd. Yeah, 1 XOR 0 is 1. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 27 16:52:46 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA13622; Mon, 27 Nov 1995 16:52:46 -0500 Resent-Date: Mon, 27 Nov 1995 16:52:46 -0500 From: Frederick Baker Date: Mon, 27 Nov 1995 13:52:00 -0800 Message-Id: <199511272152.NAA06980@fred-ss20.cisco.com> To: ietf-ppp@MERIT.EDU Subject: Dallas IETF Agenda - PPP Cc: minutes@cnri.reston.va.us Resent-Message-ID: <"O4zGY2.0.EJ3.dCZkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/889 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The following drafts have been posted since the Stockholm IETF, and their authors have requested time to discuss them at the coming IETF meeting. They, therefore, constitute the agenda - with about 20 minutes per heading. IPCP Update to Draft Standard (Pall) draft-ietf-pppext-ipcp-network-00.txt draft-ietf-pppext-des-encrypt-01.txt Updates to Draft Standard (Simpson) draft-ietf-pppext-chap-ds-00.txt draft-ietf-pppext-lqm-ds-00.txt draft-ietf-pppext-lzs-dcp-01.txt Encryption: (Sklower, Meyer) draft-ietf-pppext-des-encrypt-01.txt EAP Authentication: (Blunk et al) draft-ietf-pppext-eap-auth-01.txt draft-ietf-pppext-eaprsa-00.txt Alternative Compression Proposal (Mader) draft-ietf-pppext-wcp-00.txt LZS-DCP Compression (Schneider, Friend) draft-ietf-pppext-lzs-dcp-01.txt We are scheduled for a single two hour session 9:30 to 11:30 Monday morning December 4. Meeting progress will be enhanced if all have read the documents before coming and are prepared to discuss issues. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 27 17:03:26 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA14171; Mon, 27 Nov 1995 17:03:26 -0500 Resent-Date: Mon, 27 Nov 1995 17:03:26 -0500 From: Vartan Narikian To: "'ietf-ppp'" Subject: status of PPP in Frame Relay Date: Mon, 27 Nov 95 17:01:00 PST Message-Id: <30BA606F@admin.eicon.com> Encoding: 10 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"JM_k8.0.CT3.hMZkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/890 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU What is the status of PPP in Fame Relay??. The latest one is 'draft-ieft-pppext-frame-relay-03.txt dated April 1994 which has expired. Will there be an RFC number for this?? Vartan Narikian vartann@eicon.com Eicon Technology - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 27 17:30:25 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA15000; Mon, 27 Nov 1995 17:30:25 -0500 Resent-Date: Mon, 27 Nov 1995 17:30:25 -0500 Date: Mon, 27 Nov 1995 17:29:43 -0500 From: John Shriver Message-Id: <199511272229.RAA25180@shiva-dev.shiva.com> To: ietf-ppp@MERIT.EDU Subject: stacker options Resent-Message-ID: <"Ky00s3.0.9g3.vlZkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/891 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Well, I thought a bit more of what we can do if (and only if) we did a _NEW_ Stacker CCP option. Another limitation with the current scheme is the way that the number of histories, and the SIZE of the history number field in the packet header, are negotiated in the same sub-option for Stacker. For instance, lets say someone sends a CCP Config-Request with a Stacker history count field of 2. That implies that they will accept 0, 1, or 2 histories. That also implies that they will accept 0, 0, or 1 byte of history number in their compression header. Well, I receive that Config-Request. I only support 1 history. (Well, I admit that it's a bug that I should also support 0 histories, but I don't. Put me in the pillory!) But I do not support 2 histories, and do not have the code to put the one byte history number in the compression header. But, the normal PPP rule would be that I should ACK this, just because he offers to accept two histories doesn't mean I'm obligated to use 2 histories, I can use 1 or 0. (Just like if I get and ACK an LCP Protocol Field Compression option, I'm not obligated to compress the protocol field. This, as Bill keeps pointing out, is the "PPP Way." Or, as the draft says: [..] The peer is not required to send as many histories as the implementation indicates that it can accept. ) But that does NOT fly. Because if I ACK a history count of 2, he will interpret it to mean that I'm going to put a history number in the header. I won't. The peers have to AGREE on the number of bytes of history number. I presently address this by Config-NAK-ing any history count other than 1. (Well, maybe that is a perfectly acceptable way to deal with this!) But, I think that the real problem is that we are trying to negotiate two things at once -- the number of histories, and the number of bytes of history number. The first is a matter of range acceptance, the second is a matter where we have to AGREE. The history number size really would be better as a seperately negotiated sub-option, with three values: 0 accept 0 byte history number 1 accept 1 byte history number 2 accept 2 byte history number This is NOT bit coded, since we need to agree. Well, we have to agree on check scheme too, and that is being proposed to be bit-coded. Maybe this will still negotiate faster, you NAK with the one bit that you prefer. On the other hand, adding a seperate field means that we have two fields with cross-consistency requirements -- also a hassle. Alternately, we perhaps should add descriptive material under the history count sub-option that you are also negotiating the number of bytes of history number, and that by Config-ACK-ing anything larger than 1 you are also committing to send a 1 byte history number, and by Config-ACK-ing anything larger than 255, you are also committing to send a 2 byte history number. Using one option to negotiate everything about a compression protocol poses some rather serious design limitations. This probably was not the ideal solution in the first place. I'd have been much happer with seperate options... Perhaps the overall CCP draft should comment on the best way to design sub-options for a compression protocol, prevent future problems... - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Nov 27 19:15:51 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA17831; Mon, 27 Nov 1995 19:15:51 -0500 Resent-Date: Mon, 27 Nov 1995 19:15:51 -0500 Date: Mon, 27 Nov 1995 16:14:38 -0800 (PST) From: Keith Sklower Message-Id: <199511280014.QAA21849@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: DESE->MP bis Resent-Message-ID: <"fFhDe1.0.GM4.oIbkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/892 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I'm trading my floor time in the meeting to discuss revisions to Multilink (instead of PPP-DESE). I have had no further comments about DESE since stockholm (and the whole issue seems stalled, given motorola patent concerns). However, Multilink is up for a change of status from proposed to draft, and should be advanced. Although a new ID was mailed off to the people on wednesday, it was after the close of business on the East Coast. A copy of the draft may be obtained via anonymous ftp from vangogh.cs.berkeley.edu as: ~ftp/pub/ietf-local/draft-ietf-pppext-multilink-12.txt - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 00:26:13 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id AAA25557; Tue, 28 Nov 1995 00:26:13 -0500 Resent-Date: Tue, 28 Nov 1995 00:26:13 -0500 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-lzs-dcp-01.txt Date: Mon, 27 Nov 95 14:59:11 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9511271459.aa25803@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"1rWtg2.0.6F6.crfkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/893 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --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 LZS-DCP Compression Protocol (LZS-DCP) Author(s) : K. Schneider, R. Friend Filename : draft-ietf-pppext-lzs-dcp-01.txt Pages : 15 Date : 11/22/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Stacker LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This protocol is an enhanced version of the non-DCP (Option 17) PPP Stac LZS compression protocol [5], and will be referred to as the LZS-DCP Compression Protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-lzs-dcp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-lzs-dcp-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-lzs-dcp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19951122182342.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-lzs-dcp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lzs-dcp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122182342.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 05:04:08 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id FAA01890; Tue, 28 Nov 1995 05:04:08 -0500 Resent-Date: Tue, 28 Nov 1995 05:04:08 -0500 Date: Tue, 28 Nov 95 02:48:37 GMT From: "William Allen Simpson" Message-ID: <4588.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: I-D ACTION:draft-ietf-pppext-stacker-04.txt Resent-Message-ID: <"uDiQh.0.FT.Hwjkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/894 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: John Shriver > Just why, pray tell, was the check mode value for Sequence Number > changed from 3 to 4 with no discussion at all on this list? I don't > see any mention of this in the minutes of the latest IETF meeting, > either. > It was discussed about 2 years ago, as I remember. Was it the ppp-compress list? I'd have to check.... But the _real_ change, recommending Sequence Number over the other two, was not discussed on this list. Lots of private email on the topic. Bogus Motorola patent avoidance, of course. > This doesn't seem to be based on any consensus, and it is going to > break SHIPPING implementations. > Ah, John, as noted in the draft, the 3 was a _TYPO_. It was always supposed to be 4, to give a bit code. Sorry that my fingers were so silly to miss by one key. I didn't notice that the draft didn't match _my_ previous work. Sometimes, you see in the draft what you _expect_, even after multiple re-readings. It was intended to be able to tell the peer when you had more than one type available. Normally, only one type is available, say on an early Stac chip, but we wanted flexibility. I still vaguely remember the tirade from someone complaining that this would take multiple messages (to Nak with the selected value), and wanting 3 separate LZS options listed instead, and pick one (another perfectly legal PPP technique). That takes just as many messages, unless you just Ack, and have the first of many options take effect. That is a new feature in CCP, as I remember. But you can still do that in this case, too. It will not break shipping implementations. 4 will just look like a new number. Anyway, because of the shipping implementations, I also wrote up an "implementation note" on how to handle the old implementations automatically. Do you think it doesn't work? > I wonder what the real motive is? > Does there need to be a motive other than technical excellence? I suppose the fact that the latest Stac software supports Sequence Number is one of the reasons it is now recommended over LCB. And do I need to remind you that the draft can change all the way to Draft Standard? We ain't anywhere near that, yet. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 06:21:32 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id GAA03566; Tue, 28 Nov 1995 06:21:32 -0500 Resent-Date: Tue, 28 Nov 1995 06:21:32 -0500 Date: Tue, 28 Nov 95 10:04:40 GMT From: "William Allen Simpson" Message-ID: <4593.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Cc: Vartan Narikian Subject: Re: status of PPP in Frame Relay Resent-Message-ID: <"GpcDl1.0.Vt.v2lkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/895 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Vartan Narikian > What is the status of PPP in Fame Relay??. We are having a lunch meeting about it in Dallas. We should probably bring this up on your agenda, Fred. > The latest one is 'draft-ieft-pppext-frame-relay-03.txt dated April 1994 > which has expired. > Will there be an RFC number for this?? > Yes. Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 06:21:37 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id GAA03595; Tue, 28 Nov 1995 06:21:37 -0500 Resent-Date: Tue, 28 Nov 1995 06:21:37 -0500 Date: Tue, 28 Nov 95 10:07:23 GMT From: "William Allen Simpson" Message-ID: <4595.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Subject: Re: stacker options Resent-Message-ID: <"NXA6l3.0.vt.-2lkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/896 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: John Shriver > For instance, lets say someone sends a CCP Config-Request with a > Stacker history count field of 2. That implies that they will accept > 0, 1, or 2 histories. Yes. > That also implies that they will accept 0, 0, > or 1 byte of history number in their compression header. > No. It specifies that they will always send exactly one byte of history number. If the negotiated History Count is 2 or more, but less than 256, this field is 1 octet. > Well, I receive that Config-Request. I only support 1 history. > (Well, I admit that it's a bug that I should also support 0 histories, > but I don't. Put me in the pillory!) Yes, you do. At least in the receive direction. No matter how many histories you negotiate, if the peer sends without a history (doesn't keep one), you will never notice. You will just have wasted the history buffer space. Of course, if the peer Requests 0, you will fail to converge. But that's OK. There is no requirement that CCP succeed. Data will flow. > But I do not support 2 > histories, and do not have the code to put the one byte history number > in the compression header. > That's OK. Most early implementors did the same thing. > But, the normal PPP rule would be that I should ACK this, just because > he offers to accept two histories doesn't mean I'm obligated to use 2 > histories, I can use 1 or 0. (Just like if I get and ACK an LCP > Protocol Field Compression option, I'm not obligated to compress the > protocol field. This, as Bill keeps pointing out, is the "PPP Way." > Or, as the draft says: > > [..] The peer is not > required to send as many histories as the implementation indicates > that it can accept. ) > > But that does NOT fly. Because if I ACK a history count of 2, he will > interpret it to mean that I'm going to put a history number in the > header. I won't. The peers have to AGREE on the number of bytes of > history number. > Correct on all counts! Actually, this option is _really_ about negotiating the _size_ of the history field. I should make that more clear. > I presently address this by Config-NAK-ing any history count other > than 1. (Well, maybe that is a perfectly acceptable way to deal with > this!) > Absolutely correct! > But, I think that the real problem is that we are trying to negotiate > two things at once -- the number of histories, and the number of bytes > of history number. The first is a matter of range acceptance, the > second is a matter where we have to AGREE. > ... > On the other hand, adding a seperate field means that we have two > fields with cross-consistency requirements -- also a hassle. > Yes. I think that this is more hassle than it's worth. The checking is what killed IPCP 2 addresses (deprecated option 1). > Alternately, we perhaps should add descriptive material under the > history count sub-option that you are also negotiating the number of > bytes of history number, and that by Config-ACK-ing anything larger > than 1 you are also committing to send a 1 byte history number, and by > Config-ACK-ing anything larger than 255, you are also committing to > send a 2 byte history number. > Good ideas. I will add this! History Count Two octets, most significant octet first. Specifies both the | maximum number of Compression Histories and the size of the History Number field in the LZS Packet Format. | The value 0 indicates that the implementation expects the peer to reset the Compression History at the beginning of every packet. The value 1 is used to indicate that only one history is maintained. Every implementation MUST support at least one history. Other valid values range from 2 to 65535. When the value is 2 or | more, but less than 256, the History Number field is always 1 | octet. If 256 or more histories are negotiated, the History | Number field is always 2 octets. | The peer indicates support for smaller History Number fields | with Configure-Nak. Within a particular History Number size, the | peer is not required to send as many histories as the implementation indicates that it can accept. Actually, Stac was suggesting the same kind of things, just changing the option fields, or adding one (you could tell the new version by the length field). I had to explain that we have so many deployed implementations, that we need to be backwardly compatible.... (your previous argument). Also, this list (and several implementors privately) have asked for a method of sending an "uncompressed" indication. The latest Stac software supports this feature. They wanted to use the top bit of the history field. Again, breaking compatibility. I think that belongs in CCP, myself. As a separate code, suggested by Scott Wasson last spring. Or you could give up and use DCP format .... Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 09:04:05 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA07247; Tue, 28 Nov 1995 09:04:05 -0500 Resent-Date: Tue, 28 Nov 1995 09:04:05 -0500 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-eaprsa-00.txt Date: Mon, 27 Nov 95 10:02:13 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9511271002.aa16143@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"BF0nB3.0.vm1.9Rnkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/897 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP EAP RSA Public Key Authentication Protocol Author(s) : W. Whelan Filename : draft-ietf-pppext-eaprsa-00.txt Pages : 8 Date : 11/22/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication its peer before allowing Network Layer protocols to transmit over the link. PPP Extensible Authentication Protocol (EAP) [2] provides for a number of authentication mechanisms. One of these is RSA Public Key Authentication. This document defines RSA Public Key Authentication Protocol within PPP EAP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-eaprsa-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eaprsa-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-eaprsa-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19951122152323.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eaprsa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eaprsa-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122152323.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 09:25:20 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA07791; Tue, 28 Nov 1995 09:25:20 -0500 Resent-Date: Tue, 28 Nov 1995 09:25:20 -0500 From: gmd@proteon.com (Gina DePlanche) Message-Id: <9511281424.AA01540@columbo.proteon.com> Subject: Re: DESE->MP bis To: sklower@cs.berkeley.edu (Keith Sklower) Date: Tue, 28 Nov 1995 09:24:40 -0500 (EST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199511280014.QAA21849@vangogh.CS.Berkeley.EDU> from "Keith Sklower" at Nov 27, 95 04:14:38 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2178 Resent-Message-ID: <"8j3gt1.0.Uv1.Clnkm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/898 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU According to Keith Sklower ... -> ->I'm trading my floor time in the meeting to discuss revisions ->to Multilink (instead of PPP-DESE). I have had no further ->comments about DESE since stockholm (and the whole issue ->seems stalled, given motorola patent concerns). -> ->However, Multilink is up for a change of status from proposed to ->draft, and should be advanced. -> ->Although a new ID was mailed off to the people on wednesday, ->it was after the close of business on the East Coast. A copy ->of the draft may be obtained via anonymous ftp from ->vangogh.cs.berkeley.edu as: -> ~ftp/pub/ietf-local/draft-ietf-pppext-multilink-12.txt -> -> -> Hi! I sent the enclosed message to the authors of draft-ietf-pppext-multilink-11.txt regarding the status of this draft about a week ago. I know everyone has been busy, so I thought I'd mail my question to the whole group. I haven't yet read the above mentioned draft-ietf-pppext-multilink-12.txt. Does this mean that draft11 will not be assigned an RFC number? Thanks for the info! - Gina ************ enclosed message ************************ Message 2/8 From Gina DePlanche Nov 21, 95 01:26:37 pm -0500 Return-Path: Subject: draft-ietf-pppext-multilink-11.txt To: sklower@CS.Berkeley.EDU, brian@lloyd.com, glenn@lloyd.com, dcarr@Newbridge.COM, 70761.1664@compuserve.com Date: Tue, 21 Nov 1995 13:26:37 -0500 (EST) Sender: gmd@proteon.com Hi! I am relatively new to the PPP/MPP world. I have just read draft-ietf-pppext-multilink-11.txt and have noticed it has an expiration date of December 15, 1995. I'm writing to ask you what the status of this draft is. Will it be catagorized as a Standards Track document before the expiration date? I apologize if this information has already been announced and I have missed it. I have been subscribed to the ietf-ppp mailing list for only a few weeks. Thank you, Gina -- Gina M. DePlanche | Proteon gmd@proteon.com | MailStop #23 (508) 898-2800 x2541 | 9 Technology Drive, Westborough, MA Fax: (508) 898-2547 | 01581-1799 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 14:21:21 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA16656; Tue, 28 Nov 1995 14:21:21 -0500 Resent-Date: Tue, 28 Nov 1995 14:21:21 -0500 Date: Tue, 28 Nov 1995 11:19:46 -0800 (PST) From: Keith Sklower Message-Id: <199511281919.LAA28775@vangogh.CS.Berkeley.EDU> To: gmd@proteon.com, sklower@cs.berkeley.edu Subject: Re: DESE->MP bis Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"d2CxV3.0.-24.L4skm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/899 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RFC1717 is a standards track document. Draft 11 contained several clarifications and Draft 12 contains a couple more. It is possible that as a result of this meeting Draft 12 will be submitted to the RFC Editor and be released as a Draft Standard. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 14:36:36 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA17167; Tue, 28 Nov 1995 14:36:36 -0500 Resent-Date: Tue, 28 Nov 1995 14:36:36 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Nov 1995 11:35:55 -0800 To: gmd@proteon.com (Gina DePlanche) From: fred@cisco.com (Fred Baker) Subject: Re: DESE->MP bis Cc: sklower@cs.berkeley.edu (Keith Sklower), ietf-ppp@MERIT.EDU Resent-Message-ID: <"WnfHt2.0.-B4.0Jskm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/900 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 9:24 AM 11/28/95, Gina DePlanche wrote: >I haven't yet read the above mentioned >draft-ietf-pppext-multilink-12.txt. Does this mean that draft11 will >not be assigned an RFC number? I don't think we're quite ready for that, which is why we will be discussing it next week. Come along and help us get it sorted out! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 21:14:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA27528; Tue, 28 Nov 1995 21:14:58 -0500 Resent-Date: Tue, 28 Nov 1995 21:14:58 -0500 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-lqm-ds-00.txt Date: Mon, 27 Nov 95 10:36:40 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9511271036.aa18197@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"7aN33.0.tj6.U8ykm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/902 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Link Quality Monitoring Author(s) : W. Simpson Filename : draft-ietf-pppext-lqm-ds-00.txt Pages : 15 Date : 11/22/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. This document defines a protocol for generating Link-Quality-Reports. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-lqm-ds-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-lqm-ds-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-lqm-ds-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19951122180008.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-lqm-ds-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lqm-ds-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122180008.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Nov 28 21:14:11 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA27486; Tue, 28 Nov 1995 21:14:11 -0500 Resent-Date: Tue, 28 Nov 1995 21:14:11 -0500 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-chap-ds-00.txt Date: Mon, 27 Nov 95 10:36:33 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9511271036.aa18177@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"Ip6wj1.0.Cj6.l7ykm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/901 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Challenge Handshake Authentication Protocol (CHAP) Author(s) : W. Simpson Filename : draft-ietf-pppext-chap-ds-00.txt Pages : 14 Date : 11/22/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines a method for Authentication using PPP, which uses a random Challenge, with a cryptographically hashed Response which depends upon the Challenge and a secret key. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-chap-ds-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-chap-ds-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-chap-ds-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19951122175624.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-chap-ds-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-chap-ds-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951122175624.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 05:27:54 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id FAA09197; Wed, 29 Nov 1995 05:27:54 -0500 Resent-Date: Wed, 29 Nov 1995 05:27:54 -0500 From: meulenc@se.bel.alcatel.be Date: Wed, 29 Nov 1995 11:29:15 +0100 Message-Id: <199511291029.LAA27485@btmplq.god.bel.alcatel.be> To: fred@cisco.com Subject: Re: ATM on PPP Cc: ietf-ppp@MERIT.EDU X-Sun-Charset: US-ASCII Resent-Message-ID: <"8nnqW3.0.UF2.ZM3lm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/903 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU fred@cisco.com Mon Nov 27 19:04:59 1995 wrote: ->At 10:32 AM 11/24/95, meulenc@se.bel.alcatel.be wrote: ->>->That does pose a problem. Perhaps you could make a presentation on the ->>->subject at the Dallas IETF? I know very little about DAVIC; I have ->>->certainly heard of ATM :^) I can't be there at such a short notice. Sorry. ->>->The key question is: what protocol do these flows use? Yes, I'm certain ->>->that they package the bits in bursts of ATM cells when attached to an ATM ->>->network, but I seriously doubt that these are literally ATM encapsulated. Can you elaborate on that ? The Set-top will use the aggreed VC connections for each of the flows. So on the internal A0 interface, the ATM cells are made and ready to be presented to the core network, where they will be switched. ->>What do you exactly mean ? Actually, there are two choices : transport ->>a set of 4 different protocols (eg S2 on IP, S5 on IP (SNMP) or ISO ->>(CMIP), S4 or SSCOP and S3 on ??? (DSM-CC UN). The other solution is ->>to allow all these to be multiplexed already on ATM level in the STB, ->>which is a function already available. Then the other side of the ->>connection, let's call it the "ATM IWU" will only have to remap ->>VPI/VCI and send that to the ATM network. The first solution requires ->>a very high burden on the IWU as all protocols have to be understood, ->>as compared to only ATM. -> ->This "very high burden" is presumably small enough that you can put it in a ->TV-top device that you can either sell for what a consumer will pay for it, ->or install for "free," right? Absolutely right. But something you don't happen to see is the cost. DAVIC aims at the residential market, so the access network can not be composed of expensive devices. If you expect 10% of simultaneous usage, and you have 1 million installed boxes, I don't think the "Internet way" with routers and dial-up connections still flies. Now if you want to make it cheap, it's obvious you have to "delegate" the processing burden (e.g. ATM encapsulation of control messages) to the terminal itself. ->>Right, that's just my point. I want to use ATM as packets here, ATM is not ->>a layer 2 protocol. (It's part of 1, part of 2 and part of 3). Don't forget ->>ATM contains routing information is the header ! -> ->yes, VCI/VPI identification. It is as much a network layer protocol as is ->Ethernet, Frame Relay, X.25, SMDS, and IBM Bisync, all of which contain the ->address of a system or a virtual circuit in their header. All of which are ->generally considered to be "link layer networks" as opposed to generalized ->network layers. It goes further than that : ATM is based on connections, not on local addresses. If you look at Ethernet, you don't use the MAC address to route network-wide. Instead you use IP. So the real "inter" networking job is done by the router. Routing of ATM cells is something completely different, as, even if there is some VPI/VCI translation, there is NEVER an attempt made to interpret what's in the cell (even the AAL layer is conveyed end-to-end). ATM is connection-based, Internet is address (IP) based. These are really different things. ->All of them except, I suppose, X.25; in your part of the world it is ->considered a network layer. But let me point out to you that services like ->those offered on France's X.25 network are available to you on the ->internet, but you are not able to offer them to me on X.25. The reason, ->simply, is that X.25 never caught on in the US. So by positing your ->services on X.25, you have reduced your marketplace to a few countries. You are restricting yourself to the Internet ! I don't want to recreate that ! What should be the sense of a Video-on-Demand service on the net. Yes, there are technical tries, but it is not viable to transmit Gigabytes of video to everybody in the world for nothing ! (And even if some companies charge for services, the network usage itself _cannot_ be charged !) ->I submit that positing the services on ATM is to repeat the mistake. You ->can provide a service to a large part of the world if you use the ->architecture that is there and working, and you limit yourself when you try ->to make ATM "be" the network. This looks really like a fear of ATM to replace IP. We don't want to do that. That's the opposite : we are developing a network architecture based mainly on ATM and HFC/FTTC/ADSL access networks. Now we would like to add ISDN as a return channel low-level for adding the satellite of uni-directional CATV to the range of usable access networks. Later, we are going to provide Internet access on it, as a kind of option (a STU typically has no keyboard/mouse but a remote control with hardly 15 buttons). So I asked if it was possible to play it open and get an official PPP protocol number for the ATM cells we have to transmit instead of developing a system that may cause incompatibilities. It seems indeed more difficult than I thought, though at first sight, any network layer existing already got a number. So I guess we should use a "free" number of something in the specs, and restart it again after publication. Too bad. Regards. Christophe. ------------------------------------------------------------------------------ Statutory Disclaimer: The above is not necessarily an Alcatel position. ------------------------------------------------------------------------------ _ Christophe Vermeulen V System Engineer Third Party Products ------------------- Alcatel Bell Telephone SE275 | A L C A T E L | Fr. Wellesplein 1 - B-2018 Antwerp - Belgium ------------------- Phone: +32 3 240 8942 - Fax: +32 3 240 9920 Full Service Networks Email: meulenc@se.bel.alcatel.be Alcanet: BTMX.MEULENC ------------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 10:03:00 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA15659; Wed, 29 Nov 1995 10:03:00 -0500 Resent-Date: Wed, 29 Nov 1995 10:03:00 -0500 Date: Wed, 29 Nov 1995 08:01:53 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511291501.IAA02776@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: ATM on PPP Cc: meulenc@se.bel.alcatel.be Resent-Message-ID: <"7A2662.0.Rq3.UO7lm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/904 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: meulenc@se.bel.alcatel.be > ... > ->>->The key question is: what protocol do these flows use? Yes, I'm certain > ->>->that they package the bits in bursts of ATM cells when attached to an ATM > ->>->network, but I seriously doubt that these are literally ATM encapsulated. > Can you elaborate on that ? The Set-top will use the aggreed VC connections > for each of the flows. So on the internal A0 interface, the ATM cells are >made and ready to be presented to the core network, where they will be switched > ... > ... > Absolutely right. But something you don't happen to see is the cost. DAVIC > aims at the residential market, so the access network can not be composed of > expensive devices. ... I've heard a little about one of the major Video-On-Demand trials that is based on ATM. Cost is a concern. Yes, settops have remote controls instead of 116 key keyboards. Still, that trial involves IP packets, not just for the video, but for other things. Getting enough IP addresses and networks has been another concern. No one, including me, thought to consider adding PPP to the mix. Then there are the data-over-cable-TV people who use Ethernet-shaped packets through analogue cable modems in the head-end-to-residence direction, and in some cases vanilla PPP over telephone lines in the upstream direction. That they sometimes use PPP in one direction has little or no effect on their choices in the other direction. My point is that it is possible to use ATM to residences in might be called a "classic Internet" mode. I believe in the long run that such unimaginitive approaches will do far better than more creative tactics. V.34 modems are a case study of that process. I've spent a bunch of time fighting a relatively v.34 expensive modem that not only does the standard stuff, but a bunch of other stuff like "v.fc" and "v.32 terbo". It does not like to connect to other brands. Then I looked in the manual and discovered their proprietary modes are slower than v.34, and turning them off makes it work. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 10:40:44 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA17028; Wed, 29 Nov 1995 10:40:44 -0500 Resent-Date: Wed, 29 Nov 1995 10:40:44 -0500 Message-ID: <01BABE47.2661A980@ruiner> From: Brad Wilson To: "'meulenc@se.bel.alcatel.be'" Cc: "'ietf-ppp@merit.edu'" Subject: RE: ATM on PPP Date: Wed, 29 Nov 1995 10:40:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jbTsm3.0.r94.qx7lm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/905 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Absolutely right. But something you don't happen to see is the cost. The best thing I can suggest is to go get a protocol number from IANA, then document what you're doing in case anyone is interested. The need you've expressed seems too narrow for general usefulness, but there may be a handful of others interested. We have argued the technical merits of NOT doing it, but if the cost is too prohibitive, then you need to do what you need to do. Just PLEASE don't go "pick" a number and then don't tell anyone what you're doing with it. You may even get some useful advice from the others on the list. :-) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 11:04:28 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA17682; Wed, 29 Nov 1995 11:04:28 -0500 Resent-Date: Wed, 29 Nov 1995 11:04:28 -0500 From: meulenc@se.bel.alcatel.be Date: Wed, 29 Nov 1995 17:04:11 +0100 Message-Id: <199511291604.RAA16343@btmplq.god.bel.alcatel.be> To: bradw@netnet.net Subject: RE: ATM on PPP Cc: ietf-ppp@MERIT.EDU, iana@isi.edu X-Sun-Charset: US-ASCII Resent-Message-ID: <"8B7av3.0.iJ4.xG8lm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/906 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ->From bradw@exptech.com Wed Nov 29 16:31:23 1995 ->The best thing I can suggest is to go get a protocol number from ->IANA, But I never asked for anything else than that ! Asking for it, I was directed to this distribution list, and Fred, as the only person responding in length to my postings, was clearly against it. ->then document what you're doing in case anyone is interested. ->The need you've expressed seems too narrow for general usefulness, ->but there may be a handful of others interested. The DAVIC 1.0 specification will be released publicly short after the december meeting in Berlin. I'll put a copy of the official release note on this reflector as it is going to use PPP (probably with ATM and IP packets on it). ->We have argued the technical merits of NOT doing it, but if the cost ->is too prohibitive, then you need to do what you need to do. Just ->PLEASE don't go "pick" a number and then don't tell anyone what ->you're doing with it. You may even get some useful advice from the ->others on the list. :-) That's what I expected from the discussion. But I expected it to be a bit more constructive :-( So how to proceed ? I see two ways : -Or we get a provisional number that we can use in the Berlin meeting for ATM -Or (only if needed by iana) we issue a liason statement from DAVIC to iana after the meeting. IANA, can you reply to this mail ? Thanks in advance. Regards. Christophe. ------------------------------------------------------------------------------ _ Christophe Vermeulen V System Engineer Third Party Products ------------------- Alcatel Bell Telephone SE275 | A L C A T E L | Fr. Wellesplein 1 - B-2018 Antwerp - Belgium ------------------- Phone: +32 3 240 8942 - Fax: +32 3 240 9920 Full Service Networks Email: meulenc@se.bel.alcatel.be Alcanet: BTMX.MEULENC ------------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 11:13:19 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA18133; Wed, 29 Nov 1995 11:13:19 -0500 Resent-Date: Wed, 29 Nov 1995 11:13:19 -0500 From: meulenc@se.bel.alcatel.be Date: Wed, 29 Nov 1995 17:14:23 +0100 Message-Id: <199511291614.RAA16798@btmplq.god.bel.alcatel.be> To: ietf-ppp@MERIT.EDU, vjs@mica.denver.sgi.com Subject: Re: ATM on PPP X-Sun-Charset: US-ASCII Resent-Message-ID: <"0wrmR2.0.3R4.NQ8lm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/907 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ->From vjs@mica.denver.sgi.com Wed Nov 29 16:16:50 1995 -> ->I've heard a little about one of the major Video-On-Demand trials that ->is based on ATM. Cost is a concern. Yes, settops have remote controls ->instead of 116 key keyboards. Still, that trial involves IP packets, ->not just for the video, but for other things. IP for video, sure ??? We also use it for control flows, because it's available for free and you get lots of tools, you can debug on PCs and workstations, etc... ->Getting enough IP ->addresses and networks has been another concern. No one, including me, ->thought to consider adding PPP to the mix. Did you consider ATM-based trials with ISDN or PSTN for control and satellite MPEG-2 TS (DVB) for downstream video ? Only in that case we need PPP (or something else) ->Then there are the data-over-cable-TV people who use Ethernet-shaped ->packets through analogue cable modems in the head-end-to-residence ->direction, and in some cases vanilla PPP over telephone lines in the ->upstream direction. That they sometimes use PPP in one direction has ->little or no effect on their choices in the other direction. Yes, some people use whatever they want for trials, and I believe it is the way most trials are made. Actually, as long as you don't connect your trial to the Internet, you can do what you want, so the TCP/IP stack provides you with the shortest time to market by far. ->My point is that it is possible to use ATM to residences in might be ->called a "classic Internet" mode. I believe in the long run that such ->unimaginitive approaches will do far better than more creative ->tactics. OK for trials. But if you want to standardize that, and to provide Internet access to million people later on, you should act a bit more "cautiously" and "properly" (there must be better words in English, my meaning is "without messing up") [V.34 example deleted] ->Vernon Schryver, vjs@sgi.com Regards. Christophe. ------------------------------------------------------------------------------ _ Christophe Vermeulen V System Engineer Third Party Products ------------------- Alcatel Bell Telephone SE275 | A L C A T E L | Fr. Wellesplein 1 - B-2018 Antwerp - Belgium ------------------- Phone: +32 3 240 8942 - Fax: +32 3 240 9920 Full Service Networks Email: meulenc@se.bel.alcatel.be Alcanet: BTMX.MEULENC ------------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 12:27:34 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA20716; Wed, 29 Nov 1995 12:27:34 -0500 Resent-Date: Wed, 29 Nov 1995 12:27:34 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Nov 1995 09:22:23 -0800 To: Brad Wilson From: fred@cisco.com (Fred Baker) Subject: Protocol Number from IANA Cc: "'meulenc@se.bel.alcatel.be'" , "'ietf-ppp@merit.edu'" Resent-Message-ID: <"oe4of3.0.K35.XV9lm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/908 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 10:40 AM 11/29/95, Brad Wilson wrote: >The best thing I can suggest is to go get a protocol number from >IANA, then document what you're doing in case anyone is interested. That this is exactly what he did. IANA, as is their custom, queried me on the subject, and I have opened a discourse with him on the application. My answer was not "sure, give him a number", and that appears to be a source of frustration. I get such requests all the time. If discussion shows a reasonable use that is not likely to be publicly interesting, I signal IANA to give them a proprietary number. If there is any likely common ground with other vendors, I try to get the guy to contribute to the public domain. Sometimes I win, sometimes I don't. My objective is, simply, that everyone should win, that folks should be able to do what they need to do in the proprietary space and that things that several folks are doing come into the public domain so they will interoperate. I suppose that, if anything, is the reason I get ticked when people just pick a number. Besides guaranteeing that they or someone else get screwed in the future when IANA or that someone else happen to pick the same number, I really don't feel that the architectural guidance is a bad thing. Discussions with some vendors have seriously improved their implementation strategies, and I don't charge a thing. So when people don't even ask, as has happened in some areas, I feel like they have just selfishly thumbed their nose at the whole community. Bottom line, my definition of a "reasonable application" is one that, assuming I have the right software in my router and the application on a Mac or a Sun, would work in the simple but reasonably well connected network in my house. I connect a few ISDN subscribers (Cisco employees) via a frame relay link to Cisco in San Jose, and via that to the rest of you. Each of us has an Ethernet in his/her home, and Cisco does a good bit better than that. So it is a simple but representative network. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 12:34:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA21066; Wed, 29 Nov 1995 12:34:58 -0500 Resent-Date: Wed, 29 Nov 1995 12:34:58 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Nov 1995 09:31:24 -0800 To: meulenc@se.bel.alcatel.be From: fred@cisco.com (Fred Baker) Subject: Re: ATM on PPP Cc: ietf-ppp@MERIT.EDU, vjs@mica.denver.sgi.com Resent-Message-ID: <"_T7FU3.0.t85.uc9lm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/909 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 5:14 PM 11/29/95, meulenc@se.bel.alcatel.be wrote: >->Getting enough IP >->addresses and networks has been another concern. No one, including me, >->thought to consider adding PPP to the mix. >Did you consider ATM-based trials with ISDN or PSTN for control and >satellite MPEG-2 TS (DVB) for downstream video ? Only in that case >we need PPP (or something else) ATM would be the H.310 approach, and ISDN would be the H.320 approach; using IP would be the H.323 approach, which is being developed in concert between some IETF working groups and ITU Study Group 15. I suspect that Vernon chose IP because the network connections pretty much exist in his equipment as a given and software exists to implement the approach. Anything else is a lot more effort. Close, Vernon? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 12:59:20 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA22034; Wed, 29 Nov 1995 12:59:20 -0500 Resent-Date: Wed, 29 Nov 1995 12:59:20 -0500 Date: Wed, 29 Nov 95 12:51:34 EST Message-Id: <9511291751.AA15286@mailserv-D.ftp.com> To: ietf-ppp@MERIT.EDU Subject: re Protocol Number from IANA From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Wed Nov 29 12:51:29 1995] Originating-Client: d-cell.ftp.com Content-Length: 2245 Resent-Message-ID: <"va8Dz.0.QM5.wv9lm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/910 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Fred, Well said. I concur with what you say completely... Frank Kastenholz Co-Internet-Area-Director Fred Baker writes.... > At 10:40 AM 11/29/95, Brad Wilson wrote: > >The best thing I can suggest is to go get a protocol number from > >IANA, then document what you're doing in case anyone is interested. > > That this is exactly what he did. IANA, as is their custom, queried me on > the subject, and I have opened a discourse with him on the application. My > answer was not "sure, give him a number", and that appears to be a source > of frustration. > > I get such requests all the time. If discussion shows a reasonable use that > is not likely to be publicly interesting, I signal IANA to give them a > proprietary number. If there is any likely common ground with other > vendors, I try to get the guy to contribute to the public domain. Sometimes > I win, sometimes I don't. My objective is, simply, that everyone should > win, that folks should be able to do what they need to do in the > proprietary space and that things that several folks are doing come into > the public domain so they will interoperate. > > I suppose that, if anything, is the reason I get ticked when people just > pick a number. Besides guaranteeing that they or someone else get screwed > in the future when IANA or that someone else happen to pick the same > number, I really don't feel that the architectural guidance is a bad thing. > Discussions with some vendors have seriously improved their implementation > strategies, and I don't charge a thing. So when people don't even ask, as > has happened in some areas, I feel like they have just selfishly thumbed > their nose at the whole community. > > > Bottom line, my definition of a "reasonable application" is one that, > assuming I have the right software in my router and the application on a > Mac or a Sun, would work in the simple but reasonably well connected > network in my house. I connect a few ISDN subscribers (Cisco employees) via > a frame relay link to Cisco in San Jose, and via that to the rest of you. > Each of us has an Ethernet in his/her home, and Cisco does a good bit > better than that. So it is a simple but representative network. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 14:13:59 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA24739; Wed, 29 Nov 1995 14:13:59 -0500 Resent-Date: Wed, 29 Nov 1995 14:13:59 -0500 Date: Wed, 29 Nov 1995 12:12:21 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199511291912.MAA03737@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: ATM on PPP Cc: meulenc@se.bel.alcatel.be Resent-Message-ID: <"4Yebo1.0.526.W3Blm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/911 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: fred@cisco.com (Fred Baker) > >->Getting enough IP > >->addresses and networks has been another concern. No one, including me, > >->thought to consider adding PPP to the mix. > >Did you consider ATM-based trials with ISDN or PSTN for control and > >satellite MPEG-2 TS (DVB) for downstream video ? Only in that case > >we need PPP (or something else) The trial I've heard of involves ATM to the consumer, with UNIX boxes serving the video. MPEG-2, of course. DVB statelite downstream and PPP upstream via phones sounds quite different. The latency for the remote control sounds problematic, unless you have a very large buffer in the settop. When the user presses "freeze frame", you don't want to delay for 500 ms. How one would have a zillion different streams from the satellite, one per consumer, is beyond my ken. If I were doing such a thing, I would use PPP for the upstream link, and UDP/IP. I would not roll my own link-layer protocol for moving the control info. By using vanilla IP/PPP, I wouldn't care if ISDN failed and ASDL takes over, if ATM-to-the-curb appears, the PTT's get a different wild hare (e.g. the obsession U.S.Worst has with Frame Relay)or something else happens. I also could use any of a zillion off-the-shelf ways to link my servers, controllers and so forth on the far end of that PPP link, including FDDI, Ethernet, 802.5, and HIPPI. If the upstream control is only what is now down with C-band and DSS pay-per-view (just charging and authentication), then I don't see the point. In that case, I would use TCP/IP/PPP/2400 bit/sec modem. No, make that 110 bit/sec FSK, something that will work though wet string anywhere. I've doubts about the market for that. There are a couple dozen C-band transponders dedicated to PPV, but I've never seen anything in their listings that I could justify spending the time to hook the RJ-11 on the receiver to the phone jack 3 feet away. > ATM would be the H.310 approach, and ISDN would be the H.320 approach; > using IP would be the H.323 approach, which is being developed in concert > between some IETF working groups and ITU Study Group 15. > > I suspect that Vernon chose IP because the network connections pretty much > exist in his equipment as a given and software exists to implement the > approach. Anything else is a lot more effort. Close, Vernon? I didn't do any choosing. I was just an interested observer. If they had asked about PPP, I would have expressed opposition or befuddlement. I think there are several reasons they chose IP/ATM. One is that we've the IP religion. Another is that once you have IP, you can do many things, such as - use lots of buffering (i.e. more than one field) for de-jittering, which makes a lot of stuff easier. - use NTP to get the video timing, which makes a lot of stuff easier - use UDP/IP or TCP/IP to send games or other software to the settop - surf the net You might summarize all of that as Fred does, but I think it glosses some important facts. I also agree with the choice made by the SGI video conferencing people, H.something/IP. (I thought it was H.2xx, but I'm probably wrong). There are a lot of things you can with IP packets, and if you don't have religious problems with using IP (e.g. irrational phobias about complexity), it's cheap and easy. I think the raw-video-over-phones people are mistaken, that they're still thinking about networks as if they were still built out of relays and copper. Oh, well. Time will tell. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 15:06:19 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA26614; Wed, 29 Nov 1995 15:06:19 -0500 Resent-Date: Wed, 29 Nov 1995 15:06:19 -0500 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Nov 1995 12:05:17 -0800 To: vjs@mica.denver.sgi.com (Vernon Schryver) From: fred@cisco.com (Fred Baker) Subject: Re: ATM on PPP Cc: ietf-ppp@MERIT.EDU, meulenc@se.bel.alcatel.be Resent-Message-ID: <"lXXBh1.0.aV6.WqBlm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/912 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 12:12 PM 11/29/95, Vernon Schryver wrote: >I also agree with the choice made by the SGI video conferencing people, >H.something/IP. (I thought it was H.2xx, but I'm probably wrong). you're probably thinking H.261, which is an ISDN-oriented encoding which H.320 or H.323 carry. Yes, ITU numbers can be as numerous and confusing as RFC numbers... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Nov 29 18:23:14 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA02742; Wed, 29 Nov 1995 18:23:14 -0500 Resent-Date: Wed, 29 Nov 1995 18:23:14 -0500 X-Sender: Shawn.Richmond@nic.aaic-inc.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Nov 1995 16:22:20 -0700 To: Archive.IETF@nic.aaic-inc.com From: Shawn.Richmond@aaic-inc.com (Shawn Richmond) Subject: I-D ACTION:draft-ietf-pppext-ipcp-network-00.txt Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"7a-Oo3.0.dg.PjElm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/913 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The PPP Internet Protocol Control Protocol (IPCP) Author(s) : G. McGregor, G. Pall Filename : draft-ietf-pppext-ipcp-network-00.txt Pages : 13 Date : 10/31/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring the Internet Protocol [2] over PPP, and a method to negotiate and use Van Jacobson TCP/IP header compression [3] with PPP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-ipcp-network-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-ipcp-network-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) 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-ipcp-network-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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. Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19951031091203.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-ipcp-network-00.txt Content-Type: Message/External-body; name="draft-ietf-pppext-ipcp-network-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19951031091203.I-D@CNRI.Reston.VA.US> - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 30 06:59:18 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id GAA23907; Thu, 30 Nov 1995 06:59:18 -0500 Resent-Date: Thu, 30 Nov 1995 06:59:18 -0500 From: meulenc@se.bel.alcatel.be Date: Thu, 30 Nov 1995 12:58:13 +0100 Message-Id: <199511301158.MAA17733@btmplq.god.bel.alcatel.be> To: bradw@netnet.net, fred@cisco.com Subject: Re: Protocol Number from IANA Cc: meulenc@se.bel.alcatel.be, ietf-ppp@MERIT.EDU X-Sun-Charset: US-ASCII Resent-Message-ID: <"6zvb-1.0.Fr5.3oPlm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/914 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ->From fred@cisco.com Wed Nov 29 18:13:24 1995 -> ->At 10:40 AM 11/29/95, Brad Wilson wrote: ->>The best thing I can suggest is to go get a protocol number from ->>IANA, then document what you're doing in case anyone is interested. ->That this is exactly what he did. IANA, as is their custom, queried me on ->the subject, and I have opened a discourse with him on the application. My ->answer was not "sure, give him a number", and that appears to be a source ->of frustration. Let's say I expected it more straightforward, as there are a lot of numbers for almost any kind of protocol. I noted your strong disaggreement about that, and perhaps I misinterpreted the reason behind it. The fact we are looking at other types of applications than LAN interconnection also played a role. Of course, you _may_ look at ATM as "just another way of transporting packets between LANs". In DAVIC's view, there is a difference : ATM will be used for the deployment of Broadband ISDN, meaning not _large_ scale, but _huge_ scale. Of course, you may disaggree with this rather telco-oriented view, but at least recognize it's not the view of an individual, or a company. It's the view of an industry that serves an audience larger than the computer community (telephone users). ->I get such requests all the time. If discussion shows a reasonable use that ->is not likely to be publicly interesting, I signal IANA to give them a ->proprietary number. If there is any likely common ground with other ->vendors, I try to get the guy to contribute to the public domain. But we are doing nothing else ! This work has nothing to do with a proprietary project of any kind, but with DAVIC ! The specification is going to be released shortly. ->Sometimes ->I win, sometimes I don't. My objective is, simply, that everyone should ->win, that folks should be able to do what they need to do in the ->proprietary space and that things that several folks are doing come into ->the public domain so they will interoperate. In that respect, I think a public number makes more sense, but the decision is yours. ->I suppose that, if anything, is the reason I get ticked when people just ->pick a number. Besides guaranteeing that they or someone else get screwed ->in the future when IANA or that someone else happen to pick the same ->number, I really don't feel that the architectural guidance is a bad thing. ->Discussions with some vendors have seriously improved their implementation ->strategies, and I don't charge a thing. So when people don't even ask, as ->has happened in some areas, I feel like they have just selfishly thumbed ->their nose at the whole community. Right. That's why I _first_ asked you how to follow the rules, before doing anything else ->Bottom line, my definition of a "reasonable application" is one that, ->assuming I have the right software in my router and the application on a ->Mac or a Sun, would work in the simple but reasonably well connected ->network in my house. I connect a few ISDN subscribers (Cisco employees) via ->a frame relay link to Cisco in San Jose, and via that to the rest of you. ->Each of us has an Ethernet in his/her home, and Cisco does a good bit ->better than that. So it is a simple but representative network. I'm afraid it's a representative IP network (or IPx, or Appletalk, ...). But that's not what we aim at. If the main traffic is Real-time Video at 2-4 Mbps, it won't work the same way (eg. latency issues). We want to build a network for Interactive residential services, by using an ATM core network and a variety of access network technologies. If we want to add a satellite distribution channel and ISDN/PSTN return to our portfolio (where ATM end-to-end is present in most cases), we should think of a way of transporting the ATM cells on PSTN. I'm not sure you are thinking of this kind of architecture when you talk of routers, Macs and Suns. Using PPP and assigned numbers is for us a way of - not deciding something without contacts with other standard bodies - allowing to add later connectivity for computers of the same infrastructure (not specified in DAVIC 1.0, but asked for future versions) Regards. Christophe. ------------------------------------------------------------------------------ _ Christophe Vermeulen V System Engineer Third Party Products ------------------- Alcatel Bell Telephone SE275 | A L C A T E L | Fr. Wellesplein 1 - B-2018 Antwerp - Belgium ------------------- Phone: +32 3 240 8942 - Fax: +32 3 240 9920 Full Service Networks Email: meulenc@se.bel.alcatel.be Alcanet: BTMX.MEULENC ------------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 30 07:32:46 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id HAA24943; Thu, 30 Nov 1995 07:32:46 -0500 Resent-Date: Thu, 30 Nov 1995 07:32:46 -0500 Date: Thu, 30 Nov 95 11:30:58 GMT From: "William Allen Simpson" Message-ID: <4598.bsimpson@morningstar.com> To: ietf-ppp@MERIT.EDU Cc: iana@isi.edu Subject: Re: Protocol Number from IANA Resent-Message-ID: <"k1-_M.0.S56.dHQlm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/915 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: kasten@ftp.com (Frank Kastenholz) > Fred Baker writes.... > > I get such requests all the time. If discussion shows a reasonable use that > > is not likely to be publicly interesting, I signal IANA to give them a > > proprietary number. If there is any likely common ground with other > > vendors, I try to get the guy to contribute to the public domain. > Well said. > I concur with what you say completely... > > Frank Kastenholz > Co-Internet-Area-Director > I also agree, with the following reminder/caveat: We have a _huge_ proprietary number space. There is no reason not to pass those out with near impunity. We have a very small and constrained public space (odd numbers 33-253). Vendors _absolutely_ cannot be assigned these numbers for proprietary protocols under any circumstances! There are a few such assigned numbers for which I don't see Internet Standards Track RFCs, or even internet-drafts. Unless they are published and soon, we should officially take these numbers away again, and reassign them in the proprietary space! 0041 Cisco Systems 0043 Ascom Timeplex 0045 Fujitsu Link Backup and Load Balancing (LBLB) 0047 DCA Remote Lan 004b SNA over 802.2 004d SNA 006f Stampede Bridging Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 30 07:37:50 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id HAA25055; Thu, 30 Nov 1995 07:37:50 -0500 Resent-Date: Thu, 30 Nov 1995 07:37:50 -0500 Date: Thu, 30 Nov 95 11:52:45 GMT From: "William Allen Simpson" Message-ID: <4599.bsimpson@morningstar.com> To: meulenc@se.bel.alcatel.be Cc: ietf-ppp@MERIT.EDU, iana@isi.edu Subject: Re: ATM on PPP Resent-Message-ID: <"tf-xJ.0.C76.PMQlm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/916 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: meulenc@se.bel.alcatel.be > ->From bradw@exptech.com Wed Nov 29 16:31:23 1995 > > ->The best thing I can suggest is to go get a protocol number from > ->IANA, > But I never asked for anything else than that ! > Asking for it, I was directed to this distribution list, and Fred, as the only > person responding in length to my postings, was clearly against it. > ... > ->The need you've expressed seems too narrow for general usefulness, > ->but there may be a handful of others interested. > The DAVIC 1.0 specification will be released publicly short after the december > meeting in Berlin. I'll put a copy of the official release note on this > reflector as it is going to use PPP (probably with ATM and IP packets on it). > Sorry, I've been on the road, and am quite behind on my list reading. If you need a number for demo purposes, IANA should quickly assign one in the 2021 series that you could have forever.... I thought that Fred was doing a fine job in responding, but let me add myself to the list of folks "against". ATM and HLDC are different methods of link framing, and encapsulating one inside the other makes no sense to me. "Mutual encapsulation considered harmful." But we do have IEEE 802 Bridging all kinds of other links inside PPP, so it's not the first time. And Fred was the progenitor of that use.... Better to do the network (layer 3) protocol processing in the set-top devices. There's just no practical reason not to do it. After all, I did a complete TCP/IP/PPP stack inside a cellular phone last year in under 30K of code. Very cheap! Vastly simpler than the cellular phone signalling protocols! Bill.Simpson@um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 30 07:56:04 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id HAA25594; Thu, 30 Nov 1995 07:56:04 -0500 Resent-Date: Thu, 30 Nov 1995 07:56:04 -0500 From: meulenc@se.bel.alcatel.be Date: Thu, 30 Nov 1995 13:57:14 +0100 Message-Id: <199511301257.NAA20939@btmplq.god.bel.alcatel.be> To: bsimpson@morningstar.com Subject: Re: ATM on PPP Cc: ietf-ppp@MERIT.EDU, iana@isi.edu X-Sun-Charset: US-ASCII Resent-Message-ID: <"CJuG53.0.hF6.SdQlm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/917 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ->From bsimpson@morningstar.com Thu Nov 30 13:24:45 1995 ->If you need a number for demo purposes, IANA should quickly assign one ->in the 2021 series that you could have forever.... That would indeed solve the issue... -> ->I thought that Fred was doing a fine job in responding, but let me add ->myself to the list of folks "against". Noted. ->ATM and HLDC are different methods of link framing, and encapsulating ->one inside the other makes no sense to me. "Mutual encapsulation ->considered harmful." Sorry, I (again) disaggree. HDLC is indeed a link framing, while ATM may be a link/subnetwork framing (case of IP/ATM, E1/AAL1/ATM, ???/ATM) or an end-to-end network protocol between terminals (the case we consider). The point is that with link/subnetwork framing, you terminate the ATM layer somewhere in the network (eg. router), look at what's inside (eg. IP), and transfer that to another (ATM or other) part of the network. In the second case, you generate ATM in a ATM device (server or STB), and it goes on the way to the other terminal without ever opening/reassembling the cells. That's what allowed ATM to be called a "fast packet switching" network in its infancy. So, no time lost in protocol conversion at any place in the network (as it may carry real-time voice from NY to Sydney). ->But we do have IEEE 802 Bridging all kinds of other links inside PPP, so ->it's not the first time. And Fred was the progenitor of that use.... -> ->Better to do the network (layer 3) protocol processing in the set-top ->devices. There's just no practical reason not to do it. Right. That's the reason we don't want to interfere with the cell payload. ->After all, I did a complete TCP/IP/PPP stack inside a cellular phone ->last year in under 30K of code. Very cheap! Vastly simpler than the ->cellular phone signalling protocols! Interesting. Did you need to use assembler ? But still a remark I can't hold : with the same security guaranteed ? ->Bill.Simpson@um.cc.umich.edu -> Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 -> - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Nov 30 16:46:35 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA16105; Thu, 30 Nov 1995 16:46:35 -0500 Resent-Date: Thu, 30 Nov 1995 16:46:35 -0500 Message-Id: <199511302145.QAA16054@merit.edu> Date: Thu, 30 Nov 95 16:10:24 EST From: "Andrew M. Fuqua" To: ietf-ppp@MERIT.EDU cc: fred@cisco.com, bsimpson@morningstar.com, clogsdon@cisco.com, mgaubrey@VNET.IBM.COM Subject: SNA over PPP isn't proprietary! Resent-Message-ID: <"LSzBU1.0.zw3.LOYlm"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/918 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >From: "William Allen Simpson" > > We have a very small and constrained public space (odd numbers 33-253). > Vendors _absolutely_ cannot be assigned these numbers for proprietary > protocols under any circumstances! > > There are a few such assigned numbers for which I don't see Internet > Standards Track RFCs, or even internet-drafts. Unless they are > published and soon, we should officially take these numbers away again, > and reassign them in the proprietary space! > > 0041 Cisco Systems > 0043 Ascom Timeplex > 0045 Fujitsu Link Backup and Load Balancing (LBLB) > 0047 DCA Remote Lan > 004b SNA over 802.2 > 004d SNA > 006f Stampede Bridging SNA over 802.2 and SNA aren't proprietary protocols (they are also known as APPN HPR and ISR). I know that at least 3Com and Cisco are working on APPN. I am sure companies other than IBM have implemented or are implementing APPN (HPR and ISR) over PPP. IBM has already shipped code that uses these numbers. We (IBM) didn't bother creating a draft when we requested these numbers because: - there are no options to negotiate - the method in which such traffic is transmitted over ppp is straightforward - and I didn't think a separate published RFC was necessary to reserve these numbers for everyone's use forever. I have never created a draft RFC before but I'd be glad to give it a shot if that is what is required to reserve 004b and 004d for APPN. If that is what is required, please contact me before reclaiming these numbers! Until then I'll assume these numbers are save. THANKS, Andrew Fuqua IBM Networking Systems - - - - - - - - - - - - - - - - -