Summary

  • RFC 2132 separated a class hint (option 60), a binding-database key (61), a request list (55) and opaque vendor-specific information (43) within one DHCP/BOOTP-compatible option grammar.
  • A packet capture can establish what was sent or offered at that observation point. It cannot by itself authenticate a manufacturer, prove a stable device identity, or show that a host installed the offered configuration and reached a service.

Imagine a 1997 network administrator looking at one DHCP request. A string says something about the client's vendor class. Another sequence appears to identify the client. A list asks for particular configuration options. All three share one packet, but they do not answer the same question. The temptation is to call the capture a device record: what it is, who it is, and what it used. The specification makes that reading too strong.

RFC 2132, published by Steve Alexander and Ralph Droms in March 1997, specified DHCP options and BOOTP vendor extensions. It inherited a compact outer grammar: a tag identifies an option, most tags are followed by a length and that many data octets, while Pad and End have special one-octet treatment. BOOTP's four-octet magic cookie chooses how the following vendor field is interpreted. This grammar lets unlike receivers locate fields; it does not verify who composed their values. The earlier RFC 1048 established the BOOTP extension grammar—an important predecessor, but not the question at issue here.

The vendor-class identifier, option 60, is a client-supplied string of octets interpreted by a server. It is optional. A vendor might use it to communicate a client's type or configuration, and a server that cannot interpret the class-specific information must ignore it, though it may report it. If the server responds with vendor-specific information, RFC 2132 says it should use option 43. The class string can therefore guide a configuration branch; it is not independent proof that a named manufacturer made the hardware. Nor does a class string compel a server to act on it.

Option 43 occupies a different namespace. Its contents are opaque vendor-specific information. When it contains several items, the RFC recommends encapsulated tag-length-value fields. A vendor may redefine the inner codes other than Pad and End within that encapsulation. A nested End terminates the encapsulated vendor extensions, not the entire enclosing options field; without a nested End, the enclosing length supplies the boundary. This is a practical parser distinction: a global option number leads to a vendor-local interpretation.

Seeing returned bytes proves their presence in a response, not that a particular client understood, accepted or used them.

The client identifier, option 61, is not a second spelling of option 60. Servers use it to index their database of address bindings. The RFC asks servers to treat it as opaque. It may contain a hardware type and address, but it can instead contain another kind of identifier. The identifier must be unique among those used on the client's attached subnet; vendors and administrators are responsible for choosing one that meets that requirement. A uniqueness rule for a binding key is not an authentication protocol. A capture of the key neither establishes the physical device behind the message nor proves that the same person operated it later.

Option 55 is a request, not an inventory of what ran. Its octets name configuration parameters the client would like. A client may order them by preference; the server need not return them in the same order, though it must try to insert requested options in the requested order. The request list does not guarantee that every named parameter will be returned. Option 57 adds another limit: the client states the maximum DHCP message length it is willing to accept, with 576 octets the minimum legal value. A long wish list and a size bound are evidence of negotiation constraints, not a complete installed configuration.

These distinctions matter at each observation point. A request reveals assertions and preferences supplied by a sender. A server's response reveals what that server offered under its own policy and understanding. RFC 2131 describes further request, acknowledgement and client-side checks; an offer is not the end of that sequence. To know what actually happened, an investigator would need the relevant exchange, server binding and policy records, client-side accepted configuration and an operational test of the intended service. The RFCs do not provide those records for any named network.

The historical advance was not a claim that DHCP could attest a machine. It was a way to let heterogeneous hosts and servers make several kinds of configuration decision inside one extensible exchange while preserving the distinctions among those decisions. RFC 2132's security section explicitly does not discuss security issues. Treating its fields as credentials or measured deployment would fill that silence with a promise the document never made. In Heng Lu's running-code framing, a specification is useful when its boundaries can be checked against operation; the packet remains a record of a protocol moment, not a substitute for the running system.

Sources: RFC 2132, RFC 2131, RFC 1048, and Heng Lu's Running-Code Primacy. The latter supplies an editorial lens, not a normative claim about DHCP.