idnits 2.17.1 draft-ietf-dhc-dhcpv6-remoteid-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 243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 233. ** 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 6627 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. '4') (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 Remote ID Option 7 draft-ietf-dhc-dhcpv6-remoteid-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 Remote-ID option for the Dynamic 41 Host Configuration Protocol for IPv6 (DHCPv6). This option is the 42 DHCPv6 equivalent for the Dynamic Host Configuration Protocol for 43 IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified 44 in RFC 3046. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 50 3. The Relay Agent Remote-ID Option . . . . . . . . . . . . . . . 3 51 4. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . . . . 4 52 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 5 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 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 [4], 73 and configuration parameters that the client is to receive. 75 The memo specifies the DHCPv6 equivalent of the DHCPv4 Relay Agent 76 option's Remote-ID suboption as specified in [2]. The motivation and 77 usage scenarios are provided in [2]. 79 2. Requirements Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [3]. 85 3. The Relay Agent Remote-ID Option 87 This option MAY be added by DHCPv6 relay agents which terminate 88 switched or permanent circuits and have mechanisms to identify the 89 remote host end of the circuit. 91 The format of the DHCPv6 Relay Agent Remote-ID option is shown below: 93 0 1 2 3 94 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 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | OPTION_REMOTE_ID | option-len | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | enterprise-number | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 . . 101 . remote-id . 102 . . 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 option-code OPTION_REMOTE_ID (TBD) 107 option-len 4 + the length, in octets, of the remote-id 108 field. The minimum option-len is 5 octets. 110 enterprise-number The vendor's registered Enterprise Number as 111 registered with IANA [5]. 113 remote-id The opaque value for the remote-id. 115 The definition of the remote-id carried in this option is vendor 116 specific. The vendor is indicated in the enterprise-number field. 117 The remote-id field MAY be used to encode, for instance: 119 o a "caller ID" telephone number for dial-up connection 120 o a "user name" prompted for by a Remote Access Server 121 o a remote caller ATM address 122 o a "modem ID" of a cable data modem 123 o the remote IP address of a point-to-point link 124 o a remote X.25 address for X.25 connections 125 o an interface or port identifier 127 Each vendor MUST assure that the remote-id is unique for their 128 enterprise-number, as the octet sequence of enterprise-number 129 followed by remote-id MUST be globally unique. One way to achieve 130 uniqueness might be to include the relay agent's DUID [1] in the 131 remote-id. 133 4. DHCPv6 Relay Agent Behavior 135 DHCPv6 relay agents MAY be configured to include a Remote-ID option 136 in relayed (RELAY-FORW) DHCPv6 messages. 138 5. DHCPv6 Server Behavior 140 This option provides additional information to the DHCPv6 server. 141 The DHCPv6 server, if it is configured to support this option, MAY 142 use this information to select parameters specific to particular 143 users, hosts, or subscriber modems. The combined enterprise-number 144 and remote-id SHOULD be considered an opaque value, with policies 145 based on exact string match only; that is, the remote-id field SHOULD 146 NOT be internally parsed by the server. 148 There is no requirement that a server return this option and its data 149 in a RELAY-REPLY message. 151 6. Security Considerations 153 See [1] section 21.1, on securing DHCPv6 messages sent between 154 servers and relay agents, and section 23, on general DHCPv6 security 155 considerations. [2] discusses how this information can be used to 156 enhance trust in some environments. 158 Note that even if the DHCP server trusts the relay agent not to 159 modify information provided in this option, the confidence in that 160 information is no higher than the confidence that the relay agent has 161 in the information it puts in the option. For example, in some 162 protocols it may be possible for a DHCP client to spoof or otherwise 163 choose port identifiers, caller ID information, or other information 164 carried in this option. Sites should consider such possible spoofing 165 and how likely it is in their environment when deciding what uses of 166 this option are appropriate. 168 7. IANA Considerations 170 IANA is requested to assign a DHCPv6 option code for the Relay Agent 171 Remote-ID Option. 173 8. Acknowledgements 175 Thanks to Michael Patrick for [2], from which I've liberally borrowed 176 text. 178 9. References 179 9.1. Normative References 181 [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 182 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 183 RFC 3315, July 2003. 185 [2] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 186 January 2001. 188 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 189 Levels", BCP 14, RFC 2119, March 1997. 191 9.2. Informative References 193 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 194 Configuration Protocol (DHCP) version 6", RFC 3633, 195 December 2003. 197 [5] "IANA. Private Enterprise Numbers.", 198 . 200 Author's Address 202 Bernard Volz 203 Cisco Systems, Inc. 204 1414 Massachusetts Ave. 205 Boxborough, MA 01719 206 USA 208 Phone: +1 978 936 0382 209 Email: volz@cisco.com 211 Intellectual Property Statement 213 The IETF takes no position regarding the validity or scope of any 214 Intellectual Property Rights or other rights that might be claimed to 215 pertain to the implementation or use of the technology described in 216 this document or the extent to which any license under such rights 217 might or might not be available; nor does it represent that it has 218 made any independent effort to identify any such rights. Information 219 on the procedures with respect to rights in RFC documents can be 220 found in BCP 78 and BCP 79. 222 Copies of IPR disclosures made to the IETF Secretariat and any 223 assurances of licenses to be made available, or the result of an 224 attempt made to obtain a general license or permission for the use of 225 such proprietary rights by implementers or users of this 226 specification can be obtained from the IETF on-line IPR repository at 227 http://www.ietf.org/ipr. 229 The IETF invites any interested party to bring to its attention any 230 copyrights, patents or patent applications, or other proprietary 231 rights that may cover technology that may be required to implement 232 this standard. Please address the information to the IETF at 233 ietf-ipr@ietf.org. 235 Disclaimer of Validity 237 This document and the information contained herein are provided on an 238 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 239 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 240 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 241 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 242 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 243 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 245 Copyright Statement 247 Copyright (C) The Internet Society (2006). This document is subject 248 to the rights, licenses and restrictions contained in BCP 78, and 249 except as set forth therein, the authors retain all their rights. 251 Acknowledgment 253 Funding for the RFC Editor function is currently provided by the 254 Internet Society.