idnits 2.17.1 draft-ietf-dhc-vendor-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (September 2003) is 7526 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. '3') (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Josh Littlefield 3 INTERNET-DRAFT Cisco Systems 4 Expires: March 2004 September 2003 6 Vendor-Identifying Vendor Options for DHCPv4 7 draft-ietf-dhc-vendor-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 The DHCP options for Vendor Class and Vendor-Specific Information can 37 be ambiguous when a DHCP client represents multiple vendors. This 38 document defines two new options, modeled on the IPv6 options for 39 vendor class and vendor-specific information, which contain 40 Enterprise Numbers to remove ambiguity. 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC-2119 [1]. 48 Table of Contents 50 1. Introduction...................................................2 51 2. Vendor-Identifying Vendor Class Option.........................2 52 3. Vendor-Identifying Vendor-Specific Information Option..........3 53 4. IANA Considerations............................................5 54 5. Security Considerations........................................5 55 References........................................................5 56 Author's Address..................................................6 57 Acknowledgement...................................................7 59 1. Introduction 61 The DHCP protocol for IPv4 defines options to allow a client to 62 indicate its vendor type (option 60), and to allow the DHCP client 63 and server to exchange vendor-specific information (option 43) [2]. 64 While there is no prohibition against passing multiple copies of 65 these options in a single packet, doing so would introduce ambiguity 66 of interpretation, particularly if conveying vendor-specific 67 information for multiple vendors. The vendor identified by option 60 68 defines the interpretation of option 43, which itself carries no 69 vendor identifier. 71 There are circumstances where an implementation may need to support 72 multiple, independently defined forms of vendor-specific information. 73 For example, implementations that must conform to an industry- 74 standard use of DHCPv4, to allow interoperability in a particular 75 technology space, may be required to support the vendor-specific 76 options of that industry group. But the same implementation may also 77 require support for vendor-specific options defined by the 78 manufacturer. In particular, this is an issue for vendors of devices 79 supporting CableLabs standards, such as DOCSIS, CableHome, and 80 PacketCable, since those standards define an industry-specific use 81 for options 60 and 43. 83 This document defines two new options, modeled on the IPv6 options 84 for vendor class and vendor-specific information [3], which contain 85 Enterprise Numbers to remove ambiguity. If desired, these new 86 options can be used in addition to the current vendor class and 87 vendor information options, whose definition is unaffected by this 88 document. 90 2. Vendor-Identifying Vendor Class Option 92 A DHCP client may use this option to unambiguously identify the 93 vendor that manufactured the hardware on which the client is running, 94 or an industry consortium to which the vendor belongs. The 95 information contained in the data area of this option is contained in 96 one or more opaque fields that identify details of the hardware 97 configuration. 99 The format of the V-I Vendor Class option is: 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | OPTION_V-I VENDOR_CLASS | option-len | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | enterprise-number | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 . . 108 . vendor-class-data . 109 . . . . . 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 option-code OPTION_V-I VENDOR_CLASS (to be assigned by 113 IANA) 115 option-len 4 + length of vendor class data field 117 enterprise-number The vendor's registered Enterprise Number as 118 registered with IANA [4]. 120 vendor-class-data The hardware configuration of the host on 121 which the client is running. 123 Each instance of this option contains information corresponding to a 124 single Enterprise Number. Multiple instances of this option may be 125 present, and each is treated independently. 127 The vendor-class-data is composed of a series of separate items, each 128 of which describes some characteristic of the client's hardware 129 configuration or capabilities. Examples of vendor-class-data 130 instances might include the version of the operating system the 131 client is running or the amount of memory installed on the client. 133 Each instance of the vendor-class-data is formatted as follows: 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 136 | vendor-class-len | opaque-data | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 139 The vendor-class-len is two octets long and specifies the length of 140 the opaque vendor class data in network byte order. 142 3. Vendor-Identifying Vendor-Specific Information Option 144 DHCP Clients and servers may use this option to exchange vendor- 145 specific information. 147 The format of the V-I Vendor-specific Information option is: 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | OPTION_V-I VENDOR_OPTS | option-len | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | enterprise-number | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 . . 156 . option-data . 157 . . 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 option-code OPTION_V-I VENDOR_OPTS (to be assigned by 161 IANA) 163 option-len 4 + length of option-data field 165 enterprise-number The vendor's registered Enterprise Number as 166 registered with IANA [4]. 168 option-data Encapsulated vendor-specific options, 169 described below. 171 The definition of the information carried in this option is vendor 172 specific. The vendor is indicated in the enterprise-number field. 173 Each instance of this option contains information corresponding to a 174 single Enterprise Number. Multiple instances of this option may be 175 present, and each is treated independently. 177 Use of vendor-specific information allows enhanced operation, 178 utilizing additional features in a vendor's DHCP implementation. 179 Servers not equipped to interpret the vendor-specific information 180 sent by a client MUST ignore it. Clients that do not receive desired 181 vendor-specific information SHOULD make an attempt to operate without 182 it. 184 The encapsulated vendor-specific options field MUST be encoded as a 185 sequence of code/length/value fields of identical format to the DHCP 186 options field. The option codes are defined by the vendor identified 187 in the enterprise-number field and are not managed by IANA. Option 188 codes 0 and 255 have no pre-defined interpretation or format. Each 189 of the encapsulated options is formatted as follows: 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | opt-code | option-len | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 . . 196 . option-data . 197 . . 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 opt-code The code for the encapsulated option 201 option-len An unsigned integer giving the length of the 202 option-data field in this encapsulated option 203 in octets. 205 option-data The data area for the encapsulated option 207 Multiple instances of the Vendor-specific Information option may 208 appear in a DHCP message. Each instance of the option is interpreted 209 according to the option codes defined by the vendor identified by the 210 Enterprise Number in that option. 212 4. IANA Considerations 214 The values for the V-I VENDOR CLASS and V-I VENDOR OPTS option codes 215 must be assigned from the numbering space defined for public DHCP 216 Options in RFC 2939 [5]. 218 5. Security Considerations 220 This document in and by itself provides no security, nor does it 221 impact existing security. DHCP provides an authentication and 222 message integrity mechanism, as described in RFC 3118 [6], which may 223 be used if authenticity is required for data carried by the options 224 defined in this document. 226 References 228 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 229 Levels", BCP 14, RFC 2119, March 1997. 231 [2] S. Alexander and R. Droms. "DHCP Options and BOOTP Vendor 232 Extensions", RFC 2132, March 1997. 234 [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 235 Carney, M., "Dynamic Host Configuration Protocol for IPv6 236 (DHCPv6)", RFC 3315, July 2003. 238 [4] IANA. Private Enterprise Numbers. 239 http://www.iana.org/assignments/enterprise-numbers.html. 241 [5] Droms, R., "Procedures and IANA Guidelines for Definition of New 242 DHCP Options and Message Types", BCP 43, RFC 2939, September 243 2000. 245 [6] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 246 3118, June 2001. 248 Author's Address 250 Josh Littlefield 251 Cisco Systems, Inc. 252 1414 Massachusetts Avenue 253 Boxborough, MA 01719 USA 255 Phone: 978-936-1379 256 Email: joshl@cisco.com 258 Full Copyright Statement 260 Copyright (C) The Internet Society (2003). All Rights Reserved. 262 This document and translations of it may be copied and furnished to 263 others, and derivative works that comment on or otherwise explain it 264 or assist in its implementation may be prepared, copied, published 265 and distributed, in whole or in part, without restriction of any 266 kind, provided that the above copyright notice and this paragraph are 267 included on all such copies and derivative works. However, this 268 document itself may not be modified in any way, such as by removing 269 the copyright notice or references to the Internet Society or other 270 Internet organizations, except as needed for the purpose of 271 developing Internet standards in which case the procedures for 272 copyrights defined in the Internet Standards process must be 273 followed, or as required to translate it into languages other than 274 English. 276 The limited permissions granted above are perpetual and will not be 277 revoked by the Internet Society or its successors or assigns. 279 This document and the information contained herein is provided on an 280 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 281 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 282 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 283 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 284 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 286 Acknowledgement 288 Funding for the RFC editor function is currently provided by the 289 Internet Society.