Summary

  • RFC 7710 assigned DHCPv4 option 160 to captive-portal discovery. An IETF 106 network experiment later found that some Polycom devices already interpreted 160 for another purpose, and the standardized payload made them fail to operate as desired.
  • RFC 8910 moved the function to option 114 and left 160 unassigned with a warning. The episode shows why a registry lookup is an authority receipt, not an installed-base compatibility test.

The packet was valid; the assumption was not

At IETF 106 in Singapore, the meeting network ran an experiment for clients compatible with the Captive Portal API. The experiment advertised information through DHCP so those clients could discover a venue URL. On paper, the choice of field was settled: RFC 7710 had assigned DHCPv4 option code 160 to captive-portal identification in 2015.

Some Polycom devices on the same network disagreed—not in a standards debate, but in executable behavior. RFC 8910 records that they used option 160 for other purposes. When the network put a Captive Portal API URL in that option, the devices did not function as desired.

The RFC does not identify a model, firmware release, device count, alternative payload format or exact symptom. Those omissions are part of the evidence boundary. The event proves that two interpretations met on one observed network and that the collision mattered enough to change the standard. It does not license a claim about every Polycom product, current fleets or the intent behind the earlier use.

Erik Kline coauthored RFC 8910 with Warren Kumari. The document replaced RFC 7710, whose authors were Kumari, Olafur Gudmundsson, Paul Ebersman and Steve Sheng. This is therefore a story of collective protocol maintenance, not a lone inventor correcting someone else’s mistake. Kline’s relevance lies in the replacement document’s unusually clear preservation of the failed assumption: the number had been assigned, yet deployment showed it was not vacant.

One octet, two state machines

A DHCPv4 option begins with a one-octet code. A client receiving code 160 does not pause to fetch the current IANA table. It runs the parser built into its firmware. The server can be perfectly conformant with one specification while a device on the wire follows a different, older convention.

That is what makes numeric collisions harsher than editorial ambiguity. Two readers can debate a sentence. Two decoders receiving the same code and payload can enter incompatible state machines automatically. A URI that is meaningful to a CAPPORT-aware client may be malformed, actionable or disruptive input to software expecting another schema. The public record supports the fact of malfunction, not a reconstruction of the hidden decoder.

The registry remains the standards authority. Without it, interoperable allocation would collapse into guesswork. But registry authority answers a normative question: which meaning has the recognized claim? It cannot inspect every firmware image already installed, every vendor convention, every private extension or every abandoned implementation that still boots.

The deployed network supplied a second kind of evidence. By emitting the standardized option to a mixed population, it tested whether the supposed vacancy existed outside the document. The negative result did not transfer ownership of code 160 to the shadow use. It demonstrated that insisting on the allocation would impose compatibility damage on people who had not participated in the naming decision.

Why the answer became 114

RFC 8910, published on the Standards Track in September 2020, moved the DHCPv4 Captive-Portal option from 160 to 114. It also updated RFC 3679, the earlier record on reclaiming unused DHCP option codes. The current IANA BOOTP and DHCP Parameters registry identifies 114 as DHCP Captive-Portal, with RFC 8910 as its reference.

Code 160 now appears as Unassigned. That single word could be misread as a clean slate, so the registry preserves the scar tissue: it was previously assigned by RFC 7710 and is known also to be used by Polycom. The note converts an operational surprise into durable guidance. A future allocator can see not merely the current status but the reason the status is dangerous to read without history.

The change was deliberately scoped. DHCPv6 uses a different, two-octet option space; its Captive-Portal option remained 103. The corresponding IPv6 Router Advertisement option remained 37. Saying “CAPPORT changed from 160 to 114” is therefore true only for DHCPv4. Collapsing the three namespaces would reproduce the very category error the repair was meant to contain.

RFC 3679 adds a useful precedent. It catalogued DHCP codes that could be returned for reassignment because proposed uses never became standards or general deployment. It separately retained codes used in devices despite lacking a published RFC. The document treats field observation as relevant to registry hygiene. Formal status and implementation evidence are different columns in the same decision, not rival sources of legitimacy.

Renumbering is a beginning, not remote repair

Publishing 114 did not rewrite an old endpoint. It did not remove option 160 from DHCP server templates, upgrade phones, change relays or prove that every CAPPORT client would request and process the new value. A standards action can establish the convergent target; only deployment work can move a fleet toward it.

That work has at least four separate receipts. The server receipt shows which option code and payload were emitted. The path receipt shows what relays, network-access systems or policy layers preserved. The endpoint receipt records hardware and firmware behavior. The service receipt answers whether the device completed the task for which it was connected. A lease alone is not the service result.

Migration also creates a mixed period. A network may contain legacy equipment sensitive to 160, clients that understand 114, and clients that understand neither. Emitting both values is not automatically safe: it may recreate the collision for the legacy cohort. Emitting only 114 avoids that particular trigger but does not make unsupported clients CAPPORT-aware. The correct rollout depends on inventory, isolation and observable failure, not on the aesthetic appeal of one global switch.

The registry needs an echo from the wire

The strongest interpretation of the IETF 106 episode is not that private use defeats standardization. That would reward silent appropriation of scarce numbers and make common protocols impossible. Nor is the lesson that a formal allocation defeats installed behavior by declaration. Packets encounter parsers, not resolutions.

The durable control is a feedback loop. Before assigning or broadly activating a field, standards participants can search vendor material, ask implementers, reserve experimental space and run bounded interoperability tests. Operators can introduce a newly assigned option on a canary segment containing deliberately diverse equipment. Vendors can disclose private code-point use early and move it before the dependency spreads.

Negative results deserve publication. A successful trial says a tested cohort survived. A collision report names the assumption that failed and can protect every later deployment. RFC 8910 does this well: it records the venue, the limited device description, the observed incompatibility and the resulting number change without inventing a larger scandal.

Sources