Summary

  • RFC 3396 defined repeated instances of one DHCPv4 option code as sequential fragments of one logical value, whether splitting was required by the 255-octet limit or by space across overloaded fields.
  • Reconstruction followed a logical order—ordinary options, then file, then sname—that was not the packet’s physical field order. Fragment boundaries carried no semantics, and a conforming sender still could not prove that a deployed peer reassembled them.

An old packet format can make two kinds of order coexist. There is the order in which fields physically occupy the packet. Then there is the order in which their contents must be understood. RFC 3396 made DHCPv4 live with both and warned implementers not to confuse them.

Published in November 2002 on the Standards Track, the document addressed a limit that fit in one byte. A variable-length DHCP option consisted of a one-octet code, a one-octet length and up to 255 octets of value. The format could carry many useful configuration objects, but a single instance could not describe a value longer than 255 octets.

RFC 2131 had already said that repeated options should be concatenated, yet it did not define their ordering completely. It also contained a general statement that options could appear only once unless another document said otherwise. RFC 3396 deleted that sentence and supplied a uniform reconstruction procedure. Repetition of one code was no longer a collection of independent objects waiting for option-specific permission; it was input to concatenation.

Length was not the only reason to split. A shorter option might not fit in the remaining space of one output area even though another option-bearing area still had room. In that case the encoder could apply the same algorithm or omit the option. It could not let one encoded instance straddle the boundary between fields.

Those fields came from DHCP’s BOOTP inheritance. The ordinary optional-parameters area was the expected home. With DHCP option overload, the fixed file and sname fields could also carry options instead of their older meanings. RFC 3396 described their contents through an aggregate option buffer: first ordinary options, then file, then sname.

The warning was explicit: this logical sequence was not the physical order of the fields in the packet. A parser that simply walked memory addresses and appended repeated codes as encountered could reconstruct a different value. The aggregate buffer was conceptual, not permission to rearrange the packet format itself.

Within that logical buffer, fragments had to remain sequential. Each was encoded like a normal variable-length option, carried the same code, held no more than 255 value octets and supplied a length that contributed to the total. If an option occupied all three locations, its first part went in the ordinary options area, its second in file, and its third in sname, irrespective of where those fields sat physically.

The encoder was free to cut at any octet boundary. That freedom came with a prohibition: the cut must not express semantic information. A boundary did not mark the end of a route, a domain name, a suboption or a record. It only marked where one container stopped having space or where the size limit required another instance.

The decoder therefore had to resist a tempting shortcut. When it encountered two or more instances of one code, it had to treat them as split pieces, concatenate their value bytes in aggregate order and process the result as one option. It could not validate, interpret or expose each fragment as a separate object. Meaning began after reconstruction.

Machine alignment belonged to the receiver as well. Nothing required a sender to place fragments on boundaries convenient for the decoder’s CPU. Once the value was rebuilt, the implementation had to copy or access it in a way safe for its own architecture. A packet’s legal cut could be a local machine’s awkward address.

The RFC’s small Bootfile Name example made the point without a long payload. /diskless/foo could be divided after seven value octets, producing two instances of option 67. Neither /diskle nor ss/foo was a bootfile name. Only concatenation restored the single value. The split was legal precisely because it meant nothing.

The most revealing part of the document was not its algorithm but its compatibility warning. Many DHCP agents already deployed in 2002 did not implement concatenation. A sender could obey the new standard and still meet a receiver that read only one piece, treated pieces separately or discarded the result. Correct encoding was not evidence of successful decoding.

RFC 3396 responded with two categories. An option was “concatenation-requiring” only if its defining specification explicitly referenced this mechanism and required support. Other options were non-concatenation-requiring. A sender should avoid splitting unless forced to, unless the peer had requested or supplied at least one option in the requiring category, or unless an administrator explicitly configured the capability assumption.

That inference was intentionally narrow. It gave the sender a reason to believe the peer knew the mechanism, not proof that every length, overload path, parser and later consumer worked. Implementations could refuse to split non-requiring options. Yet any implementation claiming support for a requiring option had to concatenate received repeats in both categories. On reception, the object rule remained general.

The authentication note showed how deeply the logical object mattered. RFC 3118’s authentication option could itself be divided. Before generating or verifying the MAC, an implementation had to zero the authentication field even if that field crossed multiple option instances. Code that treated each instance as a self-contained record could hash the wrong representation while believing it was doing security work.

Later DHCP options made the generic mechanism carry varied payloads. RFC 3397 used it for a domain-search list; RFC 3361 depended on it for long SIP-proxy data; RFC 3442 applied it to classless routes; RFC 3925 used it in vendor-identifying structures. Those documents supplied application grammar. RFC 3396 supplied the prior act of turning repeated bytes into the object that grammar could parse.

This division also limits what a packet capture proves. Seeing all fragments proves that bytes traversed the observation point. It does not prove the receiver enabled option overload, walked the three areas in aggregate order, retained every duplicate, reassembled the correct length, handled alignment, authenticated the result or applied the configuration. Each step needs its own running evidence.

The RFC Editor’s current search reports no matching errata for RFC 3396. That is useful publication metadata, not an implementation certificate. The original text itself was trying to repair ambiguity in an older specification and accommodate software that had already diverged.

Lu Heng’s Minimum Initial Specification principle explains the shape of the repair. The document standardized the smallest reconstruction contract needed across implementations—identity by code, aggregate order, sequential pieces, no fragment semantics—without defining the internal buffer, memory model or error interface of every client and server.

Running-Code Primacy supplies the final test. A decoder should be challenged with fragments cut at inconvenient boundaries, distributed across all enabled fields and observed through later application of the value. A standards claim without that path only shows that the implementation knows the rule’s name.

RFC 3396 turned location into transport and preserved identity above it. The fields could be physically out of order; the pieces could be unequal; the cut could fall anywhere. What mattered was that the decoder knew when not to interpret. First make one object. Only then ask what it means.

Sources