From owner-ietf-ppp@merit.edu Mon May 12 17:36:01 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id F0E625DE66; Mon, 12 May 2003 17:36:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD05591265; Mon, 12 May 2003 17:35:47 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A659691266; Mon, 12 May 2003 17:35:47 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DF6291265 for ; Mon, 12 May 2003 17:35:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A1B85DEDA; Mon, 12 May 2003 17:35:46 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from david.siemens.com (david.siemens.com [194.138.160.5]) by segue.merit.edu (Postfix) with ESMTP id 09DEC5DED7 for ; Mon, 12 May 2003 17:35:46 -0400 (EDT) Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4]) by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4CLZlI01222 for ; Mon, 12 May 2003 17:35:47 -0400 (EDT) Received: from yogi.inside.efficient.com ([165.218.188.2]) by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4CLZkF01344 for ; Mon, 12 May 2003 17:35:46 -0400 (EDT) Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 May 2003 16:35:43 -0500 Message-ID: From: Doug Kehn To: "'ietf-ppp@merit.edu'" Subject: Extending IPCP for Route Table Entries Date: Mon, 12 May 2003 16:35:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu All, I would like to open a discussion on the possibilities for extending IPCP to allow the negotiation of route table entries. The topic of adding route information to PPP has been brought up in the DSL Forum. However, to the best of my knowledge, the DSL Forum has not approached the IETF regarding this topic. Currently, some PPPoE capable BRASs have implemented PADN (see draft-carrel-info-pppoe-ext-00.txt) as a way a add route information over PPP links. This facility only suffices the need for PPPoE links. A more general approach would be to extend PPP itself. To jump start the discussion, I've included a draft RFC (see below) that oulines a method for extending IPCP that might be used to fulfill the need. Thanks... doug INTERNET-DRAFT Doug Kehn draft-kehn-info-ppp-ipcp-ext-00.txt Efficient Networks Inc. Category: Informational May 2003 Expires: November 2003 PPP Internet Protocol Control Protocol Extensions for Route Table Entries Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ieft/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. The PPP Internet Protocol Control Protocol (IPCP) [2] defines the NCP for establishing and configuring the Internet Protocol (IP) [3]. This document extends IPCP by defining the negotiation of IP route table entries. This extension provides added functionality but is optional and preserves compatibility. 1. Introduction Kehn Informational [Page 1] INTERNET DRAFT May 2003 PPP is widely used by broadband service providers as the protocol of choice for connecting hosts to the Internet. PPP is popular because it is a well-known protocol that has been utilized by dial-up service providers for many years. PPP also provides per-user access control, billing, etc. These later features of PPP are the most appealing to providers. In recent years, PPP has seen two transport extensions emerge to support broadband access. These transports are PPP over Ethernet (PPPoE) [5] and PPP over AAL5 (PPPoA) [6]. With the emergence of broadband, the PPP client is migrating from the subscribers PC to the broadband customer premise equipment (CPE). Broadband provides more bandwidth to the subscriber. Broadband service providers are wanting to utilize this additional bandwidth to provide additional services to subscribers. Service Providers, for obvious reasons, desire to isolate these additional services from standard Internet service. As stated earlier, PPP provides the per- user access control, billing, etc. This makes PPP a logical choice for providing these additional services. PPP also allows the service provider to utilize its investment in networking hardware used to provide standard Internet access. If PPP is to be used for both Internet access and additional service access, PPP hosts (whether residing in the PC or CPE) must be able to establish multiple PPP links. The presence of multiple PPP links can complicate packet routing decisions in the host. This document proposes an extension to IPCP to address the packet routing issues induced in the presence of multiple PPP links. The extension provides the ability to add route table entries for specific PPP interfaces. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [4]. 3. Additional IPCP Configuration Option 3.1 Route-Add Description This configuration option defines a method for negotiating zero or more route table entries for the PPP interface on the local (client) end of the link. If the local peer supports the Route- Add option, it MUST include the Route-Add option with a length of 2 to its IPCP Configure Request. The remote (server) peer, if it supports the Route-Add option, SHOULD return the appropriate Kehn Informational [Page 2] INTERNET DRAFT May 2003 number of Route-Add option entries in its IPCP response. If the remote peer does not wish to add any route entries to the local peer, the remote peer MUST NOT include the Route-Add option in its response. The local peer MUST accept this response as an indication that the remote peer does not wish to add any routes to the interface. If the remote peer does not support the Route-Add option (e.g. current implementations), the remote peer MAY reject the Route-Add option. This is an indication to the local peer that the remote peer does not support the Route-Add option and IPCP negotiation MUST continue without it. A Route-Add option entry with a Route-Address and Route-Mask of zero indicates a default route. Any routes added via the Route-Add option MUST be deleted when the IPCP layer terminates. A summary of the Route-Add option format is shown below. The fields are transmitted from left to right and are in network-byte order. 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 | Route-Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Route-Address (cont) | Route-Mask +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Route-Mask (cont) | Route-Next-Hop +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Route-Next-Hop (cont) | Route-Metric +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Route-Metric (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (To be assigned by IANA) Length 18+ Route-Address The four octet field defining the destination network or host address. Kehn Informational [Page 3] INTERNET DRAFT May 2003 Route-Mask The four octet field defining the subnet mask for the route. For host route entries, this field MUST be set to all one's. Route-Next-Hop The four octet field defining the route's next hop. This field MAY be zero if the next hop for the route is the remote peer. Route-Metric The four octet field defining the metric value for the route. Normative References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994 [2] McGregor, G., "PPP Internet Control Protocol", RFC 1332, Merit, May 1992. Informative References [3] Postel, J., "Internet Protocol", RFC 971, USC/Information Sciences Institute, September 1981. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. [6] Gross, et. al., "PPP Over AAL5", RFC 2364, July 1998. Security Considerations Security issues are not discussed in this memo. IANA Considerations Requires IPCP option number assignment for the Route-Add option. Acknowledgments This draft was inspired by the "work in progress" . Kehn Informational [Page 4] INTERNET DRAFT May 2003 Special thanks goes to Stephen Lyda (Efficient Networks, Inc.), and Dan Dworin (Efficient Networks, Inc.) for their feedback. Author's Address Doug Kehn Efficient Networks Inc. 4849 Alpha Road Dallas, TX 75244 USA Phone: +1 972 852 1000 EMail: dkehn@efficient.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kehn Informational [Page 5] From owner-ietf-ppp@merit.edu Mon May 12 17:46:18 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 7F0F55DEE2; Mon, 12 May 2003 17:46:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BCD6591266; Mon, 12 May 2003 17:45:34 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9079891267; Mon, 12 May 2003 17:45:34 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8076C91266 for ; Mon, 12 May 2003 17:45:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F2145DEE1; Mon, 12 May 2003 17:45:33 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 51C3F5DEDF for ; Mon, 12 May 2003 17:45:29 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4CLjN44017286 for ietf-ppp@merit.edu env-from ; Mon, 12 May 2003 15:45:23 -0600 (MDT) Date: Mon, 12 May 2003 15:45:23 -0600 (MDT) From: Vernon Schryver Message-Id: <200305122145.h4CLjN44017286@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Extending IPCP for Route Table Entries References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Doug Kehn > I would like to open a discussion on the possibilities for extending IPCP to > allow the negotiation of route table entries. The topic of adding route > information to PPP has been brought up in the DSL Forum. However, to the > best of my knowledge, the DSL Forum has not approached the IETF regarding > this topic. Currently, some PPPoE capable BRASs have implemented PADN (see > draft-carrel-info-pppoe-ext-00.txt) as a way a add route information over > PPP links. This facility only suffices the need for PPPoE links. A more > general approach would be to extend PPP itself. To jump start the > discussion, I've included a draft RFC (see below) that oulines a method for > extending IPCP that might be used to fulfill the need. Let's put our collective feet down and stop allowing such bad ideas. It makes no sense to extend IPCP to carry routes. There are plenty of existing standards for that. For example, you could do what has been done for literally decades and use RIP. You could even use authentication in RIPv2. If you don't like RIP, you can use Router-Discovery, OSPF, BGP, and a zillion other routing protocols. I can't seem to find draft-carrel-info-pppoe-ext-00.txt or anything with the string "carrel" on ftp.isi.edu. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Mon May 12 18:25:42 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id E417D5DEF1; Mon, 12 May 2003 18:25:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4DD8691267; Mon, 12 May 2003 18:25:28 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B74491268; Mon, 12 May 2003 18:25:28 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D70691267 for ; Mon, 12 May 2003 18:25:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC0385DEF1; Mon, 12 May 2003 18:25:26 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from david.siemens.com (david.siemens.com [194.138.160.5]) by segue.merit.edu (Postfix) with ESMTP id 9D6AE5DED6 for ; Mon, 12 May 2003 18:25:26 -0400 (EDT) Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4]) by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4CMPRI11731; Mon, 12 May 2003 18:25:27 -0400 (EDT) Received: from yogi.inside.efficient.com ([165.218.188.2]) by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4CMPQF12137; Mon, 12 May 2003 18:25:26 -0400 (EDT) Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 May 2003 17:25:23 -0500 Message-ID: From: Doug Kehn To: "'Vernon Schryver '" , "'ietf-ppp@merit.edu '" Subject: RE: Extending IPCP for Route Table Entries Date: Mon, 12 May 2003 17:25:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Vernon, I agree with your comments. However, most service providers don't use the available routing protocols (???). I believe it would be okay to "put our collective feet down and stop allowing such bad ideas." But until it is done so publicly, rogue protocol extensions may prevail (i.e. I've yet to find an RFC for IPCP option 144). My goal was to come up with an admissible solution/compromise at the PPP layer or to have the working group put its foot and say no. I would hate for another non-IETF sanctioned protocol extension prevail. I've included the draft-carrel-info-pppoe-ext-00.txt for your review. ...doug PPP Working Group David Carrel, Dan Simone, INTERNET DRAFT Che-Lin Ho, Tom Stoner Category: Informational Redback Networks, Inc. Title: draft-carrel-info-pppoe-ext-00.txt Date: May 2000 Extensions to a Method for Transmitting PPP Over Ethernet (PPPoE) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." 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. The distribution of this memo is unlimited. It is filed as , and expires 30 November, 2000. Please send comments to the authors. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPPoE [2] describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This document describes extensions to PPPoE. These extensions provide added functionality, but are optional and preserve compatibility. Carrel [Page1] INTERNET DRAFT May 2000 1. Introduction PPP over Ethernet (PPPoE) [2] provides the ability to connect a network of hosts over a simple Ethernet bridging access device to a remote Access Concentrator. With this model, each host utilizes it's own PPP stack and the user is presented with a familiar user interface. Access control, billing and type of service can be done on a per-user, rather than a per-site, basis. The flexibility provided by PPPoE has inspired the development of several extensions to the protocol. These extensions provide for networking level enhancements as well as session level enhancements aimed at the user experience. These enhancements maintain backwards compatibility with the core PPPoE protocol. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [3]. 3. Discovery Stage The PADI, PADO, PADR, PADS and PADT defined in [2] are unchanged. The following discovery packets have been added. Since this is the Discovery Stage, an ETHER_TYPE of 0x8863 MUST be used. 3.1 The PPPoE Active Discovery Message (PADM) packet An Access Concentrator MAY send a PADM at any time while a session is active to convey informational messages to the Host. The DESTINATION_ADDR is the unicast address of the Host. The CODE field is set to 0xd3 and the SESSION_ID MUST be set to the current (active) SESSION_ID value. Use of this packet is optional for both the Access Concentrator and the Host. A PADM packet MUST contain at least one TAG of type HURL or MOTM and SHOULD NOT contain any other TAGs. Additional messaging TAGs may be defined in the future that are appropriate for PADM packets. Carrel [Page2] INTERNET DRAFT May 2000 3.2 The PPPoE Active Discovery Network (PADN) packet An Access Concentrator MAY send a PADN at any time while a session is active to convey network level information to the Host. The DESTINATION_ADDR is the unicast address of the Host. The CODE field is set to 0xd4 and the SESSION_ID MUST be set to the current (active) SESSION_ID value. An Access Concentrator SHOULD send a PADN as soon as possible after an NCP completes negotiation. That PADN SHOULD only contain TAGs that are appropriate for that NCP. Since there is no limit on the number of PADNs that may be sent, it is appropriate to send a PADN for each NCP. Use of this packet is optional for both the Access Concentrator and the Host, though in general it is expected that it will only be sent by the Access Concentrator. A PADN packet MUST contain at least one TAG of type IP_ROUTE_ADD and SHOULD NOT contain any other TAGs. Additional network TAGs may be defined in the future that are appropriate for PADN packets. 4. PPPoE Clarifications Since publication of [2], discussions have taken place which have identified some areas of ambiguity. To avoid confusion and inter- operability problems, we are providing further clarification. This is a clarification of [2] and does not change [2] in any way. Carrel [Page3] INTERNET DRAFT May 2000 4.1 Service Selection Service Selection is a key feature of PPPoE. It allows for the Host to request a specific service and it also allows for the Access Concentrator to "advertise" a list of services. Service Selection is optional, but if the Host and Access Concentrator wish to participate in it, they should operate as indicated below. User Interface (UI) issues are discussed as well. If either the Host or Access Concentrator does not wish to participate in Service Selection, then they SHOULD use a Service-Name TAG with zero length, indicating that any service is acceptable. This can be done in the PADI, PADO, PADR and PADS packets to indicate that PPPoE Service Selection is not being used and PPP authentication should be used to determine the user's "service". In this case, no UI is needed beyond the PPP UI. Occasionally the Host will know in advance that it wishes to use a specific PPPoE Service. In that case, it MAY put that service in a Service-Name TAG in both the PADI and PADR. For this case, the UI should allow the Service-Name to be specified prior to beginning PPPoE Discovery. Our anticipation is that this case will be very rare. Since PPPoE has no security, Service Selection should be considered informational. PPP Authentication can be trusted and should be used to identify the user when there is no desire to "discover" services. Dynamic Service Selection happens when the Host wishes to "discover" what services are out there. The Host does not put a specific Service-Name value in the PADI and waits for a list of Service-Name TAGs from the Access Concentrator(s). This is accomplished by sending a PADI with a zero length Service-Name TAG. This indicates that the Host is trying to discover all services that are available. Each Access-Concentrator MAY then reply with a PADO listing multiple services. If the Host is capable of doing Service Selection, it SHOULD send a PADI and receive the PADO(s) before accepting any user input. It SHOULD then present the list of Services to the user and wait for the user to select one prior to sending the PADR. The PADR is the point where the Host "selects" its service. The UI should display the list of discovered Services. As an added value, it could remember commonly chosen Services and could even remember the last PPP username used for each Service. The Host MUST remember which Access Concentrator sent which Service-Name TAGs so that the PADR is sent to the correct Access Concentrator. Carrel [Page4] INTERNET DRAFT May 2000 5. PPP Considerations PADM packets SHOULD be sent after PPP authentication has completed in order to provide per-user messaging. Also PADM packets containing HURL TAGs SHOULD be sent after an NCP is established so that network connectivity is available for the web browser. However a Host implementation MUST be able to receive one at any time after PPPoE session establishment. 6. Security Considerations All data confidentiality and authenticity issues are left to higher layers such as PPP or IP. As such, any information sent in a PADM packet can not be protected. To present data to a user in a secure manner, HURLs can be used to establish a connection over higher layers that do provide security. Service Selection is NOT secure and should only be used informationally. 7. Acknowledgments Copious amounts of text were stolen from RFC 2516. 8. References [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994 [2] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [5] Berners-Lee, T., Masinter, L., and McCahill, M. "Uniform Resource Locators (URL)", RFC 1738, December 1994 Carrel [Page5] INTERNET DRAFT May 2000 Appendix A TAG_TYPES and TAG_VALUES 0x0111 HURL This TAG MAY be added to PADM packets by the Access Concentrator. It contains a URL that the Host MAY pass to a web browser for presentation to the user. The TAG_VALUE contains a standard URL [5]. It is an UTF-8 string which is not NULL terminated. 0x0112 MOTM This TAG MAY be added to PADM packets by the Access Concentrator. It contains a Message Of The Minute (MOTM) that the Host MAY display to the user. The TAG_VALUE contains an UTF-8 string which is not NULL terminated. It is a text message that is presentable to the user on the Host. 0x0121 IP_ROUTE_ADD This TAG MAY be added to PADN packets by the Access Concentrator. It contains a IP route that MAY be used by the Host to populate it's routing table. The behavior of PPP is not defined in terms of what routes should be installed if multiple concurrent PPP sessions exist. Many client implementations will install a default route but that only works if one PPP session is active. When multiple PPPoE sessions are active, the IP_ROUTE_ADD TAG can provide a more granular set of routes to the client. The TAG_VALUE contains four 32 bit integers in network byte order. The first integer contains a destination network number and the second contains a destination network mask. The third integer contains the gateway IP address. The fourth integer contains a metric value. The destination of the route is always assumed to be the remote end of the PPP link. If the first two integers are zero this indicates a default route. In general the gateway IP address will be the same as the Access Concentrator's IP address on that PPP session, because use of this tag is only intended to provide routing information about the first hop (ie. which PPP interface the client should use). Any routes installed as a result of the IP_ROUTE_ADD TAG being received, SHOULD be removed when the PPPoE session terminates. Carrel [Page6] INTERNET DRAFT May 2000 Appendix B The following are some example packets: A PADM packet: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host_mac_addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host_mac_addr (cont) | Access_Concentrator_mac_addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access_Concentrator_mac_addr (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0xd3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SESSION_ID = 0xNNNN | LENGTH = 0x001a | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG_TYPE = 0x0111 | TAG_LENGTH = 0x0016 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x68 | 0x74 | 0x74 | 0x70 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x3a | 0x2f | 0x2f | 0x77 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x77 | 0x77 | 0x2e | 0x72 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x65 | 0x64 | 0x62 | 0x61 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x63 | 0x6b | 0x2e | 0x63 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x6f | 0x6d | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrel [Page7] INTERNET DRAFT May 2000 A PADN packet: This contains two IP_ROUTE_ADD TAGs. The first is the route "10.1.1.0 255.255.255.0". The second is "20.2.0.0 255.255.0.0". The Access Concentrator's IP address for the PPPoE session is 10.1.1.1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host_mac_addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host_mac_addr (cont) | Access_Concentrator_mac_addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access_Concentrator_mac_addr (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETHER_TYPE = 0x8863 | v = 1 | t = 1 | CODE = 0xd4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SESSION_ID = 0xNNNN | LENGTH = 0x0028 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG_TYPE = 0x0121 | TAG_LENGTH = 0x0010 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0a010100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xffffff00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0a010101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00000001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAG_TYPE = 0x0121 | TAG_LENGTH = 0x0010 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x14020000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xffff0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0a010101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00000001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Carrel [Page8] INTERNET DRAFT May 2000 Authors' Addresses: David Carrel Dan Simone Che-Lin Ho Tom Stoner Redback Networks, Inc. 350 Holger Way San Jose, CA 95134 United States of America Carrel [Page9] -----Original Message----- From: Vernon Schryver To: ietf-ppp@merit.edu Sent: 5/12/03 4:45 PM Subject: Re: Extending IPCP for Route Table Entries > From: Doug Kehn > I would like to open a discussion on the possibilities for extending IPCP to > allow the negotiation of route table entries. The topic of adding route > information to PPP has been brought up in the DSL Forum. However, to the > best of my knowledge, the DSL Forum has not approached the IETF regarding > this topic. Currently, some PPPoE capable BRASs have implemented PADN (see > draft-carrel-info-pppoe-ext-00.txt) as a way a add route information over > PPP links. This facility only suffices the need for PPPoE links. A more > general approach would be to extend PPP itself. To jump start the > discussion, I've included a draft RFC (see below) that oulines a method for > extending IPCP that might be used to fulfill the need. Let's put our collective feet down and stop allowing such bad ideas. It makes no sense to extend IPCP to carry routes. There are plenty of existing standards for that. For example, you could do what has been done for literally decades and use RIP. You could even use authentication in RIPv2. If you don't like RIP, you can use Router-Discovery, OSPF, BGP, and a zillion other routing protocols. I can't seem to find draft-carrel-info-pppoe-ext-00.txt or anything with the string "carrel" on ftp.isi.edu. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Mon May 12 18:36:15 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id BE4E85DEFA; Mon, 12 May 2003 18:36:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4BAF091268; Mon, 12 May 2003 18:36:02 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B3B891269; Mon, 12 May 2003 18:36:02 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2FD3091268 for ; Mon, 12 May 2003 18:36:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0FB215DF07; Mon, 12 May 2003 18:36:01 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 850215DF06 for ; Mon, 12 May 2003 18:36:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4CMEgC16226; Mon, 12 May 2003 15:14:42 -0700 Date: Mon, 12 May 2003 15:14:42 -0700 (PDT) From: Bernard Aboba To: Doug Kehn Cc: "'Vernon Schryver '" , "'ietf-ppp@merit.edu '" Subject: RE: Extending IPCP for Route Table Entries In-Reply-To: Message-ID: References: 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 > I agree with your comments. However, most service providers don't use the > available routing protocols (???). I believe it would be okay to "put our > collective feet down and stop allowing such bad ideas." But until it is > done so publicly, rogue protocol extensions may prevail (i.e. I've yet to > find an RFC for IPCP option 144). I believe that "putting our collective feet down" would require a change in the IANA allocations policy for IPCP code points. Today this is "first come first served", no? We now have the following proposals for (additional) uses of IPCP: http://www.ietf.org/internet-drafts/draft-song-pppext-sip-support-02.txt http://www.ietf.org/internet-drafts/draft-song-pppext-mipv6-support-00.txt http://www.ietf.org/internet-drafts/draft-ietf-pppext-ipv6-dns-addr-01.txt From owner-ietf-ppp@merit.edu Mon May 12 21:28:11 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 4FA315DF7A; Mon, 12 May 2003 21:28:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A9EC9126A; Mon, 12 May 2003 21:27:57 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A3449126B; Mon, 12 May 2003 21:27:57 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A32A9126A for ; Mon, 12 May 2003 21:27:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3A935DF7A; Mon, 12 May 2003 21:27:56 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 27F675DEB6 for ; Mon, 12 May 2003 21:27:55 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4D1RsuR008158 for ietf-ppp@merit.edu env-from ; Mon, 12 May 2003 19:27:54 -0600 (MDT) Date: Mon, 12 May 2003 19:27:54 -0600 (MDT) From: Vernon Schryver Message-Id: <200305130127.h4D1RsuR008158@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Doug Kehn > I agree with your comments. However, most service providers don't use the > available routing protocols (???). On the contrary, almost all service providers use the available routing protocols somewhere, even if not on their end-user PPP links. What hardware can't announce a RIP route? What hardware that might support such a new option could not at least as easily synthesize a RIP announcement. > I believe it would be okay to "put our > collective feet down and stop allowing such bad ideas." But until it is > done so publicly, rogue protocol extensions may prevail (i.e. I've yet to > find an RFC for IPCP option 144). > > My goal was to come up with an admissible solution/compromise at the PPP > layer or to have the working group put its foot and say no. I would hate > for another non-IETF sanctioned protocol extension prevail. An RFC saying "STOP BEING STUPID" would be a good idea. > I've included the draft-carrel-info-pppoe-ext-00.txt for your review. sheesh... The May 2000 date of that draft gives me a little hope that it got squelched outside Redback's customers. It was "Informational." Among the problems with putting routing into IPCP is that it is cannot advertise the route more than once, because you really don't want to re-negotiate IPCP more than once, because so much of this drek hardware is junk and cannot. But if you only announce the route once, then you may as well do what PPP implementations have done since before there was PPP and there was only SLIP. That is to install a default route to the PPP (or SLIP) peer. ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ] From: Bernard Aboba ] ... ] I believe that "putting our collective feet down" would require a change ] in the IANA allocations policy for IPCP code points. Today this is "first ] come first served", no? Why do you say that IPCP types are "first come first served"? I thought we fixed that problem that a long time ago. On http://www.iana.org/numbers.html I see something about ordering PPP protocol numbers, but nothing about IPCP. ] We now have the following proposals for (additional) uses of IPCP: ] ] http://www.ietf.org/internet-drafts/draft-song-pppext-sip-support-02.txt ] http://www.ietf.org/internet-drafts/draft-song-pppext-mipv6-support-00.txt ] http://www.ietf.org/internet-drafts/draft-ietf-pppext-ipv6-dns-addr-01.txt The IPv6 DNS extension is a mistake, but probably forced on us because we failed to stop Microsoft from perpetrating the IPv4 predecessor. The other two have expired and are about to expire. Why are those other two drafts more persuasive or "standard" than the following: http://www.ietf.org/internet-drafts/draft-terrell-iptx-dns-req-iptx-ip-add-spec-03.pdf http://www.ietf.org/internet-drafts/draft-terrell-math-quant-new-para-redefi-bin-math-04.pdf Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Mon May 12 22:10:23 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 1D2405DF88; Mon, 12 May 2003 22:10:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A4BDE9126B; Mon, 12 May 2003 22:10:09 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C2CD9126C; Mon, 12 May 2003 22:10:09 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7084A9126B for ; Mon, 12 May 2003 22:10:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 606315DF57; Mon, 12 May 2003 22:10:08 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 520695DEA6 for ; Mon, 12 May 2003 22:10:07 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4D2A6lk017052 for ietf-ppp@merit.edu env-from ; Mon, 12 May 2003 20:10:06 -0600 (MDT) Date: Mon, 12 May 2003 20:10:06 -0600 (MDT) From: Vernon Schryver Message-Id: <200305130210.h4D2A6lk017052@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries References: <200305130159.SAA10275@grigri.eng.ascend.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Ignacio Goyret > >An RFC saying "STOP BEING STUPID" would be a good idea. > > :-) > > Should that be "informational" or "standard track" ? STOP BEING STUPID might be a little ambitious. However, it would be good to have an official standards track document that says "keep upper layer stuff in upper layers" and gives examples including using DHCP (ugh), RIP, or IRDP for routing, DNS for DNS, SMTP for mail, LDAP for names, and so forth. > >> I've included the draft-carrel-info-pppoe-ext-00.txt for your review. > > > >sheesh... > >The May 2000 date of that draft gives me a little hope that it got > >squelched outside Redback's customers. It was "Informational." > > See RFC 2516. For better or worse, it made it through. at least only as Informational. > For the record, I agree with Vernon: IPCP is not the place for these things. > As he mentioned, there are a number of good alternatives. > > I guess if push comes to shove, even DHCP could be used if someone really > insists on this being "configurable"... well, yes, if you see "configurable" as somehow incompatible with routing protocols. (Yes, I've noticed the new DHCP routing option.) Oh, well, give us a few more years and we'll recapitulate the ISO OSI suite. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 13 02:05:38 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 034EA5E01E; Tue, 13 May 2003 02:05:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 183019126E; Tue, 13 May 2003 02:05:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDE929126F; Tue, 13 May 2003 02:05:23 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A7F179126E for ; Tue, 13 May 2003 02:05:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 915D45E026; Tue, 13 May 2003 02:05:21 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 1C6B75E01E for ; Tue, 13 May 2003 02:05:21 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4D6540J003099; Tue, 13 May 2003 08:05:04 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 13 May 2003 08:05:17 +0200 Message-ID: From: "Jari Arkko (LMF)" To: "'Bernard Aboba'" , Doug Kehn Cc: "'Vernon Schryver '" , "'ietf-ppp@merit.edu '" Subject: RE: Extending IPCP for Route Table Entries Date: Tue, 13 May 2003 08:04:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > http://www.ietf.org/internet-drafts/draft-song-pppext-mipv6-support-00.txt I could have misunderstood the purpose of this draft, but it appears to be against the architectural principles in Mobile IPv6, i.e. that no special support from the local routers is needed. Furthermore, if the access provider wishes to "differentiate" customers by offering some of them the possibility of using Mobile IPv6 and some of them not, a "better" way of doing that would be to install a filter at the access router for blocking some traffic for the poor users in the lower category... --Jari From owner-ietf-ppp@merit.edu Tue May 13 10:43:39 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id C73215DDA9; Tue, 13 May 2003 10:43:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C035491284; Tue, 13 May 2003 10:43:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93B4891285; Tue, 13 May 2003 10:43:24 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6365A91284 for ; Tue, 13 May 2003 10:43:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7119C5DDA9; Tue, 13 May 2003 10:43:22 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from david.siemens.com (david.siemens.com [194.138.160.5]) by segue.merit.edu (Postfix) with ESMTP id 0742B5DDA8 for ; Tue, 13 May 2003 10:43:22 -0400 (EDT) Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4]) by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4DEhNG28005; Tue, 13 May 2003 10:43:23 -0400 (EDT) Received: from yogi.inside.efficient.com ([165.218.188.2]) by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4DEhMF13775; Tue, 13 May 2003 10:43:22 -0400 (EDT) Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 May 2003 09:43:19 -0500 Message-ID: From: Doug Kehn To: "'Vernon Schryver '" , "'ietf-ppp@merit.edu '" Subject: RE: Extending IPCP for Route Table Entries Date: Tue, 13 May 2003 09:43:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Vernon, It is the end-user PPP links that are being addressed here. The usage is a broadband CPE router residing in the home. The CPE terminates the PPP interface and must route packets between the WAN (PPP interface) and the LAN. The LAN is using private IP addresses (from the CPEs DHCP server) and the CPE utilizes NAPT to translate the private LAN IP addresses to the public IP address of the PPP interface. If there is only a single PPP interface, there is no problem. The CPEs default route is the one and only PPP interface. However, in the presence of multiple PPP interfaces, which interface interface does the router choose to route the packet? The default route of course. But, what if the default route is not the correct path for the packet? Extending the scenario assume the CPE has two PPP interfaces. One interface is to the Internet and is the router's default route. The other PPP interface is to an isolated network that the Service Provider provisions for additional services (gaming, video, etc). PPP is logical choice for the additional services interface because tracking/billing services are already available. Without any routing information, the router will route all packets to the default route (unless the packets are destined to the remote peer of the additional services PPP interface). The Service Provider may wish to put several servers in the additional services network; thus, sending packets to the remote peer won't reach the desired server. Now the router needs routing information so that it can ensure packets are routed to the correct PPP interface. RIP (or another routing protocol) would suffice. However, my gut feeling is that Service Providers see the use of a routing protocol as overkill. All that is needed is a static route (most likely a single route entry) so that the CPE can properly route packets to the additional services PPP interface. Furthermore, the route only needs to exist as long the PPP interface exists. Thanks... doug BTW, we work with 15-20 service providers world wide and only 1 has a routing protocol (RIP) enabled in the CPE. -----Original Message----- From: Vernon Schryver To: ietf-ppp@merit.edu Sent: 5/12/03 8:27 PM Subject: RE: Extending IPCP for Route Table Entries > From: Doug Kehn > I agree with your comments. However, most service providers don't use the > available routing protocols (???). On the contrary, almost all service providers use the available routing protocols somewhere, even if not on their end-user PPP links. What hardware can't announce a RIP route? What hardware that might support such a new option could not at least as easily synthesize a RIP announcement. > I believe it would be okay to "put our > collective feet down and stop allowing such bad ideas." But until it is > done so publicly, rogue protocol extensions may prevail (i.e. I've yet to > find an RFC for IPCP option 144). > > My goal was to come up with an admissible solution/compromise at the PPP > layer or to have the working group put its foot and say no. I would hate > for another non-IETF sanctioned protocol extension prevail. An RFC saying "STOP BEING STUPID" would be a good idea. > I've included the draft-carrel-info-pppoe-ext-00.txt for your review. sheesh... The May 2000 date of that draft gives me a little hope that it got squelched outside Redback's customers. It was "Informational." Among the problems with putting routing into IPCP is that it is cannot advertise the route more than once, because you really don't want to re-negotiate IPCP more than once, because so much of this drek hardware is junk and cannot. But if you only announce the route once, then you may as well do what PPP implementations have done since before there was PPP and there was only SLIP. That is to install a default route to the PPP (or SLIP) peer. ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ] From: Bernard Aboba ] ... ] I believe that "putting our collective feet down" would require a change ] in the IANA allocations policy for IPCP code points. Today this is "first ] come first served", no? Why do you say that IPCP types are "first come first served"? I thought we fixed that problem that a long time ago. On http://www.iana.org/numbers.html I see something about ordering PPP protocol numbers, but nothing about IPCP. ] We now have the following proposals for (additional) uses of IPCP: ] ] http://www.ietf.org/internet-drafts/draft-song-pppext-sip-support-02.txt ] http://www.ietf.org/internet-drafts/draft-song-pppext-mipv6-support-00.t xt ] http://www.ietf.org/internet-drafts/draft-ietf-pppext-ipv6-dns-addr-01.t xt The IPv6 DNS extension is a mistake, but probably forced on us because we failed to stop Microsoft from perpetrating the IPv4 predecessor. The other two have expired and are about to expire. Why are those other two drafts more persuasive or "standard" than the following: http://www.ietf.org/internet-drafts/draft-terrell-iptx-dns-req-iptx-ip-a dd-spec-03.pdf http://www.ietf.org/internet-drafts/draft-terrell-math-quant-new-para-re defi-bin-math-04.pdf Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 13 10:58:13 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id A677A5DDB5; Tue, 13 May 2003 10:58:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED62491285; Tue, 13 May 2003 10:57:59 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8C2691286; Tue, 13 May 2003 10:57:58 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E8C091285 for ; Tue, 13 May 2003 10:57:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 790DE5DDB1; Tue, 13 May 2003 10:57:57 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 95E745DDA9 for ; Tue, 13 May 2003 10:57:56 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4DEvtXQ011434 for ietf-ppp@merit.edu env-from ; Tue, 13 May 2003 08:57:55 -0600 (MDT) Date: Tue, 13 May 2003 08:57:55 -0600 (MDT) From: Vernon Schryver Message-Id: <200305131457.h4DEvtXQ011434@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Doug Kehn > It is the end-user PPP links that are being addressed here. The usage is a > broadband CPE router residing in the home. The CPE terminates the PPP > interface and must route packets between the WAN (PPP interface) and the > LAN. The LAN is using private IP addresses (from the CPEs DHCP server) and > the CPE utilizes NAPT to translate the private LAN IP addresses to the > public IP address of the PPP interface. If there is only a single PPP > interface, there is no problem. The CPEs default route is the one and only > PPP interface. However, in the presence of multiple PPP interfaces, which > interface interface does the router choose to route the packet? The default > route of course. But, what if the default route is not the correct path for > the packet? That problem has absolutely nothing to do with PPP. We've been dealing with that problem for literally decades. It's what routing protocols are all about. Even before there was PPP, people had boxes with multiple interfaces, such as a LAN and a dynamically dialed SLIP link. > Extending the scenario assume the CPE has two PPP interfaces. One interface > is to the Internet and is the router's default route. The other PPP > interface is to an isolated network that the Service Provider provisions for > additional services (gaming, video, etc). PPP is logical choice for the > additional services interface because tracking/billing services are already > available. Without any routing information, the router will route all > packets to the default route (unless the packets are destined to the remote > peer of the additional services PPP interface). The Service Provider may > wish to put several servers in the additional services network; thus, > sending packets to the remote peer won't reach the desired server. Now the > router needs routing information so that it can ensure packets are routed to > the correct PPP interface. That sounds like a need for far fancier routing than that proposed. Have the advocates for this proposal looked at "policy routing"? > RIP (or another routing protocol) would suffice. However, my gut feeling is > that Service Providers see the use of a routing protocol as overkill. All > that is needed is a static route (most likely a single route entry) so that > the CPE can properly route packets to the additional services PPP interface. > Furthermore, the route only needs to exist as long the PPP interface exists. As I said before, reasonable PPP and SLIP implementations have for literally decades installed routes as needed when their links came up. For just as long, people have also used RIP for the same purpose. For example, the `routed` code in common UNIX flavors including IRIX, Solaris, FreeBSD, and NetBSD can notice when an interface appears and advertise a route. > BTW, we work with 15-20 service providers world wide and only 1 has a > routing protocol (RIP) enabled in the CPE. There is a difference between fully enabling RIP and enabling RIP to advertise a default route. The first can adventurous, because it implies listening to whatever RIP packets come from the customer. The second is quite safe. It's a standard feature in many PPP boxes precisely for this purpose of telling CPE where to send packets. Besides, if your 14-19 providers have turned off RIP, it would be wrong to sneak an ad hoc not-really routing protocol into PPP in order to subvert their decision to turn off routing. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed May 14 14:06:48 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 699525E195; Wed, 14 May 2003 14:06:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A887F912A4; Wed, 14 May 2003 14:06:33 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75EA9912A6; Wed, 14 May 2003 14:06:33 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64110912A4 for ; Wed, 14 May 2003 14:06:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A0375E195; Wed, 14 May 2003 14:06:32 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 50D665E190 for ; Wed, 14 May 2003 14:06:15 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4EI5spt026363 for ietf-ppp@merit.edu env-from ; Wed, 14 May 2003 12:05:54 -0600 (MDT) Date: Wed, 14 May 2003 12:05:54 -0600 (MDT) From: Vernon Schryver Message-Id: <200305141805.h4EI5spt026363@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Extending IPCP for Route Table Entries References: <3EC27CBF.4080501@heeltoe.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Brad Parker > ... > Ah. I think you're missing the point Vern. He's got an operational > problem which he's trying to fix by using the protocol at hand. I think > it's a reasonable thing he wants to do. It's a priori reasonable only if you endorse seeing all of the world as a nail because the only tool of the several in your toolbox that you how to use is a hammer. If the thinking in this proposal is so good, then let's get rid of IP, UDP, TCP, DNS, SNMP, and all application protocols. Seriously, why draw the line at routing? > [aside: I've worked at an ISP and I've shipped datacom/router boxes. > It's sometimes helpful to view both sides of this rather than being > entirely dogmatic.] It's also good to recognize dogmatism of all flavers. Besides the dogma of insisting on using routing protocols for routing, there is the "all the world's a link layer since that's all I can affect" dogma that has long been popular among people coming to this mailing list. > If I heard correctly, RIP could be used, but waiting for RIP packets to > come across the link and then adding routes based on them is cumbersom, > slow and not completely reliable (or safe). I think that's mistaken. - waiting for RIP packets to cross the link should not be more than milliseconds, which is insignificant. If you really care about those milliseconds, you can make the delay microseconds by transmitting the RIP packet immediately after your IPCP packets in anticipation of the PPP peer liking your IPCP bits. - it's good to wait to add the route until after the IP machinery is really alive, and a RIP/UDP/IP packet is a good sign of that. - adding routes based on a RIP packet is no slower or more cumbersome than adding routes with any other mechanism. - I can't see any lack of safety in this case. You'd check that the IP destination address is yours, the source address is the PPP peer's, the route is a default with next hop address also equal to the PPP peer's, and probably ignore the metric. - I can't see any lack of reliability in adding routes based on RIP packets > Adding a static route when > the link is brought up makes a lot of sense, at least from the > operational side. I've written and used code that adds and removes routes with the link state change as well as code that does the same with RIP. The main problem with adding adding routes with the link state change is that it sometimes conflicts with real routing. > > I'd solve this by adding a private option to the IPCP packet, myself. > It's not negotiating a dynamic route, so it's doesn't overlap with a > routing protocol. It's just negotiating a default route. One per > interface. (at least that's what I heard). One of the things that irritates me about this proposal is that there is little or nothing I can see to "negotiate." When would the route ever point to an IP address other than the IP address of the PPP peer? If the route ever did point to some other IP address, it would be an bogus route. The box already knows its own and its peer's IP addresses, so any IPCP bit cannot say anything useful. When would the PPP peer ever issue an IPCP NAK or REJ? If never, it's not much of a "negotiation." Another problem is that it's got the notion of who is negotiating with whom partly backwards. The PPP peer that would send say "route through me" can only really say "if you wanted, you could route through me." Only the other peer can know whether it needs a default route. > I assume the requirement is a single net number with a mask. yes? What does a netmask have to do with a default route? And again, the IP address of the router could never differ from the IP address already negotiated with IPCP. The proposal could be boiled down into a single bit saying "I've got routes to the universe and I'm willing to forward your packets." > If the requirement were multiple routes and/or the routes were dynamic > I'd say ok to RIP, OSPF, etc... (btw: have you ever deployed OSPF or RIP > on a dial-in box with 2000 interfaces? I have. It can be, ahem, > difficult to manage. ahem. please pass the motrin. ] Ever hear of the story about the camel's nose? My reading of the requirements are that they want far more than a single, simple default route. When they realize that, another IPCP option will be proposed with a single traffic type value. When that is discovered to be simplistic for policy routing, there will be another proposal, and so forth. > > That sounds like a need for far fancier routing than that proposed. > > Have the advocates for this proposal looked at "policy routing"? > > Your point about policy is a good one. I suspect there is some policy > involved (i.e. packet classification, etc...) But having said that I'm > not sure it matters for this discussion. On the contrary, if the proposal does not satisfy its osstensible requirements, then it should be rejected on those grounds alone. > >>BTW, we work with 15-20 service providers world wide and only 1 has a > >>routing protocol (RIP) enabled in the CPE. > > I'm actually suprised anyone would do this. The "1" must be brave (or > foolish; sometimes the same thing :-) > > > Besides, if your 14-19 providers have turned off RIP, it would be > > wrong to sneak an ad hoc not-really routing protocol into PPP in order > > to subvert their decision to turn off routing. > > I think he's responding to their need, not subverting their decision. I > suspect they're asking for this... (voice of the market, etc... blah blah) I suspect that there is some confusion about what those 15-20 customers really want and are really doing. I bet the one customer using RIP is not foolish or brave but is using it only for the usual, entirely safe purpose of announcing default routes. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed May 14 14:29:41 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 267A95E1A9; Wed, 14 May 2003 14:29:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 78107912A6; Wed, 14 May 2003 14:27:43 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35112912A7; Wed, 14 May 2003 14:27:43 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 891FB912A6 for ; Wed, 14 May 2003 14:27:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 696675E1A9; Wed, 14 May 2003 14:27:38 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by segue.merit.edu (Postfix) with ESMTP id F36015E1A8 for ; Wed, 14 May 2003 14:27:37 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EIRTkc187812; Wed, 14 May 2003 14:27:29 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-210-236.mts.ibm.com [9.65.210.236]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EIRSBO026664; Wed, 14 May 2003 12:27:28 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EIRIZ05372; Wed, 14 May 2003 14:27:18 -0400 Message-Id: <200305141827.h4EIRIZ05372@cichlid.adsl.duke.edu> To: "Bernard Aboba" Cc: "'ietf-ppp@merit.edu '" Subject: Reigning in "bad" extensions to PPP In-Reply-To: Message from aboba@internaut.com of "Mon, 12 May 2003 15:14:42 PDT." Date: Wed, 14 May 2003 14:27:18 -0400 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > I believe that "putting our collective feet down" would require a change > in the IANA allocations policy for IPCP code points. Today this is "first > come first served", no? Bernard is right, unfortunately. IMO, a document for PPP IANA Considerations is needed. At a minimum, an IANA considerations document would define when and under what conditions IANA should allocate code points. Right now, there are some nume spaces where anyone can get a code point just by asking. It would be quite reasonable for the WG to say "for standards track only" for some of the number spaces, for example. For a recent example of how to do this, see draft-aboba-radius-iana-07.txt, which the IESG approved recently. If you want to reign in bad uses of PPP, there are ways of documenting that too, but it's a bit more work. One possible example is: RFC 3427 "Change Process for the Session Initiation Protocol (SIP)" That document contains the steps that must be followed for extending SIP. Having such documents makes it a lot easier for the IESG to say "no" to bad requests, since we would be speaking for the PPP community. Thomas From owner-ietf-ppp@merit.edu Wed May 14 14:33:10 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id C069E5E1B1; Wed, 14 May 2003 14:33:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D869912A7; Wed, 14 May 2003 14:33:02 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC8F0912A8; Wed, 14 May 2003 14:33:01 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 096B4912A7 for ; Wed, 14 May 2003 14:32:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDA495E1B0; Wed, 14 May 2003 14:32:34 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by segue.merit.edu (Postfix) with ESMTP id 73D3F5E196 for ; Wed, 14 May 2003 14:32:34 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EIWXQs216064 for ; Wed, 14 May 2003 14:32:33 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-210-236.mts.ibm.com [9.65.210.236]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EIWWBO047718 for ; Wed, 14 May 2003 12:32:33 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EIWMU05388 for ; Wed, 14 May 2003 14:32:22 -0400 Message-Id: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu> To: ietf-ppp@merit.edu Subject: draft-song-pppext-sip-support-02.txt Date: Wed, 14 May 2003 14:32:22 -0400 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Speaking of which, the RFC editor has received a request to publish the above document as an informational RFC. What does this WG think of this request? Should the RFC editor publish this document? Or would doing so be an end-run around this WG? Thomas From owner-ietf-ppp@merit.edu Wed May 14 14:36:14 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 03B655E1BD; Wed, 14 May 2003 14:36:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3301912A8; Wed, 14 May 2003 14:36:01 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C879912A9; Wed, 14 May 2003 14:36:01 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6EF72912A8 for ; Wed, 14 May 2003 14:36:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C7D95E1BE; Wed, 14 May 2003 14:36:00 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id E96675E1BD for ; Wed, 14 May 2003 14:35:55 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4EIZt0L011006 for ietf-ppp@merit.edu env-from ; Wed, 14 May 2003 12:35:55 -0600 (MDT) Date: Wed, 14 May 2003 12:35:55 -0600 (MDT) From: Vernon Schryver Message-Id: <200305141835.h4EIZt0L011006@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Reigning in "bad" extensions to PPP References: <200305141827.h4EIRIZ05372@cichlid.adsl.duke.edu> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Thomas Narten > > I believe that "putting our collective feet down" would require a change > > in the IANA allocations policy for IPCP code points. Today this is "first > > come first served", no? > > Bernard is right, unfortunately. Ouch! > IMO, a document for PPP IANA Considerations is needed. At a minimum, > an IANA considerations document would define when and under what > conditions IANA should allocate code points. Right now, there are some > nume spaces where anyone can get a code point just by asking. It would > be quite reasonable for the WG to say "for standards track only" for > some of the number spaces, for example. For a recent example of how to > do this, see draft-aboba-radius-iana-07.txt, which the IESG approved > recently. Could we do this for all of the PPP state machines with a single document? This seems like a worthwhile effort that should be done immediately. > If you want to reign in bad uses of PPP, there are ways of documenting > that too, but it's a bit more work. One possible example is: > > RFC 3427 "Change Process for the Session Initiation Protocol (SIP)" > > That document contains the steps that must be followed for extending > SIP. Having such documents makes it a lot easier for the IESG to say > "no" to bad requests, since we would be speaking for the PPP > community. There are a lot of words in RFC 3427. Some, such as those about X-headers don't seem relevant. Perhaps it would be sufficent to corral all of the PPP (sub)option numbers. What do we need to do to get at least that started? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed May 14 14:43:41 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 0D0495E1B5; Wed, 14 May 2003 14:43:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 390F0912A9; Wed, 14 May 2003 14:43:27 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A7F3912AA; Wed, 14 May 2003 14:43:26 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 234B0912A9 for ; Wed, 14 May 2003 14:43:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BC1D5E1B4; Wed, 14 May 2003 14:43:26 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8AD995E1B1 for ; Wed, 14 May 2003 14:43:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4EIM7t02887; Wed, 14 May 2003 11:22:08 -0700 Date: Wed, 14 May 2003 11:22:07 -0700 (PDT) From: Bernard Aboba To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: Reigning in "bad" extensions to PPP In-Reply-To: <200305141835.h4EIZt0L011006@calcite.rhyolite.com> Message-ID: References: <200305141827.h4EIRIZ05372@cichlid.adsl.duke.edu> <200305141835.h4EIZt0L011006@calcite.rhyolite.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 > Could we do this for all of the PPP state machines with a single > document? This seems like a worthwhile effort that should be done > immediately. Sure. Just write a document called "IANA Consideration for PPP", and describe the procedures for assignment of each of the parameters. It's not all that hard -- you can look at draft-aboba-radius-iana-07.txt as an example. In that document we took some of the first come first served parameters that had been abused and made allocation require review. From owner-ietf-ppp@merit.edu Wed May 14 14:43:57 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 0AEF95E1B4; Wed, 14 May 2003 14:43:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F26E912AB; Wed, 14 May 2003 14:43:51 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 422AA912AA; Wed, 14 May 2003 14:43:51 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73821912BE for ; Wed, 14 May 2003 14:43:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 580045E1B4; Wed, 14 May 2003 14:43:46 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 416A65E1B1 for ; Wed, 14 May 2003 14:43:45 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4EIhiZv012331 for ietf-ppp@merit.edu env-from ; Wed, 14 May 2003 12:43:44 -0600 (MDT) Date: Wed, 14 May 2003 12:43:44 -0600 (MDT) From: Vernon Schryver Message-Id: <200305141843.h4EIhiZv012331@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: draft-song-pppext-sip-support-02.txt References: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Thomas Narten > > Speaking of which, the RFC editor has received a request to publish > the above document as an informational RFC. > > What does this WG think of this request? Should the RFC editor publish > this document? Or would doing so be an end-run around this WG? Ugh. No. Yes. The proposal makes no sense. Unless SIP Is utterly broken, there must be other means for discovering SIP proxy servers besides special link-layer kludges. What happens on other point to point links that don't use PPP? What about point-to-point links that use PPP but not IPCP, such as only BCP? Besides, this proposal could not and would not be widely deployed for a long time. Unless SIP is utterly broken, those othe mechanisms, whatever they are, must render this mechanism irrelevant. It's not a coincidence that proposal to stuff routing or at least router discovery into IPCP cited this proposal as a precedent. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed May 14 14:53:40 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id D595D5E1C1; Wed, 14 May 2003 14:53:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B29F3912AA; Wed, 14 May 2003 14:53:26 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84039912AC; Wed, 14 May 2003 14:53:26 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4F90912AA for ; Wed, 14 May 2003 14:53:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 892B75E1C1; Wed, 14 May 2003 14:53:25 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id F3E205E1B4 for ; Wed, 14 May 2003 14:53:24 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4EIW7v03510; Wed, 14 May 2003 11:32:07 -0700 Date: Wed, 14 May 2003 11:32:07 -0700 (PDT) From: Bernard Aboba To: Thomas Narten Cc: ietf-ppp@merit.edu Subject: Re: draft-song-pppext-sip-support-02.txt In-Reply-To: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu> Message-ID: References: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu> 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 Personally, I don't care much for this document. It seems to me that allowing configuration mechanisms to proliferate isn't helpful. First off, it means that devices may have to implement multiple mechanisms, since they can't be sure that they can get the required configuration via a single mechanism. Since they might need PPP IPCP, or maybe DHCP, or maybe something else, you have to implement all of them -- if you want to interoperate. More likely, the device chooses a single mechanism, which means that it won't work in a heterogenous vendor environment. Great -- multiple IETF standards, but no true interoperability. Then there is the potential for conflict. What if DHCP doesn't agree with IPCP? What about security? IPCP isn't secured -- though DHCP might be. Once upon a time, the logic for IPCP extension support was that implementing DHCP service in the ISP network would increase access latency and furthermore was an implementation burden, so that the user experience would be better and ISP deployment would be easier if configuration could be done by the authenticator. However, with DHCPINFORM it is possible for an authenticator to implement a stateless server so that it isn't required for the ISP to implement DHCP in their network. The latency argument doesn't hold anymore either. On Wed, 14 May 2003, Thomas Narten wrote: > Speaking of which, the RFC editor has received a request to publish > the above document as an informational RFC. > > What does this WG think of this request? Should the RFC editor publish > this document? Or would doing so be an end-run around this WG? > > Thomas > From owner-ietf-ppp@merit.edu Wed May 14 15:26:40 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 8DBE05E1D7; Wed, 14 May 2003 15:26:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 85700912AE; Wed, 14 May 2003 15:26:26 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50C0F912AF; Wed, 14 May 2003 15:26:26 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 533EE912AE for ; Wed, 14 May 2003 15:26:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3018B5E1C8; Wed, 14 May 2003 15:26:25 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by segue.merit.edu (Postfix) with ESMTP id 8DA1F5E1DE for ; Wed, 14 May 2003 15:26:24 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EJQEkc294214; Wed, 14 May 2003 15:26:14 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-210-236.mts.ibm.com [9.65.210.236]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EJQDBO039536; Wed, 14 May 2003 13:26:13 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EJQ3L07231; Wed, 14 May 2003 15:26:03 -0400 Message-Id: <200305141926.h4EJQ3L07231@cichlid.adsl.duke.edu> To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: Reigning in "bad" extensions to PPP In-Reply-To: Message from vjs@calcite.rhyolite.com of "Wed, 14 May 2003 12:35:55 MDT." <200305141835.h4EIZt0L011006@calcite.rhyolite.com> Date: Wed, 14 May 2003 15:26:03 -0400 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Could we do this for all of the PPP state machines with a single > document? This seems like a worthwhile effort that should be done > immediately. I agree. This gets the biggest bang for the buck. > > If you want to reign in bad uses of PPP, there are ways of documenting > > that too, but it's a bit more work. One possible example is: > > > > RFC 3427 "Change Process for the Session Initiation Protocol (SIP)" > > > > That document contains the steps that must be followed for extending > > SIP. Having such documents makes it a lot easier for the IESG to say > > "no" to bad requests, since we would be speaking for the PPP > > community. > There are a lot of words in RFC 3427. Some, such as those about X-headers > don't seem relevant. yep. Maybe enough ground can be covered in an IANA considerations document. For example, when describing the IPCP name space, one could say it is intended for link-specific PPP-specific configuration information and is not intended to be used for carrying generic stuff that can be carried by more general protocols like DHCP or RIP/OSPF. > Perhaps it would be sufficent to corral all of the PPP (sub)option numbers. > What do we need to do to get at least that started? Go to the IANA web page for PPP and look at all the name spaces. Start with a document modeled after draft-aboba-radius-iana-07.txt and have a section or sub-section for each name space and say what the policy should be for each of them and under what conditions an allocation is appropriate (Reading RFC 2434 is probably also a good thing at this point). The key thing it to ensure that sufficient review takes place by someone familiar with PPP before an assignment is allowed that might lead to "abuse" of PPP. Thomas From owner-ietf-ppp@merit.edu Wed May 14 15:48:03 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 863C95E1E8; Wed, 14 May 2003 15:48:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 813D5912AF; Wed, 14 May 2003 15:47:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E9CA912B0; Wed, 14 May 2003 15:47:56 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06BC5912AF for ; Wed, 14 May 2003 15:47:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D7CBC5E1E6; Wed, 14 May 2003 15:47:43 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from david.siemens.com (david.siemens.com [194.138.160.5]) by segue.merit.edu (Postfix) with ESMTP id 6D5CA5E1E4 for ; Wed, 14 May 2003 15:47:43 -0400 (EDT) Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4]) by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4EJli117872; Wed, 14 May 2003 15:47:44 -0400 (EDT) Received: from bambam.inside.efficient.com ([165.218.188.5]) by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4EJlgF25386; Wed, 14 May 2003 15:47:43 -0400 (EDT) Received: by bambam.inside.efficient.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 May 2003 14:47:40 -0500 Message-ID: From: Doug Kehn To: "'Thomas Narten '" Cc: "'ietf-ppp@merit.edu '" Subject: RE: Reigning in "bad" extensions to PPP Date: Wed, 14 May 2003 14:47:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas, I gather from your post that you agree that the Route-Add option proposal is a bad idea? If so, I will inform the appropriate parties that the pppext WG doesn't endorse such a proposal. What is the pppext WG stance with regard to IPCP option 144? I have yet to find an RFC or a draft describing such an option. Yet, I'm being asked (actually forced) to implement this option in order to be considered for operation in certain broadband networks. Thanks... doug -----Original Message----- From: Thomas Narten To: Vernon Schryver Cc: ietf-ppp@merit.edu Sent: 5/14/03 2:26 PM Subject: Re: Reigning in "bad" extensions to PPP > Could we do this for all of the PPP state machines with a single > document? This seems like a worthwhile effort that should be done > immediately. I agree. This gets the biggest bang for the buck. > > If you want to reign in bad uses of PPP, there are ways of documenting > > that too, but it's a bit more work. One possible example is: > > > > RFC 3427 "Change Process for the Session Initiation Protocol (SIP)" > > > > That document contains the steps that must be followed for extending > > SIP. Having such documents makes it a lot easier for the IESG to say > > "no" to bad requests, since we would be speaking for the PPP > > community. > There are a lot of words in RFC 3427. Some, such as those about X-headers > don't seem relevant. yep. Maybe enough ground can be covered in an IANA considerations document. For example, when describing the IPCP name space, one could say it is intended for link-specific PPP-specific configuration information and is not intended to be used for carrying generic stuff that can be carried by more general protocols like DHCP or RIP/OSPF. > Perhaps it would be sufficent to corral all of the PPP (sub)option numbers. > What do we need to do to get at least that started? Go to the IANA web page for PPP and look at all the name spaces. Start with a document modeled after draft-aboba-radius-iana-07.txt and have a section or sub-section for each name space and say what the policy should be for each of them and under what conditions an allocation is appropriate (Reading RFC 2434 is probably also a good thing at this point). The key thing it to ensure that sufficient review takes place by someone familiar with PPP before an assignment is allowed that might lead to "abuse" of PPP. Thomas From owner-ietf-ppp@merit.edu Thu May 15 02:38:52 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 458C95E38A; Thu, 15 May 2003 02:38:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87C5E91226; Thu, 15 May 2003 02:38:38 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 537C691228; Thu, 15 May 2003 02:38:38 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3523A91226 for ; Thu, 15 May 2003 02:38:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 137625E38C; Thu, 15 May 2003 02:38:37 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from webmail.maginet.co.kr (unknown [203.229.167.227]) by segue.merit.edu (Postfix) with ESMTP id EF9E15E38A for ; Thu, 15 May 2003 02:38:35 -0400 (EDT) Received: from gwzw2k ([218.145.160.100]) by webmail.maginet.co.kr (8.11.6/8.11.6) with ESMTP id h4F6ekQ13296; Thu, 15 May 2003 15:40:46 +0900 Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" , "'Thomas Narten'" Cc: Subject: RE: draft-song-pppext-sip-support-02.txt Date: Wed, 14 May 2003 23:38:10 -0700 Organization: Cisco Systems Message-ID: <001801c31aac$8fc252c0$1200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0019_01C31A71.E3637AC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal In-Reply-To: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C31A71.E3637AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba writes: > Personally, I don't care much for this document. > > It seems to me that allowing configuration mechanisms to proliferate > isn't helpful. Even less helpful is attempting to force all access networks to fit a single mold. > > First off, it means that devices may have to implement multiple > mechanisms, since they can't be sure that they can get the required > configuration via a single mechanism. Since they might need PPP > IPCP, or maybe DHCP, or maybe something else, you have to implement > all of them > -- if you want to interoperate. More likely, the device chooses a > single mechanism, which means that it won't work in a heterogenous > vendor environment. How does this conclusion follow? Are you claiming that no two vendors will ever implement the same set of standards? > Great -- multiple IETF standards, but no true > interoperability. your use of the term "interoperability" here seems to me to be a novel one. At the protocol level, interoperability is ensured by the correct implementation of the protocol and required features thereof, but you seem to be suggesting that "true" interoperability can only exist if all devices on the network support precisely the same protocols, implemented in exactly the same way. > > Then there is the potential for conflict. What if DHCP doesn't agree > with IPCP? If I already have the data I need (obtained through static configuration, IPCP, etc.), why am I going to ask DHCP for it? In real, existing networks, is the fact that IP addresses can be obtained through either IPCP or DHCP causing massive meltdowns? > What about security? IPCP isn't secured -- though DHCP > might be. Please excuse my ignorance: I thought that DHCP security didn't go between the client and server, just between relays and servers. > > Once upon a time, the logic for IPCP extension support was that > implementing DHCP service in the ISP network would increase access > latency and furthermore was an implementation burden, so that the > user experience would be better and ISP deployment would be easier if > configuration could be done by the authenticator. > > However, with DHCPINFORM it is possible for an authenticator to > implement a stateless server so that it isn't required for the ISP to > implement DHCP in their network. It's a long jump from "possible" to "necessary", which your definition of "true interoperability" would seem to imply. If DHCP was the only way to get config data, of course, then _every_ authenticator would have to implement the stateless server. Is that the desired outcome? > The latency argument doesn't hold > anymore either. In what environments? 802.11, Ethernet, UMTS, CDMA-2000, 14.4K dial-up? > > > On Wed, 14 May 2003, Thomas Narten wrote: > >> Speaking of which, the RFC editor has received a request to publish >> the above document as an informational RFC. >> >> What does this WG think of this request? Should the RFC editor >> publish this document? Or would doing so be an end-run around this >> WG? >> >> Thomas ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 I've stopped 24,754 spam messages. You can too! Get your free, safe spam protection at http://www.cloudmark.com/spamnetsig/ ------=_NextPart_000_0019_01C31A71.E3637AC0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_0019_01C31A71.E3637AC0-- From owner-ietf-ppp@merit.edu Thu May 15 07:34:28 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id A25F65DE66; Thu, 15 May 2003 07:34:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8090A91227; Thu, 15 May 2003 07:34:15 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E578912B5; Thu, 15 May 2003 07:34:15 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1594091227 for ; Thu, 15 May 2003 07:34:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDFBE5DE66; Thu, 15 May 2003 07:34:13 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by segue.merit.edu (Postfix) with ESMTP id 826245DE64 for ; Thu, 15 May 2003 07:34:13 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4FBY7jB011226; Thu, 15 May 2003 04:34:08 -0700 (PDT) Received: from gwzw2k (tokyo-vpn-user302.cisco.com [10.70.83.46]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id EAA08951; Thu, 15 May 2003 04:34:06 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Vernon Schryver'" , Subject: RE: draft-song-pppext-sip-support-02.txt Date: Thu, 15 May 2003 04:33:31 -0700 Organization: Cisco Systems Message-ID: <001d01c31ad5$e31cfd70$1200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001E_01C31A9B.36BFAC10" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200305141843.h4EIhiZv012331@calcite.rhyolite.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C31A9B.36BFAC10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Vernon Schryver writes: >> From: Thomas Narten >> >> Speaking of which, the RFC editor has received a request to publish >> the above document as an informational RFC. >> >> What does this WG think of this request? Should the RFC editor >> publish this document? Or would doing so be an end-run around this >> WG? > > Ugh. No. Yes. > > The proposal makes no sense. Unless SIP Is utterly broken, there > must be other means for discovering SIP proxy servers besides special > link-layer kludges. What happens on other point to point links that > don't use PPP? Who cares? > What about point-to-point links that use PPP but not > IPCP, such as only BCP? Ditto. > > Besides, this proposal could not and would not be widely deployed for > a long time. Unless SIP is utterly broken, those othe mechanisms, > whatever they are, must render this mechanism irrelevant. Vern please read the document: "This draft specifies an IPCP (PPP Internet Protocol Control Protocol) option that allows SIP clients to locate a list of SIP proxy servers that is to be used for all SIP requests. This approach is applicable to a system utilizing PPP for its link layer protocol and IP address allocation (ex. 3GPP2 Packet Data System)." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Presumably, 3GPP2 will be widely deployed in less than a long time (if not, sell your Sprint stock now ;-). Please understand that I don't much care for this idea either, but all of the arguments against it so far seem at best lame. > > It's not a coincidence that proposal to stuff routing or at least > router discovery into IPCP cited this proposal as a precedent. > > > Vernon Schryver vjs@rhyolite.com ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 I've stopped 24,754 spam messages. You can too! Get your free, safe spam protection at http://www.cloudmark.com/spamnetsig/ ------=_NextPart_000_001E_01C31A9B.36BFAC10 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_001E_01C31A9B.36BFAC10-- From owner-ietf-ppp@merit.edu Thu May 15 09:03:45 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id DABAE5DEC1; Thu, 15 May 2003 09:03:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 21A1B912B9; Thu, 15 May 2003 09:03:37 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD06C912BA; Thu, 15 May 2003 09:03:36 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D5606912B9 for ; Thu, 15 May 2003 09:03:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB7BA5DEBF; Thu, 15 May 2003 09:03:35 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C0F025DEBC for ; Thu, 15 May 2003 09:03:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FCgAr32040; Thu, 15 May 2003 05:42:10 -0700 Date: Thu, 15 May 2003 05:42:10 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: "'Thomas Narten'" , ietf-ppp@merit.edu Subject: RE: draft-song-pppext-sip-support-02.txt In-Reply-To: <001801c31aac$8fc252c0$1200000a@amer.cisco.com> Message-ID: References: <001801c31aac$8fc252c0$1200000a@amer.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 > How does this conclusion follow? Are you claiming that no two vendors > will ever implement the same set of standards? I'm claiming that requiring embedded devices to implement multiple standards may not be practical -- so they'll choose one and not interoperate instead. > your use of the term "interoperability" here seems to me to be a novel > one. At the protocol level, interoperability is ensured by the correct > implementation of the protocol and required features thereof, but you > seem to be suggesting that "true" interoperability can only exist if all > devices on the network support precisely the same protocols, implemented > in exactly the same way. If the network is only supporting one set of protocols for configuration, then the device must support that set in order to obtain configuration. If different networks use different protocols and the device is mobile, then it must support *all* the potential configuration protocols, or when it moves to some networks, it will be unable to obtain configuration. Worse yet, when it moves, it may have to try multiple mechanisms in order to obtain configuration. This can increase the latency required for the device to become functional on movement. > If I already have the data I need (obtained through static > configuration, IPCP, etc.), why am I going to ask DHCP for it? In real, > existing networks, is the fact that IP addresses can be obtained through > either IPCP or DHCP causing massive meltdowns? Presumably once a host obtains an IP address it is done. If the host needs more configuration than is provided by IPCP it still may need to do DHCPINFORM. > Please excuse my ignorance: I thought that DHCP security didn't go > between the client and server, just between relays and servers. It goes between client and server -- see RFC 3118. > It's a long jump from "possible" to "necessary", which your definition > of "true interoperability" would seem to imply. If DHCP was the only > way to get config data, of course, then _every_ authenticator would have > to implement the stateless server. Is that the desired outcome? I think it is. We're already much of the way there -- Cisco IOS includes support for a full fledged DHCP server, something that was not considered possible back in 1995 when the idea of IPCP "extensions" was first proposed. > In what environments? 802.11, Ethernet, UMTS, CDMA-2000, 14.4K dial-up? If the authenticator implements a DHCP server, there won't be much latency difference between DHCPINFORM and IPCP. From owner-ietf-ppp@merit.edu Thu May 15 10:23:58 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 990285DEFB; Thu, 15 May 2003 10:23:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A156291229; Thu, 15 May 2003 10:23:43 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 771D3912BB; Thu, 15 May 2003 10:23:43 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60F5D91229 for ; Thu, 15 May 2003 10:23:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4C9B55DEAD; Thu, 15 May 2003 10:23:42 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 6ACF55DEFC for ; Thu, 15 May 2003 10:23:41 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4FENe90012307 for ietf-ppp@merit.edu env-from ; Thu, 15 May 2003 08:23:40 -0600 (MDT) Date: Thu, 15 May 2003 08:23:40 -0600 (MDT) From: Vernon Schryver Message-Id: <200305151423.h4FENe90012307@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: draft-song-pppext-sip-support-02.txt References: <001d01c31ad5$e31cfd70$1200000a@amer.cisco.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "Glen Zorn" > > The proposal makes no sense. Unless SIP Is utterly broken, there > > must be other means for discovering SIP proxy servers besides special > > link-layer kludges. What happens on other point to point links that > > don't use PPP? > > Who cares? > > > What about point-to-point links that use PPP but not > > IPCP, such as only BCP? > > Ditto. Please stop the insults and think about what we've said. If SIP is utterly broken, then there is no need for the proposal because it can't and won't be used. Let's assume that SIP is not broken, not useless, and can be used and is used. I don't know that SIP is good, but given the vast number of IDs and RFCs about it, I hope it is. That SIP is good implies that it already has perfectly good mechanisms for finding proxies without this new, quite late idea. Thus this new, late idea is redundant, unnecessary, extra, and can only cause confusion and interoperation problems. > > Besides, this proposal could not and would not be widely deployed for > > a long time. Unless SIP is utterly broken, those othe mechanisms, > > whatever they are, must render this mechanism irrelevant. > > Vern please read the document: "This draft specifies an IPCP (PPP > Internet Protocol Control Protocol) option that allows SIP clients to > locate a list of SIP proxy servers that is to be used for all SIP > requests. This approach is applicable to a system utilizing PPP for its > link layer protocol and IP address allocation (ex. 3GPP2 Packet Data > System)." > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Presumably, 3GPP2 will be widely deployed in less than a long time (if > not, sell your Sprint stock now ;-). Please understand that I don't > much care for this idea either, but all of the arguments against it so > far seem at best lame. Whether 3GPP2 is deployed implies nothing that I can see. I haven't been buying any more stock in 3G telephones than I did in WAP telephones and for some of the same reasons, but you should make your own investment decisions. This PPP proposal stinks of the same sort of Internet Engineering that brought us WAP. It is based on the assumption that existing mechanisms do not exist or are irrelevant. Perhaps the existing SIP mechanisms cannot work over PPP. If that is true, then this proposal must say so and provide convincing technical reasons. Let's cut the obscuring politeness and admit the main motive for these IDs. Like the old Microsoft DNS server botch, they come from ignorance of existing standards and practices and an ambition to see one's name in the RFC index. The fact that this SIP proposal does not advert to the existence of any mechanism on other link layers without broadcasts to discover proxies suggests that the author does not know how SIP works on other media. The IPCP default route proposal has a similar stigmata of not mentioning the ancient alternatives to its wonderful idea. I'm sure that author is not trying to hide the alternatives but was innocently unaware of their ease, popularity, and effectiveness. If all you know about routing comes from the cries of anquish of people fighting with BGP, you wouldn't consider using RIP for router discovery, not to mention the IP router discovery protocol or the ancient mechanism of adding routes as interfaces awaken. If you don't really understand IPCP, you'd not realize that it makes no sense to put the IP address of the peer into the IPCP packet twice. You'd also not recognize the dangerous swamp of policy routing you'd wandered into. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Thu May 15 11:51:38 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id B43135DF28; Thu, 15 May 2003 11:51:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5CF4F912C7; Thu, 15 May 2003 11:48:29 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30627912C6; Thu, 15 May 2003 11:48:29 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9FCFC912C7 for ; Thu, 15 May 2003 11:48:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 87A245DF1F; Thu, 15 May 2003 11:48:22 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by segue.merit.edu (Postfix) with ESMTP id 1E1D75DF16 for ; Thu, 15 May 2003 11:48:22 -0400 (EDT) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4FFmKtd211102; Thu, 15 May 2003 11:48:20 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4FFm7iN016976; Thu, 15 May 2003 11:48:13 -0400 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h4FFkI15024764; Thu, 15 May 2003 11:46:18 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h4FFkIIM024760; Thu, 15 May 2003 11:46:18 -0400 Message-Id: <200305151546.h4FFkIIM024760@rotala.raleigh.ibm.com> To: Doug Kehn Cc: "'ietf-ppp@merit.edu '" Subject: Re: Reigning in "bad" extensions to PPP In-Reply-To: Message from dkehn@efficient.com of "Wed, 14 May 2003 14:47:35 CDT." Date: Thu, 15 May 2003 11:46:18 -0400 From: Thomas Narten Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > I gather from your post that you agree that the Route-Add option proposal is > a bad idea? That would be an accurate reflection of my personal opinion. > If so, I will inform the appropriate parties that the pppext WG > doesn't endorse such a proposal. That would not be a logical next step from the previous statement. I don't speak for the WG. > What is the pppext WG stance with regard to IPCP option 144? I have > yet to find an RFC or a draft describing such an option. Yet, I'm > being asked (actually forced) to implement this option in order to > be considered for operation in certain broadband networks. I would assume that since there is no IETF-blessed RFC, this WG has chosen not to do something along the lines of option 144. Indeed, my recollection is that this WG has a long tradition of not supporting extensions to PPP that are not really PPP-specific. E.g., quoting from the PPPEXT charter: > The Point-to-Point Protocol (PPP, RFC 1661) is a mature protocol with a > large number of subprotocols, encapsulations and other extensions. The > group will actively advance PPP's most useful extensions to full > standard, while defending against further enhancements of questionable > value. Thomas From owner-ietf-ppp@merit.edu Thu May 15 18:59:21 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 420035E0C4; Thu, 15 May 2003 18:59:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BDBB591230; Thu, 15 May 2003 18:59:08 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 895B1912D7; Thu, 15 May 2003 18:59:08 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 450D991230 for ; Thu, 15 May 2003 18:59:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23B505E0C4; Thu, 15 May 2003 18:59:06 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by segue.merit.edu (Postfix) with ESMTP id AD5355E0C3 for ; Thu, 15 May 2003 18:59:05 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4FMwtG4007717; Thu, 15 May 2003 15:58:56 -0700 (PDT) Received: from gwzw2k (tokyo-vpn-user302.cisco.com [10.70.83.46]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id PAA03971; Thu, 15 May 2003 15:58:54 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Bernard Aboba'" Cc: "'Thomas Narten'" , Subject: RE: draft-song-pppext-sip-support-02.txt Date: Thu, 15 May 2003 15:58:17 -0700 Organization: Cisco Systems Message-ID: <001d01c31b35$8c4b0810$1200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001E_01C31AFA.DFEC3010" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C31AFA.DFEC3010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bernard Aboba writes: >> How does this conclusion follow? Are you claiming that no two >> vendors will ever implement the same set of standards? > > I'm claiming that requiring embedded devices to implement multiple > standards may not be practical -- so they'll choose one and not > interoperate instead. Possibly. So, presupposing that these devices use PPP, why would they choose to implement DHCP instead of an IPCP option? > >> your use of the term "interoperability" here seems to me to be a >> novel one. At the protocol level, interoperability is ensured by the >> correct implementation of the protocol and required features thereof, >> but you seem to be suggesting that "true" interoperability can only >> exist if all devices on the network support precisely the same >> protocols, implemented in exactly the same way. > > If the network is only supporting one set of protocols for > configuration, then the device must support that set in order to > obtain configuration. If different networks use different protocols > and the device is mobile, then it must support *all* the potential > configuration protocols, or when it moves to some networks, it will > be unable to obtain configuration. Worse yet, when it moves, it may > have to try multiple mechanisms in order to obtain configuration. > This can increase the latency required for the device to become > functional on movement. > >> If I already have the data I need (obtained through static >> configuration, IPCP, etc.), why am I going to ask DHCP for it? In >> real, existing networks, is the fact that IP addresses can be >> obtained through either IPCP or DHCP causing massive meltdowns? > > Presumably once a host obtains an IP address it is done. If the host > needs more configuration than is provided by IPCP it still may need > to do DHCPINFORM. Exactly. > >> Please excuse my ignorance: I thought that DHCP security didn't go >> between the client and server, just between relays and servers. > > It goes between client and server -- see RFC 3118. Yup, thanks for the pointer! > >> It's a long jump from "possible" to "necessary", which your >> definition of "true interoperability" would seem to imply. If DHCP >> was the only way to get config data, of course, then _every_ >> authenticator would have to implement the stateless server. Is that >> the desired outcome? > > I think it is. We're already much of the way there -- Cisco IOS > includes support for a full fledged DHCP server, something that was > not considered possible back in 1995 when the idea of IPCP > "extensions" was first proposed. > >> In what environments? 802.11, Ethernet, UMTS, CDMA-2000, 14.4K >> dial-up? > > If the authenticator implements a DHCP server, there won't be much > latency difference between DHCPINFORM and IPCP. Only if the DHCP server in the authenticator is omniscient: if the correct values can only be provided by the home network (in a roaming situation), then presumably the request would need to be relayed. OTOH, (devil's advocate hat on) if the appropriate values were returned from the home AAA server and set in IPCP, the task would be complete before DHCP would even have started, reducing both latency and code footprint in the mobile device. ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 I've stopped 24,785 spam messages. You can too! Get your free, safe spam protection at http://www.cloudmark.com/spamnetsig/ ------=_NextPart_000_001E_01C31AFA.DFEC3010 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_001E_01C31AFA.DFEC3010-- From owner-ietf-ppp@merit.edu Thu May 15 19:07:19 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 39CD35E0C3; Thu, 15 May 2003 19:07:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58AF891232; Thu, 15 May 2003 19:07:10 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28679912D7; Thu, 15 May 2003 19:07:10 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 511EB91232 for ; Thu, 15 May 2003 19:07:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 401F35E0C8; Thu, 15 May 2003 19:07:09 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B4D9A5E0C7 for ; Thu, 15 May 2003 19:07:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4FMjhb12254; Thu, 15 May 2003 15:45:43 -0700 Date: Thu, 15 May 2003 15:45:43 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: "'Thomas Narten'" , ietf-ppp@merit.edu Subject: RE: draft-song-pppext-sip-support-02.txt In-Reply-To: <001d01c31b35$8c4b0810$1200000a@amer.cisco.com> Message-ID: References: <001d01c31b35$8c4b0810$1200000a@amer.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 > Possibly. So, presupposing that these devices use PPP, why would they > choose to implement DHCP instead of an IPCP option? If they ever needed to move to a link which didn't support PPP. > Only if the DHCP server in the authenticator is omniscient: if the > correct values can only be provided by the home network (in a roaming > situation), then presumably the request would need to be relayed. OTOH, > (devil's advocate hat on) if the appropriate values were returned from > the home AAA server and set in IPCP, the task would be complete before > DHCP would even have started, reducing both latency and code footprint > in the mobile device. In either case, assuming that the AAA protocol supported the necessary configuration, then it could be made to work -- all that changes is the protocol spoken between the peer and authenticator. For example, if AAA were to provide the address of the DNS server, then the peer could request this via DHCP or IPCP and the authenticator could answer. So roaming doesn't come into it, really. From owner-ietf-ppp@merit.edu Thu May 15 19:35:04 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 080555E0F7; Thu, 15 May 2003 19:35:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3E435912D7; Thu, 15 May 2003 19:35:02 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B700912DA; Thu, 15 May 2003 19:35:01 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDE97912D7 for ; Thu, 15 May 2003 19:35:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D251F5E10C; Thu, 15 May 2003 19:35:00 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by segue.merit.edu (Postfix) with ESMTP id 956DD5E0F7 for ; Thu, 15 May 2003 19:35:00 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4FNYuG4015534; Thu, 15 May 2003 16:34:56 -0700 (PDT) Received: from gwzw2k (tokyo-vpn-user302.cisco.com [10.70.83.46]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id QAA27784; Thu, 15 May 2003 16:34:55 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "'Vernon Schryver'" , Subject: RE: draft-song-pppext-sip-support-02.txt Date: Thu, 15 May 2003 16:34:21 -0700 Organization: Cisco Systems Message-ID: <006801c31b3a$953111e0$1200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0069_01C31AFF.E8D239E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200305151423.h4FENe90012307@calcite.rhyolite.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_0069_01C31AFF.E8D239E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Vernon Schryver writes: >> From: "Glen Zorn" > >>> The proposal makes no sense. Unless SIP Is utterly broken, there >>> must be other means for discovering SIP proxy servers besides >>> special link-layer kludges. What happens on other point to point >>> links that don't use PPP? >> >> Who cares? >> >>> What about point-to-point links that use PPP but not >>> IPCP, such as only BCP? >> >> Ditto. > > Please stop the insults and think about what we've said. I apologize if you feel that I've insulted you: that certainly wasn't my intent; nor do I believe the questions to be facetious. The draft in question only addresses systems (specifically, 3GPP2 PDS) that run over PPP/IP, so I really think that these objections are kind of irrelevant. It seems much like calling FTP evil because it doesn't run over, say, LU6.2. > > If SIP is utterly broken, then there is no need for the proposal > because it can't and won't be used. Let's assume that SIP is not > broken, not useless, and can be used and is used. I don't know that > SIP is good, but given the vast number of IDs and RFCs about it, I > hope it is. That SIP is good implies that it already has perfectly > good mechanisms for finding proxies without this new, quite late > idea. Thus this new, late idea is redundant, unnecessary, extra, and > can only cause confusion and interoperation problems. I'm certainly not a SIP expert either, but OTOH I'm willing to entertain the idea that some discovery/configuration methods that work perfectly well in e.g., a high-bandwidth/low latency environment might not be worth a damn in a more constrained one. > > >>> Besides, this proposal could not and would not be widely deployed >>> for a long time. Unless SIP is utterly broken, those othe >>> mechanisms, whatever they are, must render this mechanism >>> irrelevant. >> >> Vern please read the document: "This draft specifies an IPCP (PPP >> Internet Protocol Control Protocol) option that allows SIP clients to >> locate a list of SIP proxy servers that is to be used for all SIP >> requests. This approach is applicable to a system utilizing PPP for >> its link layer protocol and IP address allocation (ex. 3GPP2 Packet >> Data System)." >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Presumably, 3GPP2 will be widely >> deployed in less than a long time (if not, sell your Sprint stock >> now ;-). Please understand that I don't much care for this idea >> either, but all of the arguments against it so far seem at best lame. > > Whether 3GPP2 is deployed implies nothing that I can see. I haven't > been buying any more stock in 3G telephones than I did in WAP > telephones and for some of the same reasons, but you should make your > own investment decisions. Whatever we think of the future of 3G, my point was that if 3GPP2 has decided that this is way to do it, it will be deployed. > This PPP proposal stinks of the same sort > of Internet Engineering that brought us WAP. It is based on the > assumption that existing mechanisms do not exist or are irrelevant. Since you and I both admit that we are basically ignorant of whatever alternative mechanisms may exist, it seems that you are assuming that this draft is based upon an assumption, rather than careful analysis of the options in the context of the system under design. > > Perhaps the existing SIP mechanisms cannot work over PPP. If that is > true, then this proposal must say so and provide convincing technical > reasons. I agree. > > Let's cut the obscuring politeness and admit the main motive for > these IDs. Like the old Microsoft DNS server botch, they come from > ignorance of existing standards and practices and an ambition to see > one's name in the RFC index. > > The fact that this SIP proposal does not advert to the existence of > any mechanism on other link layers without broadcasts to discover > proxies suggests that the author does not know how SIP works on other > media. Another possibility is that the author thinks that it is so completely obvious that the question needn't be broached. It would be very good if they addressed the question, though. > The IPCP default route proposal has a similar stigmata of not > mentioning the ancient alternatives to its wonderful idea. I'm sure > that author is not trying to hide the alternatives but was innocently > unaware of their ease, popularity, and effectiveness. If all you > know about routing comes from the cries of anquish of people fighting > with BGP, you wouldn't consider using RIP for router discovery, not > to mention the IP router discovery protocol or the ancient mechanism > of adding routes as interfaces awaken. If you don't really > understand IPCP, you'd not realize that it makes no sense to put the > IP address of the peer into the IPCP packet twice. You'd also not > recognize the dangerous swamp of policy routing you'd wandered into. > > > Vernon Schryver vjs@rhyolite.com ~gwz "They that can give up essential liberty to obtain a little temporary safety deserve neither..." -- Benjamin Franklin, 1759 I've stopped 24,811 spam messages. You can too! Get your free, safe spam protection at http://www.cloudmark.com/spamnetsig/ ------=_NextPart_000_0069_01C31AFF.E8D239E0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn ORG:Cisco Systems TITLE:CTO Consulting Engineer NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D = E2FC 9769 FB97 FBCF 7DA4 9A2D 1963=3D0D=3D =3D0A=3D0D=3D0A TEL;HOME;VOICE:+1 (425) 513-8512 TEL;CELL;VOICE:+1 (425) 344-8113 TEL;WORK;FAX:+1 (425) 740-0168 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue = N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue = N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA URL;WORK:http://www.cisco.com EMAIL;PREF;INTERNET:gwz@cisco.com REV:20021107T033833Z END:VCARD ------=_NextPart_000_0069_01C31AFF.E8D239E0-- From owner-ietf-ppp@merit.edu Thu May 15 20:44:22 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 786735E15A; Thu, 15 May 2003 20:44:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CB3129122B; Thu, 15 May 2003 20:44:09 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FA33912DB; Thu, 15 May 2003 20:44:09 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 476249122B for ; Thu, 15 May 2003 20:44:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CCAD5E168; Thu, 15 May 2003 20:44:07 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by segue.merit.edu (Postfix) with ESMTP id 84F895E167 for ; Thu, 15 May 2003 20:44:06 -0400 (EDT) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9/8.12.9) with ESMTP id h4G0i0iK011058; Thu, 15 May 2003 20:44:00 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9/8.12.9/Submit) id h4G0i0up011057; Thu, 15 May 2003 20:44:00 -0400 (EDT) Date: Thu, 15 May 2003 20:44:00 -0400 From: Barney Wolff To: Bernard Aboba Cc: Glen Zorn , "'Thomas Narten'" , ietf-ppp@merit.edu Subject: Re: draft-song-pppext-sip-support-02.txt Message-ID: <20030516004400.GA10926@pit.databus.com> References: <001d01c31b35$8c4b0810$1200000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Possibly. So, presupposing that these devices use PPP, why would they > choose to implement DHCP instead of an IPCP option? Funny, I listened to this exact debate in the ipsec wg: whether to pass dhcp or invent a new mechanism. Apparently the inventive urge is universal. DHCP is a perfectly respectable and useful protocol. What is there that people don't like about it? The IESG really needs to speak up, and promulgate a policy that inventing new ways to do old things is BAD unless the old ways are manifestly inferior. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-ietf-ppp@merit.edu Thu May 15 22:05:45 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 213C65E1A2; Thu, 15 May 2003 22:05:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 14C1191234; Thu, 15 May 2003 22:05:35 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCABE912DC; Thu, 15 May 2003 22:05:34 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B66691234 for ; Thu, 15 May 2003 22:05:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 608B25E1A2; Thu, 15 May 2003 22:05:33 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B3CF75E1DD for ; Thu, 15 May 2003 22:05:32 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4G1i4h22210; Thu, 15 May 2003 18:44:04 -0700 Date: Thu, 15 May 2003 18:44:04 -0700 (PDT) From: Bernard Aboba To: Barney Wolff Cc: Glen Zorn , "'Thomas Narten'" , ietf-ppp@merit.edu Subject: Re: draft-song-pppext-sip-support-02.txt In-Reply-To: <20030516004400.GA10926@pit.databus.com> Message-ID: References: <001d01c31b35$8c4b0810$1200000a@amer.cisco.com> <20030516004400.GA10926@pit.databus.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 > Funny, I listened to this exact debate in the ipsec wg: whether to pass > dhcp or invent a new mechanism. Apparently the inventive urge is > universal. In the name of optimization, even reuse can be dangerous. Given the solutions for integrating DHCP, AAA and EAP which are now IPsec WG work items, I'm not sure that they could have done worse inventing something new. > DHCP is a perfectly respectable and useful protocol. What is there that > people don't like about it? Traditionally people have been adverse to the idea of DHCP relays and the extra latency involved in DHCP exchanges. Also there is the need for stable storage in classical DHCPv4 servers. Neither of those considerations apply to stateless deployments of DHCPINFORM, though. > The IESG really needs to speak up, and promulgate a policy that inventing > new ways to do old things is BAD unless the old ways are manifestly > inferior. The IAB has been looking at issuing some architectural guidance on the subject of IP configuration. If you think that there is something useful that they could do you might send mail to iab@ietf.org proposing what that is. From owner-ietf-ppp@merit.edu Fri May 16 22:07:42 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 57D195DF2C; Fri, 16 May 2003 22:07:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CFE479123A; Fri, 16 May 2003 22:07:29 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9775A91245; Fri, 16 May 2003 22:07:29 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56A119123A for ; Fri, 16 May 2003 22:07:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3B6E65DF28; Fri, 16 May 2003 22:07:28 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 68C3B5DF2D for ; Fri, 16 May 2003 22:07:27 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4H27P9q014203 for ietf-ppp@merit.edu env-from ; Fri, 16 May 2003 20:07:25 -0600 (MDT) Date: Fri, 16 May 2003 20:07:25 -0600 (MDT) From: Vernon Schryver Message-Id: <200305170207.h4H27P9q014203@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: proposed draft IANA Considerations Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Enclosed is a proposed IANA Considerations ID for PPP numbers. What say you? Should I send it to the RFC Editor? Does it need large or small changes? Vernon Schryver vjs@rhyolite.com P.S. It's sad how much boilerplate required by the modern IETF, but not quite as sad as the need for this procedural change. ........................................................................... Network Working Group Schryver Internet Draft Rhyolite Software May 2003 IANA Considerations for PPP Status of this Memo 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 its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." 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. This Internet-Draft will expire on November 15, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. 1. Introduction The charter of the Point-to-Point Protocol Extensions (pppext) working group includes the responsibility to "actively advance PPP's most useful extensions to full standard, while defending against further enhancements of questionable value." In support of that charter, the allocation of PPP protocol and other assigned numbers will no longer be "first come first served." 2. Terminology Schryver [Page 1] Internet-Draft IP IANA Considerations for PPP May 2003 The terms "name space", "assigned value", and "registration" are used here with the meanings defined in BCP 26. The policies "First Come First Served" and "IETF Consensus" used here also have the meanings defined in BCP 26. 3. IANA Considerations The Point-to-Point protocol (PPP, RFC 1661) is a mature protocol with a large number of subprotocols, encapsulations and other extensions. The main protocol as well as its extensions involve many name spaces in which values must be assigned. Http://www.iana.org/assignments/ppp-numbers contains a list of the address spaces and their current assignments. Historically, initial values in new name spaces have often been chosen in the RFCs creating the name spaces. The IANA made subsequent assignments with a "First Come First Served" policy. This memo changes that policy for some PPP address spaces. Most of the PPP names spaces are quiescent, but some continue to attract proposed extensions. Extensions of PPP have been defined in RFCs that are "Informational" and so are not subject to review. These extensions usually require values assigned in one or more of the PPP name spaces. Making these allocations require "IETF Consensus," usually through the Point-to-Point Protocol Extensions (pppext) working group, will ensure that proposals are reviewed. It is sufficient to require IETF Consensus for assigning new values in the following address spaces: DLL PROTOCOL NUMBERS LCP AND IPCP CODES LCP CONFIGURATION OPTION TYPES CCP CONFIGURATION OPTION TYPES AUTHENTICATION ALGORITHMS LCP FCS-ALTERNATIVES MULTILINK ENDPOINT DISCRIMINATOR CLASS LCP CALLBACK OPERATION FIELDS BRIDGING CONFIGURATION OPTION TYPES BRIDGING MAC TYPES BRIDGING SPANNING TREE EAP REQUEST/RESPONSE TYPES IPCP CONFIGURATION OPTION TYPES IPV6CP CONFIGURATION OPTIONS IP-Compression-Protocol Types Schryver [Page 2] Internet-Draft IP IANA Considerations for PPP May 2003 4. Security Considerations This memo deals with matters of process, not protocol. Normative References [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Author's Address Vernon Schryver Rhyolite Software 2482 Lee Hill Drive Boulder, Colorado 80302 EMail: vjs@rhyolite.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. Schryver [Page 3] Internet-Draft IP IANA Considerations for PPP May 2003 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Schryver [Page 4] From owner-ietf-ppp@merit.edu Fri May 16 22:59:27 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 3CF475DEC1; Fri, 16 May 2003 22:59:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A884891319; Fri, 16 May 2003 22:59:15 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D7909131A; Fri, 16 May 2003 22:59:15 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E76691319 for ; Fri, 16 May 2003 22:59:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 580965DF48; Fri, 16 May 2003 22:59:14 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E099A5DEC1 for ; Fri, 16 May 2003 22:59:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4H2bbP08397; Fri, 16 May 2003 19:37:37 -0700 Date: Fri, 16 May 2003 19:37:37 -0700 (PDT) From: Bernard Aboba To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: proposed draft IANA Considerations In-Reply-To: <200305170207.h4H27P9q014203@calcite.rhyolite.com> Message-ID: References: <200305170207.h4H27P9q014203@calcite.rhyolite.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 One comment -- allocation policy for EAP Request/Response types is being handled in RFC 2284bis (and is also being upgraded from FCFS). So you don't need to bother with that one. From owner-ietf-ppp@merit.edu Mon May 19 12:05:34 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id BD51D5DDB4; Mon, 19 May 2003 12:05:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F355991212; Mon, 19 May 2003 12:05:20 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEEE391213; Mon, 19 May 2003 12:05:19 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 946E291212 for ; Mon, 19 May 2003 12:05:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 80CEC5DDB0; Mon, 19 May 2003 12:05:18 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id AE8755DDAD for ; Mon, 19 May 2003 12:05:17 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4JG5GEJ014372 for ietf-ppp@merit.edu env-from ; Mon, 19 May 2003 10:05:16 -0600 (MDT) Date: Mon, 19 May 2003 10:05:16 -0600 (MDT) From: Vernon Schryver Message-Id: <200305191605.h4JG5GEJ014372@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Extending IPCP for Route Table Entries References: <3EC8FCCE.6020904@heeltoe.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Brad Parker > ... > > - adding routes based on a RIP packet is no slower or more > > cumbersome than adding routes with any other mechanism. > > well, not sure I agree. How is the CPE to know who the RIP packet > came from? AH? what if just as the link comes up someone outside > (who knows this will work) injects some RIP packets? Please investigate RIP. You are supposed to ignore RIP packets from distant networks. > > - I can't see any lack of safety in this case. You'd check that the > > IP destination address is yours, the source address is the PPP peer's, > > the route is a default with next hop address also equal to > > the PPP peer's, and probably ignore the metric. > > I wish I could trust the source IP, but I'm not sure I can. In this case, what would be the point of a forged RIP packet? A bad guy could at most turn on the routing that you say is desirable. If you are worried about authentication and authorization, then RIPv2 has far better A&A facilities than IPCP. >> - I can't see any lack of reliability in adding routes based on RIP packets > > I can. My instinct is that it would be fragile. On what is your instinct based? This is an engineering issue, so while instincts and intuition can be good pointers, they are only pointers to concrete problems or dangers. > ... > granted it's not much of a negotiation, but I think the goal was to end > up with two static routes, which would allow some policy to exist which > says "packets to this net go through this link and packet to everything > else go through the other link". > > So, a default route through the "primary" link would work, but what is > needed is a net/mask pair to specify the other link. I think this is > what is "communicated" via the IPCP option (which is granted, not > negotiated,but the CPE could reject it...) How does one PPP peer know about the netmask and IP address for the other PPP peer? > > Another problem is that it's got the notion of who is negotiating with > > whom partly backwards. The PPP peer that would send say "route through > > me" can only really say "if you wanted, you could route through me." > > Only the other peer can know whether it needs a default route. > > really? I'm not sure what "peer" is in this context. I'm thinking CPE > box and large ISP concentrator. The concentrator wants to offer some > links which are used to route to a special network. It needs to > communicate what the route should be. We are talking about PPP. In this context, "peer" has a fixed and well known meaning. The peer is the box sending IPCP packets. > >>I assume the requirement is a single net number with a mask. yes? > > > > What does a netmask have to do with a default route? > > And again, the IP address of the router could never differ from the > > IP address already negotiated with IPCP. > > as I said before, it's not the default route that is the interesting > part. It's the other-link/other-route. > > > The proposal could be boiled down into a single bit saying "I've got > > routes to the universe and I'm willing to forward your packets." > > sorry, no. The main link has the default route but I suspect the > secondary link needs a net/mask pair to define routing to it. How does one PPP peer of the customer premise equipment know anything about the IP address and netmaks of any other PPP peer of the CPE? How does one PPP peer even know there is a second PPP peer? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 20 10:04:27 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 3E4955DDE0; Tue, 20 May 2003 10:04:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 90BF991259; Tue, 20 May 2003 10:03:02 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EB599125F; Tue, 20 May 2003 10:03:02 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB16191259 for ; Tue, 20 May 2003 10:03:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D58855DDCB; Tue, 20 May 2003 10:03:00 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 25CAA5DDCA for ; Tue, 20 May 2003 10:02:59 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4KE2skX023141 for ietf-ppp@merit.edu env-from ; Tue, 20 May 2003 08:02:54 -0600 (MDT) Date: Tue, 20 May 2003 08:02:54 -0600 (MDT) From: Vernon Schryver Message-Id: <200305201402.h4KE2skX023141@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Extending IPCP for Route Table Entries References: <3ECA2DEA.1020800@heeltoe.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Brad Parker > ... > > Please investigate RIP. You are supposed to ignore RIP packets from > > distant networks. > > I've implemented RIP, thanks. Many times. I've also implemented RIP, but only once in the current version of the `routed` source used in IRIX, Solaris, FreeBSD, NetBSD, and elsewhere, unless you count the many versions of that source. I didn't think there were many other implementations of RIP, at least not by one person. Where did you write your implementations? > ... > > How does one PPP peer know about the netmask and IP address for the > > other PPP peer? > > You may wish to refer them as PPP peers but I am sticking to my CO and > CPE phrases, where the CPE gear is less capable and subordinant. > > The CO concentrator provides two PPP links. On one is expect the CPE to > have a default route. On the other it would like to provide a net and > netmask so as to estabilish a single route to the alternate link. I do not understand. Which is the "it" that would "like to provide a net and netmask, the CPE or the CO PPP peer? Do you mean that the CO is to tell the CPE "put most of your packets on this PPP link but only send packets with my IP address on this link PPP link"? > ... > > How does one PPP peer of the customer premise equipment know anything > > about the IP address and netmaks of any other PPP peer of the CPE? > > How does one PPP peer even know there is a second PPP peer? > > I don't understand what you are saying here. Normally, PPP state machines are entirely independent, with the partial exception of Multilink (MP). The fact that a box has two or more PPP links is normally unknown to all PPP state machines. > Presumably the CPE hear has some method of establishing a PPP session > with the CO gear. Let's assume for a moment the CPE gear has 2 modems > (but it could just as well be two ATM PVC's). Each one is a distinct > interface and does a separate IPCP negotiation. One acts in the nominal > case and gets a default route. The other, by convention, gets an IPCP > option which says "add a single static route to this net and route it > through this interface". > > Is that not clear? > ... No, it is not clear to me. I thought by "CO" you meant "telco central office" and by "CPE" you meant "customer premise equipment." Among the things that don't make sense to me are: - how many IP addresses are negotiated with IPCP for the two PPP links, 0, 1, 2, 3, or 4? I assume not zero, since IPCP is in use and you've mententioned IP addresses, but that is only a guess because you don't need to have any IP addresses in use (not to mention negotiated) even with IPCP Configure-Acks being exchanged. - which pair of PPP peers, the pair at the CPE or at the CO, sends the new IPCP option in an IPCP configure-Req? My guess is the CO. - how are the two PPP state machines in a pair at either the CO or the CPE related or coordinated? What happens if one of the PPP links goes down? Should traffic that would normally use the other link switch to the remaining link? - what is the difference between the traffic for the two links? Does it differ only by IP address? - how do the two pairs of PPP state machine ensure that they are not crossed? Would you use some extension of endpoint discriminators? - why do you need a netmask for a point-to-point link? - why do you need two PPP links to a single 3G telephone? Why not use a single PPP link and an appropriate queuing discipline for the various kinds of traffic? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 20 10:10:25 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id D33D55DDC4; Tue, 20 May 2003 10:10:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF00A91258; Tue, 20 May 2003 10:10:08 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 848C39125A; Tue, 20 May 2003 10:10:08 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6878191258 for ; Tue, 20 May 2003 10:10:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F3565DDA1; Tue, 20 May 2003 10:10:07 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 59B3B5DDC2 for ; Tue, 20 May 2003 10:10:06 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4KEA08d025571 for ietf-ppp@merit.edu env-from ; Tue, 20 May 2003 08:10:00 -0600 (MDT) Date: Tue, 20 May 2003 08:10:00 -0600 (MDT) From: Vernon Schryver Message-Id: <200305201410.h4KEA08d025571@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: I-D ACTION:draft-schryver-pppext-iana-00.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I don't know if the RFC editor normally sends copies of ID announcements to this mailing list these days, but it seems it won't happen for the ID to change the IANA considerations for many PPP numbers from "First come, first served" to "IETF consensus." The announcement is in http://www1.ietf.org/mail-archive/ietf-announce/Current/msg24163.html The draft can be found in http://www.ietf.org/internet-drafts/draft-schryver-pppext-iana-00.txt What needs to be done to get the ID advanced, after it has been modified or corrected? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 20 10:25:00 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 2DCB35DDA6; Tue, 20 May 2003 10:25:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 03D869125A; Tue, 20 May 2003 10:24:47 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C38929125B; Tue, 20 May 2003 10:24:46 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A756B9125A for ; Tue, 20 May 2003 10:24:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 927665DDA8; Tue, 20 May 2003 10:24:45 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from goliath.siemens.com (goliath.siemens.com [194.138.160.6]) by segue.merit.edu (Postfix) with ESMTP id 977575DDA4 for ; Tue, 20 May 2003 10:24:44 -0400 (EDT) Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4]) by goliath.siemens.com (8.11.7/8.11.7) with ESMTP id h4KEOfJ24076; Tue, 20 May 2003 10:24:45 -0400 (EDT) Received: from bambam.inside.efficient.com ([165.218.188.5]) by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4KEOeF27715; Tue, 20 May 2003 10:24:40 -0400 (EDT) Received: by bambam.inside.efficient.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 May 2003 09:24:37 -0500 Message-ID: From: Doug Kehn To: "'Vernon Schryver '" , "'ietf-ppp@merit.edu '" Subject: RE: Extending IPCP for Route Table Entries Date: Tue, 20 May 2003 09:24:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu >From: Vernon Schryver >How does one PPP peer of the customer premise equipment know anything >about the IP address and netmaks of any other PPP peer of the CPE? >How does one PPP peer even know there is a second PPP peer? 1. [DSL specific] Each PPP link could be transported across a separate ATM PVC. The ATM PVCs could be switched, in the Access Providers network, to separate PPP termination points. The CPE would be configured to bring up each PPP link. Once each PPP link was established, the CPE's routing table would contain a host route entry to the remote peer for each PPP interface. At this point the CPE has mutlitple PPP interfaces which packets can be routed. The remote peers don't necessarily know or care about all the remote peers that the CPE is attached. 2. [PPPoE specific] The CPE could request a unique Access Concentrator/Service for each PPP link. Each Access Concentrator/Service combination could be linked (i.e. L2TP) to separate PPP termination points. The CPE would be configured to bring up each PPPoE link. Once each PPPoE link was established, the CPE's routing table would contain a host route entry to the remote peer for each PPPoE interface. At this point the CPE has mutlitple PPPoE interfaces which packets can be routed. The remote peers don't necessarily know or care about all the remote peers that the CPE is attached. From owner-ietf-ppp@merit.edu Tue May 20 10:39:24 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 5E5E65DDC3; Tue, 20 May 2003 10:39:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D82769125C; Tue, 20 May 2003 10:39:18 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7BBA9125D; Tue, 20 May 2003 10:39:18 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 36CC69125C for ; Tue, 20 May 2003 10:39:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 21B0A5DDC5; Tue, 20 May 2003 10:39:16 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 276685DDC3 for ; Tue, 20 May 2003 10:39:14 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4KEdB1x028961 for ietf-ppp@merit.edu env-from ; Tue, 20 May 2003 08:39:11 -0600 (MDT) Date: Tue, 20 May 2003 08:39:11 -0600 (MDT) From: Vernon Schryver Message-Id: <200305201439.h4KEdB1x028961@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Doug Kehn > >How does one PPP peer of the customer premise equipment know anything > >about the IP address and netmaks of any other PPP peer of the CPE? > >How does one PPP peer even know there is a second PPP peer? > > 1. [DSL specific] Each PPP link could be transported across a separate ATM > PVC. The ATM PVCs could be switched, in the Access Providers network, to > separate PPP termination points. The CPE would be configured to bring up > each PPP link. Once each PPP link was established, the CPE's routing table > would contain a host route entry to the remote peer for each PPP interface. > At this point the CPE has mutlitple PPP interfaces which packets can be > routed. The remote peers don't necessarily know or care about all the > remote peers that the CPE is attached. > > 2. [PPPoE specific] The CPE could request a unique Access > Concentrator/Service for each PPP link. Each Access Concentrator/Service > combination could be linked (i.e. L2TP) to separate PPP termination points. > The CPE would be configured to bring up each PPPoE link. Once each PPPoE > link was established, the CPE's routing table would contain a host route > entry to the remote peer for each PPPoE interface. At this point the CPE > has mutlitple PPPoE interfaces which packets can be routed. The remote > peers don't necessarily know or care about all the remote peers that the CPE > is attached. Isn't that exactly the way things work today without the proposed IPCP extension? How is the proposal used in either the DSL or PPPoE case? In either case, doesn't one set of PPP state machines need to know about each other so that one of them can include the proposed extra IPCP option? How is the PPP state machine that should include the proposed extra IPCP option chosen? What distinguishes that PPP link from the others? I clearly don't understand the scenarios in which the proposed IPCP option would be used. I thought it had something to do with 3G radio-telephones. Could you repeat the description of the game (?) scenario with different words? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 20 11:11:04 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 5AE5C5DDEB; Tue, 20 May 2003 11:11:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F1349125E; Tue, 20 May 2003 11:10:51 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEBBE9125F; Tue, 20 May 2003 11:10:50 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 962729125E for ; Tue, 20 May 2003 11:10:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7554A5DDEA; Tue, 20 May 2003 11:10:49 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from goliath.siemens.com (goliath.siemens.com [194.138.160.6]) by segue.merit.edu (Postfix) with ESMTP id F408E5DDD1 for ; Tue, 20 May 2003 11:10:48 -0400 (EDT) Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4]) by goliath.siemens.com (8.11.7/8.11.7) with ESMTP id h4KFAoJ10933; Tue, 20 May 2003 11:10:50 -0400 (EDT) Received: from yogi.inside.efficient.com ([165.218.188.2]) by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4KFAmF16445; Tue, 20 May 2003 11:10:48 -0400 (EDT) Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 May 2003 10:10:46 -0500 Message-ID: From: Doug Kehn To: "'Vernon Schryver'" , ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries Date: Tue, 20 May 2003 10:10:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Vernon Schryver [mailto:vjs@calcite.rhyolite.com] > > > > From: Brad Parker > Brad, could you please cc the group on your responses? > > ... > > > Please investigate RIP. You are supposed to ignore RIP > packets from > > > distant networks. > > > > I've implemented RIP, thanks. Many times. > > I've also implemented RIP, but only once in the current version of > the `routed` source used in IRIX, Solaris, FreeBSD, NetBSD, and > elsewhere, unless you count the many versions of that source. > I didn't > think there were many other implementations of RIP, at least not by > one person. Where did you write your implementations? > > > > ... > > > How does one PPP peer know about the netmask and IP > address for the > > > other PPP peer? > > > > You may wish to refer them as PPP peers but I am sticking > to my CO and > > CPE phrases, where the CPE gear is less capable and subordinant. > > > > The CO concentrator provides two PPP links. On one is > expect the CPE to > > have a default route. On the other it would like to > provide a net and > > netmask so as to estabilish a single route to the alternate link. > > I do not understand. Which is the "it" that would "like to provide > a net and netmask, the CPE or the CO PPP peer? Do you mean that the > CO is to tell the CPE "put most of your packets on this PPP link but > only send packets with my IP address on this link PPP link"? > The CO PPP peer is to provide the route information. The CO PPP peer is telling the CPE to route packets on "this" interface. The route information could either be a network route or a host route. > > > ... > > > How does one PPP peer of the customer premise equipment > know anything > > > about the IP address and netmaks of any other PPP peer of the CPE? > > > How does one PPP peer even know there is a second PPP peer? > > > > I don't understand what you are saying here. > > Normally, PPP state machines are entirely independent, with the > partial exception of Multilink (MP). The fact that a box has two > or more PPP links is normally unknown to all PPP state machines. > Each PPP interface has its own PPP state machine. The analogy is similar to having multiple ethernet NICs. > > Presumably the CPE hear has some method of establishing a > PPP session > > with the CO gear. Let's assume for a moment the CPE gear > has 2 modems > > (but it could just as well be two ATM PVC's). Each one is > a distinct > > interface and does a separate IPCP negotiation. One acts > in the nominal > > case and gets a default route. The other, by convention, > gets an IPCP > > option which says "add a single static route to this net > and route it > > through this interface". > > > > Is that not clear? > > ... > > No, it is not clear to me. I thought by "CO" you meant "telco central > office" and by "CPE" you meant "customer premise equipment." Among > the things that don't make sense to me are: > > - how many IP addresses are negotiated with IPCP for the > two PPP links, > 0, 1, 2, 3, or 4? I assume not zero, since IPCP is in use > and you've mententioned IP addresses, but that is only > a guess because > you don't need to have any IP addresses in use (not to mention > negotiated) even with IPCP Configure-Acks being exchanged. > IPCP negotiates one IP address per PPP link. > - which pair of PPP peers, the pair at the CPE or at the CO, sends > the new IPCP option in an IPCP configure-Req? My guess > is the CO. > The intent was for the CPE to add the option in the Configure-Request. The remote peer could then ACK, NAK, REJ the option just as it does with the IP Address and DNS Address options. > - how are the two PPP state machines in a pair at either > the CO or the > CPE related or coordinated? What happens if one of the > PPP links > goes down? Should traffic that would normally use the > other link > switch to the remaining link? > The PPP state machines are independent at both peers. The proposal states that any routes added to an interface using the option should be deleted when IPCP terminates. In the absence of any routing information, the CPE will send packets out its default route (which could be a PPP interface). > - what is the difference between the traffic for the two > links? Does > it differ only by IP address? > It doesn't matter. The intent to route packets on the appropriate interface. > - how do the two pairs of PPP state machine ensure that they are not > crossed? Would you use some extension of endpoint > discriminators? > The practical application would be to use PPPoE and have the PPPoE Session ID be the descriminator. However, there are probably other ways to bind the protocol stack in order to ensure the PPP state machines are not crossed. > - why do you need a netmask for a point-to-point link? > A netmask isn't necessarily needed. If a netmask were available (e.g. Option 144), the CPE could treat the point-to-point interface as if it were a networked interface. Instead of making a host route to the remote peer on the PPP interface, the CPE could make a network route [with the remote peer as the gateway] on the PPP interface. Without a netmask and in the presence of multiple PPP interfaces, the CPE needs route entries in order to reach specific hosts on specific PPP links. > - why do you need two PPP links to a single 3G telephone? Why not > use a single PPP link and an appropriate queuing discipline for > the various kinds of traffic? > > > Vernon Schryver vjs@rhyolite.com > From owner-ietf-ppp@merit.edu Tue May 20 11:24:53 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 40D235DDF2; Tue, 20 May 2003 11:24:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7542D9125F; Tue, 20 May 2003 11:24:40 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40CE991260; Tue, 20 May 2003 11:24:40 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 26A409125F for ; Tue, 20 May 2003 11:24:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C2515DDFB; Tue, 20 May 2003 11:24:39 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 802955DDF9 for ; Tue, 20 May 2003 11:24:38 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4KFOQsa004711; Tue, 20 May 2003 09:24:26 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4KFOPEg002444; Tue, 20 May 2003 11:24:25 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4KFOP6e011166; Tue, 20 May 2003 11:24:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4KFOPTt011163; Tue, 20 May 2003 11:24:25 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16074.18601.268635.128179@gargle.gargle.HOWL> Date: Tue, 20 May 2003 11:24:25 -0400 From: James Carlson To: Doug Kehn Cc: "'Vernon Schryver'" , ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries In-Reply-To: Doug Kehn's message of 20 May 2003 10:10:39 References: X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Doug Kehn writes: > The CO PPP peer is to provide the route information. The CO PPP peer is > telling the CPE to route packets on "this" interface. The route information > could either be a network route or a host route. That's exactly what RIP-2 and other routing protocols do. > Each PPP interface has its own PPP state machine. The analogy is similar to > having multiple ethernet NICs. If you had multiple Ethernet NICs, where would you get your non-local routes? You wouldn't have an IPCP to modify. If some solution works reasonably for Ethernet interfaces, why does that solution not work for PPP? > > - which pair of PPP peers, the pair at the CPE or at the CO, sends > > the new IPCP option in an IPCP configure-Req? My guess > > is the CO. > > > > The intent was for the CPE to add the option in the Configure-Request. The > remote peer could then ACK, NAK, REJ the option just as it does with the IP > Address and DNS Address options. Note that the Microsoft DNS address option is defined backwards and should not be used as a model here. It has the "CPE" side specifying (via Configure-Request) its knowledge of (or lack thereof) the name servers on the remote side, and requires the remote to correct erroneous information with Configure-Nak. > > - why do you need a netmask for a point-to-point link? > > > > A netmask isn't necessarily needed. If a netmask were available (e.g. > Option 144), the CPE could treat the point-to-point interface as if it were > a networked interface. Huh? PPP interfaces *are* network interfaces. No netmask is required (or even really usable) because they're point-to-point. > Instead of making a host route to the remote peer on > the PPP interface, the CPE could make a network route [with the remote peer > as the gateway] on the PPP interface. > > Without a netmask and in the presence of multiple PPP interfaces, the CPE > needs route entries in order to reach specific hosts on specific PPP links. ... which brings us back to the purpose of routing protocols. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue May 20 11:31:32 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 0C5795DE0B; Tue, 20 May 2003 11:31:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AD4E91260; Tue, 20 May 2003 11:30:32 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C61791262; Tue, 20 May 2003 11:30:32 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 141AF91260 for ; Tue, 20 May 2003 11:30:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0299A5DDFA; Tue, 20 May 2003 11:30:31 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 9E0295DE14 for ; Tue, 20 May 2003 11:30:29 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4KFUSeb012319 for ietf-ppp@merit.edu env-from ; Tue, 20 May 2003 09:30:28 -0600 (MDT) Date: Tue, 20 May 2003 09:30:28 -0600 (MDT) From: Vernon Schryver Message-Id: <200305201530.h4KFUSeb012319@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Doug Kehn > > - how many IP addresses are negotiated with IPCP for the > > two PPP links, > > 0, 1, 2, 3, or 4? ... > IPCP negotiates one IP address per PPP link. Formally, IPCP does not negotiate IP addresses for PPP links, but for the PPP peer that sends the IPCP configure-request. When PPP links are run in some form of "unnumbered" mode, only 0 or 1 IP address is used by the two PPP peers. Otherwise, IPCP is commonly used to negotiate two IP addreses for each link, one address for each PPP peer. In this case, are there a total of 2 or 4 IP addresses for the 4 PPP peers or state machines? If there are only 2, do the PPP peers at the CO or CPE get the addresses? > > - which pair of PPP peers, the pair at the CPE or at the CO, sends > > the new IPCP option in an IPCP configure-Req? My guess is the CO. > > The intent was for the CPE to add the option in the Configure-Request. The > remote peer could then ACK, NAK, REJ the option just as it does with the IP > Address and DNS Address options. > > - how are the two PPP state machines in a pair at either the CO or the > > CPE related or coordinated? What happens if one of the PPP links > > goes down? Should traffic that would normally use the other link > > switch to the remaining link? > > The PPP state machines are independent at both peers. The proposal states > that any routes added to an interface using the option should be deleted > when IPCP terminates. In the absence of any routing information, the CPE > will send packets out its default route (which could be a PPP interface). That sounds as the answer to my second question is "yes, if the remaining link has the default route." However, your answer raises other questions. What happens if the route was already present as a static route? Should the link going down delete routes added by other mechanisms? What should happen if a routing protocol is running? Which processes routes, IPCP's or the routing protocol's, should have preference? (By "IPCP terminates" I assume that means any state transition out of "Opened". See page 16 of RFC 1661.) > > - what is the difference between the traffic for the two links? Does > > it differ only by IP address? > > It doesn't matter. The intent to route packets on the appropriate > interface. Which is the appropriate interface for an IP packet? Is that appropriateness determined by anything other than IP address, such as IP TOS/QOS bits? Or other bits in the IP payload? > > - how do the two pairs of PPP state machine ensure that they are not > > crossed? Would you use some extension of endpoint discriminators? > > The practical application would be to use PPPoE and have the PPPoE Session > ID be the descriminator. However, there are probably other ways to bind the > protocol stack in order to ensure the PPP state machines are not crossed. How do the CPE PPP state machines know which PPPoE Sessions ID should have a default route and which should not? > > - why do you need a netmask for a point-to-point link? > > A netmask isn't necessarily needed. If a netmask were available (e.g. > Option 144), the CPE could treat the point-to-point interface as if it were > a networked interface. Instead of making a host route to the remote peer on > the PPP interface, the CPE could make a network route [with the remote peer > as the gateway] on the PPP interface. > > Without a netmask and in the presence of multiple PPP interfaces, the CPE > needs route entries in order to reach specific hosts on specific PPP links. That's interesting. Why only a single network route? Why wouldn't several be necessary? > > - why do you need two PPP links to a single 3G telephone? Why not > > use a single PPP link and an appropriate queuing discipline for > > the various kinds of traffic? What about that question? And why are you talking about PPPoE and ATM now when earlier messages talked about 3G phones? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 20 12:26:12 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id A1DDE5DE4A; Tue, 20 May 2003 12:26:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8628291252; Tue, 20 May 2003 12:25:59 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53BBC91261; Tue, 20 May 2003 12:25:59 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 08DC791252 for ; Tue, 20 May 2003 12:25:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E57325DE4A; Tue, 20 May 2003 12:25:57 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from david.siemens.com (david.siemens.com [194.138.160.5]) by segue.merit.edu (Postfix) with ESMTP id 4F93A5DE48 for ; Tue, 20 May 2003 12:25:56 -0400 (EDT) Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4]) by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4KGPt007195; Tue, 20 May 2003 12:25:56 -0400 (EDT) Received: from yogi.inside.efficient.com ([165.218.188.2]) by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4KGPrF15551; Tue, 20 May 2003 12:25:54 -0400 (EDT) Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 May 2003 11:25:51 -0500 Message-ID: From: Doug Kehn To: "'James Carlson '" , Doug Kehn Cc: "''Vernon Schryver' '" , "'ietf-ppp@merit.edu '" Subject: RE: Extending IPCP for Route Table Entries Date: Tue, 20 May 2003 11:25:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu From the outset, it has been acknowledged that this proposal duplicates what could be done with a routing protocol. The argument for the duplication is that a routing protocol is "seen" as overkill when all that the Service Providers are wanting to do is add a single (okay...maybe two) static route entries on an interface. Another factor to consider is the realization that CPE cost is being driven down to that of a dial-up modem. Cost reductions are mainly realized through using lower density flash/RAM (when dealing with 100K+ magnitude every penny counts). Lower memory density means that features must be removed/reduced as every byte counts. Also, Service Providers (I'm referring to broadband) use PPP because it provides accountability and authentication. It also resembles the familiar dial-up model. However, a problem arises as PPP termination moves off the PC and on to the CPE. The CPE now becomes a router but is straddled with a point-to-point WAN interface when what is really needed is a networked interface. I don't see (my opinion of course) Service Providers moving away from PPP because of the cost already invested in a PPP infrastructure. At the expense of duplication could another method be found to solve the problems. If the Route-Add option isn't appealing, maybe reconsider Option 144 (Subnet mask) again. -----Original Message----- From: James Carlson To: Doug Kehn Cc: 'Vernon Schryver'; ietf-ppp@merit.edu Sent: 5/20/03 10:24 AM Subject: RE: Extending IPCP for Route Table Entries Doug Kehn writes: > The CO PPP peer is to provide the route information. The CO PPP peer is > telling the CPE to route packets on "this" interface. The route information > could either be a network route or a host route. That's exactly what RIP-2 and other routing protocols do. > Each PPP interface has its own PPP state machine. The analogy is similar to > having multiple ethernet NICs. If you had multiple Ethernet NICs, where would you get your non-local routes? You wouldn't have an IPCP to modify. If some solution works reasonably for Ethernet interfaces, why does that solution not work for PPP? > > - which pair of PPP peers, the pair at the CPE or at the CO, sends > > the new IPCP option in an IPCP configure-Req? My guess > > is the CO. > > > > The intent was for the CPE to add the option in the Configure-Request. The > remote peer could then ACK, NAK, REJ the option just as it does with the IP > Address and DNS Address options. Note that the Microsoft DNS address option is defined backwards and should not be used as a model here. It has the "CPE" side specifying (via Configure-Request) its knowledge of (or lack thereof) the name servers on the remote side, and requires the remote to correct erroneous information with Configure-Nak. > > - why do you need a netmask for a point-to-point link? > > > > A netmask isn't necessarily needed. If a netmask were available (e.g. > Option 144), the CPE could treat the point-to-point interface as if it were > a networked interface. Huh? PPP interfaces *are* network interfaces. No netmask is required (or even really usable) because they're point-to-point. > Instead of making a host route to the remote peer on > the PPP interface, the CPE could make a network route [with the remote peer > as the gateway] on the PPP interface. > > Without a netmask and in the presence of multiple PPP interfaces, the CPE > needs route entries in order to reach specific hosts on specific PPP links. ... which brings us back to the purpose of routing protocols. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue May 20 12:37:20 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id E7D925DE62; Tue, 20 May 2003 12:37:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5D8C91262; Tue, 20 May 2003 12:37:12 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A92EC91263; Tue, 20 May 2003 12:37:12 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D65591262 for ; Tue, 20 May 2003 12:37:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8AB325DE62; Tue, 20 May 2003 12:37:11 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 4E0D55DE5B for ; Tue, 20 May 2003 12:37:09 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4KGatkV023951 for ietf-ppp@merit.edu env-from ; Tue, 20 May 2003 10:36:55 -0600 (MDT) Date: Tue, 20 May 2003 10:36:55 -0600 (MDT) From: Vernon Schryver Message-Id: <200305201636.h4KGatkV023951@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Doug Kehn > >From the outset, it has been acknowledged that this proposal duplicates what > could be done with a routing protocol. The argument for the duplication is > that a routing protocol is "seen" as overkill when all that the Service > Providers are wanting to do is add a single (okay...maybe two) static route > entries on an interface. Another factor to consider is the realization that > CPE cost is being driven down to that of a dial-up modem. Cost reductions > are mainly realized through using lower density flash/RAM (when dealing with > 100K+ magnitude every penny counts). Lower memory density means that > features must be removed/reduced as every byte counts. Are you sure that even a penny would be needed for the at most 2000 instructions needed to implement the fragment of RIP required to have the same effect as the proposed IPCP option? Could you justify the implicit claim that it would cost more in the CPE to implement the necessary fragment of RIP than to implement the same functions with the propsed IPCP option? I suspect that in fact the IPCP implementation would require more code, because there are more corner cases. For example, you don't need to handle configure-Naks and and configure-Rejs in the RIP case. Both cases require the same changes to the CPE's routing table. Both require the same sanity checking of the route itself. Given the reported popularity of software n CPE that is not known for its small size, such as Windows CE, worrying about 100 lines of C or 2000 machine instructions seems misplaced. > Also, Service Providers (I'm referring to broadband) use PPP because it > provides accountability and authentication. It also resembles the familiar > dial-up model. However, a problem arises as PPP termination moves off the > PC and on to the CPE. The CPE now becomes a router but is straddled with a > point-to-point WAN interface when what is really needed is a networked > interface. I don't see (my opinion of course) Service Providers moving away > from PPP because of the cost already invested in a PPP infrastructure. What is a "networked interface" and how does it differ from at "point-to-point WAN interface?" Both seem to involve PPP. > At the expense of duplication could another method be found to solve the > problems. If the Route-Add option isn't appealing, maybe reconsider Option > 144 (Subnet mask) again. I can't find any such option in http://www.iana.org/assignments/ppp-numbers Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 20 12:46:38 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 5A1FD5DDD1; Tue, 20 May 2003 12:46:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A559A91263; Tue, 20 May 2003 12:46:23 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A7A091264; Tue, 20 May 2003 12:46:23 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4757C91263 for ; Tue, 20 May 2003 12:46:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 25B4A5DE69; Tue, 20 May 2003 12:46:15 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from goliath.siemens.com (goliath.siemens.com [194.138.160.6]) by segue.merit.edu (Postfix) with ESMTP id B2D0F5DE19 for ; Tue, 20 May 2003 12:46:14 -0400 (EDT) Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4]) by goliath.siemens.com (8.11.7/8.11.7) with ESMTP id h4KGkFT14229; Tue, 20 May 2003 12:46:15 -0400 (EDT) Received: from yogi.inside.efficient.com ([165.218.188.2]) by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4KGkEF22013; Tue, 20 May 2003 12:46:14 -0400 (EDT) Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 May 2003 11:46:12 -0500 Message-ID: From: Doug Kehn To: "'Vernon Schryver'" , ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries Date: Tue, 20 May 2003 11:46:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Vernon Schryver [mailto:vjs@calcite.rhyolite.com] > > > From: Doug Kehn > > > > - how many IP addresses are negotiated with IPCP for the > > > two PPP links, > > > 0, 1, 2, 3, or 4? ... > > > IPCP negotiates one IP address per PPP link. > > Formally, IPCP does not negotiate IP addresses for PPP links, but > for the PPP peer that sends the IPCP configure-request. When PPP > links are run in some form of "unnumbered" mode, only 0 or 1 IP > address is used by the two PPP peers. Otherwise, IPCP is commonly > used to negotiate two IP addreses for each link, one address for > each PPP peer. > > In this case, are there a total of 2 or 4 IP addresses for the 4 PPP > peers or state machines? > If there are only 2, do the PPP peers at the CO or CPE get > the addresses? > My mistake, I was only thinking about the CPE-end of the link. Yes, both peers get an address. > > > > > - which pair of PPP peers, the pair at the CPE or at > the CO, sends > > > the new IPCP option in an IPCP configure-Req? My > guess is the CO. > > > > The intent was for the CPE to add the option in the > Configure-Request. The > > remote peer could then ACK, NAK, REJ the option just as it > does with the IP > > Address and DNS Address options. > > > > > - how are the two PPP state machines in a pair at > either the CO or the > > > CPE related or coordinated? What happens if one of > the PPP links > > > goes down? Should traffic that would normally use > the other link > > > switch to the remaining link? > > > > The PPP state machines are independent at both peers. The > proposal states > > that any routes added to an interface using the option > should be deleted > > when IPCP terminates. In the absence of any routing > information, the CPE > > will send packets out its default route (which could be a > PPP interface). > > That sounds as the answer to my second question is "yes, if the > remaining link has the default route." However, your answer raises > other questions. What happens if the route was already present as > a static route? Should the link going down delete routes added by > other mechanisms? What should happen if a routing protocol is > running? Which processes routes, IPCP's or the routing protocol's, > should have preference? > > (By "IPCP terminates" I assume that means any state transition out > of "Opened". See page 16 of RFC 1661.) > > These are good questions. Maybe only routes added by the Route-Add option should be deleted when IPCP transitions out of "Opened" (I like your description). Preference should/could be determined by the route metric. > > > - what is the difference between the traffic for the > two links? Does > > > it differ only by IP address? > > > > It doesn't matter. The intent to route packets on the appropriate > > interface. > > Which is the appropriate interface for an IP packet? Is that > appropriateness determined by anything other than IP address, such > as IP TOS/QOS bits? Or other bits in the IP payload? > The answer is yes. But, other mechinisms, not IP routing, would be used to direct the packet to the appropriate interface. > > > > - how do the two pairs of PPP state machine ensure that > they are not > > > crossed? Would you use some extension of endpoint > discriminators? > > > > The practical application would be to use PPPoE and have > the PPPoE Session > > ID be the descriminator. However, there are probably other > ways to bind the > > protocol stack in order to ensure the PPP state machines > are not crossed. > > How do the CPE PPP state machines know which PPPoE Sessions ID > should have a default route and which should not? > We do it by configuring the interface to be the default route (I'm sure there are other ways). > > > > - why do you need a netmask for a point-to-point link? > > > > A netmask isn't necessarily needed. If a netmask were > available (e.g. > > Option 144), the CPE could treat the point-to-point > interface as if it were > > a networked interface. Instead of making a host route to > the remote peer on > > the PPP interface, the CPE could make a network route [with > the remote peer > > as the gateway] on the PPP interface. > > > > Without a netmask and in the presence of multiple PPP > interfaces, the CPE > > needs route entries in order to reach specific hosts on > specific PPP links. > > That's interesting. Why only a single network route? Why wouldn't > several be necessary? > > > > > - why do you need two PPP links to a single 3G > telephone? Why not > > > use a single PPP link and an appropriate queuing > discipline for > > > the various kinds of traffic? > > What about that question? > > And why are you talking about PPPoE and ATM now when earlier messages > talked about 3G phones? > I never talked about 3G phones. That was someone else. > > Vernon Schryver vjs@rhyolite.com > From owner-ietf-ppp@merit.edu Tue May 20 13:06:11 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 29DF25DE8E; Tue, 20 May 2003 13:06:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67C2391264; Tue, 20 May 2003 13:05:58 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 395C491265; Tue, 20 May 2003 13:05:58 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00BB691264 for ; Tue, 20 May 2003 13:05:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC5165DE81; Tue, 20 May 2003 13:05:56 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 9E3B85DE1F for ; Tue, 20 May 2003 13:05:55 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4KH5kAI003850 for ietf-ppp@merit.edu env-from ; Tue, 20 May 2003 11:05:46 -0600 (MDT) Date: Tue, 20 May 2003 11:05:46 -0600 (MDT) From: Vernon Schryver Message-Id: <200305201705.h4KH5kAI003850@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: Extending IPCP for Route Table Entries References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Doug Kehn > > > > - how many IP addresses are negotiated with IPCP for the > > > > two PPP links, > > > > 0, 1, 2, 3, or 4? ... > ... > My mistake, I was only thinking about the CPE-end of the link. Yes, both > peers get an address. So there are a total of 4 IP addresses involved, two for the CPE and two for the CO? > ... > > > > goes down? Should traffic that would normally use the other link > > > > switch to the remaining link? > ... > > That sounds as the answer to my second question is "yes, if the > > remaining link has the default route." However, your answer raises > > other questions. What happens if the route was already present as > > a static route? Should the link going down delete routes added by > > other mechanisms? What should happen if a routing protocol is > > running? Which processes routes, IPCP's or the routing protocol's, > > should have preference? > These are good questions. Maybe only routes added by the Route-Add option > should be deleted when IPCP transitions out of "Opened" (I like your > description). Preference should/could be determined by the route metric. By "preference" I did not mean metric. There are implementation problems with that, since routing tables tend to not contain the process origins of routes or duplicates. It's usual to expect that when one mechanism adds a route and a second mechasm adds and then deletes a similar route, the route added by the first mechanism is first overwritten and then deleted. Your mention of paying attention to metrics opens a large can of worms. My guess was that the IPCP option would not involve any metrics or that any and all metrics would be ignored or treated as if they were equal. If you have metrics, do you also have hop counts? If the metrics for the two routes added for the two PPP links (I think you said there would be two routes) differ, then how do you pick the outgoing interface on the CPE? Do you do longest-match? Do you have an "infinite" metric that means "use this only as a last resort because it's being removed"? ("Opened" is the official word in these parts since the first PPP RFC. I don't like it, and I disavow all ownership of it. However, using the official terminology minimizes misunderstanding, even when the official terms might have been chosen better.) > > > > - what is the difference between the traffic for the two links? Does > > > > it differ only by IP address? > > > > > > It doesn't matter. The intent to route packets on the appropriate > > > interface. > > > > Which is the appropriate interface for an IP packet? Is that > > appropriateness determined by anything other than IP address, such > > as IP TOS/QOS bits? Or other bits in the IP payload? > > The answer is yes. But, other mechinisms, not IP routing, would be used to > direct the packet to the appropriate interface. I am confused. If IP routing is not used to direct the packet to the appropriate interface, then what do IP routes have to do with anything? Why bother with sending IP routes though IPCP? > ... > > How do the CPE PPP state machines know which PPPoE Sessions ID > > should have a default route and which should not? > > We do it by configuring the interface to be the default route (I'm sure > there are other ways). I clearly have no clue about the target application, because that makes no sense to me. > ... > > > Without a netmask and in the presence of multiple PPP > > interfaces, the CPE > > > needs route entries in order to reach specific hosts on > > specific PPP links. > > > > That's interesting. Why only a single network route? Why wouldn't > > several be necessary? What about that question? > > And why are you talking about PPPoE and ATM now when earlier messages > > talked about 3G phones? > > I never talked about 3G phones. That was someone else. Oh, my mistake. Could you please describe a scenario in which CPE would have two ATM VCs or two PPPoE links and would use the proposed mechanism? What sort of CPE are we talking about? I almost understood the issue of 1000 words of code in EEPROM for a phone, but I don't understand why there is any shortage in a box that probably does NAT, general firewalling, has both HTTP and telnet configuration interfaces and MBytes of program storage. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 20 13:47:14 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 932895DED8; Tue, 20 May 2003 13:47:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2689191265; Tue, 20 May 2003 13:46:52 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E01AC91266; Tue, 20 May 2003 13:46:51 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D830D91265 for ; Tue, 20 May 2003 13:46:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE2635DECA; Tue, 20 May 2003 13:46:50 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 4A02A5DDA9 for ; Tue, 20 May 2003 13:46:50 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4KHkGx9015327; Tue, 20 May 2003 10:46:16 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4KHkFEg010986; Tue, 20 May 2003 13:46:15 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4KHkF6e011987; Tue, 20 May 2003 13:46:15 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4KHkF3s011984; Tue, 20 May 2003 13:46:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16074.27111.497748.906222@gargle.gargle.HOWL> Date: Tue, 20 May 2003 13:46:15 -0400 From: James Carlson To: Brad Parker Cc: Doug Kehn , "'Vernon Schryver'" , ietf-ppp@merit.edu Subject: Re: Extending IPCP for Route Table Entries In-Reply-To: Brad Parker's message of 20 May 2003 13:40:37 References: <16074.18601.268635.128179@gargle.gargle.HOWL> <3ECA6895.4010008@heeltoe.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Brad Parker writes: > > If you had multiple Ethernet NICs, where would you get your non-local > > routes? You wouldn't have an IPCP to modify. > > yes, but to fill in the analogy, if I where using ethernet, I'd be > mobile and "plug in" (the analog to dialing-in) and then I'd probably > use DHCP which would no doubt give me a default route. In this scenario > I wonder if IPCP is like DHCP (and believe me, it pains me to say that). It's not like DHCP, unless we allow unnecessary duplication like that proposed here to creep in. If you would use DHCP in the Ethernet case, then why would you not use it in the PPP case? DHCP runs over UDP, and it works just fine over just about any reasonable medium. > > If some solution works reasonably for Ethernet interfaces, why does > > that solution not work for PPP? > > None of my mobile hosts listen for RIP when the plug in. They all use > DHCP and get a default route. Maybe I'm 2 sigmas out of the norm... :-) Fine. Then send DHCPINFORM (per RFC 2131) and use the existing mechanism to do this. No new standards required, no IPCP changes, no changes to existing implementations. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue May 20 14:25:40 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 5A4B35DE7C; Tue, 20 May 2003 14:25:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA29191269; Tue, 20 May 2003 14:25:27 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91A4E9126A; Tue, 20 May 2003 14:25:27 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D8E991269 for ; Tue, 20 May 2003 14:25:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B95C5DF21; Tue, 20 May 2003 14:25:26 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id B8F855DF27 for ; Tue, 20 May 2003 14:25:25 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4KIPOe0023170 for ietf-ppp@merit.edu env-from ; Tue, 20 May 2003 12:25:24 -0600 (MDT) Date: Tue, 20 May 2003 12:25:24 -0600 (MDT) From: Vernon Schryver Message-Id: <200305201825.h4KIPOe0023170@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Extending IPCP for Route Table Entries References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > To: Brad Parker > ... > > None of my mobile hosts listen for RIP when the plug in. They all use > > DHCP and get a default route. Maybe I'm 2 sigmas out of the norm... :-) > > Fine. Then send DHCPINFORM (per RFC 2131) and use the existing > mechanism to do this. No new standards required, no IPCP changes, no > changes to existing implementations. There's also the router discovery protocol that is older than the DHCP option, stands alone, works anywhere that IP works, and can be treated as simply as the DHCP option. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 20 14:35:29 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 79EBB5DF3E; Tue, 20 May 2003 14:35:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADBB99126B; Tue, 20 May 2003 14:35:16 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F57A9126C; Tue, 20 May 2003 14:35:16 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 819D49126B for ; Tue, 20 May 2003 14:35:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D1BD5DF3D; Tue, 20 May 2003 14:35:15 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E0B2D5DF3C for ; Tue, 20 May 2003 14:35:14 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4KIZ1Y9027886; Tue, 20 May 2003 12:35:01 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4KIZ1Eg022937; Tue, 20 May 2003 14:35:01 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4KIZ16e012044; Tue, 20 May 2003 14:35:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4KIZ1EE012041; Tue, 20 May 2003 14:35:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16074.30037.250657.317739@gargle.gargle.HOWL> Date: Tue, 20 May 2003 14:35:01 -0400 From: James Carlson To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: Extending IPCP for Route Table Entries In-Reply-To: Vernon Schryver's message of 20 May 2003 12:25:24 References: <200305201825.h4KIPOe0023170@calcite.rhyolite.com> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Vernon Schryver writes: > > > None of my mobile hosts listen for RIP when the plug in. They all use > > > DHCP and get a default route. Maybe I'm 2 sigmas out of the norm... :-) > > > > Fine. Then send DHCPINFORM (per RFC 2131) and use the existing > > mechanism to do this. No new standards required, no IPCP changes, no > > changes to existing implementations. > > There's also the router discovery protocol that is older than the DHCP > option, stands alone, works anywhere that IP works, and can be treated > as simply as the DHCP option. My point was that if he already needed to have DHCP in *some* cases, and he was already relying on that, then there's really no reason not to use it for the PPP case as well. If he has nothing at all, then, certainly, RFC 1256 router discovery is about as simple as you're possibly going to get. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue May 20 14:51:32 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 7A14E5DF4C; Tue, 20 May 2003 14:51:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 90A2A9126C; Tue, 20 May 2003 14:51:19 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 602F69126D; Tue, 20 May 2003 14:51:19 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 565129126C for ; Tue, 20 May 2003 14:51:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F12E5DF4C; Tue, 20 May 2003 14:51:18 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 59E025DF56 for ; Tue, 20 May 2003 14:51:17 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4KIpChD026625 for ietf-ppp@merit.edu env-from ; Tue, 20 May 2003 12:51:12 -0600 (MDT) Date: Tue, 20 May 2003 12:51:12 -0600 (MDT) From: Vernon Schryver Message-Id: <200305201851.h4KIpChD026625@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Extending IPCP for Route Table Entries References: <3ECA66D8.3070302@heeltoe.com> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Brad Parker > ... > > I've also implemented RIP, but only once in the current version of > > the `routed` source used in IRIX, Solaris, FreeBSD, NetBSD, and > > elsewhere, unless you count the many versions of that source. I didn't > > think there were many other implementations of RIP, at least not by > > one person. Where did you write your implementations? > > you're joking, right? there must be 5,000 implementation of RIP out > there. I've certainly writen 4-5 myself. (sad to say). I do not believe there are 5000 implementations of RIP, but that there are more installations than 5000. I'm still curious about where your 4-5 implementations landed, but that's just irrelevant, nosey curiosity about stuff that's none of my business. > ... > yes, exactly. The CO PPP peer would (I presume) like to tell the > CPE PPP peer that certain links have a static route. Are you talking about G3 phones or something else? > ... > > 0, 1, 2, 3, or 4? I assume not zero, since IPCP is in use > > and you've mententioned IP addresses, but that is only a guess because > > you don't need to have any IP addresses in use (not to mention > > negotiated) even with IPCP Configure-Acks being exchanged. > > Each link has only one address. Are there 2 or 4 IP addresses total? IPCP does not negotiate addresses for "links" but for PPP peers. Sometimes both PPP peers negotiate the same address or one peer has not address so that the link can be said to have one address. Modulo my confusion about the scenario, the most likely case I can imagine is 3 IP addresses, 1 for the CPE, and 1 for each of the two CO instances. I can get 4 addresses by assuming the "gaming" involves RFC 1918 addresses. > ... > If by "pair of PPP peers" you mean two things located in the same box, > then we are not talking about the same thing. Just to be clear, I am > describing two independant PPP session. One session from a CPE box to > a CO concentrator which has the default route and one session from the > same CPE box to the same CO concentrator over a different link (perhaps > physical but possibly virtual) which has a static route to a single > network. > > > - how are the two PPP state machines in a pair at either the CO or the > > CPE related or coordinated? What happens if one of the PPP links > > goes down? Should traffic that would normally use the other link > > switch to the remaining link? > > They are not related or coordinated (as far as PPP goes). They just > come from the same box and go to the same box. Yes, but what happens to IP traffic? Say the non-default-route PPP link goes down. By the usual rules, the "game" traffic should now use the default-route PPP link. Is that desired in this case? How does the CPE know which PPP link is which? Does it just assume that the PPP link with the non-default route is for gaming? On the other hand, if the CPE knows gaming by manual configuration and CHAP username, then why does it need any IPCP, RIP, or DHCP bits? Why can't that manual conguration say "use this PPP link for game packets" intead of "use this PPP link for anything with the right route"? > > - what is the difference between the traffic for the two links? Does > > it differ only by IP address? > > I can't speak to payload, but the one link carries all the default > traffic and the other link carries only traffic to/from the single > static network. How does the CPE know that it should put this special, ill defined traffic into IP packets with a "static" IP address? Since there is to be a "static network," how does the CPE know about it? > ... > > - why do you need two PPP links to a single 3G telephone? Why not > > use a single PPP link and an appropriate queuing discipline for > > the various kinds of traffic? > > Good point. I suspect the answer has something to do with operational > requirements/constraints. I don't think, however, that separate > parallel networks are completely uncommon. Certainly folks like UUNet > and PSI have (in the way back past) used them for multicast traffic. > I suspect gaming traffic is operationally like multicast... (if you > squint hard :-) Yes, but I think those parallel PPP links were rather more static. At least, they didn't use an IPCP option for routing. My best guess of the instant is that what is really wanted is not an IPCP option carrying a route, but something carrying a netmask and a bit that says "DO NOT use this link for anything except packets to this network." It sounds as if you would put default-route options into all IPCP Configure-Requests except the special "gaming" links. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Tue May 27 23:31:27 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 8EF5A5DF47; Tue, 27 May 2003 23:31:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA00F91227; Tue, 27 May 2003 23:31:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 346459122B; Tue, 27 May 2003 23:31:09 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3CD291227 for ; Tue, 27 May 2003 23:31:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8462A5DF4C; Tue, 27 May 2003 23:31:02 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 93D6C5DF4B for ; Tue, 27 May 2003 23:31:01 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h4S3UxO1011115 for ietf-ppp@merit.edu env-from ; Tue, 27 May 2003 21:30:59 -0600 (MDT) Date: Tue, 27 May 2003 21:30:59 -0600 (MDT) From: Vernon Schryver Message-Id: <200305280330.h4S3UxO1011115@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: IANA PPP considerations Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu What needs to be done to get the IANA considerations advanced? I've heard no comments about draft-schryver-pppext-iana-00.txt since it was published a week ago. It's not listed on http://ietf.org/html.charters/pppext-charter.html If I misunderstood and someone else should write it or it is a bad thing best forgotten, that's fine with me. If I understood correctly that there is a consensus for trying to ensure that allocations of PPP numbers get reviewed, what needs to be done next? Is it something I can do? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp@merit.edu Wed May 28 07:32:29 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 6BD295E2BA; Wed, 28 May 2003 07:32:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 65E7E9122E; Wed, 28 May 2003 07:32:23 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3596291235; Wed, 28 May 2003 07:32:23 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 33BC69122E for ; Wed, 28 May 2003 07:32:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F3255E2CD; Wed, 28 May 2003 07:31:35 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 905295E2CB for ; Wed, 28 May 2003 07:31:34 -0400 (EDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4SBVMLv017153; Wed, 28 May 2003 04:31:22 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SBVL7O016700; Wed, 28 May 2003 07:31:21 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4SBVL6e054737; Wed, 28 May 2003 07:31:21 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4SBVL6O054734; Wed, 28 May 2003 07:31:21 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16084.40457.414124.898357@gargle.gargle.HOWL> Date: Wed, 28 May 2003 07:31:21 -0400 From: James Carlson To: Vernon Schryver Cc: ietf-ppp@merit.edu Subject: Re: IANA PPP considerations In-Reply-To: Vernon Schryver's message of 27 May 2003 21:30:59 References: <200305280330.h4S3UxO1011115@calcite.rhyolite.com> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Vernon Schryver writes: > If I misunderstood and someone else should write it or it is a bad > thing best forgotten, that's fine with me. I think it's a good thing, though perhaps the IPR statement could be dropped as (I hope!) you haven't actually filed a patent on the IANA statement. > If I understood correctly that there is a consensus for trying to > ensure that allocations of PPP numbers get reviewed, what needs to be > done next? Is it something I can do? I believe that Karl Fox needs to send mail to the IAD (Thomas Narten and Erik Nordmark) proposing that this be published as a Best Current Practice. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed May 28 08:50:44 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id B9BD55DE73; Wed, 28 May 2003 08:50:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7D25291235; Wed, 28 May 2003 08:50:31 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44B5691236; Wed, 28 May 2003 08:50:31 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5108291235 for ; Wed, 28 May 2003 08:50:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 314655E302; Wed, 28 May 2003 08:50:30 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ohsmtp03.ogw.rr.com (ohsmtp03.ogw.rr.com [65.24.7.38]) by segue.merit.edu (Postfix) with ESMTP id E56935E1B5 for ; Wed, 28 May 2003 08:50:29 -0400 (EDT) Received: from [10.0.0.3] (dhcp93126241.columbus.rr.com [24.93.126.241]) by ohsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h4SCoL6E028475; Wed, 28 May 2003 08:50:21 -0400 (EDT) Subject: Re: IANA PPP considerations From: Karl Fox To: James Carlson Cc: Vernon Schryver , ietf-ppp@merit.edu In-Reply-To: <16084.40457.414124.898357@gargle.gargle.HOWL> References: <200305280330.h4S3UxO1011115@calcite.rhyolite.com> <16084.40457.414124.898357@gargle.gargle.HOWL> Content-Type: text/plain Organization: Message-Id: <1054126219.30937.1.camel@kff> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 28 May 2003 08:50:20 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Should I do it now or should I wait for a change to the IPR statement? Is it really necessary in a document like this? Karl On Wed, 2003-05-28 at 07:31, James Carlson wrote: > Vernon Schryver writes: > > If I misunderstood and someone else should write it or it is a bad > > thing best forgotten, that's fine with me. > > I think it's a good thing, though perhaps the IPR statement could be > dropped as (I hope!) you haven't actually filed a patent on the IANA > statement. > > > If I understood correctly that there is a consensus for trying to > > ensure that allocations of PPP numbers get reviewed, what needs to be > > done next? Is it something I can do? > > I believe that Karl Fox needs to send mail to the IAD (Thomas Narten > and Erik Nordmark) proposing that this be published as a Best Current > Practice. From owner-ietf-ppp@merit.edu Wed May 28 08:56:55 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 4CE055DD90; Wed, 28 May 2003 08:56:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42BD091236; Wed, 28 May 2003 08:56:40 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1682391237; Wed, 28 May 2003 08:56:40 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 20D6691236 for ; Wed, 28 May 2003 08:56:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E2FC5DD95; Wed, 28 May 2003 08:56:39 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id AA9EB5DD90 for ; Wed, 28 May 2003 08:56:38 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4SCuRep029538; Wed, 28 May 2003 06:56:27 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SCuREg019378; Wed, 28 May 2003 08:56:27 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4SCuQ6e056791; Wed, 28 May 2003 08:56:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4SCuQtV056788; Wed, 28 May 2003 08:56:26 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16084.45562.814515.137200@gargle.gargle.HOWL> Date: Wed, 28 May 2003 08:56:26 -0400 From: James Carlson To: Karl Fox Cc: Vernon Schryver , ietf-ppp@merit.edu Subject: Re: IANA PPP considerations In-Reply-To: Karl Fox's message of 28 May 2003 08:50:20 References: <200305280330.h4S3UxO1011115@calcite.rhyolite.com> <16084.40457.414124.898357@gargle.gargle.HOWL> <1054126219.30937.1.camel@kff> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Karl Fox writes: > Should I do it now or should I wait for a change to the IPR statement? > Is it really necessary in a document like this? Since this bit of boilerplate is not really material to the wg's interest in the document, and appears to be more of an editorial matter that will almost certainly be handled by IESG review, I don't see a particular need to wait before doing a last call and submission. But I think it should be your call. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Wed May 28 09:05:15 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 57B155DDA2; Wed, 28 May 2003 09:05:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE05C91237; Wed, 28 May 2003 09:05:03 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7193A91238; Wed, 28 May 2003 09:05:03 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52D9E91237 for ; Wed, 28 May 2003 09:05:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0FE505DDA2; Wed, 28 May 2003 09:05:02 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ohsmtp03.ogw.rr.com (ohsmtp03.ogw.rr.com [65.24.7.38]) by segue.merit.edu (Postfix) with ESMTP id 8DF435DDA3 for ; Wed, 28 May 2003 09:05:01 -0400 (EDT) Received: from [10.0.0.3] (dhcp93126241.columbus.rr.com [24.93.126.241]) by ohsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h4SD506E009928; Wed, 28 May 2003 09:05:00 -0400 (EDT) Subject: IANA Considerations for PPP to Proposed Standard From: Karl Fox To: Thomas Narten , Erik Nordmark Cc: ietf-ppp@merit.edu, iesg-secretary@ietf.org Content-Type: text/plain Organization: Message-Id: <1054127099.30903.5.camel@kff> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 28 May 2003 09:04:59 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that IANA Considerations for PPP, draft-schryver-pppext-iana-00.txt, be advanced to Proposed Standard. Thanks, Karl From owner-ietf-ppp@merit.edu Wed May 28 20:36:38 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 334915E001; Wed, 28 May 2003 20:36:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C07891245; Wed, 28 May 2003 20:36:25 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DC1191246; Wed, 28 May 2003 20:36:24 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1808791245 for ; Wed, 28 May 2003 20:36:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F2B7B5E001; Wed, 28 May 2003 20:36:23 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ohsmtp02.ogw.rr.com (ohsmtp02.ogw.rr.com [65.24.7.37]) by segue.merit.edu (Postfix) with ESMTP id 82DFD5DFA8 for ; Wed, 28 May 2003 20:36:23 -0400 (EDT) Received: from [10.0.0.3] (dhcp93126241.columbus.rr.com [24.93.126.241]) by ohsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h4T0aIYU018718; Wed, 28 May 2003 20:36:22 -0400 (EDT) Subject: Re: draft-song-pppext-sip-support-02.txt From: Karl Fox To: Thomas Narten Cc: ietf-ppp@merit.edu In-Reply-To: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu> References: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu> Content-Type: text/plain Organization: Message-Id: <1054168576.30937.42.camel@kff> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 28 May 2003 20:36:16 -0400 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I think the consensus is clear: Existing mechanisms are adequate to the task. Karl On Wed, 2003-05-14 at 14:32, Thomas Narten wrote: > Speaking of which, the RFC editor has received a request to publish > the above document as an informational RFC. > > What does this WG think of this request? Should the RFC editor publish > this document? Or would doing so be an end-run around this WG? > > Thomas From owner-ietf-ppp@merit.edu Thu May 29 08:07:33 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 53E145E2C9; Thu, 29 May 2003 08:07:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6024091250; Thu, 29 May 2003 08:07:20 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DC7691253; Thu, 29 May 2003 08:07:20 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19AB691250 for ; Thu, 29 May 2003 08:07:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7AE55E2C9; Thu, 29 May 2003 08:07:19 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mta03bw.bigpond.com (mta03bw.bigpond.com [139.134.6.86]) by segue.merit.edu (Postfix) with ESMTP id B7CF85E2C4 for ; Thu, 29 May 2003 08:07:17 -0400 (EDT) Received: from oemcomputer ([144.135.24.87]) by mta03bw.bigpond.com (Netscape Messaging Server 4.15 mta03bw Jul 16 2002 22:47:55) with SMTP id HFNDO100.CQA for ; Thu, 29 May 2003 22:07:13 +1000 Received: from 144.139.99.87 ([144.139.99.87]) by bwmam07.bigpond.com(MailRouter V3.2g 56/5688759); 29 May 2003 22:07:04 Message-ID: <006201c325db$848b67e0$7a638b90@oemcomputer> From: "Glardy" To: "PPP Mailing List" Subject: Configuration of remote routers (IPCP vs DHCP) Date: Thu, 29 May 2003 22:11:03 +1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C3262F.31C63EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C3262F.31C63EA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The recent discussions about using IPCP to pass static routes to a PPP = peer, negotiate a netmask etc, suggest that a lot of people are trying = to work out how to address the problem of configuring remote routers = over a PPP connection (dial-up or xDSL mostly I would guess). Summary: Check out RFC 3442 and draft-ietf-dhc-subnet-alloc-00.txt for = how to do this with DHCP. Long version: The context where I have faced this problem is where I have a large = number of small remote sites connecting up to my central access server = using PPP. Each remote site generally has a router with a small network = behind it, and I want my central server to be able to send the router a = subnet to use in addition to the IP address it got for the PPP link. It = could then give itself an address out of that subnet and set itself up = as a DHCP server (or possibly a relay) to allow other hosts on the = remote network to get an IP address, netmask and default gateway. In = more complex scenarios there may be multiple subnets involved and = perhaps a couple of static routes required as well. Many small routers have a DHCP server and/or relay agent built-in = already, and RADIUS gives me the ability to send the necessary = addressing and routing information to the access server. What is = lacking is a protocol to transport that information from the server to = the remote router for it to set up its DHCP server. Given the general consensus on the list that DHCP is a better protocol = than IPCP for this function, I have had a quick look at the dhc working = group's list of work completed and in progress. The problem I have just outlined appears to have been solved there. The = option to pass classless static routes in DHCP is in RFC 3442 (Standards = track) and the option to allocate multiple subnets to a host is = currently a dhc working group draft = (draft-ietf-dhc-subnet-alloc-00.txt). Looks like I will have to implement DHCP on my access server. I don't = suppose anyone knows of an ISDN/ADSL router that implements a DHCP = client for remote configuration? Cheers, Greg Lampard ------=_NextPart_000_005F_01C3262F.31C63EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The recent discussions about using IPCP = to pass=20 static routes to a PPP peer, negotiate a netmask etc, suggest that = a lot of=20 people are trying to work out how to address the problem of configuring = remote=20 routers over a PPP connection (dial-up or xDSL mostly I would=20 guess).
 
Summary:  Check out RFC 3442 and=20 draft-ietf-dhc-subnet-alloc-00.txt for how to do this with = DHCP.
 
Long version:
 
The context where I have faced = this problem is=20 where I have a large number of small remote sites connecting up to my = central=20 access server using PPP.  Each remote site generally has a router = with a=20 small network behind it, and I want my central server to be able to send = the=20 router a subnet to use in addition to the IP address it got for the PPP=20 link.  It could then give itself an address out of that subnet and = set=20 itself up as a DHCP server (or possibly a relay) to allow other hosts on = the=20 remote network to get an IP address, netmask and default gateway.  = In more=20 complex scenarios there may be multiple subnets involved and perhaps a = couple of=20 static routes required as well.
 
Many small routers have a DHCP = server and/or=20 relay agent built-in already, and RADIUS gives me the ability to send = the=20 necessary addressing and routing information to the access server.  = What is=20 lacking is a protocol to transport that information from the server to = the=20 remote router for it to set up its DHCP server.
 
Given the general consensus on the list = that DHCP=20 is a better protocol than IPCP for this function, I have had a quick = look at the=20 dhc working group's list of work completed and in progress.
 
The problem I have just outlined = appears to have=20 been solved there.  The option to pass classless static routes in = DHCP is=20 in RFC 3442 (Standards track) and the option to allocate multiple = subnets to a=20 host is currently a dhc working group draft=20 (draft-ietf-dhc-subnet-alloc-00.txt).
 
Looks like I will have to implement = DHCP on my=20 access server.  I don't suppose anyone knows of an ISDN/ADSL router = that=20 implements a DHCP client for remote configuration?
 
Cheers,
 
Greg Lampard
 
 
------=_NextPart_000_005F_01C3262F.31C63EA0-- From owner-ietf-ppp@merit.edu Thu May 29 09:04:48 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 8E9355E243; Thu, 29 May 2003 09:04:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4010391253; Thu, 29 May 2003 09:04:36 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DB2A91255; Thu, 29 May 2003 09:04:35 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E54091253 for ; Thu, 29 May 2003 09:04:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0135B5E2C8; Thu, 29 May 2003 09:04:35 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E8F605E243 for ; Thu, 29 May 2003 09:04:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h4TCfiq22635; Thu, 29 May 2003 05:41:45 -0700 Date: Thu, 29 May 2003 05:41:44 -0700 (PDT) From: Bernard Aboba To: Glardy Cc: PPP Mailing List Subject: Re: Configuration of remote routers (IPCP vs DHCP) In-Reply-To: <006201c325db$848b67e0$7a638b90@oemcomputer> Message-ID: References: <006201c325db$848b67e0$7a638b90@oemcomputer> 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 > Many small routers have a DHCP server and/or relay agent built-in already, and RADIUS >gives me the ability to send the necessary addressing and routing >information to the access server. What is lacking is a protocol to >transport that information from the server to the remote router for it to >set up its DHCP server. RADIUS has Framed-Route and Framed-Routing. You can use these to setup a routing protocol such as RIP, to operate between your Access Server and the clients. > Given the general consensus on the list that DHCP is a better protocol than IPCP for this I don't think that the concensus was that either was a subsitute for a routing protocol. From owner-ietf-ppp@merit.edu Thu May 29 10:05:40 2003 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 7A1B55DDB2; Thu, 29 May 2003 10:05:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEDEE91255; Thu, 29 May 2003 10:05:26 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4A1191256; Thu, 29 May 2003 10:05:26 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B101391255 for ; Thu, 29 May 2003 10:05:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 948675DD9A; Thu, 29 May 2003 10:05:25 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 0D7D15DDB2 for ; Thu, 29 May 2003 10:05:25 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4TE55ep013847; Thu, 29 May 2003 08:05:06 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4TE55Eg004418; Thu, 29 May 2003 10:05:05 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4TE556e061035; Thu, 29 May 2003 10:05:05 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4TE55IO061032; Thu, 29 May 2003 10:05:05 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16086.5008.998630.432757@gargle.gargle.HOWL> Date: Thu, 29 May 2003 10:05:04 -0400 From: James Carlson To: Bernard Aboba Cc: Glardy , PPP Mailing List Subject: Re: Configuration of remote routers (IPCP vs DHCP) In-Reply-To: Bernard Aboba's message of 29 May 2003 05:41:44 References: <006201c325db$848b67e0$7a638b90@oemcomputer> X-Mailer: VM 7.01 under Emacs 21.3.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Bernard Aboba writes: > > Given the general consensus on the list that DHCP is a better protocol than IPCP for this > > I don't think that the concensus was that either was a subsitute for a routing protocol. It all depends on what you're trying to accomplish. If you're delegating address assignment authority for a subnet from one DHCP server to another, then a DHCP-specific mechanism sounds like the best way to go about doing this. If you're just configuring an Ethernet interface that happens to be attached to some CPE box with a PPP link on the other side, then BOOTP, DHCP, or just DHCPINFORM would probably be about right. If all that you're doing is ferrying routes around (and not specifically configuring an interface), then ICMP Router Discovery or RIP-2 are good choices. In any event, the one thing that does *NOT* make sense is to pass a subnet mask along via IPCP and have that mask be somehow applied to either a remote DHCP server, some interface unrelated to the PPP link itself, or to a forwarding table. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677