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 February 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 February 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 with out 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 February 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 February 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]