idnits 2.17.1 draft-ietf-pppext-nles-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 63 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '... Drafts are ...' == Line 12 has weird spacing: '...cuments of t...' == Line 13 has weird spacing: '...t other group...' == Line 19 has weird spacing: '... Drafts as re...' == Line 21 has weird spacing: '...cts.txt listi...' == (58 more instances...) -- 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 (25 March 1997) is 9894 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Extensions Working Group Avri Doria 2 Internet Draft Xing Chen 3 Expires 30 Sep. 1997 General DataComm 4 25 March 1997 6 Proposal for a PPP Network Layer Entity Selection Protocol 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 Areas, and its Working Groups. Note that other groups may also 14 distribute working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Inter- 19 net Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress.'' Please check the 1id- 21 abstracts.txt listing contained in the internet-drafts Shadow 22 Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, 23 ftp.nisc.sri.com, or munnari.oz.au to learn the current status of 24 any Internet Draft. 26 Abstract 28 With the introduction of xDSL services into public telecommunica- 29 tions networks, direct access (in contrast to dial-up access) will 30 start to be used as an access method for data as well as other 31 services. PPP has been very successful in providing connections 32 for IP as well as other protocols in the dial-up access network. 33 With the advent of direct access, changes will be need to be made 34 for identifying the target hosts, as it will no longer be possible 35 to rely on the telephone number that is dialed prior to initiating 36 the PPP session. This proposal indicates one method for adapting 37 PPP to the new requirements. 39 1. Overview 41 Whether it is for business reasons, or, in the US, because of the 42 Telecommunications Act of 1996, local exchange carriers (LECs), 43 competitive access providers (CAPs) and Internet service providers 44 (ISPs) are all vying for the same markets. Many of the proposed 45 access models include shifting away from POTS (plain old telephone 46 service) to xDSL. This will allow the LECs to offer high end 47 broadband access, with at least partial PPP termination, in the 48 central office with trunking of IP and other traffic over ATM, 49 Frame Relay or Sonet connections. 51 Currently there are two ways to provide PPP access in a direct 52 access network; by using hard wired connections or by using hard 53 state connections. Both of these are unsatisfactory solutions, 54 however, and the LECs are already searching for equipment which 55 allows a direct access customer to switch service providers 56 without needing to also change a hard provisioning. 58 The normal procedure in PPP, is for the PPP termination point to 59 be identified prior to making the connection; for example, the 60 phone number is dialed, or the DLCI is assigned. In a direct 61 access scenario, the customers will have a permanent connection to 62 the central office where the copper loop is terminated. There is 63 currently no means of dynamically defining the service provider 64 prior to making a connection. Several different scenarios were 65 investigated: 67 (1) Add a protocol before LCP to define the service provider 68 requested. 70 This was rejected because the nature of the connection will 71 not change when switching from one service provider to 72 another. While running the LCP connection phase may not be 73 that expensive, it did seem like a a wasted step. Addition- 74 ally, this would require another protocol which did not seem 75 to fit in the PPP model. 77 (2) Add the system identification information to the RADIUS pro- 78 tocol. 80 This was considered, but rejected because of the essential 81 nature of the decision being made. The system to be accessed 82 must be defined before the correct network access server can 83 be selected. It was suggested that the system identifier 84 could be included in one of the RADIUS protocol fields. This 85 becomes difficult when we start to consider different types 86 of addressing that might be used; for example, IP addressing, 87 E.164 addressing, NANP addressing (telephone numbers as in 88 the dial-up case). These have differing forms and lengths 89 and will need to be identified in any protocol used to carry 90 them. 92 (3) Add the target service to the authentication name when using 93 L2TP. 95 This was rejected for similar reasons to those outlined 96 above. It was also rejected because a general mechanism is 97 required, that is, one which does not require tunneling. It 98 is very possible that the LECs will be offering virtual col- 99 location services which use the RADIUS model for authentica- 100 tion and accounting. In this case a model which relies on 101 tunneling would not be effective. 103 (4) Include a connection phase LCP option to identify the ser- 104 vice provider desired. It was suggested that this could 105 either be defined as a standard or as a proprietary solution. 107 This was rejected for several reasons. Partially it was for 108 the same reason suggested above, the connection will not 109 change and there is no reason to renegotiate a connection 110 that is already established. Additionally, it is felt that 111 this may not be an appropriate task for a link establishment 112 phase. Finally, it was felt that this service would be too 113 wide spread for a vendor specific solution. 115 For the reasons outlined above, this draft proposes a new LCP pro- 116 tocol which can be optionally run after the LCP connection phase 117 has completed, but before any authentication protocols are run. 118 This Network Layer Entity Selection Protocol (NLES) is defined in 119 this draft. 121 2. Description of NLES 123 After the LCP has completed but before any of the authentication 124 protocols were run, the NLES will be run. This would be PPP proto- 125 col number cXXX (a number has yet to be applied for from IANA). 127 The message format will be as follows. It follows the Internet 128 Protocol convention for packet description. 130 2.1. NLES Packet format 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Code | Address Type | Address Length | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Address 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 140 2.2. NLES Codes 142 The PPP NLES protocol will support 4 message codes. 144 Code Function 146 1 NLES-Request 147 2 NLES-Ack 148 3 NLES-Nak 149 4 NLES-Reject 151 Code 1 152 In the NLES request, the sender would declare the addressing 153 mode to be used and request a certain address. The reply 154 could be: 156 Code 2 157 In this case, the original message would be returned with the 158 code changed to indicate success. 160 Code 3 161 In this case, the message would be changed to include a pre- 162 ferred address type and address. This type of message could 163 be used to do a query of a service provider if that service 164 provider wished to provide service on different servers 165 depending on some particular policy. 167 Code 4 168 In this case the message would be returned with the code 169 changed to indicate failure. 171 2.3. NLES Address Types 173 The PPP NLES address types are: 175 Type Description Size 177 1 E.164 encoded in BCD format 8 178 2 NANP - North American Number Plan 5 179 3 IP Version 4 4 180 4 IP Version 6 16 182 3. Security Considerations 184 Security issues are not considered in this draft. 186 4. References 188 TBD 190 5. Contacts 192 Chair's Address 194 The working group can be contacted via the current chair: 196 Karl F. Fox 197 Ascend Communications 198 3518 Riverside Dr., Suite 101 199 Columbus, OH USA 43221 201 Authors' Addresses 203 Questions about this draft can be directed to: 205 Avri Doria 206 Boston Research Center 207 General DataComm Inc. 208 5 Mount Royal Ave 209 Marlborough MA USA 01752 211 (508) 624 6723 212 avri@gdc.com 214 Xing Chen 215 Technology Research Center 216 General DataComm Inc 217 Park Road Extension 218 P.O. Box 1299 219 Middlebury, CT 06762-1299 221 (203) 758 1811 222 xchen@gdc.com