idnits 2.17.1 draft-ietf-dhc-subscriber-id-02.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 7133 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-02.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 an arbitrary 40 number of bytes defining what will be called the "Subscriber ID". 41 This value is simply defined as a printable character string. Its 42 intended purpose is to give additional information which the DHCP 43 server can use in address allocation. 45 1.0 Introduction 47 The Remote-ID sub-option of the relay agent information option (also 48 called option-82) are calculated based on network resources like ip- 49 address of the NSAP, atm VP, atm VC. As a result, when moving a link 50 to a different port, a different value is calculated. This holds true 51 for every subscriber that is connected with the particular link and 52 the links are connected to different service providers. When the 53 subscriber moves, each Service Provider has to be informed of the 54 change and all the Service Providers have to change their DHCP [2] 55 settings for the affected customers at the same time. 57 When the service delivered has not changed, every move involves 58 administrative changes in Service Providers environment causing delay 59 in the customer service. 61 Therefore an additional Relay Suboption for the DHCP Relay Agent 62 option is being introduced, to add a configurable printable character 63 string to provide this information. This unique id will enable the 64 Service Provider to identify a subscriber and to assign/activate 65 subscriber specific actions, e.g. assignment of host IP address, 66 subnet mask, DNS, trigger accounting, etc. This specific field is de- 67 coupled from the NAS-IP, since the users could be able to move from 68 NAS termination points. Thus when a subscriber moves from one NAS to 69 another, this would not result in a configuration change on the side 70 of the DHCP server of the Service Provider. 72 This memo describes a new DHCP Relay suboption which would carry a 73 "Subscriber ID" value. The value is a printable character string 74 giving the name of the subscriber. 76 1.1 Conventions 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC-2119 [1]. 82 1.2 Terminology 84 VC Virtual Channel. Logical circuit created to ensure reliable 85 communication between two network devices. A virtual circuit 86 is defined by a VPI/VCI pair, and can be either permanent 87 (PVC) or switched (SVC). Virtual circuits are used in Frame 88 Relay and X.25. In ATM, a virtual circuit is called a virtual 89 channel. 91 VP Virtual Path. Logical grouping of virtual circuits that 92 connect two sites. 94 NAS Network Access Server. Platform (or collection of platforms) 95 that interfaces between the packet world (for example, the 96 Internet) and the circuit world (for example, the PSTN). 98 NSAP Network Service Access Point. Network addresses, as specified 99 by ISO. An NSAP is the point at which OSI network service is 100 made available to a transport layer (Layer 4) entity. 102 PSTN Public Switched Telephone Network. General term referring to 103 the variety of telephone networks and services in place 104 worldwide. 106 NVT ASCII Network Virtual Terminal American Standard Code for 107 Information Interchange. [6] 109 2.0 DHCP Relay Information Suboption Definition 111 The Subscriber ID is a DHCP Relay Information Suboption. The exact 112 option code value is TBD. The suboption takes the same form as other 113 Relay Information Suboptions: 115 Code Len Subscribe ID string 116 +-----+-----+------+-----+-----+--- 117 | TBD | n | v1 | v2 | v3 | ... 118 +-----+-----+------+-----+-----+--- 120 The option minimum length (n) is 1. 122 The "Subscriber ID string", in NVT ASCII, MUST NOT be NULL terminated 123 since the length is specified in the "len" field. 125 This option provides the DHCP server additional information upon 126 which to make a determination of address to be assigned. The DHCP 127 server, if it is configured to support this option, should use this 128 information in addition to other options included in the DHCPDISCOVER 129 packet in order to assign an IP address for the DHCP client. 131 As per [3], the contents of the entire Relay Agent Option SHALL be 132 included in all replies by DHCP servers understanding the Relay Agent 133 Option. There is no special additional processing for this 134 suboption. 136 3.0 Security Considerations 138 Message authentication in DHCP for intradomain use where the out-of- 139 band exchange of a shared secret is feasible is defined in RFC 3118 140 [5]. Potential exposures to attack are discussed in section 7 of the 141 DHCP protocol specification in RFC 2131 [2]. 143 The DHCP Relay Agent option depends on a trusted relationship between 144 the DHCP relay agent and the server, as described in section 5 of RFC 145 3046. While the introduction of fraudulent relay-agent options can 146 be prevented by a perimeter defense that blocks these options unless 147 the relay agent is trusted, a deeper defense using the authentication 148 option for relay agent options [4] SHOULD be deployed as well. 150 4.0 IANA Considerations 152 IANA has assigned a value of TBD for the DHCP Relay Information 153 Suboption code described in this document. 155 5.0 Acknowledgements 157 This document is the result of work done within Cisco Systems. 158 Thanks to Mark Stapp and Theyn Palaniappan for their work on this 159 option definition and the other related work for which this is 160 necessary. Thanks also to Andy Sudduth for his review comments. 162 References 164 [1] Bradner, S., "Key words for use in RFCs to Indicate 165 Requirement Levels", RFC 2119, BCP 14, March 1997. 167 [2] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 168 March 1997. 170 [3] Patrick, M., "DHCP Relay Agent Information Option", 171 RFC 3046, January 2001 173 [4] Stapp, M. "The Authentication Suboption for the DHCP 174 Relay Agent Option", draft-ietf-dhc-auth-suboption-00.txt, 175 June 23, 2002 177 [5] Droms, R. "Authentication for DHCP Messages", RFC 3118, 178 June 2001 180 [6] Postel, J., "Telnet Protocol Specification", RFC 854, 181 May 1983 183 Author Information: 185 Richard Johnson 186 Theyn Palaniappan 187 Cisco Systems 188 170 W. Tasman Dr. 189 San Jose, CA 95134 191 Phone: (408) 526-4000 193 EMail: athenmoz@cisco.com 194 raj@cisco.com 196 Mark Stapp 197 Cisco Systems 198 250 Apollo Drive 199 Chelmsford, MA 01824 201 Phone: (978) 244-8000 203 EMail: rdroms@cisco.com 204 mjs@cisco.com 206 Copyright Notice 208 Copyright (C) The Internet Society (2002). All Rights Reserved. 210 This document and translations of it may be copied and furnished to 211 others, and derivative works that comment on or otherwise explain it 212 or assist in its implementation may be prepared, copied, published 213 and distributed, in whole or in part, without restriction of any 214 kind, provided that the above copyright notice and this paragraph are 215 included on all such copies and derivative works. However, this 216 document itself may not be modified in any way, such as by removing 217 the copyright notice or references to the Internet Society or other 218 Internet organizations, except as needed for the purpose of 219 developing Internet standards in which case the procedures for 220 copyrights defined in the Internet Standards process must be 221 followed, or as required to translate it into languages other than 222 English. 224 The limited permissions granted above are perpetual and will not be 225 revoked by the Internet Society or its successors or assigns. 227 This document and the information contained herein is provided on an 228 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 229 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 230 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 231 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 232 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."