idnits 2.17.1 draft-ietf-dhc-dhcpv6-subid-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 236. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 4, 2006) is 6628 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) ** Obsolete normative reference: RFC 3315 (ref. '1') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '3') (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC B. Volz 3 Internet-Draft Cisco Systems, Inc. 4 Expires: September 5, 2006 March 4, 2006 6 DHCPv6 Relay Agent Subscriber-ID Option 7 draft-ietf-dhc-dhcpv6-subid-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 5, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This memo defines a new Relay Agent Subscriber-ID option for the 41 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option 42 allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" 43 with DHCPv6 client messages in a way that is independent of the 44 client and of the underlying physical network infrastructure. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 50 3. The Relay Agent Subscriber-ID Option . . . . . . . . . . . . . 3 51 4. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . . 4 52 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 4 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 58 9.2. Informative References . . . . . . . . . . . . . . . . . . 5 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 Intellectual Property and Copyright Statements . . . . . . . . . . 8 62 1. Introduction 64 DHCPv6 [1] provides IP addresses and configuration information for 65 IPv6 clients. It includes a relay agent capability, in which 66 processes within the network infrastructure receive multicast 67 messages from clients and relay them to DHCPv6 servers. In some 68 network environments, it will be useful for the relay agent to add 69 information to the DHCPv6 message before relaying it. 71 The information that relay agents supply can also be used in the 72 server's decision making about the addresses, delegated prefixes [3], 73 and configuration parameters that the client is to receive. 75 In many service provider environments, it is believed to be desirable 76 to associate some provider-specific information with clients' DHCPv6 77 messages that is independent of the physical network configuration 78 and which the relay agent has learned through some means which is 79 outside the scope of this memo. 81 2. Requirements Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [2]. 87 3. The Relay Agent Subscriber-ID Option 89 In complex service provider environments, there is a need to connect 90 a customer's DHCPv6 configuration with the customer's administrative 91 information. The Relay Agent Subscriber-ID option carries a value 92 that can be independent of the physical network configuration through 93 which the subscriber is connected. This value complements, and might 94 well be used in addition to, the network-based information. The 95 "subscriber-id" assigned by the provider is intended to be stable as 96 customers connect through different paths, and as network changes 97 occur. 99 The subscriber-id information allows the service provider to assign/ 100 activate subscriber-specific actions, e.g. assignment of specific IP 101 addresses, prefixes, DNS configuration, trigger accounting, etc. 102 This option is de-coupled from the access network's physical 103 structure, so subscriber moves from one access-point to another, for 104 example, would not require reconfiguration at the service provider's 105 DHCPv6 servers. 107 The subscriber-id information is only intended for use within a 108 single administrative domain and is only exchanged between the relay 109 agents and DHCPv6 servers within that domain. Therefore, the format 110 of and encoding of the data in the option is not standardized and 111 this specification does not establish any semantic requirements on 112 the data. This specification only defines the option for conveying 113 this information from relay agents to DHCPv6 servers. 115 However, as the DHCPv4 Subscriber-ID suboption [4] specifies NVT 116 ASCII [5] encoded data, in environments where both DHCPv4 [6] and 117 DHCPv6 are being used, it MAY be beneficial to use that encoding. 119 The format of the DHCPv6 Relay Agent Subscriber-ID option is shown 120 below: 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | OPTION_SUBSCRIBER_ID | option-len | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 . . 128 . subscriber-id . 129 . . 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 option-code OPTION_SUBSCRIBER_ID (TBD) 134 option-len length, in octets, of the subscriber-id field. 135 The minimum length is 1 octet. 137 subscriber-id The subscriber's identity. 139 4. DHCPv6 Relay Agent Behavior 141 DHCPv6 relay agents MAY be configured to include a Subscriber-ID 142 option in relayed (RELAY-FORW) DHCPv6 messages. How the 143 subscriber-id is assigned and the mechanisms used to configure it are 144 outside the scope of this memo. 146 5. DHCPv6 Server Behavior 148 This option provides additional information to the DHCPv6 server. 149 The DHCPv6 server MAY use this information, if available, in addition 150 to other relay agent option data, other options included in the 151 DHCPv6 client messages, and physical network topology information in 152 order to assign IP addresses, delegate prefixes, and/or other 153 configuration parameters to the client. There is no special 154 additional processing for this option. 156 There is no requirement that a server return this option and its data 157 in a RELAY-REPLY message. 159 6. Security Considerations 161 As the subscriber-id option is only exchanged between relay agents 162 and DHCPv6 servers, [1] section 21.1, provides details on securing 163 DHCPv6 messages sent between servers and relay agents. And, [1] 164 section 23, provides general DHCPv6 security considerations. 166 7. IANA Considerations 168 IANA is requested to assign a DHCPv6 option code for the Relay Agent 169 Subscriber-ID Option. 171 8. Acknowledgements 173 Thanks to Richard Johnson, Theyn Palaniappan, and Mark Stapp as this 174 document is essentially an edited version of their memo [4]. 176 9. References 178 9.1. Normative References 180 [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 181 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 182 RFC 3315, July 2003. 184 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 185 Levels", BCP 14, RFC 2119, March 1997. 187 9.2. Informative References 189 [3] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 190 Configuration Protocol (DHCP) version 6", RFC 3633, 191 December 2003. 193 [4] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID 194 Suboption for the Dynamic Host Configuration Protocol (DHCP) 195 Relay Agent Option", RFC 3993, March 2005. 197 [5] Postel, J. and J. Reynolds, "Telnet Protocol Specification", 198 STD 8, RFC 854, May 1983. 200 [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 201 March 1997. 203 Author's Address 205 Bernard Volz 206 Cisco Systems, Inc. 207 1414 Massachusetts Ave. 208 Boxborough, MA 01719 209 USA 211 Phone: +1 978 936 0382 212 Email: volz@cisco.com 214 Intellectual Property Statement 216 The IETF takes no position regarding the validity or scope of any 217 Intellectual Property Rights or other rights that might be claimed to 218 pertain to the implementation or use of the technology described in 219 this document or the extent to which any license under such rights 220 might or might not be available; nor does it represent that it has 221 made any independent effort to identify any such rights. Information 222 on the procedures with respect to rights in RFC documents can be 223 found in BCP 78 and BCP 79. 225 Copies of IPR disclosures made to the IETF Secretariat and any 226 assurances of licenses to be made available, or the result of an 227 attempt made to obtain a general license or permission for the use of 228 such proprietary rights by implementers or users of this 229 specification can be obtained from the IETF on-line IPR repository at 230 http://www.ietf.org/ipr. 232 The IETF invites any interested party to bring to its attention any 233 copyrights, patents or patent applications, or other proprietary 234 rights that may cover technology that may be required to implement 235 this standard. Please address the information to the IETF at 236 ietf-ipr@ietf.org. 238 Disclaimer of Validity 240 This document and the information contained herein are provided on an 241 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 242 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 243 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 244 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 245 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 246 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 248 Copyright Statement 250 Copyright (C) The Internet Society (2006). This document is subject 251 to the rights, licenses and restrictions contained in BCP 78, and 252 except as set forth therein, the authors retain all their rights. 254 Acknowledgment 256 Funding for the RFC Editor function is currently provided by the 257 Internet Society.