Summary

  • RFC 3925 gave DHCPv4 a framed way to carry data for more than one vendor in the same message.
  • It registered the outer option numbers, but left inner sub-option codes and their meanings to each vendor; a PEN labels a namespace, not an authenticated claim.

For a decade, the common DHCPv4 path for vendor information had a narrow shape. RFC 2132’s option 60 let a client send a vendor-class string; option 43 carried an opaque vendor-specific object. The server interpreted option 43 in the context of the vendor indicated by option 60. That was workable when one vendor’s vocabulary was enough. It became ambiguous when a device or industry profile needed independently defined information for more than one vendor. RFC 3925 describes that collision as a framing problem, not a failure of DHCP address assignment.

Its answer was a second pair of options. Option 124, Vendor-Identifying Vendor Class, and option 125, Vendor-Identifying Vendor-Specific Information, put an IANA Private Enterprise Number beside each vendor’s data. Option 125 can contain multiple entries: an enterprise number, a length, and that vendor’s bytes. The length separates one payload from the next; the enterprise number selects which vendor’s interpretation applies. RFC 3925 explicitly leaves the older options 60 and 43 intact, so an implementation can encounter both the legacy and identifying forms.

That structure is a small but consequential design distinction. IANA assigns the outer DHCP option code. IANA’s Enterprise Numbers registry assigns the number that names a vendor’s namespace. Neither registry defines what a vendor’s payload means. Inside each payload, sub-options use code/length/value framing, but RFC 3925 says the sub-option codes are defined by the vendor, not managed by IANA. The standard created a place to keep several dialects apart, not a common dictionary that translates them.

There is also a boundary in the packet itself. Because the combined data can exceed the one-byte option-length limit, RFC 3925 marks options 124 and 125 as requiring concatenation under RFC 3396. A receiver joins repeated fragments into one logical option before interpreting the inner entries. It should not treat each fragment as a new vendor record. The standard recommends that an enterprise number occur only once across instances; if it appears more than once, behavior is undefined. The frame accommodates multiplicity, but does not make every malformed or repeated combination meaningful.

RFC 3925 borrowed its pattern from DHCPv6’s vendor-class and vendor-specific options in RFC 3315. That is evidence of deliberate design reuse, not proof that the two protocol families share payload semantics or deployment. The extension also does not authenticate a vendor. RFC 3925 says it supplies no security itself; RFC 3118 defines a separate DHCP authentication mechanism that may be used when authenticity is required. A number carried in an option is a selector, not a signature.

This is why RFC 3925 matters as history: it solved coexistence by making boundaries explicit while leaving local meaning local. The outer registry can tell an implementer how to parse a container and which namespace it names. It cannot tell a client what a vendor-specific byte will do, whether a device really belongs to that vendor, or whether any implementation supports the option. Those facts require separate evidence. The RFC and IANA records establish the design and codepoint assignments; they do not measure adoption, interoperability, or operational outcomes.

Sources