Summary

  • From RFC 1883 onward, the two highest bits of an IPv6 TLV Option Type specified what a processing node should do when it did not recognize that option: skip it, discard the packet, or discard and return a precisely pointed ICMPv6 error.
  • A third bit declared whether the option data might change en route. These bits bounded ignorance and protected authentication calculations, but they never guaranteed that a node would process the header, a middlebox would pass it, or the option deserved trust.

The first IPv6 options carried instructions for strangers

Consider an IPv6 destination that recognizes a Destination Options header but not one TLV inside it. It can read the type and length, yet has no parser for the option data. The packet has reached exactly the compatibility boundary an extension mechanism is meant to survive: new meaning has arrived at old code.

RFC 1883, the first published IPv6 specification in December 1995, did not leave that node with a generic “unknown” case. It encoded a fallback in the Option Type octet itself. The two highest bits said what ignorance should cost. The third said whether the data could change on the way to the final destination. The remaining five bits participated in identifying the option.

This was a small but consequential allocation of authority. The new option's designer could declare the safe consequence of non-recognition in a globally parseable form. The old implementation did not have to invent semantics for the data. It only had to understand the common envelope and obey a narrow instruction.

Two bits bounded four consequences of ignorance

The four two-bit values did not form a ladder from harmless to malicious. They described processing outcomes.

00 meant: skip this option and continue processing the header. The length byte supplied the boundary, so the node could advance without understanding the private data. 01 meant discard the packet. 10 meant discard and send ICMPv6 Parameter Problem, Code 2, to the source, with the pointer aimed at the unrecognized Option Type. 11 imposed the same discard but sent that error only when the packet's destination was not multicast.

The pointer mattered. It turned a generic loss into evidence about the exact octet that stopped processing. But the error remained a packet, not a verdict service. It could be rate-limited, filtered, misrouted or lost. Its arrival showed that one node reported one unrecognized type; its absence did not prove that every node skipped the option.

Nor did 00 grant a right of passage. It told a conforming node already processing that options header how to proceed. A firewall could still apply a local rule, a router might not be configured to process Hop-by-Hop options, and a path could fail before the intended processor saw the type.

The multicast distinction bounded error traffic

The difference between 10 and 11 was deliberately visible in the type. With 10, the processing node reported the failure even if the destination was multicast. With 11, it suppressed the ICMP response for multicast destinations.

That distinction kept reporting policy attached to the option rather than to an implementation's guess about its importance. It also made the possible amplification surface auditable. An operator can read whether the option called for a report in the multicast case; the operator still controls rate limits and must observe whether replies are actually emitted.

The bit pattern did not say that multicast itself was unsafe. It said which error behavior belonged to this particular option type when a processor did not recognize it.

A third bit kept mutable data out of a false promise

The next bit answered a different question. Zero declared that the Option Data did not change en route; one declared that it might. This was not another unknown-option action. It described the stability of the data.

That distinction mattered when an IPv6 Authentication Header was present. For an option marked mutable, the entire Option Data field was treated as zero-valued octets when the authentication value was calculated or checked. The protocol did not authenticate a changing field and then pretend that a legitimate in-path update was tampering.

The exclusion was narrow. It did not authorize every router to rewrite the option. The option's own specification still determined who could change what. The bit merely kept an expected mutation outside the invariant covered by the authentication calculation.

The bits belonged to the type

RFC 2460 made an important clarification in 1998: the three high-order bits were part of the complete eight-bit Option Type. They were not a separate policy field laid over a five-bit identity. Two options with different high bits had different types, even if their low five bits matched.

Hop-by-Hop Options and Destination Options used the same type-number space, although an option specification could restrict where its type was valid. Options also had to be processed in the order they appeared. A receiver was not allowed to scan ahead for a familiar option and execute it before an unfamiliar predecessor.

Order preserved causality. If an early option required discard, a later option could not retroactively make the packet acceptable. The common grammar supplied both a byte boundary and a decision boundary.

Unknown option was not unknown extension header

The mechanism had a sharp edge. These bits live inside TLV options carried by the recognized Hop-by-Hop Options or Destination Options headers. They do not solve the case where a Next Header value names an extension-header type the node does not recognize.

An unknown TLV still exposes its length and action bits. An unknown extension header historically might not expose a format a legacy inspector could traverse safely. RFC 6564 therefore preferred adding optional destination information as an option when possible and imposed a common length-bearing layout on future extension headers. It did not make older header formats uniform.

RFC 7045 drew the role boundary. A destination host discards a packet containing an unrecognized extension header. An intermediate forwarding node generally should not discard merely because it does not recognize a newly standardized header; if it chooses to inspect extension headers, it must keep its knowledge current. That is a different contract from consulting the action bits of an unknown option inside a header it already knows how to parse.

Middleboxes exposed what self-description could not solve

The option format reduced synchronized-upgrade pressure, but it did not abolish deployment friction. Devices that search for transport ports, enforce access rules or distribute flows may need to traverse the IPv6 header chain. Unknown types, long chains and options that leave the fast path create real parsing and resource costs.

RFC 8200 retained the four actions and the change bit, while making Hop-by-Hop processing by transit nodes dependent on explicit configuration. RFC 9098 later documented the operational choices faced by devices that cannot find the information they need: pass without the desired inspection, drop, or process outside the normal fast path. Each choice has a security or capacity cost.

This is why a self-describing fallback is necessary but insufficient. The type tells a conforming processor what ignorance means after the processor reaches that option. It cannot force a middlebox to reach it, allocate silicon to it or accept its resource cost.

What the bits never authorized

An action class is not an authenticity grade. 00 does not mean safe, and 11 does not mean hostile. The change bit is not permission for arbitrary modification. An ICMP pointer does not prove the identity or intent of the sender. A registered type does not establish that a path supports it.

The architecture is useful precisely because its authority is narrow. Standards define a common consequence. The sender chooses an option. The processing node acts at its own boundary. The operator owns resource policy. Running packets provide the evidence of deployment.

Sources and evidence limits

The original bit semantics come from RFCs 1883 and 2460; the current core rule is in RFC 8200. The distinction from new extension-header formats and forwarding behavior comes from RFCs 6564 and 7045. Operational constraints come from RFC 9098. These documents define rules and recorded failure modes. They do not prove present support, drop rates or conformance for every product or network.