idnits 2.17.1 draft-ietf-dhc-dhcpv4-vendor-message-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document date (August 3, 2009) is 5374 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'EID' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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 Intended status: Standards Track August 3, 2009 5 Expires: February 4, 2010 7 DHCPv4 Vendor-specific Message 8 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on February 4, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document requests a vendor-specific DHCPv4 message assignment. 47 This message can be used for vendor specific and experimental 48 purposes. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Vendor-specific Message . . . . . . . . . . . . . . . . . . . . 3 55 4. Vendor Message Option . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 60 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 DHCPv4 [RFC2131] specifies a mechanism for the assignment of 66 addresses and configuration information to nodes. The protocol 67 provides for 256 possible message codes, of which a small number are 68 assigned ([DHCPv4Params]). Each of the assigned message codes have 69 specific purposes. New message codes are assigned through IETF 70 Standards Action. 72 There may be a need for vendors of DHCPv4 clients, relay agents, or 73 servers to experiment with new capabilities that require new messages 74 to be exchanged between these elements. Thus, this document defines 75 the format for and requests that a new message code be reserved for 76 vendor-specific and experimental purposes. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 3. Vendor-specific Message 86 The vendor-specific message may be exchanged between clients, relay 87 agents, and/or servers and allows multiple vendors to make use of the 88 message for completely different and independent purposes. 90 Clients and servers MAY chose to support this message; those that do 91 not, MUST discard the message. Relay agents SHOULD relay these 92 messages as they would other DHCPv4 messages unless the relay agent 93 understands the specific message and knows that the message was 94 directed at it. 96 Applications using these messages MUST NOT assume that all DHCPv4 97 clients, relay agents, and servers support them and MUST use good 98 networking practices when transmitting and retransmitting these 99 messages. For some applications, it may be appropriate to use 100 Vendor-Identifying Vendor Options [RFC3925] in a standard DHCPv4 101 exchange to negotiate whether the end-points support the vendor- 102 specific message. 104 A vendor-specifc message is constructed by placing the Vendor- 105 Specific Message number (254) into the DHCP Message Type option 106 [RFC2132] and including the Vendor Message Option defined below. A 107 Vendor-Specific Message that does not contain the Vendor Message 108 Option MUST be ignored. A Vendor Message Option in a DHCPv4 message 109 other than the Vendor-Specific Message MUST be ignored. 111 4. Vendor Message Option 113 The Vendor Message Option serves three purposes. It specifies the 114 Enterprise Number to identify the vendor, it specifies the vendor's 115 message type, and optionally contains vendor options related to the 116 message. 118 The format of the Vendor Message Option is shown below: 120 1 1 1 1 1 1 121 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | option-code | option-len | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | | 126 + enterprise-number + 127 | | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | vendor | | 130 | msg-type | | 131 +-+-+-+-+-+-+-+-+ | 132 / option-data / 133 ~ ... ~ 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 option-code OPTION_VENDOR_MESSAGE (TBD) 138 option-len 5 plus the length of the vendor-option-data. 140 enterprise-number The vendor's 32-bit Enterprise Number as 141 registered with [EID], in network octet order. 143 vendor-msg-type The vendor's message-type. The values are 144 defined by the vendor identified in the 145 enterprise-number field and are not managed by 146 IANA. 148 option-data Vendor specific data (of length option-len 149 minus 5 octets). This is optional. 151 The option-data field MUST be encoded as a sequence of code/length/ 152 value fields of identical format to the DHCP options field and is 153 identical to the option-data field of Vendor-Identifying Vendor 154 Options [RFC3925]. The option codes are defined by the vendor 155 identified in the enterprise-number field and are not managed by 156 IANA. Option codes 0 and 255 have no pre-defined interpretation or 157 format. Each of the encapsulated options is formatted as follows: 159 1 1 1 1 1 1 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | subopt-code | subopt-len | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 / sub-option-data / 165 ~ ... ~ 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 subopt-code The code for the encapsulated option. 170 subopt-len An unsigned integer giving the length of the 171 option-data field in this encapsulated option in 172 octets. 174 sub-option-data Data area for the encapsulated option. 176 Clients, relay agents, and/or servers supporting the Vendor Message 177 Option MUST support [RFC3396]. 179 Note: Vendor-Identifying Vendor Options [RFC3925] are not used to 180 convey the vendor identification (enterprise-number) for the vendor- 181 specific message as the message may contain instances of those 182 options for other reasons. 184 5. Security Considerations 186 The Security Considerations of [RFC2131] apply. 188 This new message does potentially open up new avenues of attacking 189 clients, relay agents, or servers. The exact nature of these attacks 190 will depend on what functions and capabilities the message exposes 191 and are thus not possible to describe in this document. Clients and 192 servers that have no use for these messages SHOULD discard them and 193 thus the threat is no different than before this message was 194 assigned. 196 Vendors using this new message should use the DHCPv4 security 197 mechanisms (such as [RFC3118] as appropriate) and carefully consider 198 the security implications of the functions and capabilities exposed. 200 6. IANA Considerations 202 IANA is requested to assign DHCPv4 Message type 254 to the Vendor- 203 specific Message in the registry maintained in [DHCPv4Params]: 205 254 VENDOR-SPECIFIC 207 IANA is requested to assign a DHCPv4 option number to the Vendor 208 Message Option in the registry maintained in [DHCPv4Params]: 210 TBD OPTION_VENDOR_MESSAGE 212 7. References 214 7.1. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, March 1997. 219 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 220 RFC 2131, March 1997. 222 [EID] IANA, "Private Enterprise Numbers. 223 http://www.iana.org/assignments/enterprise-numbers". 225 7.2. Informative References 227 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 228 Extensions", RFC 2132, March 1997. 230 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 231 Messages", RFC 3118, June 2001. 233 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 234 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 235 November 2002. 237 [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for 238 Dynamic Host Configuration Protocol version 4 (DHCPv4)", 239 RFC 3925, October 2004. 241 [DHCPv4Params] 242 IANA, "Dynamic Host Configuration Protocol (DHCP) and 243 Bootstrap Protocol (BOOTP) Parameters. 244 http://www.iana.org/assignments/bootp-dhcp-parameters". 246 Author's Address 248 Bernard Volz 249 Cisco Systems, Inc. 250 1414 Massachusetts Ave. 251 Boxborough, MA 01719 252 USA 254 Phone: +1 978 936 0000 255 Email: volz@cisco.com