idnits 2.17.1 draft-johnson-dhc-subscriber-id-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: ---------------------------------------------------------------------------- == 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 24, 2002) is 7854 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 Ralph Droms 4 Expiration: April 2003 Mark Stapp 5 File: draft-johnson-dhc-subscriber-id-00.txt Theyn Palaniappan 6 Cisco Systems, Inc. 8 DHCP Subscriber ID Suboption for the DHCP Relay Agent Option 9 11 October 24, 2002 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This memo defines a new DHCP Relay Suboption for passing an arbitrary 41 number of bytes defining what will be called the "Subscriber ID". 42 This value is simply defined as an array of bytes and can be 43 interpreted in any form by the DHCP server. Its intended purpose is 44 to give additional information which the DHCP server can use in 45 address allocation. 47 1.0 Introduction 49 The Remote-ID sub-option of the relay agent information option (also 50 called option-82) are calculated based on network resources like ip- 51 address of the NSAP, atm VP, atm VC. As a result, when moving a link 52 to a different port, a different value is calculated. This holds true 53 for every subscriber that is connected with the particular link and 54 the links are connected to different service providers. When the 55 subscriber moves, each Service Provider has to be informed of the 56 change and all the Service Providers have to change their DHCP [2] 57 settings for the affected customers at the same time. 59 When the service delivered has not changed, every move involves 60 administrative changes in Service Providers environment causing delay 61 in the customer service. 63 Therefore an additional Relay Suboption for the DHCP Relay Agent 64 option is being introduced, to add a configurable hexadecimal value 65 to provide this information. This unique id will enable the Service 66 Provider to identify a subscriber and to assign/activate subscriber 67 specific actions, e.g. assignment of host IP address, subnet mask, 68 DNS, trigger accounting, etc. This specific field is de-coupled from 69 the NAS-IP, since the users could be able to move from NAS 70 termination points. Thus when a subscriber moves from one NAS to 71 another, this would not result in a configuration change on the side 72 of the DHCP server of the Service Provider. 74 This memo describes a new DHCP Relay suboption which would carry a 75 "Subscriber ID" value. The value is simply an array of bytes which 76 can be interpreted by the DHCP server in whatever manner wanted. The 77 value can be a character string giving the name of the subscriber, 78 four bytes interpreted as a big endian unsigned integer giving the 79 number of the subscriber, a string of hex digits giving the 80 subscriber ID, or whatever is needed. The precise definition of the 81 bytes is left to the implementation and field use. 83 1.1 Conventions 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC-2119 [1]. 89 1.2 Terminology 91 VC Virtual Channel. Logical circuit created to ensure reliable 92 communication between two network devices. A virtual circuit is 93 defined by a VPI/VCI pair, and can be either permanent (PVC) or 94 switched (SVC). Virtual circuits are used in Frame Relay and 95 X.25. In ATM, a virtual circuit is called a virtual channel. 97 VP Virtual Path. Logical grouping of virtual circuits that connect 98 two sites. 100 NAS Network Access Server. Platform (or collection of platforms) 101 that interfaces between the packet world (for example, the 102 Internet) and the circuit world (for example, the PSTN). 104 NSAP Network Service Access Point. Network addresses, as specified by 105 ISO. An NSAP is the point at which OSI network service is made 106 available to a transport layer (Layer 4) entity. 108 PSTN Public Switched Telephone Network. General term referring to the 109 variety of telephone networks and services in place worldwide. 111 2.0 DHCP Relay Information Suboption Definition 113 The Subscriber ID is a DHCP Relay Information Suboption. The exact 114 option code value is TBD. The suboption takes the same form as other 115 Relay Information Suboptions: 117 Code Len Subscribe ID octets 118 +-----+-----+------+-----+-----+--- 119 | TBD | n | v1 | v2 | v3 | ... 120 +-----+-----+------+-----+-----+--- 122 The option minimum length (n) is 1. 124 This option provides the DHCP server additional information upon 125 which to make a determination of address to be assigned. The DHCP 126 server, if it is configured to support this option, should use this 127 information in addition to other options included in the DHCPDISCOVER 128 packet in order to assign an IP address for the DHCP client. 130 As per [3], the contents of the entire Relay Agent Option SHALL be 131 included in all replies by DHCP servers understanding the Relay Agent 132 Option. There is no special additional processing for this 133 suboption. 135 3.0 Security Considerations 137 Message authentication in DHCP for intradomain use where the out-of- 138 band exchange of a shared secret is feasible is defined in RFC 3118 139 [5]. Potential exposures to attack are discussed in section 7 of the 140 DHCP protocol specification in RFC 2131 [2]. 142 The DHCP Relay Agent option depends on a trusted relationship between 143 the DHCP relay agent and the server, as described in section 5 of RFC 144 3046. While the introduction of fraudulent relay-agent options can 145 be prevented by a perimeter defense that blocks these options unless 146 the relay agent is trusted, a deeper defense using the authentication 147 option for relay agent options [4] SHOULD be deployed as well. 149 4.0 IANA Considerations 151 IANA has assigned a value of TBD for the DHCP Relay Information 152 Suboption code described in this document. 154 5.0 Acknowledgements 156 This document is the result of work done within Cisco Systems. 157 Thanks to Ralph Droms, Mark Stapp and Theyn Palaniappan for their 158 work on this option definition and the other related work for which 159 this is necessary. Thanks also to Andy Sudduth for his review 160 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 Author Information: 182 Richard Johnson 183 Theyn Palaniappan 184 Cisco Systems 185 170 W. Tasman Dr. 186 San Jose, CA 95134 188 Phone: (408) 526-4000 190 EMail: athenmoz@cisco.com 191 raj@cisco.com 193 Ralph Droms 194 Mark Stapp 195 Cisco Systems 196 250 Apollo Drive 197 Chelmsford, MA 01824 199 Phone: (978) 244-8000 201 EMail: rdroms@cisco.com 202 mjs@cisco.com 204 Copyright Notice 206 Copyright (C) The Internet Society (2002). All Rights Reserved. 208 This document and translations of it may be copied and furnished to 209 others, and derivative works that comment on or otherwise explain it 210 or assist in its implementation may be prepared, copied, published 211 and distributed, in whole or in part, without restriction of any 212 kind, provided that the above copyright notice and this paragraph are 213 included on all such copies and derivative works. However, this 214 document itself may not be modified in any way, such as by removing 215 the copyright notice or references to the Internet Society or other 216 Internet organizations, except as needed for the purpose of 217 developing Internet standards in which case the procedures for 218 copyrights defined in the Internet Standards process must be 219 followed, or as required to translate it into languages other than 220 English. 222 The limited permissions granted above are perpetual and will not be 223 revoked by the Internet Society or its successors or assigns. 225 This document and the information contained herein is provided on an 226 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 227 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 228 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 229 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 230 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."