From owner-ietf-ppp-outgoing@merit.edu Thu Mar 2 17:29:16 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29902 for ; Thu, 2 Mar 2000 17:29:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA5505DE1C; Thu, 2 Mar 2000 17:28:44 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9A4585DE1F; Thu, 2 Mar 2000 17:28:44 -0500 (EST) Received: from blue.cosinecom.com (proxy4.cosinecom.com [208.248.148.132]) by segue.merit.edu (Postfix) with ESMTP id B5FDC5DE1C for ; Thu, 2 Mar 2000 17:28:42 -0500 (EST) Received: from cosinecom.com by blue.cosinecom.com (8.8.8+Sun/SMI-SVR4) id OAA15383; Thu, 2 Mar 2000 14:28:24 -0800 (PST) Message-ID: <38BEEB35.8678AA0@cosinecom.com> Date: Thu, 02 Mar 2000 14:29:09 -0800 From: Srinivasan Chakravarthy Organization: CoSine Communications Inc. X-Mailer: Mozilla 4.06 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: PPP over FR. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi, I am implementing PPP over FR as per RFC 1973. Could you pls let me know if the address (0xFF) and control (0x03) fields should be sent with the ppp packets (both control and data) when sent over a FR DLCI (assuming Address and Control field compression is NOT negotiated during LCP)? Thanks & Regards, Srinivasan. From owner-ietf-ppp-outgoing@merit.edu Fri Mar 3 07:05:06 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23521 for ; Fri, 3 Mar 2000 07:05:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 40EF25DD9B; Fri, 3 Mar 2000 07:04:42 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2D8395DDA6; Fri, 3 Mar 2000 07:04:42 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 5C0F95DD9B for ; Fri, 3 Mar 2000 07:04:40 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id HAA28804 for ietf-ppp@merit.edu; Fri, 3 Mar 2000 07:04:39 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: PPP over FR. Date: 03 Mar 2000 07:04:38 -0500 Organization: IronBridge Networks Lines: 29 Message-ID: <86r9dsqmy1.fsf@ironbridgenetworks.com> References: <38BEEB35.8678AA0@cosinecom.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu cs@cosinecom.com (Srinivasan Chakravarthy) writes: > I am implementing PPP over FR as per RFC 1973. Could you pls let me know if the > address (0xFF) and control (0x03) fields should be sent with the ppp packets > (both control and data) when sent over a FR DLCI (assuming Address and Control > field compression is NOT negotiated during LCP)? The address and control fields are part of the HDLC header and not part of PPP. Accordingly, when PPP is run over FR, the HDLC address field is used as the DLCI, the control field is used according to the FR specs, the PPP NLPID (hex CF) follows that, and then PPP Protocol ID field and Information (payload) field follow. The diagram on page 2 of RFC 1973 shows this. You MUST NOT negotiate ACFC when running over FR. You MUST NOT include an extra address and control field. Section 3.2 of RFC 1973 describes this. (All this having been said, I've seen a number of buggy PPP implementations. For instance, the AO/DI folks run duplicate address and control fields over X.25, which is rather similar to FR, in violation of RFC 1598. You'll likely need to do a fair bit of interoperability testing and may need compatibility modes. Your mileage will vary.) -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Mar 3 09:24:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28021 for ; Fri, 3 Mar 2000 09:24:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA69F5DDA6; Fri, 3 Mar 2000 09:24:01 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D6D3D5DD9E; Fri, 3 Mar 2000 09:24:01 -0500 (EST) Received: from luna.host4u.net (luna.host4u.net [216.71.64.45]) by segue.merit.edu (Postfix) with ESMTP id 5F4325DD90 for ; Fri, 3 Mar 2000 09:24:00 -0500 (EST) Received: from toy (jgateadsl.cais.net [205.252.5.196]) by luna.host4u.net (8.8.5/8.8.5) with ESMTP id IAA17455; Fri, 3 Mar 2000 08:23:56 -0600 Message-Id: <4.2.2.20000303092056.00b14bb0@mail.labn.net> X-Sender: lberger@mail.labn.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 03 Mar 2000 09:23:57 -0500 To: ietf-ppp@merit.edu From: Lou Berger Subject: Fwd: I-D ACTION:draft-berger-mpls-hdr-comp-00.txt Cc: lberger@labn.net, Jason Jeffords Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu FYI - The rfc2509 equivalent companion document should be announce in a day or so and is available at http://www.labn.net/docs/draft-berger-mpls-hdr-comp-over-ppp-00.txt in the interim. We expect/hope to present this in Adelaide in the AVT and MPLS WGs. Lou >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-berger-mpls-hdr-comp-00.txt >Date: Wed, 19 Jan 2000 06:57:36 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : MPLS/IP Header Compression > Author(s) : L. Berger, J. Jeffords > Filename : draft-berger-mpls-hdr-comp-00.txt > Pages : 14 > Date : 14-Jan-00 > >This document describes a method for compressing the headers of IP >datagrams that are being transported over MPLS. This work extends >the existing IP and IP/UDP/RTP header compression techniques, as >defined in [RFC2507] and [RFC2508], to operate over and to compress >MPLS label stack entries. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-berger-mpls-hdr-comp-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-berger-mpls-hdr-comp-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-berger-mpls-hdr-comp-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000114083955.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-berger-mpls-hdr-comp-00.txt > > From owner-ietf-ppp-outgoing@merit.edu Mon Mar 6 06:58:33 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02583 for ; Mon, 6 Mar 2000 06:58:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id B46735DD90; Mon, 6 Mar 2000 06:57:58 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A40B25DD97; Mon, 6 Mar 2000 06:57:58 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id E5D545DD90 for ; Mon, 6 Mar 2000 06:57:56 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02550; Mon, 6 Mar 2000 06:57:55 -0500 (EST) Message-Id: <200003061157.GAA02550@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-aodi-02.txt Date: Mon, 06 Mar 2000 06:57:54 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Always On Dynamic ISDN (AODI). Author(s) : M. Holdrege Filename : draft-ietf-pppext-aodi-02.txt Pages : 15 Date : 03-Mar-00 Always On/Dynamic ISDN (AO/DI) is a networking service that provides an always-available connection to TCP/IP-based services through a specific wide area connection. This service provides several advantages over current practices for dial-up access to Internet services. * For the end-user, there is no need to dial-up the service each time access is desired. * For the Internet service provider, it is possible to give the end-user a notification, such as the arrival of new mail. * For the Local Exchange Carrier, the switched circuit trunk utilization is more efficient. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-aodi-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-aodi-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-aodi-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000303144505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-aodi-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-aodi-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000303144505.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Tue Mar 7 14:10:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07824 for ; Tue, 7 Mar 2000 14:10:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 15B6B5DDCF; Tue, 7 Mar 2000 14:09:42 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F39EE5DDC4; Tue, 7 Mar 2000 14:09:41 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 309705DDB2 for ; Tue, 7 Mar 2000 14:09:40 -0500 (EST) Received: (from carlson@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id OAA28386; Tue, 7 Mar 2000 14:09:18 -0500 (EST) Date: Tue, 7 Mar 2000 14:09:18 -0500 (EST) Message-Id: <200003071909.OAA28386@ironbridgenetworks.com> X-Authentication-Warning: helios.helios: carlson set sender to carlson@ironbridgenetworks.com using -f From: James Carlson To: jeremy.de_clercq@alcatel.be, peter.de_schrijver@alcatel.be, carmelo.zaccone@alcatel.be, yves.tjoens@alcatel.be Cc: pppext Subject: draft-declercq-ppp-ds-sla-negotiation-00.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I noticed your recent Internet Draft contribution, and I have a few comments. First one overall comment: shouldn't this be submitted to the PPP Extensions working group? On to the draft: > 3.1 Summary of Operation [...] > The basic operation will be that a PPP peer that requires negotiation > about a SLS will send an IPCP CONFREQ including a list of SLS > options. Every SLS Option will contain a certain service the peer > wants to have access to. The receiving PPP peer will analyse all the > included options. After parsing an SLS Option, the receiving PPP > peer can make the following decisions: This style would appear to be counter to the normal semantics for PPP option negotiation. The usual way this works is that the Configure-Request sender indicates what options it would like the peer to adopt when sending data in the other direction. In mapping this to the SLS option, I would expect that the system supporting multiple service levels would *offer* those services to the peer by way of Configure-Request. The peer would then Configure-Nak or Configure-Reject the services it doesn't want and finally Configure-Ack the set of services it does want. (All of that assumes that negotiating this information within IPCP is the right way to go. I don't think it is.) > Cancelling a specific Service > > To cancel a specific service, the 'client' can send an IPCP > CONFREQ message containing an appropriate IPCP SLS Option. The > SLS Option Data field of that appropriate SLS Option must contain > only the Service ID Parameter, and may not contain the other > mandatory and optional Service Parameters. > > If a provider receives an IPCP CONFREQ message containing an SLS > Option with a Data field containing only the Service ID Parameter, > this provider must cancel the service identified by the considered > Service ID. > > Altering a specific Service > > To alter a specific existing service, the 'client' can send an > IPCP CONFREQ message containing an appropriate IPCP SLS Option. > The SLS Option Data field of that SLS Option must contain the > according Service ID Parameter and all the requested Service > Parameters (the changed Service Parameters and the unchanged > Service Parameters). > I don't think that either of these works the manner intended. Sending IPCP Configure-Request will cause the peer's state machine to leave Opened state and revert to either Req-Sent (RCR-) or Ack-Sent (RCR+). Either way, IP traffic will abruptly halt and data will (most likely) be lost at this point and (depending on the implementations used) routing will be disturbed with a link flap. I think it's more appropriate and more general to consider an IP-based protocol to negotiate these profiles (not IPCP; along the same lines as the way multicast groups are handled with IGMP or int-serv flows are handled with RSVP). Alternatively, it might be possible to do this negotiation with a new NCP for PPP, although I think that's certainly less desirable than a higher layer signaling solution. > 4. Security Considerations > > No security considerations outside these described in [IPCP] are > foreseen. I think the granting of access to higher levels of service (above standard DSCP==0 "best effort") probably has security implications above those for basic IPCP. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Mar 7 14:54:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21119 for ; Tue, 7 Mar 2000 14:54:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A7D75DD91; Tue, 7 Mar 2000 14:54:10 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 24E1C5DDA4; Tue, 7 Mar 2000 14:54:10 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id B9AB55DD91 for ; Tue, 7 Mar 2000 14:54:07 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id MAA22966 env-from ; Tue, 7 Mar 2000 12:54:00 -0700 (MST) Date: Tue, 7 Mar 2000 12:54:00 -0700 (MST) From: Vernon Schryver Message-Id: <200003071954.MAA22966@calcite.rhyolite.com> To: carmelo.zaccone@alcatel.be, jeremy.de_clercq@alcatel.be, peter.de_schrijver@alcatel.be, yves.tjoens@alcatel.be Subject: Re: draft-declercq-ppp-ds-sla-negotiation-00.txt Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > To: jeremy.de_clercq@alcatel.be, peter.de_schrijver@alcatel.be, > carmelo.zaccone@alcatel.be, yves.tjoens@alcatel.be > Cc: pppext > I noticed your recent Internet Draft contribution, and I have a few > comments. First one overall comment: shouldn't this be submitted to > the PPP Extensions working group? Oh, I thought it was. It clearly is in the PPP Extensions turf. I hope the authors have subscribed or will subscribe to the PPP mailing list at ietf-ppp-request@Merit.edu See also http://www.ietf.org/html.charters/pppext-charter.html > ... > > Altering a specific Service > > > > To alter a specific existing service, the 'client' can send an > > IPCP CONFREQ message containing an appropriate IPCP SLS Option. > > The SLS Option Data field of that SLS Option must contain the > > according Service ID Parameter and all the requested Service > > Parameters (the changed Service Parameters and the unchanged > > Service Parameters). > > I don't think that either of these works the manner intended. Sending > IPCP Configure-Request will cause the peer's state machine to leave > Opened state and revert to either Req-Sent (RCR-) or Ack-Sent (RCR+). > Either way, IP traffic will abruptly halt and data will (most likely) > be lost at this point and (depending on the implementations used) > routing will be disturbed with a link flap. I understood the authors to mean that the IPCP state machine should fall down and re-negotiate from scratch. If that's not what they meant, then it obviously can't work. The text should be changed to make clear that IPCP will shut down at least momentarily. I think no reasonable PPP implementation would lose any IP packets due to such a hiccup, but I also realize that most deployed implementations are unreasonable by that standard. > I think it's more appropriate and more general to consider an IP-based > protocol to negotiate these profiles (not IPCP; along the same lines > as the way multicast groups are handled with IGMP or int-serv flows > are handled with RSVP). Alternatively, it might be possible to do > this negotiation with a new NCP for PPP, although I think that's > certainly less desirable than a higher layer signaling solution. I half disagree. I think a new NCP to negotiate what is clearly an aspect of IP would be wrong. If you do it in PPP, it belongs in IPCP. I agree that PPP is the wrong place to do this negotiating, unless you assume that IP with such modified/negotiated Diff-Serv parameters will never be run except over PPP, and that's certainly false. There should be a single mechanism for all such negotiating, and it should work and work as much the same as possible over all media that carry IP packets. That suggests it should use some kind of IP packets, from existing RSVP tactics to new UDP, ICMP, or even SNMP schemes. > > 4. Security Considerations > > > > No security considerations outside these described in [IPCP] are > > foreseen. > > I think the granting of access to higher levels of service (above > standard DSCP==0 "best effort") probably has security implications > above those for basic IPCP. That's a good, if understated point. At the very least, such a document must contain a proof (in the professional mathematican's sense of an arguement that convinces someone with mathematical maturity) that no illicit fun and games are possible with such an IPCP option. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue Mar 7 15:48:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08942 for ; Tue, 7 Mar 2000 15:48:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id A43995DDDF; Tue, 7 Mar 2000 15:45:21 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8BC3F5DDC4; Tue, 7 Mar 2000 15:45:21 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 68B6F5DDD7 for ; Tue, 7 Mar 2000 15:45:19 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id PAA11747 for ietf-ppp@merit.edu; Tue, 7 Mar 2000 15:45:18 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: draft-declercq-ppp-ds-sla-negotiation-00.txt Date: 07 Mar 2000 15:45:18 -0500 Organization: IronBridge Networks Lines: 43 Message-ID: <86n1oah5lt.fsf@ironbridgenetworks.com> References: <200003071954.MAA22966@calcite.rhyolite.com> NNTP-Posting-Host: helios.ibnets.com To: carmelo.zaccone@alcatel.be, jeremy.de_clercq@alcatel.be, peter.de_schrijver@alcatel.be, yves.tjoens@alcatel.be X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu vjs@calcite.rhyolite.com (Vernon Schryver) writes: > I think no reasonable PPP implementation would lose any IP packets > due to such a hiccup, but I also realize that most deployed > implementations are unreasonable by that standard. The likely effect on routing protocols is even more interesting, I think. A good implementation should probably have a debouncing function between IPCP states and OSPF LSA origination, but ... > > I think it's more appropriate and more general to consider an IP-based > > protocol to negotiate these profiles (not IPCP; along the same lines > > as the way multicast groups are handled with IGMP or int-serv flows > > are handled with RSVP). Alternatively, it might be possible to do > > this negotiation with a new NCP for PPP, although I think that's > > certainly less desirable than a higher layer signaling solution. > > I half disagree. I think a new NCP to negotiate what is clearly an > aspect of IP would be wrong. Except that it's not so clearly an aspect of *just* IP. The differential queuing services negotiated here could just as easily apply to diff-serv for MPLS over PPP, couldn't they? (I do agree that putting it anywhere in PPP is likely a mistake.) > If you do it in PPP, it belongs in IPCP. > I agree that PPP is the wrong place to do this negotiating, unless you > assume that IP with such modified/negotiated Diff-Serv parameters will > never be run except over PPP, and that's certainly false. There should > be a single mechanism for all such negotiating, and it should work and > work as much the same as possible over all media that carry IP packets. > That suggests it should use some kind of IP packets, from existing RSVP > tactics to new UDP, ICMP, or even SNMP schemes. Yep; that's exactly what I was saying. Pop it up to a more closely related signaling function -- diffserv extensions to {insert your favorite hop-by-hop signaling protocol here}. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Tue Mar 7 16:12:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15037 for ; Tue, 7 Mar 2000 16:12:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4610D5DDC4; Tue, 7 Mar 2000 16:11:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D24F35DDA4; Tue, 7 Mar 2000 16:11:14 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id BB7D35DDA4 for ; Tue, 7 Mar 2000 16:11:00 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id OAA24236 env-from ; Tue, 7 Mar 2000 14:04:18 -0700 (MST) Date: Tue, 7 Mar 2000 14:04:18 -0700 (MST) From: Vernon Schryver Message-Id: <200003072104.OAA24236@calcite.rhyolite.com> To: carlson@ironbridgenetworks.com, carmelo.zaccone@alcatel.be, ietf-ppp@merit.edu, jeremy.de_clercq@alcatel.be, peter.de_schrijver@alcatel.be, yves.tjoens@alcatel.be Subject: Re: draft-declercq-ppp-ds-sla-negotiation-00.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > To: carmelo.zaccone@alcatel.be, jeremy.de_clercq@alcatel.be, > peter.de_schrijver@alcatel.be, yves.tjoens@alcatel.be > ... > > I half disagree. I think a new NCP to negotiate what is clearly an > > aspect of IP would be wrong. > > Except that it's not so clearly an aspect of *just* IP. The > differential queuing services negotiated here could just as easily > apply to diff-serv for MPLS over PPP, couldn't they? Yes, if you fiddle with queuing for IP, then you'll probably affect queuing for other things, which is an arguement for doing it outside of IPCP if you do it in PPP. On the other hand, IP is a major protocol so anything you do to IP will affect other traffic and so on those grounds be pushed into a new NCP, which wouldn't make sense. Don't the DiffServ bits only appear only in IP headers? If so, wouldn't one expect negotiation of them, if in PPP, to be in IPCP? > ... > Yep; that's exactly what I was saying. Pop it up to a more closely > related signaling function -- diffserv extensions to {insert your > favorite hop-by-hop signaling protocol here}. yes. That extending IPCP would be easy is irrelevant to finding the right place to put it. It should be repeated that changing the DiffServ parameters with IPCP would bounce the link and lose packets, while using your favorite IP or higher hop-by-hop signalling protocol would not. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue Mar 7 16:13:29 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15186 for ; Tue, 7 Mar 2000 16:13:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id F375F5DDE0; Tue, 7 Mar 2000 16:12:56 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DD19C5DDD7; Tue, 7 Mar 2000 16:12:55 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id B95AD5DDC5 for ; Tue, 7 Mar 2000 16:12:50 -0500 (EST) Received: (from carlson@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id QAA23237; Tue, 7 Mar 2000 16:09:55 -0500 (EST) Date: Tue, 7 Mar 2000 16:09:55 -0500 (EST) Message-Id: <200003072109.QAA23237@ironbridgenetworks.com> X-Authentication-Warning: helios.helios: carlson set sender to carlson@ironbridgenetworks.com using -f From: James Carlson To: vjs@calcite.rhyolite.com Cc: carmelo.zaccone@alcatel.be, ietf-ppp@merit.edu, jeremy.de_clercq@alcatel.be, peter.de_schrijver@alcatel.be, yves.tjoens@alcatel.be In-reply-to: <200003072104.OAA24236@calcite.rhyolite.com> (message from Vernon Schryver on Tue, 7 Mar 2000 14:04:18 -0700 (MST)) Subject: Re: draft-declercq-ppp-ds-sla-negotiation-00.txt References: <200003072104.OAA24236@calcite.rhyolite.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > Except that it's not so clearly an aspect of *just* IP. The > > differential queuing services negotiated here could just as easily > > apply to diff-serv for MPLS over PPP, couldn't they? > > Yes, if you fiddle with queuing for IP, then you'll probably affect queuing > for other things, which is an arguement for doing it outside of IPCP if > you do it in PPP. On the other hand, IP is a major protocol so anything > you do to IP will affect other traffic and so on those grounds be pushed > into a new NCP, which wouldn't make sense. Don't the DiffServ bits only > appear only in IP headers? If so, wouldn't one expect negotiation of > them, if in PPP, to be in IPCP? There's a very strong relationship between MPLS and IP. In some traffic engineering deployments, it's assumed that MPLS LSPs are used to explicitly route to IP-referred objects (BGP next-hops, ABRs, and such) based on TE constraints. One would expect that the diffserv PHBs are created in that context. (Again, I'm *NOT* advocating a new NCP. Only that it makes a little more sense than doing this in IPCP.) -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Mar 8 19:40:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02842 for ; Wed, 8 Mar 2000 19:40:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB0A75DDBD; Wed, 8 Mar 2000 19:39:40 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 99A8C5DD9E; Wed, 8 Mar 2000 19:39:40 -0500 (EST) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by segue.merit.edu (Postfix) with ESMTP id EADFA5DD9B for ; Wed, 8 Mar 2000 19:39:38 -0500 (EST) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id QAA71632; Wed, 8 Mar 2000 16:39:37 -0800 (PST) From: Archie Cobbs Message-Id: <200003090039.QAA71632@bubba.whistle.com> Subject: Re: draft-ietf-pppext-aodi-02.txt To: ietf-ppp@merit.edu Date: Wed, 8 Mar 2000 16:39:37 -0800 (PST) Cc: holdrege@lucent.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Re: draft-ietf-pppext-aodi-02.txt I have one comment about this draft.. please separate this draft into two separate drafts, or at least, two completely separate sections: 1. One describing how to setup and perform PPP over an ISDN D-channel using X.25 2. Another describing how to use BACP in the above scenario to dynamically increase/decrease bandwidth using the 2 B channels. This draft seems to assume everybody will use BACP, but that's an unwarranted assumption. Moreover, it's confusing that the above two concepts are being glommed together. #1 can be relatively short, and rely on RFC 1598 as appropriate. It should include the discussion about X.25 paramters, Use of Call User Data field, etc. #2 can discuss the situtation where BACP is also being used, e.g., the section on BACP phone deltas. Thanks, -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-ietf-ppp-outgoing@merit.edu Thu Mar 9 07:48:41 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20009 for ; Thu, 9 Mar 2000 07:48:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 76C3A5DE01; Thu, 9 Mar 2000 07:45:28 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 63E9F5DE00; Thu, 9 Mar 2000 07:45:28 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 85C545DDE4 for ; Thu, 9 Mar 2000 07:45:26 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id HAA22002 for ietf-ppp@merit.edu; Thu, 9 Mar 2000 07:45:26 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: draft-ietf-pppext-aodi-02.txt Date: 09 Mar 2000 07:45:25 -0500 Organization: IronBridge Networks Lines: 32 Message-ID: <86vh2we2hm.fsf@ironbridgenetworks.com> References: <200003090039.QAA71632@bubba.whistle.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu archie@whistle.com (Archie Cobbs) writes: > I have one comment about this draft.. please separate this draft > into two separate drafts, or at least, two completely separate sections: I've been conversing with Matt Holdrege privately about this draft, and I've pointed out similar things. There are deeper problems here. The AO/DI use of X.25 is nonstandard and broken. It's also deployed in a lot of boxes and unlikely to change. > 1. One describing how to setup and perform PPP over an ISDN D-channel > using X.25 > > 2. Another describing how to use BACP in the above scenario to > dynamically increase/decrease bandwidth using the 2 B channels. Assuming you also want to hack MP's calculation of 'M' (as suggested in this draft), that should be yet another completely separate section or draft. (I suggested to Mr. Holdrege that MP isn't at all what you want here. It doesn't make sense. It makes a lot of sense to bring up the X.25 link without MP, then, on demand, bring up a B channel and quiesce the X.25 link. No MP and no incompatible modification required.) Again, the problem is that AO/DI is really just documentation of what was already shipped. As that, I think it doesn't belong in standards track. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Mar 9 08:11:09 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25369 for ; Thu, 9 Mar 2000 08:11:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD5ED5DDEB; Thu, 9 Mar 2000 08:10:44 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9BA8C5DDE9; Thu, 9 Mar 2000 08:10:44 -0500 (EST) Received: from intra0.extant.net (intra0.extant.net [12.17.197.65]) by segue.merit.edu (Postfix) with ESMTP id 16B5C5DDE3 for ; Thu, 9 Mar 2000 08:10:43 -0500 (EST) Received: from karl ([208.46.234.146]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA3D4E; Thu, 9 Mar 2000 06:10:40 -0700 Message-Id: <4.2.2.20000309080723.04d39b60@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Mar 2000 08:10:08 -0500 To: James Carlson , ietf-ppp@merit.edu From: "Karl Fox" Subject: Re: draft-ietf-pppext-aodi-02.txt In-Reply-To: <86vh2we2hm.fsf@ironbridgenetworks.com> References: <200003090039.QAA71632@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu What do others think? Matt, what about you? Is there any chance this spec could be "fixed"? We've made non-backward-compatible changes to protocols before. Karl At 07:45 AM 3/9/00 -0500, James Carlson wrote: >I've been conversing with Matt Holdrege privately about this draft, >and I've pointed out similar things. There are deeper problems here. >The AO/DI use of X.25 is nonstandard and broken. It's also deployed >in a lot of boxes and unlikely to change. ... >Again, the problem is that AO/DI is really just documentation of what >was already shipped. As that, I think it doesn't belong in standards >track. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Thu Mar 9 11:21:00 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25918 for ; Thu, 9 Mar 2000 11:20:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 31DE85DD9E; Thu, 9 Mar 2000 11:20:31 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BAC535DDF1; Thu, 9 Mar 2000 11:20:30 -0500 (EST) Received: from intra0.extant.net (intra0.extant.net [12.17.197.65]) by segue.merit.edu (Postfix) with ESMTP id 8B9E15DD9E for ; Thu, 9 Mar 2000 11:20:28 -0500 (EST) Received: from karl ([216.28.121.202]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA42DE; Thu, 9 Mar 2000 09:20:24 -0700 Message-Id: <4.2.2.20000309111859.04d33900@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 09 Mar 2000 11:19:53 -0500 To: Matt Holdrege From: "Karl Fox" Subject: Re: draft-ietf-pppext-aodi-02.txt Cc: ietf-ppp@merit.edu In-Reply-To: <4.2.2.20000309080614.00b9a850@porky> References: <4.2.2.20000309080723.04d39b60@mail.extant.net> <86vh2we2hm.fsf@ironbridgenetworks.com> <200003090039.QAA71632@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Matt, What I was asking about was the protocol itself, to make it compatible with other standards such as PPP over X.25. Karl At 08:11 AM 3/9/00 -0800, Matt Holdrege wrote: >First of all, I've made several fixes in this draft thanks to comments from James and others. Secondly, there are a lot of choices in this draft and I need to fix the language to make that more clear. MP on the D channel is one such choice, BACP is another. > >There is nothing horribly wrong with using either BACP or MP and vice versa there is nothing wrong with choosing not to use them. As we all know, a PPP endpoint can make its own choices and it's peer can ack or nack. I'll take this input to make the draft more clear on this point. I know PPPEXT isn't meeting in Adelaide, but I'll be there if anyone wants to chat face-to-face. > > >At 08:10 AM 3/9/00 -0500, Karl Fox wrote: >>What do others think? Matt, what about you? >> >>Is there any chance this spec could be "fixed"? We've made >>non-backward-compatible changes to protocols before. >> >>Karl >> >>At 07:45 AM 3/9/00 -0500, James Carlson wrote: >> >I've been conversing with Matt Holdrege privately about this draft, >> >and I've pointed out similar things. There are deeper problems here. >> >The AO/DI use of X.25 is nonstandard and broken. It's also deployed >> >in a lot of boxes and unlikely to change. >>... >> >Again, the problem is that AO/DI is really just documentation of what >> >was already shipped. As that, I think it doesn't belong in standards >> >track. >> >> >>Karl Fox >>Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Thu Mar 9 15:24:18 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11952 for ; Thu, 9 Mar 2000 15:24:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E27F95DE6A; Thu, 9 Mar 2000 15:19:23 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C73475DDEF; Thu, 9 Mar 2000 15:19:23 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 3B3575DE53 for ; Thu, 9 Mar 2000 15:18:52 -0500 (EST) Received: from gdommety-pc2 (dhcp-sjc9-233-161.cisco.com [171.71.233.161]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id MAA17086; Thu, 9 Mar 2000 12:18:47 -0800 (PST) Message-Id: <200003092018.MAA17086@omega.cisco.com> X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 09 Mar 2000 12:31:14 -0800 To: ietf-ppp@merit.edu, l2tp@ipsec.org, gre@ops.ietf.org From: Gopal Dommety Subject: New GRE Draft Extensions Cc: mobile-ip@standards.nortelnetworks.com, dmm@cisco.com, Erik.Nordmark@eng.sun.com, fred@cisco.com, udlr@sophia.inria.fr, narten@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hello: I am attaching the GRE addendum/extensions. As you go through the draft at places identified by # there are request for comments. I have split the sequence no into two subfeilds (the other option is to define an acknowledgement like PPTP WHEN such a need it felt). Please send your comments to gre@ops.ietf.org mailing list. you can subscribe to this mailing list by sending an email to request-gre@ops.ietf.org Thanks Gopal Network Working Group Gopal Dommety INTERNET DRAFT cisco Systems March 2000 Expires October 2000 Key and Sequence Number Extensions to GRE draft-dommety-gre-ext-00.txt Status of this Memo This document is a submission by the Network Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the gre@ops.ietf.org mailing list. Distribution of this memo is unlimited. This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE (Generic Routing Encapsulation) Header [1]. GRE specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. Dommety [Page 1] Internet Draft Key and Sequence Number Extensions to GRE February 2000 1. Introduction Current specification of Generic Routing Encapsulation [1] specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This document describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1]. The Key field is used to create separate sub-tunnels within a GRE Tunnel. Sequence Number field is used to maintain sequence of packets within a GRE Tunnel. 1.1. Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. In addition, the following words are used to signify the requirements of the specification. Silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter. 2. Extensions to GRE Header The GRE packet header[1] has the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The proposed GRE header will have the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Sequence Number (Optional)| Tx Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Present (bit 2) If the Key Present bit is set to 1, then it indicates that the Key field is present in the GRE header. Otherwise, the Key field is not present in the GRE header. Sequence Number Present (bit 3) If the Sequence Number Present bit is set to 1, then it indicates that the Sequence Number field is present. Otherwise, the Sequence Number field is not present in the GRE header. The Key and Sequence Present bits are chosen to be compatible with RFC 1701 [2]. 2.1. Key Field (4 octets) The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of this document. Key field is intended to be used for creating separate sub-tunnels within a GRE Tunnel and the Key field identifies the sub-tunnel. 2.2. Sequence Number (4 octets) The Sequence Number field is divided into two sub-fields (Tx and Rx sequence number). These subfields are inserted by the encapsulator when Sequence Number Present Bit is set . Tx Sequence Number MUST be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. The intended use of the Tx Sequence Field is to provide unreliable and in-order delivery. If the Key present bit (bit 2) is set, the sequence number is specific to the sub-tunnel identified by the Key field. The Tx sequence number value ranges from 1 to 65535. The first datagram is sent with a Tx sequence number of 1. The Tx sequence number is thus a free running counter represented modulo 65536, with the exception that 1 is used when modulo 65536 results in 0 (i.e., rollover to 1 instead of 0). The Rx Sequence number is set to 0. #Q The Rx can be the Tx sequence number of the last successfully decap pack. And say that how you use this info is implementation dependent. I am currently saying Rx sequence no is set to 0. Comments? When the decapsulator receives an out-of sequence packet it SHOULD be silently discarded. Additionally, reordering of out-of sequence packets MAY be performed by the decapsulator for improved performance and tolerance to reordering in the network (since the state of the stateful compression or encryption is reset by packet loss, it might help the performance to tolerate some amount of packet reordering in the network by buffering). Exact buffering schemes are outside the scope of this document. Note that the Tx sequence number is used to detect lost packets and/or restore the original sequence of packets that may have been reordered during transport. A packet is considered an out-of-sequence packet if the Tx sequence number of the received packet is lesser than or equal to the Tx sequence number of last successfully decapsulated packet. The Tx sequence number of a received message is considered less than or equal to the last successfully received Tx sequence number if its value lies in the range of the last received Tx sequence number and the preceding 32766 values, inclusive. For example, if the last successfully received Tx sequence number was 15, then messages with Tx sequence numbers 1 through 15, as well as 32784 through 65535, would be considered less than or equal. Such a message would be considered an out-of-sequence packet and ignored from processing. If the received packet is an in-sequence packet, it is successfully de capsulated. Note that the TX sequence number is used to detect lost packets and/or restore the original sequence of packets (with buffering) that may have been reordered during transport. #C I have considered trying to have a different starting point for TX sequence nos during rollover and initial starting point. This would let a node identify if the other end reset (like agent advertisement sequence no to identify reboot and normal rollover). This is useful if we keep turning on and off sequence nos option in a tunnel. Since there is no security it is easy for others to reset the sequence also. Comments? 3. IANA Considerations 4. Acknowledgments 5. References [1] Farinacci, D., Li, T., Hnaks, S., Meyer, D. and Traina, P., "Generic Routing Encapsulation (GRE)," draft-meyer-gre-update-03.txt, January 2000. [2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and cisco Systems, October 1994. [3] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Dommety [Page 4] Internet Draft Key and Sequence Number extensions to GRE February 2000 Author Information Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: gdommety@cisco.com Dommety Thank You. Regards, Gopal ------------------------------------------------------------------------------------------------------------- Gopal Dommety 408 525 1404 gdommety@cisco.com Cisco Systems, San Jose, CA, 95051 From owner-ietf-ppp-outgoing@merit.edu Fri Mar 10 04:40:35 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25295 for ; Fri, 10 Mar 2000 04:40:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F1BC5DDE9; Fri, 10 Mar 2000 04:40:09 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F7905DDE3; Fri, 10 Mar 2000 04:40:09 -0500 (EST) Received: from relay5.ftech.net (littleblue.ftech.net [195.200.12.27]) by segue.merit.edu (Postfix) with ESMTP id 0753A5DD98 for ; Fri, 10 Mar 2000 04:40:08 -0500 (EST) Received: from ibm9.ftech.net ([212.32.16.79] helo=hardy.farsite.co.uk) by relay5.ftech.net with esmtp (Exim 3.12.ftech-p6 #1) id 12TLtu-000659-00 for ietf-ppp@merit.edu; Fri, 10 Mar 2000 09:40:06 +0000 Received: by HARDY with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 09:38:11 -0000 Message-ID: From: Jonathan Goodchild To: ietf-ppp@merit.edu Subject: Re: draft-ietf-pppext-aodi-02.txt Date: Fri, 10 Mar 2000 09:38:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > What do others think? What is the status of RFC 1598 at the moment? And how many deployed implementations of it are there? I see that it's not on the list of milestones for the working group. Does it matter if AODI is incompatible with an RFC that isn't going to advance? > Is there any chance this spec could be "fixed"? We've made > non-backward-compatible changes to protocols before. In that case, we could change the PPP in X.25 spec instead. Jonathan Goodchild Farsite Communications Ltd From owner-ietf-ppp-outgoing@merit.edu Mon Mar 13 02:43:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29096 for ; Mon, 13 Mar 2000 02:43:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 63B2A5DDA4; Mon, 13 Mar 2000 02:43:26 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 49AE05DDB2; Mon, 13 Mar 2000 02:43:26 -0500 (EST) Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by segue.merit.edu (Postfix) with ESMTP id 52C0A5DDA4 for ; Mon, 13 Mar 2000 02:43:24 -0500 (EST) Received: from gdommety-pc2 (gdommety-dsl3.cisco.com [10.19.17.140]) by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id XAA14315; Sun, 12 Mar 2000 23:42:51 -0800 (PST) Message-Id: <200003130742.XAA14315@omega.cisco.com> X-Sender: gdommety@omega.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Sun, 12 Mar 2000 23:55:23 -0800 To: "Frederick N. Chase" From: Gopal Dommety Subject: Re: New GRE Draft Extensions Cc: ietf-ppp@merit.edu, l2tp@ipsec.org, gre@ops.ietf.org, mobile-ip@standards.nortelnetworks.com, dmm@cisco.com, Erik.Nordmark@eng.sun.com, fred@cisco.com, udlr@sophia.inria.fr, narten@raleigh.ibm.com In-Reply-To: <38C94502.7D3D5026@mitre.org> References: <200003092046.MAA21507@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 01:54 PM 10/03/00 -0500, Frederick N. Chase wrote: >Re: Key and Sequence Number Extensions to GRE > > > >The proposed use of two previously-reserved header bits >in draft-dommety-gre-ext-00.txt >differ in a fundamental way. > >The proposed use of a reserved bit as a >"Sequence Number Present" bit is a >potentially-beneficial modifier >on encapsulator/decapsulator behavior and therefore >seems to me to be advisable or at least not inadvisable. > >The proposed use of a reserved bit as a >"Key Present" bit does not affect (narrowly construed) >encapsulator/decapsulator behavior but rather >concerns the processor of the encapsulated or decapsulated >data. This proposal seems to me to be inadvisable. > >Acceptance of the "Key Present" proposal unnecessarily >encumbers some other >processor of encapsulated or decapsulated data >which might like to have an optional extra 32 bits for some purpose >where the terms "Key and "sub-tunnel" would be >confusing and inappropriate. Fred, I am not sure of the concern. Would appreciate if you could explain. Is your concern that we have to maintain a Sequence number per Key when both are present? Or that earlier (in RFC1701) it was supposed to be used by the receiver to authenticate the source of the packet? Thanks Gopal > > > -Fred Chase > Thank You. Regards, Gopal ------------------------------------------------------------------------------------------------------------- Gopal Dommety 408 525 1404 gdommety@cisco.com Cisco Systems, San Jose, CA, 95051 From owner-ietf-ppp-outgoing@merit.edu Tue Mar 14 13:00:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27361 for ; Tue, 14 Mar 2000 13:00:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8CE755DDD5; Tue, 14 Mar 2000 12:59:40 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 708125DDB8; Tue, 14 Mar 2000 12:59:40 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id C1E275DD9E for ; Tue, 14 Mar 2000 12:59:38 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id KAA23169 for ietf-ppp@merit.edu env-from ; Tue, 14 Mar 2000 10:59:37 -0700 (MST) Date: Tue, 14 Mar 2000 10:59:37 -0700 (MST) From: Vernon Schryver Message-Id: <200003141759.KAA23169@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: draft-helenius-ppp-subnet-00.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Is there a name for the law of nature that says that the persistence of bad ideas increases with their badness? Didn't we deal with the idea in draft-helenius-ppp-subnet-00.txt and reach consensus that it is a bad idea?o Isn't it a little offensive that Juha Heinanen is still pushing it? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue Mar 14 13:34:27 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10660 for ; Tue, 14 Mar 2000 13:34:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE5795DE20; Tue, 14 Mar 2000 13:33:14 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 98F885DE1F; Tue, 14 Mar 2000 13:33:14 -0500 (EST) Received: from wacko.redbacknetworks.com (wacko.redbacknetworks.com [155.53.130.200]) by segue.merit.edu (Postfix) with ESMTP id 1E1965DE20 for ; Tue, 14 Mar 2000 13:33:12 -0500 (EST) Received: from tradrat.redbacknetworks.com (tradrat.redbacknetworks.com [155.53.190.107]) by wacko.redbacknetworks.com (8.9.3/8.9.3) with ESMTP id KAA18160; Tue, 14 Mar 2000 10:33:06 -0800 (PST) Received: (from tor@localhost) by tradrat.redbacknetworks.com (8.8.8/8.6.9) id KAA09977; Tue, 14 Mar 2000 10:33:06 -0800 (PST) Date: Tue, 14 Mar 2000 10:33:06 -0800 From: Rene Tio To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: draft-helenius-ppp-subnet-00.txt Message-ID: <20000314103306.C21503@redback.com> References: <200003141759.KAA23169@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200003141759.KAA23169@calcite.rhyolite.com>; from vjs@calcite.rhyolite.com on Tue, Mar 14, 2000 at 10:59:37AM -0700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Tue, Mar 14, 2000 at 10:59:37AM -0700, Vernon Schryver wrote: > Is there a name for the law of nature that says that the persistence > of bad ideas increases with their badness? > > Didn't we deal with the idea in draft-helenius-ppp-subnet-00.txt > and reach consensus that it is a bad idea?o DISCLAIMER: Views are mine and not my employers', nor are they necessarily an endorsement of the draft. As I recall, the last discussion petered out with the question that using DHCP may involve a change in the semantics of the DHCP subnet option. I don't believe we (the group) answered that, nor did we answer how to resolve the issue that the DHCP and RADIUS information reside on if not two different machines then two different databases, which brings the question of how to authorise the remote end via RADIUS to use a particular subnet that is doled out via DHCP. Rene > Isn't it a little offensive that Juha Heinanen is still pushing it? > > > Vernon Schryver vjs@rhyolite.com > From owner-ietf-ppp-outgoing@merit.edu Tue Mar 14 14:27:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02096 for ; Tue, 14 Mar 2000 14:27:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7091D5DF9E; Tue, 14 Mar 2000 14:23:26 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 500185DFA1; Tue, 14 Mar 2000 14:23:19 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 2D7FE5DEFE for ; Tue, 14 Mar 2000 14:17:30 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id MAA24634 for ietf-ppp@merit.edu env-from ; Tue, 14 Mar 2000 12:17:29 -0700 (MST) Date: Tue, 14 Mar 2000 12:17:29 -0700 (MST) From: Vernon Schryver Message-Id: <200003141917.MAA24634@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: draft-helenius-ppp-subnet-00.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Rene Tio > ... > As I recall, the last discussion petered out with the question that using > DHCP may involve a change in the semantics of the DHCP subnet option. I > don't believe we (the group) answered that, nor did we answer how to resolve > the issue that the DHCP and RADIUS information reside on if not two > different machines then two different databases, which brings the question > of how to authorise the remote end via RADIUS to use a particular subnet > that is doled out via DHCP. I don't recall the leading contender for the right place to put the netmask. Assuming it was DHCP, you already have DHCP and RADIUS involved in most such PPP session. Adding the IPCP state machine can only exacerbate any problems with multiple databases. DHCP and RADIUS are not exactly strangers to PPP today. Changing DHCP, if necesssary, surely would not be any more difficult than changing IPCP. Even if it were more difficult (and never mind the recent blizzard of I-D's proposing changes to DHCP), the primary criterion should be technical correctness, not political expediency PPP is a point-to-point protocol. The notion of netmask is unrelated to the problems PPP is intended to address. The IP address negotiated by IPCP is related to other network interfaces on the point-to-point router by at most convention, and today generally not even that (consider NAT routers). It is as wrong to shove DNS into PPP as to push routing into PPP. The netmask of other network than the PPP link simply does not belong in PPP. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 15 02:10:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29369 for ; Wed, 15 Mar 2000 02:10:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 05EAF5DDA3; Wed, 15 Mar 2000 02:10:16 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E28945DDE4; Wed, 15 Mar 2000 02:10:15 -0500 (EST) Received: from wacko.redbacknetworks.com (wacko.redbacknetworks.com [155.53.130.200]) by segue.merit.edu (Postfix) with ESMTP id 1E4305DDA3 for ; Wed, 15 Mar 2000 02:10:14 -0500 (EST) Received: from tradrat.redbacknetworks.com (tradrat.redbacknetworks.com [155.53.190.107]) by wacko.redbacknetworks.com (8.9.3/8.9.3) with ESMTP id XAA07032; Tue, 14 Mar 2000 23:10:13 -0800 (PST) Received: (from tor@localhost) by tradrat.redbacknetworks.com (8.8.8/8.6.9) id XAA23726; Tue, 14 Mar 2000 23:10:13 -0800 (PST) Date: Tue, 14 Mar 2000 23:10:13 -0800 From: Rene Tio To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: draft-helenius-ppp-subnet-00.txt Message-ID: <20000314231013.C23654@redback.com> References: <200003141917.MAA24634@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200003141917.MAA24634@calcite.rhyolite.com>; from vjs@calcite.rhyolite.com on Tue, Mar 14, 2000 at 12:17:29PM -0700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Tue, Mar 14, 2000 at 12:17:29PM -0700, Vernon Schryver wrote: > > From: Rene Tio > > > ... > > As I recall, the last discussion petered out with the question that using > > DHCP may involve a change in the semantics of the DHCP subnet option. I > > don't believe we (the group) answered that, nor did we answer how to resolve > > the issue that the DHCP and RADIUS information reside on if not two > > different machines then two different databases, which brings the question > > of how to authorise the remote end via RADIUS to use a particular subnet > > that is doled out via DHCP. > > I don't recall the leading contender for the right place to put the > netmask. Assuming it was DHCP, you already have DHCP and RADIUS involved > in most such PPP session. Adding the IPCP state machine can only > exacerbate any problems with multiple databases. DHCP and RADIUS > are not exactly strangers to PPP today. > > Changing DHCP, if necesssary, surely would not be any more difficult > than changing IPCP. Even if it were more difficult (and never mind > the recent blizzard of I-D's proposing changes to DHCP), the primary > criterion should be technical correctness, not political expediency I disagree with the first statement. Ignoring the other arguments, changing IPCP to pass subnets is very simple. Changing DHCP would require adding authorisation hooks into RADIUS to see if a user is allowed a particular sized subnets, or syncing the databases manually or via a new protocol so that if DHCP sees a particular address it knows it should hand out a particular subnet. Then you need to add a new message so the server can unilaterally yank the address and subnet away from the current CPE and dole it out to someone else. While I agree that IPCP subnet is not the right way, especially given the many times it has been discarded, I don't see any other option currently solving this problem in a timely fashion. Note I have since passed on to another life, and have not kept up with new developments. > PPP is a point-to-point protocol. The notion of netmask is unrelated > to the problems PPP is intended to address. The IP address negotiated > by IPCP is related to other network interfaces on the point-to-point > router by at most convention, and today generally not even that (consider > NAT routers). > It is as wrong to shove DNS into PPP as to push routing into PPP. > The netmask of other network than the PPP link simply does not belong > in PPP. Unfortunately that decision isn't in our hands. I know of at least one vendor who already does this. Rene > Vernon Schryver vjs@rhyolite.com > From owner-ietf-ppp-outgoing@merit.edu Wed Mar 15 10:28:56 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08592 for ; Wed, 15 Mar 2000 10:28:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id A6BD35DDF6; Wed, 15 Mar 2000 10:28:29 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 939CA5DDF5; Wed, 15 Mar 2000 10:28:29 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 923E55DDE8 for ; Wed, 15 Mar 2000 10:28:27 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id IAA13958 for ietf-ppp@merit.edu env-from ; Wed, 15 Mar 2000 08:28:26 -0700 (MST) Date: Wed, 15 Mar 2000 08:28:26 -0700 (MST) From: Vernon Schryver Message-Id: <200003151528.IAA13958@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: draft-helenius-ppp-subnet-00.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Rene Tio > ... > > Changing DHCP, if necesssary, surely would not be any more difficult > > than changing IPCP. Even if it were more difficult (and never mind > > the recent blizzard of I-D's proposing changes to DHCP), the primary > > criterion should be technical correctness, not political expediency > > I disagree with the first statement. Ignoring the other arguments, changing > IPCP to pass subnets is very simple. Changing DHCP would require adding > authorisation hooks into RADIUS to see if a user is allowed a particular > sized subnets, or syncing the databases manually or via a new protocol so > that if DHCP sees a particular address it knows it should hand out a > particular subnet. Then you need to add a new message so the server can > unilaterally yank the address and subnet away from the current CPE and dole > it out to someone else. I don't see why you need to do any of that to DHCP: - you couldn't "yank the address and subnet away from the current CPE" with the proposed IPCP change - any synchronizing between RADIUS and DHCP that is needed would also be needed between PPP and RADIUS and DHCP. - how do RADIUS and DHCP current talk to each other when DHCP hands ou the correct IP address based on a RADIUS profile? - if DHCP does or does not now need authorization hooks for handing out host addresses, why would it need or not need authorization hooks for handing out network numbers - note the recent Internet-Drafts about authorization hooks in DHCP. > While I agree that IPCP subnet is not the right way, especially given the > many times it has been discarded, I don't see any other option currently > solving this problem in a timely fashion. Exactly what problem needs solving in a timely fashion? > ... > > PPP is a point-to-point protocol. The notion of netmask is unrelated > > to the problems PPP is intended to address. The IP address negotiated > > by IPCP is related to other network interfaces on the point-to-point > > router by at most convention, and today generally not even that (consider > > NAT routers). > > It is as wrong to shove DNS into PPP as to push routing into PPP. > > The netmask of other network than the PPP link simply does not belong > > in PPP. > > Unfortunately that decision isn't in our hands. I know of at least one > vendor who already does this. What do you mean by "this"? Yes, I know of the Microsoft DNS garbage, but do you mean that some others at some other vendor have shipped this IP netmask nonsense? Contrary to the to-be-determined blank for the IPCP option number in the I-D? If so, the IETF should finally put its foot down, and refuse to publish this nonsense even as Informational, because in view of the previous cycle of this discussion such an action would have demonstrated bad faith on the part of those who did it. The IETF has become too accomodating to the Microsoft style of trash-an-IETF-protocol-and-then--get-IETF-sanction. And by the way, why was the draft not announced to the PPP mailinglist? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 15 12:37:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01989 for ; Wed, 15 Mar 2000 12:37:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 023475DD98; Wed, 15 Mar 2000 12:36:39 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DD3755DDC5; Wed, 15 Mar 2000 12:36:38 -0500 (EST) Received: from wacko.redbacknetworks.com (wacko.redbacknetworks.com [155.53.130.200]) by segue.merit.edu (Postfix) with ESMTP id 81CAA5DD98 for ; Wed, 15 Mar 2000 12:36:36 -0500 (EST) Received: from tradrat.redbacknetworks.com (tradrat.redbacknetworks.com [155.53.190.107]) by wacko.redbacknetworks.com (8.9.3/8.9.3) with ESMTP id JAA13049; Wed, 15 Mar 2000 09:36:35 -0800 (PST) Received: (from tor@localhost) by tradrat.redbacknetworks.com (8.8.8/8.6.9) id JAA20204; Wed, 15 Mar 2000 09:36:35 -0800 (PST) Date: Wed, 15 Mar 2000 09:36:35 -0800 From: Rene Tio To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: draft-helenius-ppp-subnet-00.txt Message-ID: <20000315093634.B4102@redback.com> References: <200003151528.IAA13958@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200003151528.IAA13958@calcite.rhyolite.com>; from vjs@calcite.rhyolite.com on Wed, Mar 15, 2000 at 08:28:26AM -0700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I'm going to have to make this my last email on the subject because (a) I no longer do this stuff, and (b) I feel somewhat silly defending this in a public forum, especially when the authors haven't spoken up, and when neither I nor Redback had anything to do with the draft, nor do I/we necessarily want to. I'd just like to see the problem solved instead of peter out like last time without a clear direction. The implicit assumption in this model is that there is no DHCP server. There is a RADIUS which contains the user record, including the size of the users' subnet and most likely a static IP address. Instead of a static IP, there was thought to use a pool in the NAS, which hands out address in increments according to a subnet size (different pools for different subnet sizes). I don't believe anyone is doing the latter today, since it introduces other problems, however using a pool was seen as an advantage since one could oversubscribe when deploying a not-always-on service, and the NAS could regain addresses by taking down the CPE PPP connection. Regarding the problem to be solved, it was autoconfiguration of the CPE home ethernet segment, with autoconfiguration of other parameters a distant second. I cannot comment beyond this since I have not kept up with the latest work in this area, although I would venture a guess that anything which involves protocols other than RADIUS or DHCP would meet with great resistance. When this discussion popped up a year ago I believe several vendors at least prototyped it. Finally, I really don't know why the draft wasn't published on the PPP mailing list since I was not part of it. Rene On Wed, Mar 15, 2000 at 08:28:26AM -0700, Vernon Schryver wrote: > > From: Rene Tio > > > ... > > > Changing DHCP, if necesssary, surely would not be any more difficult > > > than changing IPCP. Even if it were more difficult (and never mind > > > the recent blizzard of I-D's proposing changes to DHCP), the primary > > > criterion should be technical correctness, not political expediency > > > > I disagree with the first statement. Ignoring the other arguments, changing > > IPCP to pass subnets is very simple. Changing DHCP would require adding > > authorisation hooks into RADIUS to see if a user is allowed a particular > > sized subnets, or syncing the databases manually or via a new protocol so > > that if DHCP sees a particular address it knows it should hand out a > > particular subnet. Then you need to add a new message so the server can > > unilaterally yank the address and subnet away from the current CPE and dole > > it out to someone else. > > I don't see why you need to do any of that to DHCP: > > - you couldn't "yank the address and subnet away from the current CPE" > with the proposed IPCP change > > - any synchronizing between RADIUS and DHCP that is needed would > also be needed between PPP and RADIUS and DHCP. > > - how do RADIUS and DHCP current talk to each other when DHCP hands ou > the correct IP address based on a RADIUS profile? > > - if DHCP does or does not now need authorization hooks for handing out > host addresses, why would it need or not need authorization hooks > for handing out network numbers > > - note the recent Internet-Drafts about authorization hooks in DHCP. > > > > While I agree that IPCP subnet is not the right way, especially given the > > many times it has been discarded, I don't see any other option currently > > solving this problem in a timely fashion. > > Exactly what problem needs solving in a timely fashion? > > > > ... > > > PPP is a point-to-point protocol. The notion of netmask is unrelated > > > to the problems PPP is intended to address. The IP address negotiated > > > by IPCP is related to other network interfaces on the point-to-point > > > router by at most convention, and today generally not even that (consider > > > NAT routers). > > > It is as wrong to shove DNS into PPP as to push routing into PPP. > > > The netmask of other network than the PPP link simply does not belong > > > in PPP. > > > > Unfortunately that decision isn't in our hands. I know of at least one > > vendor who already does this. > > What do you mean by "this"? Yes, I know of the Microsoft DNS garbage, > but do you mean that some others at some other vendor have shipped this > IP netmask nonsense? Contrary to the to-be-determined blank for the > IPCP option number in the I-D? If so, the IETF should finally put > its foot down, and refuse to publish this nonsense even as Informational, > because in view of the previous cycle of this discussion such an action > would have demonstrated bad faith on the part of those who did it. > The IETF has become too accomodating to the Microsoft style of > trash-an-IETF-protocol-and-then--get-IETF-sanction. > > And by the way, why was the draft not announced to the PPP mailinglist? > > > Vernon Schryver vjs@rhyolite.com > From owner-ietf-ppp-outgoing@merit.edu Wed Mar 15 13:04:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12542 for ; Wed, 15 Mar 2000 13:04:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id E1C775DEBD; Wed, 15 Mar 2000 13:01:52 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CB6BE5DEBC; Wed, 15 Mar 2000 13:01:52 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 597095DE1D for ; Wed, 15 Mar 2000 13:01:50 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id LAA16756 for ietf-ppp@merit.edu env-from ; Wed, 15 Mar 2000 11:01:45 -0700 (MST) Date: Wed, 15 Mar 2000 11:01:45 -0700 (MST) From: Vernon Schryver Message-Id: <200003151801.LAA16756@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: draft-helenius-ppp-subnet-00.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Rene Tio > .. > I'm going to have to make this my last email on the subject because (a) I no > longer do this stuff, and (b) I feel somewhat silly defending this in a > public forum, especially when the authors haven't spoken up, and when > neither I nor Redback had anything to do with the draft, nor do I/we > necessarily want to. I'd just like to see the problem solved instead of > peter out like last time without a clear direction. If what you've said accurately represents the assumptions of the draft, you've done us all a sigificant service. > The implicit assumption in this model is that there is no DHCP server. That sounds like a problem that should be fixed. Why assume there is no DHCP server merely to rationalize jamming DHCP facilities into PPP? > There is a RADIUS which contains the user record, including the size of the > users' subnet and most likely a static IP address. Instead of a static IP, > there was thought to use a pool in the NAS, which hands out address in > increments according to a subnet size (different pools for different subnet > sizes). I don't believe anyone is doing the latter today, since it > introduces other problems, My guess is that the use of NAT has made the issue moot, as well as the fact that it is impossible to such an allocation once it is made. > however using a pool was seen as an advantage > since one could oversubscribe when deploying a not-always-on service, and > the NAS could regain addresses by taking down the CPE PPP connection. That seems to assume that it makes sense to revoke a network allocation after it has been made, as you mentioned before. Revoking a network allocation is NONSENSE! There is no need to communicate more than one IP address unless there are 2 or more computers beyond the PPP link (possibly including the PPP box itself). Just how would the other computers on the network be told that their host addresses have been revoked? To put it mildly, most hosts or applications don't take well to having their IP addresses changed. There is lots of machinery in DHCP to deal with this unavoidable fact. > Regarding the problem to be solved, it was autoconfiguration of the CPE home > ethernet segment, with autoconfiguration of other parameters a distant > second. It sounds to me like the ever popular, unthinking "if it has something to do with networking it has to have its own packets" reaction. Autoconfiguration of the CPE home Ethernet segment makes no sense if you stop and think about the computers on the Ethernet. First and foremost, you expect them to continue to be able to talk to each other (e.g. NETBIOS file and print sharing) even when disconnected from the Internet. That implies you can cannot change the CIDR block given a CPE home Ethernet segment. That "autoconfiguration" necessarily degenerates into "configure once and never change for the life of the customer's contract." > I cannot comment beyond this since I have not kept up with the > latest work in this area, although I would venture a guess that anything > which involves protocols other than RADIUS or DHCP would meet with great > resistance. When this discussion popped up a year ago I believe several > vendors at least prototyped it. There's nothing wrong with trying things, although it pays to think about implications first, such as what you expect the other computers on the home CPE Ethernet segment to do when the IPCP negotiation offers a different CIDR block). > Finally, I really don't know why the draft wasn't published on the PPP > mailing list since I was not part of it. I can think of two reasons. One is almost reasonable, that the working group will not bee meeting. I'm trying not to mention the other. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 15 14:04:09 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08464 for ; Wed, 15 Mar 2000 14:04:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0CDB45DE40; Wed, 15 Mar 2000 14:01:21 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E6CC75DE3E; Wed, 15 Mar 2000 14:01:20 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 994DD5DE3D for ; Wed, 15 Mar 2000 14:01:14 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id OAA00069 for ietf-ppp@merit.edu; Wed, 15 Mar 2000 14:01:14 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: draft-helenius-ppp-subnet-00.txt Date: 15 Mar 2000 14:01:14 -0500 Organization: IronBridge Networks Lines: 49 Message-ID: <861z5coy6d.fsf@ironbridgenetworks.com> References: <200003151528.IAA13958@calcite.rhyolite.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu vjs@calcite.rhyolite.com (Vernon Schryver) writes: > What do you mean by "this"? Yes, I know of the Microsoft DNS garbage, > but do you mean that some others at some other vendor have shipped this > IP netmask nonsense? Yes. In fact, Juha Heinanen described using option 0x90 on this list to do subnet assignment back in August last year. He was told to do DHCP back then as well. As he described it, it was explicitly for ADSL. Actually, his description of the option itself back then was different from this draft. I don't know why. Here's what he wrote: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Mask +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mask (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Type = 0x90 and Length = 0x06. > Contrary to the to-be-determined blank for the > IPCP option number in the I-D? Ayup. > If so, the IETF should finally put > its foot down, and refuse to publish this nonsense even as Informational, > because in view of the previous cycle of this discussion such an action > would have demonstrated bad faith on the part of those who did it. Well, it *is* ADSL. The same group that gave us PPPoE. The pattern is striking, isn't it? > The IETF has become too accomodating to the Microsoft style of > trash-an-IETF-protocol-and-then--get-IETF-sanction. > > And by the way, why was the draft not announced to the PPP mailinglist? Hey, anybody can publish a non-wg document ... -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Mar 15 14:14:24 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12987 for ; Wed, 15 Mar 2000 14:14:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0E7D5DDEC; Wed, 15 Mar 2000 14:13:55 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A03665DDE9; Wed, 15 Mar 2000 14:13:55 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 70BA75DDBE for ; Wed, 15 Mar 2000 14:13:53 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id MAA18456 for ietf-ppp@merit.edu env-from ; Wed, 15 Mar 2000 12:13:52 -0700 (MST) Date: Wed, 15 Mar 2000 12:13:52 -0700 (MST) From: Vernon Schryver Message-Id: <200003151913.MAA18456@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: draft-helenius-ppp-subnet-00.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > > If so, the IETF should finally put > > its foot down, and refuse to publish this nonsense even as Informational, > > because in view of the previous cycle of this discussion such an action > > would have demonstrated bad faith on the part of those who did it. > > Well, it *is* ADSL. The same group that gave us PPPoE. The pattern > is striking, isn't it? > > > The IETF has become too accomodating to the Microsoft style of > > trash-an-IETF-protocol-and-then--get-IETF-sanction. > > > > And by the way, why was the draft not announced to the PPP mailinglist? > > Hey, anybody can publish a non-wg document ... I've the impression that the IESG is refusing to publish some of the most silly I-D's as RFC's. Refusing to publish RFC's that are intended to bypass, subvert, bamboolze, co-opt, and defraud the IETF seems like a good idea that should be extended to I-D's. Of course, it would have to be applied after initial publishing of I-D's. That this proposal differs from the previuos version seem like evidence that it is not evil and so should be taken at face value. On the other hand, those differences could instead be evidence of evil intent to subvert the IETF's processes. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Mar 15 16:37:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11729 for ; Wed, 15 Mar 2000 16:37:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id DFC605DE48; Wed, 15 Mar 2000 16:34:43 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C418C5DE96; Wed, 15 Mar 2000 16:34:43 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 9DC915DE48 for ; Wed, 15 Mar 2000 16:34:41 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id QAA06629 for ietf-ppp@merit.edu; Wed, 15 Mar 2000 16:34:40 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: draft-helenius-ppp-subnet-00.txt Date: 15 Mar 2000 16:34:40 -0500 Organization: IronBridge Networks Lines: 27 Message-ID: <86zorzor2n.fsf@ironbridgenetworks.com> References: <861z5coy6d.fsf@ironbridgenetworks.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu carlson@ironbridgenetworks.com (James Carlson) blathers as though he were sending private email: > Well, it *is* ADSL. The same group that gave us PPPoE. The pattern > is striking, isn't it? As was quite graciously pointed out to me by one of the folks that I just splattered for no good reason, my comment above is clearly way out of line. I apologize. There is still a coordination problem here. Some clearly IETF-related work (like PPPoE and this new subnet option) are being done in an unrelated forum. The resulting efforts aren't being reviewed by the folks nominally responsible for guiding PPP development. It's entirely possible that the working group consensus is misinformed and needs some correction, but that won't happen without at least some substantive and intentional debate on serious proposals. This is bad for everyone. The fundamental network design issues aren't being addressed and the working group's role is reduced to just publishing what's already being shipped. That's not how interoperable implementations are built. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Mar 16 19:41:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08822 for ; Thu, 16 Mar 2000 19:41:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8AC015DDDD; Thu, 16 Mar 2000 19:40:58 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 793F65DD92; Thu, 16 Mar 2000 19:40:58 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id DFCF45DD8C for ; Thu, 16 Mar 2000 19:40:53 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id RAA15193 for ietf-ppp@merit.edu env-from ; Thu, 16 Mar 2000 17:40:52 -0700 (MST) Date: Thu, 16 Mar 2000 17:40:52 -0700 (MST) From: Vernon Schryver Message-Id: <200003170040.RAA15193@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: draft-helenius-ppp-subnet-00.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "Petri Helenius" > ... > > Exactly what problem needs solving in a timely fashion? > > Configuring the CPE device´s netmask without having to have DHCP client on > the CPE > (or in the whole system). The proposal would a bad solution if the problem were real, but the problem is not real: - without a DHCP (or BOOTP, etc) server somewhere, the hosts beyond the PPP router cannot use the CIDR block that would be communicated by the proposed IPCP option. Without DHCP, the hosts beyond the PPP router must be statically configured. If the hosts are statically configured, then there is no technical reason for an IPCP option. - the notion of IPCP negotiating implies that sometimes the negotiated CIDR block would change. If the block does change, then how do hosts on the network beyond the PPP router discover they need to kill all of their applications and reconfigure their interfaces? On the other hand, if the network number and netmask never change, then why complicate IPCP by negotiating something that is unrelated to PPP? - NAT, for all of its disadvantages and bad side effects, is a better solution. It is better because it does not require the hosts on the leaf network to change their IP addresses and netmasks (and if they don't change then the proposed IPCP option is useless). NAT is also better because it does a better job of conserving IPv4 addresses. - even if this proposal were better than NAT, then the proposal would be moot, because the industry has already decided to use NAT to solve the problem. > With this added, you could also (in another > scenario) > populate an DHCP server in the CPE with IPCP derived information. (but that > is not the main goal here) That thought is another compelling reason for the IETF to refuse to publish the proposal. > > > Unfortunately that decision isn't in our hands. I know of at least one > > > vendor who already does this. > > > > What do you mean by "this"? Yes, I know of the Microsoft DNS garbage, > > This netmask stuff. Two major vendors are shipping this, in both CPE and > aggregation equipment. They are also interoperable. It is believable that tests by two vendors have failed to find interoperability problems. However, it is *not* plausible that this proposal has been or can be used by real life end user customers in the supposed scenarios, especially including having no DHCP servers. It is believable that non-trivial CIDR blocks (i.e. not /32's) have appeared in IPCP packets sent by the vendors' equipment, but not that the CIDR blocks were honestly "allocated" (because of the lack of DHCP server) or honestly "negotiated" (because you can't change the IP addresses of all of the hosts on a network unilaterally). > ... > One of the reasons for putting the (revised) draft forward was to get it > documented > and, if possible, move it forward towards being accepted. Because of the bad faith by the vendors involved, as well as the technical flaws in the proposal, the IETF should refuse to publish anything documenting this proposal. Yes, I mean bad faith, as demonstrated by the history of the proposal, including the effort to sneak it past the PPP working group. There is also the evidence that those involved had and have no intention of listening to the IETF. Their plan is get an IETF rubber stamp for their bad, proprietary idea, and then advertise the bad idea as IETF approved. It's one thing to have an outside protocol published by the IETF when the protocol is widely used and when the IETF has not examined the protocol and found it to be a bad idea. It is something else to demand a stamp of approval for a bad modification to an IETF protocol that the IETF has examined and found to be bad. That the proposal has been rendered moot by the industry decision to use NAT makes the proposal a good place for the IETF to start resisting the efforts by vendors to make the IETF into a rubber stamp for bad ideas. > It's significantly > more compicated to get DHCP to do this job so I think this is optimal > approach > to the problem regardless if DHCP is used in the picture or not. That is wrong on technical as well as administrative grounds. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Thu Mar 16 20:56:06 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07452 for ; Thu, 16 Mar 2000 20:56:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F27B5DDA0; Thu, 16 Mar 2000 20:55:41 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0E78E5DD93; Thu, 16 Mar 2000 20:55:41 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id 486695DD92 for ; Thu, 16 Mar 2000 20:55:39 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id UAA00197 for ietf-ppp@merit.edu; Thu, 16 Mar 2000 20:55:38 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: draft-helenius-ppp-subnet-00.txt Date: 16 Mar 2000 20:55:38 -0500 Organization: IronBridge Networks Lines: 35 Message-ID: <86itymfjhh.fsf@ironbridgenetworks.com> References: <200003170040.RAA15193@calcite.rhyolite.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu vjs@calcite.rhyolite.com (Vernon Schryver) writes: > - the notion of IPCP negotiating implies that sometimes the negotiated > CIDR block would change. If the block does change, then how do hosts > on the network beyond the PPP router discover they need to kill all of > their applications and reconfigure their interfaces? Pretty clearly, they'll need to be doing DHCP with this hypothetical CPE box. Of course, once they're doing DHCP there, it hardly makes a difference whether the CPE box is relaying to an upstream server or it's pooling locally from data it got out of IPCP. In fact, the only real difference is that the latter is going to be *much* harder for the ISP to administer and control. There are all sorts of common tools for dealing with DHCP accounting. What exists for this new subnet mask option? > On the other > hand, if the network number and netmask never change, then why > complicate IPCP by negotiating something that is unrelated to PPP? I think part of the underlying assumption seems to be that that IPCP negotiation somehow "controls" the addresses that the peer may use. It doesn't. There's nothing at all stopping the peer from negotiating one address and then using another. In fact, the intelligence has to be up at the ISP end -- where source address filtering is required. (One could imagine a network where the server systems have extensive host-route support and customers can get individual IP addresses on demand, rather than requiring a doubling of the allocation every time. Will we then need an "IP-Address-List" option ... ?) -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Mar 17 01:34:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05413 for ; Fri, 17 Mar 2000 01:34:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4DF185DDED; Fri, 17 Mar 2000 01:33:58 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 255D25DDF5; Fri, 17 Mar 2000 01:33:58 -0500 (EST) Received: from silver.kpnqwest.fi (silver.kpnqwest.fi [193.64.226.17]) by segue.merit.edu (Postfix) with ESMTP id 6596B5DDED for ; Fri, 17 Mar 2000 01:33:55 -0500 (EST) Received: from tossu (silver.kpnqwest.fi [193.64.226.17]) by silver.kpnqwest.fi (8.9.3/8.9.2) with SMTP id IAA37478; Fri, 17 Mar 2000 08:33:42 +0200 (EET) (envelope-from pete@kpnqwest.fi) Message-ID: <004101bf8fda$d027e060$2a3cf3c6@ad.kpnqwest.fi> From: "Petri Helenius" To: "James Carlson" Cc: References: <200003170040.RAA15193@calcite.rhyolite.com> <86itymfjhh.fsf@ironbridgenetworks.com> Subject: Re: draft-helenius-ppp-subnet-00.txt Date: Thu, 16 Mar 2000 22:33:32 -0800 Organization: KPNQwest Finland Oy MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit > I think part of the underlying assumption seems to be that that IPCP > negotiation somehow "controls" the addresses that the peer may use. > It doesn't. There's nothing at all stopping the peer from negotiating > one address and then using another. In fact, the intelligence has to > be up at the ISP end -- where source address filtering is required. Modern aggregation devices install anti-spoofing filters automatically based on the IPCP netmask negotiation. This helps getting rid of all kinds of source-address spoofing pollution on the public Internet. I´m open to suggestions how the above will be accomplished with DHCP and how the DSL aggregation device would know the routes and neccessary filters to install? > Pete From owner-ietf-ppp-outgoing@merit.edu Fri Mar 17 07:53:29 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11814 for ; Fri, 17 Mar 2000 07:53:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id B52885DDF2; Fri, 17 Mar 2000 07:52:57 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 989305DD94; Fri, 17 Mar 2000 07:52:57 -0500 (EST) Received: from ironbridgenetworks.com (ibn-host12.ironbridgenetworks.com [146.115.140.12]) by segue.merit.edu (Postfix) with ESMTP id F2CC95DD93 for ; Fri, 17 Mar 2000 07:52:55 -0500 (EST) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id HAA04939 for ietf-ppp@merit.edu; Fri, 17 Mar 2000 07:52:55 -0500 (EST) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: draft-helenius-ppp-subnet-00.txt Date: 17 Mar 2000 07:52:55 -0500 Organization: IronBridge Networks Lines: 47 Message-ID: <86r9d969nc.fsf@ironbridgenetworks.com> References: <004101bf8fda$d027e060$2a3cf3c6@ad.kpnqwest.fi> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu pete@kpnqwest.fi ("Petri Helenius") writes: > Modern aggregation devices install anti-spoofing filters automatically > based on the IPCP netmask negotiation. This helps getting rid of all > kinds of source-address spoofing pollution on the public Internet. Modern, sure, but certainly not all, and perhaps not even many. I'm pretty sure RPF is off by default on Ciscos. This is certainly an ongoing sore spot with ISPs. If the anti-spoofing were always automatic on (at least!) links to single-homed sites, those recent DDoS attacks would have been much easier to trace and prevent. > I´m open to suggestions how the above will be accomplished with DHCP > and how the DSL aggregation device would know the routes and neccessary > filters to install? The CPE box will need to receive and process the DHCPDISCOVER message. One obvious way to handle this would be to allow the CPE to send the DHCP subnet option (draft-ietf-dhc-subnet-option-03.txt) to the aggregation device, and have the aggregation device allocate a network for the CPE and set the filters. The CPE can then do its own address pooling and DHCPOFFER replies. Another way would be to make the CPE box just a DHCP relay. Have the aggregation device handle the DHCPDISCOVER messages individually. That probably doesn't scale as well, but it probably also doesn't matter. It would have interesting network management possibilities. Clearly, the aggregation box has exactly the right information in both cases to apply appropriate filters, install static routes, and dynamically update DNS entries. You would, of course, be likely to use unrelated addresses in the IPCP IP-Address option. If the networks allocated by DHCP were real, globally visible addresses (not NAT'd), then I'd use regular RFC 1918 addresses on the PPP link itself. The actual addresses in use there don't matter, since folks outside of the link itself -- like the owner of the computers on that CPE-side network -- cannot see them. There are certainly many other possibilities here using application- level protocols like DHCP. One doesn't need link-layer negotiation to solve the problem. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Mar 17 13:11:09 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18591 for ; Fri, 17 Mar 2000 13:11:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 32A595DD8C; Fri, 17 Mar 2000 13:10:42 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 20CDD5DD94; Fri, 17 Mar 2000 13:10:42 -0500 (EST) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by segue.merit.edu (Postfix) with SMTP id EDEEC5DD93 for ; Fri, 17 Mar 2000 13:10:39 -0500 (EST) From: Barney Wolff To: ietf-ppp@merit.edu Date: Fri, 17 Mar 2000 13:02 EST Subject: Re: draft-helenius-ppp-subnet-00.txt Content-Type: text/plain Message-ID: <38d2751d0.4ded@databus.databus.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is not relevant to preventing spoofing. That must be done by the network-side device, which can (and should) have used the Radius Framed-Route attribute to be informed of the proper set of source addresses to accept. Filtering in CPE certainly won't stop the bad guys. Barney Wolff > From: "Petri Helenius" > Date: Thu, 16 Mar 2000 22:33:32 -0800 > > Modern aggregation devices install anti-spoofing filters automatically > based on the IPCP netmask negotiation. This helps getting rid of all > kinds of source-address spoofing pollution on the public Internet.