Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
Extracted elements (16)
Existing DHCPv4 options 60 and 43 are ambiguous when a client represents multiple vendors: option 43 carries no vendor identifier of its own, and RFC 3396 concatenation means multiple instances of the same option lose independence. New options with IANA Enterprise Numbers remove this ambiguity.
The options are modeled on DHCPv6 (RFC 3315) vendor class and vendor-specific information options, which use Enterprise Numbers for unambiguous vendor identification, applying the same approach to DHCPv4 to resolve the multi-vendor ambiguity problem.
OPTION_V-I_VENDOR_CLASS may be used wherever Vendor Class Identifier (option 60) may be used, except in DHCPNAK messages where other options are not permitted. It does not replace options 60 and 43 but may be used in addition to them.
These options are declared concatenation-requiring per RFC 3396; splitting on boundaries between vendor instances is not required but may be convenient for encoding or packet tracing.
An Enterprise Number SHOULD only occur once among all instances of OPTION_V-I_VENDOR_OPTS; behavior is undefined if an Enterprise Number occurs multiple times.
Clients that do not receive desired vendor-specific information SHOULD make an attempt to operate without it.
Multiple instances of OPTION_V-I_VENDOR_CLASS or OPTION_V-I_VENDOR_OPTS MUST be concatenated in accordance with RFC 3396, because the aggregate vendor-specific data may exceed 255 octets.
Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it.
The encapsulated vendor-specific option-data field MUST be encoded as a sequence of code/length/value fields of identical format to the DHCP options field.
OPTION_V-I_VENDOR_CLASS (option code 124) allows a DHCP client to unambiguously identify one or more vendors by embedding 32-bit IANA Enterprise Numbers, each followed by a data-len and opaque vendor-class-data. Multiple vendor entries may appear within a single option.
OPTION_V-I_VENDOR_OPTS (option code 125) allows DHCP clients and servers to exchange vendor-specific information keyed by 32-bit IANA Enterprise Numbers. Either party may send this option; it may appear in DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, and DHCPINFORM messages.
Within OPTION_V-I_VENDOR_OPTS, sub-option codes 0 and 255 have no pre-defined interpretation or format; all other sub-option codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA.
Two new DHCPv4 option codes are assigned from the public DHCP Options numbering space defined in RFC 2939: OPTION_V-I_VENDOR_CLASS (124) and OPTION_V-I_VENDOR_OPTS (125). Vendor-specific sub-option codes within option 125 are defined by each vendor and are not managed by IANA.
This document itself provides no security mechanisms. If authenticity is required for data carried by the new options, implementations should use the DHCP authentication and message integrity mechanism described in RFC 3118.
The V-I Vendor Class option format: 1-octet option-code (124), 1-octet option-len, then one or more repetitions of 4-octet enterprise-number, 1-octet data-len, and variable-length vendor-class-data. Each vendor-class-data item is itself length-prefixed with a 1-octet data-len followed by opaque-data.
The V-I Vendor-Specific Information option format: 1-octet option-code (125), 1-octet option-len, then one or more repetitions of 4-octet enterprise-number, 1-octet data-len, and variable-length option-data. Encapsulated option-data is encoded as code/length/value sub-options with 1-octet subopt-code and 1-octet subopt-len.