idnits 2.17.1 draft-ietf-dhc-subscriber-id-03.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: ---------------------------------------------------------------------------- == 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 Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 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 (October 15, 2004) is 7134 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) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-auth-suboption-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Richard Johnson 3 Internet Draft Mark Stapp 4 Expiration: October 2004 Theyn Palaniappan 5 File: draft-ietf-dhc-subscriber-id-03.txt Cisco Systems, Inc. 7 DHCP Subscriber ID Suboption for the DHCP Relay Agent Option 8 10 October 15, 2004 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 Abstract 39 This memo defines a new DHCP Relay Suboption for passing a printable 40 character string defining named the "Subscriber ID". Its intended 41 purpose is to provide an unchanging description of a "subscriber" 42 such that the underlying hardware and/or aggregation point for a 43 particular DHCP client may change without having to change the 44 configuration on the DHCP server itself. 46 1.0 Introduction 48 The Remote-ID sub-option of the relay agent information option (also 49 called option-82) are calculated based on network resources like IP 50 address of the NSAP, atm VP, atm VC. As a result, when moving a link 51 to a different port, a different value is calculated. This holds true 52 for every subscriber that is connected with the particular link and 53 the links may connected to different service providers. In a 54 situation where the connection to the customer is provided separately 55 from the DHCP service, when the subscriber moves, each Service 56 Provider must be informed of the change and all the Service Providers 57 have to change their DHCP [2] settings for the affected customers. 58 This results in delays and complications due to necessary 59 synchronization of the changes between all parties involved. 61 When the service delivered to the customer has not changed, every 62 move involves administrative changes in Service Providers environment 63 causing delay in the customer service. Any change in the underlying 64 hardware connecting to the customer site will involve reconfiguration 65 of the Service Provider's DHCP server. 67 From an administrative viewpoint there is a simple need to connect a 68 customer's DHCP configuration with the customer administrative 69 information. Using a "subscriber-id" character string, which can 70 uniquely identify the customer, would be preferable to maintaining a 71 database relating the customer to their Option 82 information. 72 Furthermore, any such database would need to be constantly updated 73 whenever a customer moves or the hardware is changed, while the 74 "subscriber-id" designating the customer will not change. 76 An additional Relay Suboption for the DHCP Relay Agent option is 77 being introduced, to add a configurable printable character string to 78 provide this customer information. This unique id will enable the 79 Service Provider to identify a subscriber and to assign/activate 80 subscriber specific actions, e.g. assignment of host IP address, 81 subnet mask, DNS, trigger accounting, etc. This specific field is de- 82 coupled from the NAS-IP, since the users could be able to move 83 between NAS termination points. Thus when a subscriber moves from one 84 NAS to another, this would not result in a configuration change on 85 the side of the DHCP server of the Service Provider. 87 This memo describes a new DHCP Relay suboption which would carry a 88 "Subscriber ID" value. The value is a printable character string 89 giving the name of the subscriber. 91 1.1 Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC-2119 [1]. 97 1.2 Terminology 99 VC Virtual Channel. Logical circuit created to ensure 100 reliable communication between two network devices. A 101 virtual circuit is defined by a VPI/VCI pair, and can be 102 either permanent (PVC) or switched (SVC). Virtual circuits 103 are used in Frame Relay and X.25. In ATM, a virtual 104 circuit is called a virtual channel. 106 VP Virtual Path. Logical grouping of virtual circuits that 107 connect two sites. 109 NAS Network Access Server. Platform (or collection of 110 platforms) that interfaces between the packet world (for 111 example, the Internet) and the circuit world (for example, 112 the PSTN). 114 NSAP Network Service Access Point. Network addresses, as 115 specified by ISO. An NSAP is the point at which OSI 116 network service is made available to a transport layer 117 (Layer 4) entity. 119 PSTN Public Switched Telephone Network. General term referring 120 to the variety of telephone networks and services in place 121 worldwide. 123 NVT ASCII Network Virtual Terminal American Standard Code for 124 Information Interchange. [6] 126 2.0 DHCP Relay Information Suboption Definition 128 The Subscriber ID is a DHCP Relay Information Suboption. The exact 129 option code value is TBD. The suboption takes the same form as other 130 Relay Information Suboptions: 132 Code Len Subscriber ID string 133 +-----+-----+------+-----+-----+--- 134 | TBD | n | v1 | v2 | v3 | ... 135 +-----+-----+------+-----+-----+--- 137 The option minimum length (n) is 1. 139 The "Subscriber ID string", in NVT ASCII, MUST NOT be NULL terminated 140 since the length is specified in the "len" field. 142 This option provides the DHCP server additional information to the 143 DHCP server. The DHCP server, if it is configured to support this 144 option, should use this information in addition to other options 145 included in the DHCPDISCOVER packet in order to assign an IP address 146 and/or other configuration parameters for the DHCP client. 148 As per [3], the contents of the entire Relay Agent Option SHALL be 149 included in all replies by DHCP servers understanding the Relay Agent 150 Option. There is no special additional processing for this 151 suboption. 153 3.0 Security Considerations 155 Message authentication in DHCP for intradomain use where the out-of- 156 band exchange of a shared secret is feasible is defined in RFC 3118 157 [5]. Potential exposures to attack are discussed in section 7 of the 158 DHCP protocol specification in RFC 2131 [2]. 160 The DHCP Relay Agent option depends on a trusted relationship between 161 the DHCP relay agent and the server, as described in section 5 of RFC 162 3046. While the introduction of fraudulent relay-agent options can 163 be prevented by a perimeter defense that blocks these options unless 164 the relay agent is trusted, a deeper defense using the authentication 165 option for relay agent options [4] SHOULD be deployed as well. 167 4.0 IANA Considerations 169 IANA has assigned a value of TBD for the DHCP Relay Information 170 Suboption code described in this document. 172 5.0 Acknowledgments 174 This document is the result of work done within Cisco Systems. 175 Thanks to Mark Stapp and Theyn Palaniappan for their work on this 176 option definition and the other related work for which this is 177 necessary. Thanks also to Andy Sudduth for his review comments. 179 References 181 [1] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", RFC 2119, BCP 14, March 1997. 184 [2] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 185 March 1997. 187 [3] Patrick, M., "DHCP Relay Agent Information Option", 188 RFC 3046, January 2001 190 [4] Stapp, M. "The Authentication Suboption for the DHCP 191 Relay Agent Option", draft-ietf-dhc-auth-suboption-00.txt, 192 June 23, 2002 194 [5] Droms, R. "Authentication for DHCP Messages", RFC 3118, 195 June 2001 197 [6] Postel, J., "Telnet Protocol Specification", RFC 854, 198 May 1983 200 Author Information: 202 Richard Johnson 203 Theyn Palaniappan 204 Cisco Systems 205 170 W. Tasman Dr. 206 San Jose, CA 95134 208 Phone: (408) 526-4000 210 EMail: athenmoz@cisco.com 211 raj@cisco.com 213 Mark Stapp 214 Cisco Systems 215 250 Apollo Drive 216 Chelmsford, MA 01824 218 Phone: (978) 244-8000 220 EMail: rdroms@cisco.com 221 mjs@cisco.com 223 Copyright Notice 225 Copyright (C) The Internet Society (2002). All Rights Reserved. 227 This document and translations of it may be copied and furnished to 228 others, and derivative works that comment on or otherwise explain it 229 or assist in its implementation may be prepared, copied, published 230 and distributed, in whole or in part, without restriction of any 231 kind, provided that the above copyright notice and this paragraph are 232 included on all such copies and derivative works. However, this 233 document itself may not be modified in any way, such as by removing 234 the copyright notice or references to the Internet Society or other 235 Internet organizations, except as needed for the purpose of 236 developing Internet standards in which case the procedures for 237 copyrights defined in the Internet Standards process must be 238 followed, or as required to translate it into languages other than 239 English. 241 The limited permissions granted above are perpetual and will not be 242 revoked by the Internet Society or its successors or assigns. 244 This document and the information contained herein is provided on an 245 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 246 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 247 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 248 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 249 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."