idnits 2.17.1 draft-kehn-info-ppp-ipcp-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2003) is 7652 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Doug Kehn 3 draft-kehn-info-ppp-ipcp-ext-00.txt Efficient Networks Inc. 4 Category: Informational May 2003 5 Expires: November 2003 7 PPP Internet Protocol Control Protocol Extensions 8 for 9 Route Table Entries 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ieft/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 The Point-to-Point Protocol (PPP) [1] provides a standard method for 39 transporting multi-protocol datagrams over point-to-point links. PPP 40 defines a family of Network Control Protocols (NCPs) for establishing 41 and configuring different network-layer protocols. The PPP Internet 42 Protocol Control Protocol (IPCP) [2] defines the NCP for establishing 43 and configuring the Internet Protocol (IP) [3]. 45 This document extends IPCP by defining the negotiation of IP route 46 table entries. This extension provides added functionality but is 47 optional and preserves compatibility. 49 1. Introduction 50 PPP is widely used by broadband service providers as the protocol of 51 choice for connecting hosts to the Internet. PPP is popular because 52 it is a well-known protocol that has been utilized by dial-up service 53 providers for many years. PPP also provides per-user access control, 54 billing, etc. These later features of PPP are the most appealing to 55 providers. In recent years, PPP has seen two transport extensions 56 emerge to support broadband access. These transports are PPP over 57 Ethernet (PPPoE) [5] and PPP over AAL5 (PPPoA) [6]. With the 58 emergence of broadband, the PPP client is migrating from the 59 subscribers PC to the broadband customer premise equipment (CPE). 61 Broadband provides more bandwidth to the subscriber. Broadband 62 service providers are wanting to utilize this additional bandwidth to 63 provide additional services to subscribers. Service Providers, for 64 obvious reasons, desire to isolate these additional services from 65 standard Internet service. As stated earlier, PPP provides the per- 66 user access control, billing, etc. This makes PPP a logical choice 67 for providing these additional services. PPP also allows the service 68 provider to utilize its investment in networking hardware used to 69 provide standard Internet access. 71 If PPP is to be used for both Internet access and additional service 72 access, PPP hosts (whether residing in the PC or CPE) must be able to 73 establish multiple PPP links. The presence of multiple PPP links can 74 complicate packet routing decisions in the host. This document 75 proposes an extension to IPCP to address the packet routing issues 76 induced in the presence of multiple PPP links. The extension 77 provides the ability to add route table entries for specific PPP 78 interfaces. 80 2. Conventions 82 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 83 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 84 document, are to be interpreted as described in [4]. 86 3. Additional IPCP Configuration Option 88 3.1 Route-Add 90 Description 92 This configuration option defines a method for negotiating zero or 93 more route table entries for the PPP interface on the local 94 (client) end of the link. If the local peer supports the Route- 95 Add option, it MUST include the Route-Add option with a length of 96 2 to its IPCP Configure Request. The remote (server) peer, if it 97 supports the Route-Add option, SHOULD return the appropriate 98 number of Route-Add option entries in its IPCP response. If the 99 remote peer does not wish to add any route entries to the local 100 peer, the remote peer MUST NOT include the Route-Add option in its 101 response. The local peer MUST accept this response as an 102 indication that the remote peer does not wish to add any routes to 103 the interface. 105 If the remote peer does not support the Route-Add option (e.g. 106 current implementations), the remote peer MAY reject the Route-Add 107 option. This is an indication to the local peer that the remote 108 peer does not support the Route-Add option and IPCP negotiation 109 MUST continue with out it. 111 A Route-Add option entry with a Route-Address and Route-Mask of 112 zero indicates a default route. 114 Any routes added via the Route-Add option MUST be deleted when the 115 IPCP layer terminates. 117 A summary of the Route-Add option format is shown below. The fields 118 are transmitted from left to right and are in network-byte order. 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Type | Length | Route-Address 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 Route-Address (cont) | Route-Mask 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Route-Mask (cont) | Route-Next-Hop 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Route-Next-Hop (cont) | Route-Metric 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Route-Metric (cont) | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Type 136 (To be assigned by IANA) 138 Length 140 18 142 Route-Address 144 The four octet field defining the destination network or host 145 address. 147 Route-Mask 149 The four octet field defining the subnet mask for the route. For 150 host route entries, this field MUST be set to all one's. 152 Route-Next-Hop 154 The four octet field defining the route's next hop. This field 155 MAY be zero if the next hop for the route is the remote peer. 157 Route-Metric 159 The four octet field defining the metric value for the route. 161 Normative References 163 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 164 RFC 1661, Daydreamer, July 1994 166 [2] McGregor, G., "PPP Internet Control Protocol", RFC 1332, Merit, 167 May 1992. 169 Informative References 171 [3] Postel, J., "Internet Protocol", RFC 971, USC/Information 172 Sciences Institute, September 1981. 174 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 175 Levels", BCP 14, RFC 2119, March 1997. 177 [5] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet 178 (PPPoE)", RFC 2516, February 1999. 180 [6] Gross, et. al., "PPP Over AAL5", RFC 2364, July 1998. 182 Security Considerations 184 Security issues are not discussed in this memo. 186 IANA Considerations 188 Requires IPCP option number assignment for the Route-Add option. 190 Acknowledgments 192 This draft was inspired by the "work in progress" . 195 Special thanks goes to Stephen Lyda (Efficient Networks, Inc.), and 196 Dan Dworin (Efficient Networks, Inc.) for their feedback. 198 Author's Address 200 Doug Kehn 201 Efficient Networks Inc. 202 4849 Alpha Road 203 Dallas, TX 75244 204 USA 206 Phone: +1 972 852 1000 207 EMail: dkehn@efficient.com 209 Full Copyright Statement 211 Copyright (C) The Internet Society (2003). All Rights Reserved. 213 This document and translations of it may be copied and furnished to 214 others, and derivative works that comment on or otherwise explain it 215 or assist in its implementation may be prepared, copied, published 216 and distributed, in whole or in part, without restriction of any 217 kind, provided that the above copyright notice and this paragraph are 218 included on all such copies and derivative works. However, this 219 document itself may not be modified in any way, such as by removing 220 the copyright notice or references to the Internet Society or other 221 Internet organizations, except as needed for the purpose of 222 developing Internet standards in which case the procedures for 223 copyrights defined in the Internet Standards process must be 224 followed, or as required to translate it into languages other than 225 English. 227 The limited permissions granted above are perpetual and will not be 228 revoked by the Internet Society or its successors or assigns. 230 This document and the information contained herein is provided on an 231 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 232 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 233 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 234 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 235 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.