Summary

  • RFC 3679 distinguished proposed option codes that could return to IANA from PXE and Apple codes that lacked published RFC descriptions but were already used.
  • RFC 3942 supplied a transition process for private-range codes; RFC 8910 later moved captive-portal signaling from code 160 after an experiment exposed conflicting Polycom use. A registry entry records coordination, not a census of deployed devices.

An empty bibliography was not an empty network

DHCP options are compact instructions carried during address configuration: a client can receive such things as a subnet mask, router address or other service parameters. Their numbers are a shared namespace. If an abandoned proposal keeps a number forever, later work loses room; if an actually deployed option is reassigned, two devices may read the same field differently.

In January 2004, RFC 3679 addressed both sides of that problem. It listed earlier assignments whose proposals had expired, never reached a published definition, or were no longer used by the then-current failover protocol. Those codes could be returned to IANA’s available pool. But a separate section described PXE option codes 93, 94 and 97 as being in widespread use despite lacking a published RFC. It also named Apple uses for 95 and 112–114 without RFC documentation. The document asked that these remain assigned while the DHC Working Group considered their disposition. The key evidence was not publication status alone; it was the reported use. RFC 3679

That separation was deliberately cautious, not a blanket rule that undocumented use earns a permanent public number. The RFC listed individual reasons for recovery and treated the known PXE and Apple cases differently. Its IANA direction put the recoverable codes back into the pool only after never-assigned or previously returned numbers were exhausted. It was an Informational memo, not proof that every named implementation still existed or that every assignment had been resolved in the field. RFC 3679 status

From a list to a transition

Later in 2004, RFC 3942 widened the publicly defined DHCPv4 option space from 1–127 to 1–223 by reclassifying the upper range, which had been reserved for private use. That move could not make existing local configurations disappear. The standard therefore introduced a transition: a code with known private use could be marked unavailable while vendors notified the working group and IANA; a tentative public assignment carried a six-month notification interval and an 18-month Internet-Draft deadline. Sites were encouraged to move to the remaining private-use range. RFC 3942

The collision rule was sharper. If multiple vendors showed reasonably widespread use of the same number, none could simply keep it as its private code; each had to seek a normal public assignment. This did not declare private use illegitimate. It recognized that a number cannot coordinate two incompatible meanings merely because each vendor had used it locally. RFC 3942 also rejected alternatives such as a 16-bit extension, which would burden early adopters, and a new format or magic cookie, which would add compatibility and discovery costs.

The later conflict that made the distinction concrete

RFC 4578 subsequently described PXE options 93, 94 and 97 as widely used, while noting that PXE clients also requested codes 128–135 that were not officially assigned for PXE use and could conflict with other uses on the same network. That is a useful boundary: a request observed in a client does not itself turn a code into an official assignment.

An even more explicit case arrived with captive portals. RFC 7710 initially used DHCPv4 option 160 to advertise a portal URI. During an IETF 106 network experiment, some Polycom devices used 160 for other purposes; carrying the portal URI there caused them not to work as desired. RFC 8910 therefore moved the captive-portal signal to option 114, updated RFC 3679, and returned 160 to Unassigned while recording the known Polycom use. The authors describe an observed conflict in that experiment, not its prevalence across all networks. RFC 7710 RFC 8910

The current IANA table shows the afterlife of several numbers: 83 later carries iSNS, 88 and 89 later carry BCMCS options, 114 is Captive-Portal, and 96 remains unassigned. It also shows 126 and 127 unassigned. These are registry states, not evidence that a code is silent on every live network. Nor does a later assignment prove that every earlier implementation vanished. IANA BOOTP/DHCP Parameters RFC 4174 RFC 4280

Lu Heng’s later Note 72 offers a narrow conceptual echo: a coordination record and operational reality are different kinds of evidence. The note concerns Internet-number uniqueness, not DHCP, and neither caused nor endorsed these RFC decisions. Here the practical lesson comes from the DHCP record itself: reclaiming a number requires evidence about use, and reassignment is a transition problem, not a clerical edit. Note 72

Sources

Additional protocol context