idnits 2.17.1 draft-volz-dhc-dhcpv6-subid-00.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 228. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (December 20, 2004) is 7067 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) -- No information found for draft-ietf-dhc-subscriber-id- - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 9 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: June 20, 2005 December 20, 2004 6 DHCPv6 Relay Agent Subscriber-ID Option 7 draft-volz-dhc-dhcpv6-subid-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 This Internet-Draft will expire on June 20, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This memo defines a new Relay Agent Subscriber-ID option for the 43 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option 44 allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" 45 with DHCPv6 client messages in a way that is independent of the 46 client and of the underlying physical network infrastructure. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 52 3. The Relay Agent Subscriber-ID Option . . . . . . . . . . . . . 3 53 4. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . 4 54 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 4 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 5 60 9.2 Informative References . . . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 62 Intellectual Property and Copyright Statements . . . . . . . . 6 64 1. Introduction 66 DHCPv6 [1] provides IP addresses and configuration information for 67 IPv6 clients. It includes a relay agent capability, in which 68 processes within the network infrastructure receive multicast 69 messages from clients and relay them to DHCPv6 servers. In some 70 network environments, it will be useful for the relay agent to add 71 information to the DHCPv6 message before relaying it. 73 The information that relay agents supply can also be used in the 74 server's decision making about the addresses, delegated prefixes [3], 75 and configuration parameters that the client is to receive. 77 In many service provider environments, it is believed to be desirable 78 to associate some provider-specific information with clients' DHCPv6 79 messages that is independent of the physical network configuration 80 and which the relay agent has learned through some means which is 81 outside the scope of this memo. 83 2. Requirements Terminology 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 [2]. 89 3. The Relay Agent Subscriber-ID Option 91 In complex service provider environments, there is a need to connect 92 a customer's DHCPv6 configuration with the customer's administrative 93 information. The Relay Agent Subscriber-ID option carries a value 94 that can be independent of the physical network configuration through 95 which the subscriber is connected. This value complements, and might 96 well be used in addition to, the network-based information. The 97 "subscriber-id" assigned by the provider is intended to be stable as 98 customers connect through different paths, and as network changes 99 occur. 101 The subscriber-id information allows the service provider to assign/ 102 activate subscriber-specific actions, e.g. assignment of specific IP 103 addresses, prefixes, DNS configuration, trigger accounting, etc. 104 This option is de-coupled from the access network's physical 105 structure, so subscriber moves from one access-point to another, for 106 example, would not require reconfiguration at the service provider's 107 DHCPv6 servers. 109 The subscriber-id is an NVT ASCII [4] string. The semantic contents 110 of the subscriber-id field are of course provider-specific. This 111 specification does not establish any semantic requirements on the 112 data in the string. 114 The format of the DHCPv6 Relay Agent Subscriber-ID option is shown 115 below: 117 0 1 2 3 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | OPTION_SUBSCRIBER_ID | option-len | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 . . 123 . subscriber-id . 124 . . 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 option-code OPTION_SUBSCRIBER_ID (TBD) 129 option-len length, in octets, of the subscriber-id field. 130 The minimum length is 1 octet. 132 subscriber-id A NVT ASCII string. It MUST NOT be null 133 terminated. 135 4. DHCPv6 Relay Agent Behavior 137 DHCPv6 relay agents MAY be configured to include a Subscriber-ID 138 option in relayed (RELAY-FORW) DHCPv6 messages. The subscriber-id 139 strings themselves are assigned and configured through mechanisms 140 that are outside the scope of this memo. 142 5. DHCPv6 Server Behavior 144 This option provides additional information to the DHCPv6 server. 145 The DHCPv6 server, if it is configured to support this option, MAY 146 use this information in addition to other relay agent option data, 147 other options included in the DHCPv6 client messages, and physical 148 network topology information in order to assign IP addresses, 149 delegate prefixes, and/or other configuration parameters to the 150 client. There is no special additional processing for this option. 152 There is no requirement that a server return this option and its data 153 in a RELAY-REPLY message. 155 6. Security Considerations 157 See [1] section 21.1, on securing DHCPv6 messages sent between 158 servers and relay agents, and section 23, on general DHCPv6 security 159 considerations. 161 7. IANA Considerations 163 IANA is requested to assign a DHCPv6 option code for the Relay Agent 164 Subscriber-ID Option. 166 8. Acknowledgements 168 Thanks to Richard Johnson, Theyn Palaniappan, and Mark Stapp as this 169 document is essentially an edited verison of their memo [5]. 171 9. References 173 9.1 Normative References 175 [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 176 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 177 RFC 3315, July 2003. 179 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 180 Levels", BCP 14, RFC 2119, March 1997. 182 9.2 Informative References 184 [3] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 185 Configuration Protocol (DHCP) version 6", RFC 3633, December 186 2003. 188 [4] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 189 8, RFC 854, May 1983. 191 [5] Johnson, R., Palaniappan, T. and M. Stapp, "Subscriber-ID 192 Suboption for the DHCP Relay Agent Option 193 (draft-ietf-dhc-subscriber-id-*.txt)", September 2004. 195 Author's Address 197 Bernard Volz 198 Cisco Systems, Inc. 199 1414 Massachusetts Ave. 200 Boxborough, MA 01719 201 USA 203 Phone: +1 978 936 0382 204 EMail: volz@cisco.com 206 Intellectual Property Statement 208 The IETF takes no position regarding the validity or scope of any 209 Intellectual Property Rights or other rights that might be claimed to 210 pertain to the implementation or use of the technology described in 211 this document or the extent to which any license under such rights 212 might or might not be available; nor does it represent that it has 213 made any independent effort to identify any such rights. Information 214 on the procedures with respect to rights in RFC documents can be 215 found in BCP 78 and BCP 79. 217 Copies of IPR disclosures made to the IETF Secretariat and any 218 assurances of licenses to be made available, or the result of an 219 attempt made to obtain a general license or permission for the use of 220 such proprietary rights by implementers or users of this 221 specification can be obtained from the IETF on-line IPR repository at 222 http://www.ietf.org/ipr. 224 The IETF invites any interested party to bring to its attention any 225 copyrights, patents or patent applications, or other proprietary 226 rights that may cover technology that may be required to implement 227 this standard. Please address the information to the IETF at 228 ietf-ipr@ietf.org. 230 Disclaimer of Validity 232 This document and the information contained herein are provided on an 233 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 234 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 235 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 236 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 237 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 238 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 240 Copyright Statement 242 Copyright (C) The Internet Society (2004). This document is subject 243 to the rights, licenses and restrictions contained in BCP 78, and 244 except as set forth therein, the authors retain all their rights. 246 Acknowledgment 248 Funding for the RFC Editor function is currently provided by the 249 Internet Society.