Summary

  • DHCP can reuse its fixed server-name and boot-filename fields for options, but only through an explicit overload declaration in the ordinary options field.
  • Extra storage and long-value encoding are separate problems. RFC 3396 joins repeated option data in the logical order options, file, sname—not their physical order in the packet.
  • Reuse preserves field boundaries and can relocate the old boot information. It does not create unlimited space, upgrade old receivers or establish authority to configure a host.

A short name that still needed two pieces

The example is almost aggressively ordinary: /diskless/foo. It occupies thirteen bytes, far below the 255-byte data limit of one conventional DHCP option instance. Yet RFC 3396, published in November 2002, shows it split into portions of seven and six bytes.

The division falls inside the word diskless. It does not separate directory components or encode two alternative filenames. Its purpose is packing. A field with limited public evidence remaining room for the whole option can still hold part of it, while another permitted field holds the rest.

This small example exposes two constraints that are easily confused. An option value may exceed what its one-byte length can express. Or it may fit that length perfectly well but not fit the unused space in a particular field. Increasing the places available for options does not, by itself, define how a receiver reconstructs either case.

DHCP had inherited a packet with rooms already assigned to other purposes. The first step was to borrow some of them. The harder step was to ensure that a receiver knew which rooms had changed use, where each encoded item stopped and in what order the pieces belonged together.

The boot packet had reserved places for names

In September 1985, RFC 951 described BOOTP with a fixed layout suited to bootstrap. A machine could obtain information before its full operating environment was available: an address, a server and a boot file.

The packet gave the optional server hostname a 64-byte field called sname. It gave the boot filename a 128-byte field called file. Both were null-terminated strings. A separate 64-byte vend area could carry vendor-specific information. These were not meaningless gaps in the original design; they reflected the service it was meant to provide.

DHCP retained the underlying layout while broadening configuration. In the March 1997 RFC 2131, options became variable-length, and clients had to be prepared for an options field of at least 312 octets. Larger-message negotiation was another available mechanism. The complete message was not limited to the 255 octets representable in one option-data length.

Nevertheless, a configuration packet could still run short of useful room. The older name fields were tempting capacity precisely because they had stable positions. Reusing them did not require moving every later field. It required a controlled change of interpretation.

The declaration arrived before the long-option standard

Option Overload was already specified in RFC 1533 in October 1993. Its code was 52, with a one-octet value: 1 selected file, 2 selected sname and 3 selected both. It was not an invention of the 2002 concatenation document, nor first introduced by the 1997 revision.

The declaration was local to the message and the indicated fields. It did not grant a parser permission to hunt for options wherever bytes happened to resemble them. Nor did it permanently change the interpretation of all subsequent packets.

RFC 2131 required the overload option to appear in the ordinary options field. The receiver had to interpret that field first, then file if selected, then sname if selected. The instruction to reinterpret a field was thus placed somewhere the receiver already knew how to read.

That placement avoids a circular dependency. If permission to parse a repurposed field were discoverable only inside that field, an implementation would have to guess whether it should begin. A common declaration made the sender’s local packing choice observable without guesswork.

Borrowed space retained its walls

The ordinary options area starts with a four-octet magic cookie, followed by tagged items. A typical item has a code, a length and the stated number of data octets. The length excludes the code and length octets themselves. Pad and End are single-octet exceptions rather than ordinary length-bearing values.

An overloaded file or sname begins its option sequence at the first octet of that field. It does not receive another magic cookie. Each such field must terminate its options with End and fill the remainder with Pad. Every individually encoded option must remain wholly inside one field.

These rules distinguish available capacity from a continuous physical stream. A sender cannot let an option run through the wall into the next field and expect the receiver to follow it. An End marker in one field also does not erase the other fields selected for later logical interpretation.

Together, file and sname offer 192 raw octets of field space. They do not yield 192 free data octets. Tags, lengths, termination, padding, the overload declaration and any displaced boot information consume capacity. This is bounded reuse, not unlimited expansion and not IP fragmentation under another name.

Moving the name did not delete the boot information

The March 1997 RFC 2132 supplied a way to represent the displaced meanings. Option 66 identifies a TFTP server when sname is being used for options; option 67 identifies a boot file when file has been repurposed.

The old parameter could therefore survive after leaving its dedicated box. A receiver looking only for a printable filename in the fixed field might report missing configuration when the information had merely changed representation. The absence of the old string was not the absence of a boot file.

The current IANA BOOTP and DHCP parameters registry records Overload as 52, Server-Name as 66, Bootfile-Name as 67 and Domain Search as 119. These are option codes. Option 67 is not the DHCP server transport port merely because the number also happens to be used for that purpose in UDP.

Registration establishes common recognition of a parameter, not its operational truth. A returned filename does not prove that the file exists, that a transfer will succeed or that execution is authorized. The encoding locates information; it does not perform the later boot operation.

More than one instance, only one value

RFC 2131 contained both a restriction on repeated options unless otherwise specified and language about concatenating repeated values. RFC 3396 explicitly removed the one-occurrence sentence and defined the construction and interpretation of split options. It was a clarification and update, not evidence that every older implementation already behaved consistently.

Each portion carries the same option code and its own length. No portion contains more than 255 data octets. The lengths of the portions add to the length of the logical value, and each encoded instance still respects the containing field’s boundary.

The receiver joins the data, not the code-and-length wrappers. It cannot select only the first instance, overwrite it with the last, or present every portion as a separate configuration entity. In the filename example, seven bytes and six bytes become one thirteen-byte path; neither fragment is a useful alternative name.

There is no semantic significance to the split point. A sender can divide at any octet boundary. A decoder must therefore reconstruct the whole before imposing the rules of the particular value. Treating each piece as independently meaningful would make packing decisions alter configuration semantics.

Logical order overruled physical order

RFC 3396 calls the relevant sequence an aggregate option buffer, but the aggregation is logical. The actual fields stay in their original places. The common order is ordinary options, then file, then sname, excluding either borrowed field when it is not selected.

On the wire, sname precedes file, and both precede the ordinary options area. Reading the captured packet from its beginning and immediately concatenating every encountered instance would therefore produce the wrong sequence in a cross-field case.

The receiver first learns which fields count, then follows the defined logical order, then joins the matching data portions. A storage layout and an interpretation order can differ, provided the difference is explicit and shared. It cannot be left to whichever scanning loop an implementation happened to use.

Overload and concatenation remain separate. Borrowed fields may hold complete unsplit options. Repeated portions can also fit entirely inside the ordinary options field without any overload. One mechanism expands the permitted storage locations; the other defines a logical value across multiple encoded instances.

A careful sender still needed a capable receiver

The 2002 document recorded a deployment constraint: many DHCP agents then in use did not implement concatenation. It advised against splitting unless necessary or unless the sender knew its peer could handle the result. Publication was not a remote upgrade for installed parsers.

A peer could be assumed capable after supplying or requesting an option whose specification required this concatenation mechanism. An administrator could also explicitly configure that assumption. This was not a new universal capability bit, and the dated observation is not a count of present-day devices.

An implementation could choose to split only options that required concatenation. But once it supported such an option, it also had to be able to concatenate received portions of other options. Simplicity of output was not a license to narrow the accepted input language arbitrarily.

The distinction assigns responsibilities to different places. The encoder decides whether splitting is warranted and whether its compatibility assumption is justified. The decoder applies the common reconstruction rule to the received representation. Neither can substitute a local preference for a shared byte order.

A pointer whose origin exists only after assembly

The companion November 2002 RFC 3397 provides a concrete reason to get reconstruction right. Its domain-search option, code 119, can carry a DNS search list across repeated option instances. It also uses DNS-style name compression to avoid repeatedly spelling shared suffixes.

The compression offsets refer to the complete concatenated data portion. They exclude the individual option codes and lengths. They are not measured from the beginning of the DHCP packet or reset to zero at each fragment.

All the search-list data must therefore be logically joined before interpretation. A fragment ending inside a label is not necessarily a malformed complete name; it is not yet the complete entity at all. The correct boundary for interpretation is established by the lower-level assembly rule.

This example does not require retelling the entire history of DNS compression. Its relevance is the dependency: a higher-level coordinate system relies on lower-level reconstruction. A packing shortcut can corrupt meaning even when every individual fragment has a plausible length.

Nor does correct reconstruction confer trust. RFC 3397 warns that a search list can cause a short name to select a different fully qualified domain, even if that other domain has valid DNSSEC signatures. Syntactic correctness and authority to configure a host remain separate questions.

DHCP’s borrowed fields worked by making reuse explicit, not by pretending the old boundaries had disappeared. The durable agreement was not simply that more bytes were available. It was that every entity could determine where those bytes belonged before deciding what they meant.