Summary

  • RFC 9983 assigns the OSPFv2 Extended Prefix TLV's 0x10 AC-Flag one deliberately narrow meaning: the prefix is intended to be advertised by multiple nodes.
  • That declared property must remain distinct from evidence of a usable route, a selected replica, replica health, and the application result reached through the route.

A routing incident room often wants a binary answer: “is this anycast service up?” A control-plane capture sometimes seems to offer one. An Extended Prefix advertisement bears the new AC-Flag; several routers advertise the same prefix; a BGP-LS collector displays the bit. The dashboard turns the property into a green label.

That is a category error. The bit is meaningful precisely because it says less than the label is tempted to say.

RFC 9983, published on the IETF Standards Track in May 2026, defines OSPFv2 Anycast Property Advertisement. It allocates 0x10 as the Anycast Flag in the Extended Prefix TLV Flags registry. The definition is concise: an AC-Flag says that the prefix is intended to be advertised by multiple nodes. A prefix configured as anycast must set it; one not configured as anycast must clear it.

The standard is solving a real ambiguity. A duplicate prefix in OSPF is not, by itself, an adequate statement of intent. It might result from a temporary topology condition, a configuration accident, or a design that does not present an anycast service. The flag gives operators and consuming systems a common, routable assertion about that intent. When an Extended Prefix Opaque LSA is re-advertised into another area, the flag must be preserved, so the property does not silently disappear at an area boundary.

It still does not make the advertisement a service receipt.

A property, a route, and a service are different facts

Consider three routers advertising the same prefix. The first fact is administrative: the configuration says this prefix is anycast. The second is protocol-visible: one or more advertisements carry AC-Flag, and routers build their views of the topology and paths. The third is forwarding-specific: a particular ingress selects one next hop under its current shortest-path calculation, equal-cost multipath policy, recursion, filters and installed FIB. The fourth is operational: the chosen replica can receive traffic, meet its health requirements, and return the required application result.

Each fact can be true while the next one is false.

An advertisement can carry the right bit but fail to arrive in a relevant area. It can arrive while a local route policy prevents installation. A route can install while an ECMP choice reaches an impaired replica. A replica can answer transport probes while the application behind it rejects an update, serves stale data, or lacks the authority assumed by the caller. None of these observations refutes RFC 9983. They establish that the RFC's semantic claim is not an end-to-end assertion.

Heng Lu's distinction between a minimum common specification and localized future decision is helpful here. The common layer needs a small interoperable fact: “this is intended as a multi-node prefix.” It does not need to standardise every operator's failure detector, load-distribution policy, service ownership model, or application success condition. Those decisions are local because their evidence and consequences are local. Treating a shared routing bit as if it already contained them erases that boundary.

The N-flag conflict is an operator warning, not a curiosity

RFC 9983 is unusually direct about one semantic collision. Its AC-Flag and the Node flag defined by RFC 7684 must not both be set. If a router receives both, it must treat the state as a configuration anomaly, ignore the N-flag, and should log the event subject to rate limiting.

That instruction matters beyond parser correctness. An automation system that reduces flags to a generic “prefix metadata valid” boolean loses the one condition the standard identifies as contradictory. A leadership dashboard that aggregates the data from multiple areas may then make a confident availability inference from an input the receiving router itself treats as anomalous.

The safe response is not to declare the service down whenever the conflict appears. RFC 9983 does not prescribe that operational outcome. The safe response is to preserve the conflict, identify the configuration and advertisement sources, and prevent the conflict from being used as positive proof of a replica's capability.

The property travels farther than the operating proof

The RFC also gives the bit useful reach. For a multi-advertised prefix, if at least one advertisement has AC-Flag, the prefix is considered anycast; a singly advertised prefix without the flag remains node-specific. The document asks operators to manage anycast prefixes consistently and to monitor stale configuration strictly, since the flag takes precedence when identifying anycast property. The complementary BGP-LS representation in RFC 9085 carries the relevant prefix flags, allowing the property to appear in a topology or analytics system that is not itself originating OSPF.

That propagation improves visibility; it does not confer command authority on the collector. A BGP-LS consumer can report what it received. It cannot, from that fact alone, prove which ingress computed which path, whether the path reached a live host, or whether a packet produced the intended business result. The more systems repeat a clean flag, the easier it becomes to mistake repeated declaration for independent confirmation.

The YANG work makes the same boundary practical. RFC 9983 augments the OSPF model in RFC 9129 and the routing-management model in RFC 8349 with writable anycast-flag data. Management access can therefore alter an assertion that downstream tools rely on. The RFC requires secure management transport and mutual authentication, and points to NACM for restricting access because both readable and writable state may be sensitive.

This is not merely a control-plane hardening footnote. If the organization makes a flag influence forwarding or security decisions, the RFC says receivers must consider configuration error and inconsistent implementation. The owning control should therefore record who wrote the state, what was reviewed, which routers advertise it, which versions interpret it, and what contradiction rules apply. A read-only topology picture is not enough.

An evidence chain that can survive an incident

For a high-consequence anycast service, separate the record into six linked observations:

  1. the approved configuration and management identity that declared the prefix anycast;
  2. the originating and received OSPF advertisements, including AC/N conflicts and area propagation;
  3. route-computation and FIB evidence at relevant ingresses;
  4. data-plane selection evidence, including ECMP and return-path conditions;
  5. replica-specific health and capacity evidence; and
  6. an application-level outcome appropriate to the service.

This does not demand that every alert collect all six before action. It says the evidence label must match the layer actually observed. “AC-Flag present” is an excellent alert. “Anycast service healthy” is not justified by that alert alone.

The distinction also prevents perverse incentives. A platform team may prefer one simple global availability field. A routing team may assume a consistent control plane proves enough. A service team may assume network reachability is somebody else's proof. The missing joins sit exactly where an incident becomes expensive: a known prefix that routes to no acceptable replica, or a valid replica that has no authority to perform the requested action.

RFC 9983 deserves adoption for the honest coordination it adds. Leadership should protect that honesty in its own language. The flag can say that several routers are meant to speak for a prefix. It cannot tell us which one spoke, whether that router could act, or whether the world on the other side of the packet changed as intended.