Summary

  • RFC 9792 defined a variable-length OSPFv2/OSPFv3 Prefix Extended Flags sub-TLV, but deliberately assigned no flag meaning of its own.
  • The live IANA registries now contain U and UP flags from RFC 9929; that later allocation still does not prove implementation, advertisement, acceptance or forwarding effect.

The striking sentence in RFC 9792 is not a new routing instruction. It is the admission that there is none: “Currently, no bits are defined in this document.” The RFC standardized a place where later standards could put prefix properties. It also standardized the rules that keep that place safe when it is absent, short, unknown, duplicated or malformed.

That distinction matters because network evidence often collapses layers. A standards document becomes “support”; a registry entry becomes “enabled”; a decoded bit becomes “the router acted”; a route becomes “traffic followed it.” RFC 9792 is unusually useful because its first published state makes that collapse impossible. A carrier existed while its payload vocabulary was empty.

The carrier, precisely

For OSPFv2, the new Prefix Extended Flags sub-TLV has type 11 and sits inside the Extended Prefix TLV defined by RFC 7684. For OSPFv3, it has type 37 and may sit in the Inter-Area-Prefix, External-Prefix and Intra-Area-Prefix TLVs of RFC 8362, or the SRv6 Locator TLV of RFC 9513.

The value is a sequence of 32-bit blocks. Bit zero is the most significant bit of the first block; bit 32 is the most significant bit of the fifth octet. The length must be a multiple of four. A nonconforming length makes the containing LSA malformed and requires it to be ignored. Senders must stop after the last block needed to carry a one bit. A defined flag beyond the received length is treated as zero.

These rules make absence meaningful, but only negatively. No sub-TLV, no transmitted trailing block, or an all-zero block supplies no affirmative property. Unassigned bits must be sent as zero and ignored on receipt. A legacy implementation that does not recognize the sub-TLV ignores it under the extension rules in RFC 3630 and RFC 8362. Compatibility is achieved by withholding inference, not by inventing a default.

Multiplicity is equally disciplined. If a parent TLV contains more than one instance, the receiver uses the first, ignores the rest and should rate-limit its error reporting. It does not OR the copies together. The first occurrence is a parsing boundary, not a consensus among duplicate claims.

The registry moved after publication

The historical and current statements must be kept together. RFC 9792 was published in June 2025 with no defined bits. The live IANA OSPFv2 and OSPFv3 registries now assign bit zero to U and bit one to UP, both by RFC 9929; bits 2–31 remain unassigned. RFC 9792 created the address space. RFC 9929 supplied the first properties.

Even then, reading a one bit is not enough. RFC 9929 makes U mean unreachable and UP mean planned unreachable. UP without U must be ignored. For OSPFv2, U and UP are valid only when the metric is LSInfinity. For OSPFv3, LSInfinity and the NU bit in the parent Prefix Options are also required. The later property is a relation among fields, not an isolated lamp in a decoder.

The fixed fields did not disappear. RFC 5340 gives OSPFv3's eight-bit Prefix Options field route-calculation meanings including NU, LA, P and DN. RFC 7684 gives OSPFv2's Extended Prefix TLV its own fixed flag octet, and RFC 9792 explicitly says that unused fixed OSPFv2 flags should be consumed before new extended flags are allocated. Extension does not erase the older control surface.

A disciplined evidence statement

An analyst can now state exactly what was observed: an IETF specification defined a carrier; IANA allocated a bit; a device release claims support; a local configuration enables it; an LSA capture contains a valid first instance; a receiver retains the LSA; route calculation changes; a FIB entry changes; traffic follows the new path. Each clause needs its own evidence. Missing clauses must remain missing.

The registration policy reinforces the point. “IETF Review” under RFC 8126 governs who can assign meaning to a codepoint. It is a provenance rule for the namespace, not telemetry from a network. Likewise, RFC 9792's statement that it adds no new security problem does not promise that malformed input is harmless; RFC 8362 requires robust rejection so an extension cannot become an OSPFv3 failure mechanism.

The operational value of RFC 9792 therefore began before the first bit acquired a name. It created a bounded place for future meaning and, more importantly, a set of rules for refusing meaning when the evidence is not there.

Sources