Summary

  • RFC 5175 gives IPv6 Router Advertisements forty-eight additional flag positions and rules for length, order and duplicate handling. It creates a forward-compatible assertion surface, not forty-eight deployed capabilities.
  • A defensible operational claim needs separate receipts for the observed packet, the first valid option, the registry snapshot, the receiver build, the allocating specification, filter and trust decisions, host state and resulting traffic.

The tempting sentence in an incident report is “the router enabled the feature.” The packet usually proves less. It can prove that one sender placed a one in a defined position of one Router Advertisement. Between that event and a changed host lie several independent decisions: whether a Layer-2 filter forwarded the message, whether the option length was acceptable, whether the receiver knew the bit, whether associated options followed it, whether local policy authorized the action and whether any state or traffic actually changed.

RFC 5175 is valuable precisely because it does not pretend those decisions are one thing. The base Router Advertisement header had eight flag positions. The Expanded Flags Option, ICMPv6 option Type 26, provides another forty-eight. That is a namespace for future standards. It is an address system for assertions.

Extensibility works by tolerating ignorance

The option carries a length measured in eight-octet units. A sender using the defined form sets that length to one. A receiver checks the field because a later specification may make the option longer; data it does not recognize can be skipped. An option shorter than one unit is ignored. Unknown bits are ignored too.

This is sound interoperability engineering. An older host need not reject an entire Router Advertisement because a newer router knows a flag it has never seen. Yet the same rule creates an evidence boundary. On one host, the bit may drive a supported feature. On another, it may be a harmless unknown. A capture common to both hosts cannot prove a common outcome.

Registry language should therefore stay exact. An IANA row coordinates a position, a label and a reference. It does not remotely install code, select a software version, turn on an administrative policy or validate an outcome. At the date of this research, the registry shows an S position linked to an active Internet-Draft. That is a current allocation record, not permission to describe the draft as a published RFC or the function as universal.

The first option is the effective option

RFC 5175 permits the Expanded Flags Option only in a Router Advertisement. A sender includes it no more than once and omits it if none of its defined expanded bits are set. A receiver faced with duplicates processes the first instance and ignores every later one.

That small rule changes how telemetry must work. A decoder that merges every displayed option can manufacture a union of flags no conforming receiver used. A monitoring system that highlights the last option may report an attacker’s correction rather than the first value the host was required to process. Evidence needs the full packet, byte order, selected instance and length result, not a normalized bag of flag names.

Order also carries meaning. The expanded option must precede additional options associated with its flags. The flag can announce an interpretation whose operational material arrives later in the same Router Advertisement. Recording the bit while dropping the following options preserves the headline and discards the explanation.

A registry is a map, not a capability inventory

RFC 5075 had already described almost the same expanded format while the option type was still provisional. RFC 5175 replaced the placeholder with the allocated value 26 and removed text made redundant by that assignment. The change mattered: independent implementations could now put the option at a coordinated point on the wire. It still did not prove that a particular device shipped the parser or any later flag behavior.

This distinction matters in procurement and security reporting. “Registered” is a standards fact. “Advertised” is a packet fact. “Recognized” is a receiver-version fact. “Authorized” is a trust and policy fact. “Applied” is a host-state fact. “Affected traffic” is an outcome fact. Each can be true while the next is false.

SEND and RA-Guard sit on other parts of that chain. SEND can provide cryptographic authorization for Neighbor Discovery. RA-Guard filters Router Advertisements in the Layer-2 fabric according to deployed criteria. RFC 6105 makes its topology assumptions explicit, and RFC 7113 records that some implementations were bypassable without deeper header-chain parsing. A product checkbox saying RA-Guard is present cannot stand in for a packet-specific forward or drop receipt.

The current SNAC-router flag draft offers a useful live example without proving deployment. It says devices that do not understand the bit silently ignore it and notes that a filter policy can prevent such advertisements reaching the transit network. The same one on the sender’s wire may thus become a recognized signal, an ignored novelty or an unseen packet.

Sources