idnits 2.17.1 draft-volz-dhc-dhcpv6-remoteid-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 223. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 213. ** 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 7060 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: 6 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: June 20, 2005 December 20, 2004 6 DHCPv6 Relay Agent Remote ID Option 7 draft-volz-dhc-dhcpv6-remoteid-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 Remote-ID option for the Dynamic 43 Host Configuration Protocol for IPv6 (DHCPv6). This option is the 44 DHCPv6 equivalent for the Dynamic Host Configuration Protocol for 45 IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified 46 in RFC 3046. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 52 3. The Relay Agent Remote-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 [4], 75 and configuration parameters that the client is to receive. 77 The memo specifies the DHCPv6 equivalent of the DHCPv4 Relay Agent 78 option's Remote-ID suboption as specified in [2]. The motivation and 79 usage scenarios are provided in [2]. 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 [3]. 87 3. The Relay Agent Remote-ID Option 89 This option MAY be added by DHCPv6 relay agents which terminate 90 switched or permanent circuits and have mechanisms to identify the 91 remote host end of the circuit. The remote-id field MAY be used to 92 encode, for instance: 94 o a "caller ID" telephone number for dial-up connection 95 o a "user name" prompted for by a Remote Access Server 96 o a remote caller ATM address 97 o a "modem ID" of a cable data modem 98 o the remote IP address of a point-to-point link 99 o a remote X.25 address for X.25 connections 100 o an interface identity, which might be the switch's DUID [1] 101 suffixed by the interface-id from the DHCPv6 Interface-Id option. 103 The remote ID MUST be globally unique. 105 The format of the DHCPv6 Relay Agent Remote-ID option is shown below: 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | OPTION_REMOTE_ID | option-len | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 . . 113 . remote-id . 114 . . 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 option-code OPTION_REMOTE_ID (TBD) 119 option-len length, in octets, of the remote-id field. 120 The minimum length is 1 octet. 122 remote-id The opaque value for the globally unique 123 remote-id. 125 4. DHCPv6 Relay Agent Behavior 127 DHCPv6 relay agents MAY be configured to include a Remote-ID option 128 in relayed (RELAY-FORW) DHCPv6 messages. 130 5. DHCPv6 Server Behavior 132 This option provides additional information to the DHCPv6 server. 133 The DHCPv6 server, if it is configured to support this option, MAY 134 use this information to select parameters specific to particular 135 users, hosts, or subscriber modems. The remote-id SHOULD be 136 considered an opaque value, with policies based on exact string match 137 only; that is, the option SHOULD NOT be internally parsed by the 138 server. 140 There is no requirement that a server return this option and its data 141 in a RELAY-REPLY message. 143 6. Security Considerations 145 See [1] section 21.1, on securing DHCPv6 messages sent between 146 servers and relay agents, and section 23, on general DHCPv6 security 147 considerations. [2] discusses how this information can be used to 148 enhance trust in some environments. 150 7. IANA Considerations 152 IANA is requested to assign a DHCPv6 option code for the Relay Agent 153 Remote-ID Option. 155 8. Acknowledgements 157 Thanks to Michael Patrick for [2], from which I've liberally borrowed 158 text. 160 9. References 162 9.1 Normative References 164 [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 165 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 166 RFC 3315, July 2003. 168 [2] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 169 January 2001. 171 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 172 Levels", BCP 14, RFC 2119, March 1997. 174 9.2 Informative References 176 [4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 177 Configuration Protocol (DHCP) version 6", RFC 3633, December 178 2003. 180 Author's Address 182 Bernard Volz 183 Cisco Systems, Inc. 184 1414 Massachusetts Ave. 185 Boxborough, MA 01719 186 USA 188 Phone: +1 978 936 0382 189 EMail: volz@cisco.com 191 Intellectual Property Statement 193 The IETF takes no position regarding the validity or scope of any 194 Intellectual Property Rights or other rights that might be claimed to 195 pertain to the implementation or use of the technology described in 196 this document or the extent to which any license under such rights 197 might or might not be available; nor does it represent that it has 198 made any independent effort to identify any such rights. Information 199 on the procedures with respect to rights in RFC documents can be 200 found in BCP 78 and BCP 79. 202 Copies of IPR disclosures made to the IETF Secretariat and any 203 assurances of licenses to be made available, or the result of an 204 attempt made to obtain a general license or permission for the use of 205 such proprietary rights by implementers or users of this 206 specification can be obtained from the IETF on-line IPR repository at 207 http://www.ietf.org/ipr. 209 The IETF invites any interested party to bring to its attention any 210 copyrights, patents or patent applications, or other proprietary 211 rights that may cover technology that may be required to implement 212 this standard. Please address the information to the IETF at 213 ietf-ipr@ietf.org. 215 Disclaimer of Validity 217 This document and the information contained herein are provided on an 218 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 219 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 220 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 221 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 222 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 223 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 225 Copyright Statement 227 Copyright (C) The Internet Society (2004). This document is subject 228 to the rights, licenses and restrictions contained in BCP 78, and 229 except as set forth therein, the authors retain all their rights. 231 Acknowledgment 233 Funding for the RFC Editor function is currently provided by the 234 Internet Society.