idnits 2.17.1 draft-volz-dhc-dhcpv6-vendor-message-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 219. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 07, 2008) is 5743 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 (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. 'EID' -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Volz 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track July 07, 2008 5 Expires: January 8, 2009 7 DHCP Vendor-specific Message 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 8, 2009. 35 Abstract 37 This document requests a vendor-specific DHCPv6 message assignment. 38 This message can be used for vendor specific and experimental 39 purposes. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 3. Vendor-specific Message . . . . . . . . . . . . . . . . . . . . 3 46 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 47 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 48 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 50 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 51 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 Intellectual Property and Copyright Statements . . . . . . . . . . 6 54 1. Introduction 56 The DHCPv6 [RFC3315] protocol specifies a mechanism for the 57 assignment of addresses and configuration information to nodes. The 58 protocol provides for 256 possible message codes, of which a small 59 number are assigned ([DHCPv6Params]). Each of the assigned message 60 codes have specific purposes. New message codes are assigned through 61 IETF Standards Action as defined in [RFC2434] (see Section 24 of 62 [RFC3315]). 64 There may be a need for vendors of DHCPv6 clients, relay agents, or 65 servers to experiment with new capabilities that require new messages 66 to be exchanged between these elements. Thus, this document defines 67 the format for and requests that a new message code be reserved for 68 vendor-specific and experimental purposes. 70 2. Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 3. Vendor-specific Message 78 The vendor-specific message may be exchanged between clients, relay 79 agents, and/or servers and allows multiple vendors to make use of the 80 message for completely different and independent purposes. 82 Clients and servers MAY chose to support this message; those that do 83 not, MUST discard the message. Relay agents SHOULD relay these 84 messages as they would other DHCPv6 messages unless the relay agent 85 understands the specific message and knows that the message was 86 directed at it. 88 Applications using these messages MUST NOT assume that all DHCPv6 89 clients, relay agents, and servers support them and MUST use good 90 networking practices when transmitting and retransmitting these 91 messages (see Section 14 of [RFC3315] for recommendations). For some 92 applications, it may be appropriate to use a Vendor Class or Vendor- 93 specific Information Option ([RFC3315]) in a standard DHCPv6 exchange 94 to negotiate whether the end-points support the vendor-specific 95 message. 97 The format of the DHCPv6 Vendor-specific Message is shown below: 99 0 1 2 3 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | msg-type | enterprise-number | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | enterprise- | | 105 | number (contd)| . 106 +-+-+-+-+-+-+-+-+ . 107 . vendor-data . 108 . (variable length) . 109 | | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 msg-type VENDOR-SPECIFIC (to-be-assigned) 114 enterprise-number The vendor's registered Enterprise Number as 115 registered with [EID]. 117 vendor-data The vendor's message data. 119 The contents and format of the vendor-data field is up to the vendor. 121 4. Security Considerations 123 The Security Considerations of [RFC3315] apply. 125 This new message does potentially open up new avenues of attacking 126 clients, relay agents, or servers. The exact nature of these attacks 127 will depend on what functions and capabilities the message exposes 128 and are thus not possible to describe in this document. Clients and 129 servers that have no use for these messages SHOULD discard them and 130 thus the threat is no different than before this message was 131 assigned. 133 Vendors using this new message should use the DHCPv6 security 134 mechanisms (the Auth option or IPsec [RFC3315] as appropriate) and 135 carefully consider the security implications of the functions and 136 capabilities exposed. 138 5. IANA Considerations 140 IANA is requested to assign DHCPv6 Message type 254 to the Vendor- 141 specific Message in the registry maintained in [DHCPv6Params]: 143 254 VENDOR-SPECIFIC 145 6. References 147 6.1. Normative References 149 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 150 Requirement Levels", BCP 14, RFC 2119, March 1997. 152 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 153 and M. Carney, "Dynamic Host Configuration Protocol for 154 IPv6 (DHCPv6)", RFC 3315, July 2003. 156 [EID] IANA, "Private Enterprise Numbers. 157 http://www.iana.org/assignments/enterprise-numbers". 159 6.2. Informative References 161 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 162 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 163 October 1998. 165 [DHCPv6Params] 166 IANA, "Dynamic Host Configuration Protocol for IPv6 167 (DHCPv6). 168 http://www.iana.org/assignments/dhcpv6-parameters". 170 Author's Address 172 Bernard Volz 173 Cisco Systems, Inc. 174 1414 Massachusetts Ave. 175 Boxborough, MA 01719 176 USA 178 Phone: +1 978 936 0000 179 Email: volz@cisco.com 181 Full Copyright Statement 183 Copyright (C) The IETF Trust (2008). 185 This document is subject to the rights, licenses and restrictions 186 contained in BCP 78, and except as set forth therein, the authors 187 retain all their rights. 189 This document and the information contained herein are provided on an 190 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 191 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 192 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 193 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 194 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 195 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 197 Intellectual Property 199 The IETF takes no position regarding the validity or scope of any 200 Intellectual Property Rights or other rights that might be claimed to 201 pertain to the implementation or use of the technology described in 202 this document or the extent to which any license under such rights 203 might or might not be available; nor does it represent that it has 204 made any independent effort to identify any such rights. Information 205 on the procedures with respect to rights in RFC documents can be 206 found in BCP 78 and BCP 79. 208 Copies of IPR disclosures made to the IETF Secretariat and any 209 assurances of licenses to be made available, or the result of an 210 attempt made to obtain a general license or permission for the use of 211 such proprietary rights by implementers or users of this 212 specification can be obtained from the IETF on-line IPR repository at 213 http://www.ietf.org/ipr. 215 The IETF invites any interested party to bring to its attention any 216 copyrights, patents or patent applications, or other proprietary 217 rights that may cover technology that may be required to implement 218 this standard. Please address the information to the IETF at 219 ietf-ipr@ietf.org.