RFC 9983: an anycast flag is intent, not service health

Summary

RFC 9983 assigns the OSPFv2 AC-Flag one narrow meaning: a prefix is intended to be advertised by multiple nodes. One flagged advertisement is enough to classify the prefix as anycast.
The bit does not enumerate nodes or attest to reachability, application readiness, capacity, synchronized answers or a successful client transaction. Re-advertisement across areas and export through BGP-LS can repeat the assertion without independently confirming it.
Daniel Kade proposes a layered anycast-property receipt that separates configuration, originated and observed advertisements, node-level service readiness and client-vantage results.

The light is on, but what room does it describe?

Picture a network controller receiving an OSPFv2 prefix attribute. A new bit is set. The controller no longer has to infer from duplicate advertisements that the prefix might be anycast. It has a common, machine-readable statement. That is real progress: a topology consumer can interpret the prefix according to declared intent instead of reverse-engineering intent from circumstances.

The tempting next sentence is also the dangerous one: “therefore the anycast service is healthy.” Nothing in the bit supports it.

The router could have a correct configuration while the application behind the address is unavailable. One node could advertise stale state. Several nodes could serve inconsistent datasets. A route could be accepted in one area but absent from another. A user could be steered to a distant or impaired instance. The flag has done its job even while all of those questions remain unanswered, because its job is classification.

Governance often fails at exactly this promotion step. A control-plane assertion becomes a dashboard badge; the badge becomes a service promise; the promise is repeated until nobody remembers which observation originally justified it. RFC 9983 is useful partly because its language resists that expansion. It names a property and then warns operators about the conditions under which even that property can be misread.

One bit, one meaning

Published in May 2026 by the IETF’s Link State Routing working group, RFC 9983 allocates value 0x10 in the OSPFv2 Extended Prefix TLV Flags registry. It calls the bit the Anycast Flag, or AC-Flag. The specification’s decisive sentence is restrictive: the flag’s only meaning is that the prefix is intended to be advertised by multiple nodes.

“Intended” matters. It places the assertion at the configuration and operating-policy layer. When a prefix is configured as anycast, the flag must be set; otherwise it must be clear. The rule makes intent explicit and testable against configuration. It does not report how many advertisements currently exist, which routers emitted them, whether forwarding reaches those routers or whether an application will accept the resulting traffic.

RFC 7684 supplied the Extended Prefix TLV in which OSPFv2 can carry extra attributes. Its N-flag marks a node-specific prefix. RFC 9983 forbids the N-flag and AC-Flag from being set together because “this identifies one node” and “this is intended to come from multiple nodes” are conflicting classifications. A receiver must treat the combination as a configuration anomaly, ignore the N-flag and should log the problem with rate limiting.

That is not a mechanism for choosing which service is trustworthy. It is a mechanism for keeping two routing semantics from silently coexisting. The logged anomaly is evidence of a contradiction in advertised classification, not evidence that traffic was lost or that either application was compromised.

Precedence creates a duty to remember dissent

RFC 9983 also settles a practical aggregation question. The same prefix may be advertised by several routers. If at least one of those advertisements sets the AC-Flag, the prefix is considered anycast. A single set bit therefore takes precedence over several clear bits for classification.

This rule keeps a consumer from wrongly treating an anycast prefix as node-specific merely because one origin is stale or lacks implementation support. But a convenient resolution rule can erase diagnostic detail if a controller stores only the final label. “Anycast” might mean unanimous, current configuration. It might instead mean one flagged origin beside four unflagged origins. Those states have the same class and different operational implications.

RFC 9983 tells operators to manage anycast prefixes consistently and strictly monitor stale configuration. The sound evidence model therefore keeps both the resolved property and its inputs: which origin was observed, whether the bit was set, when the LSA was received, which area and collector saw it, and whether a conflict changed over time. The resolved label is useful for computation. The dissent record is useful for accountability.

Absence needs similar care. An unflagged advertisement can mean a node-specific prefix. It can also appear where a router lacks support, an operator omitted configuration, or propagation preserved an older state. RFC 9983’s security considerations expressly require receivers to allow for misconfiguration and inconsistent implementation when relying on the flag for forwarding or security decisions. A clear bit is not a universal negative attestation.

Propagation is continuity, not corroboration

The AC-Flag must be preserved when the Extended Prefix Opaque LSA is re-advertised into another OSPF area. RFC 9085’s BGP-LS Prefix Attribute Flags TLV can convey the same property to topology consumers outside the originating IGP view. These rules prevent useful semantics from falling off as the data crosses a boundary.

Preservation can nevertheless look like confirmation on a dashboard. A collector may see the bit in Area 0, in another area and again in a BGP-LS feed. Three observations do not necessarily mean three independent parties inspected the underlying configuration. They may be descendants of one originating assertion.

Provenance must therefore travel with propagation. An operator needs to distinguish the source LSA, the area-border re-advertisement and the BGP-LS representation. Each hop can show that a carrier preserved the bit. None, by repetition alone, proves that another node is advertising, that the source is current or that an application is serving.

This is a general lesson for automated assurance. Redundant copies increase availability of evidence. They do not automatically increase independence of evidence. Without lineage, a copied assertion can masquerade as consensus.

An anycast property is not an anycast service

RFC 4786 describes the operating work that begins where the property flag stops. Once a routing system has reachability information for a service address, packets begin arriving. The document says coupling advertisement to service availability is desirable: a node should be ready before it attracts requests, and withdrawal can follow non-availability where the design permits.

“Desirable” is the boundary. OSPF does not inspect the application merely because a prefix carries the AC-Flag. Health might be coupled by a local process, a controller, a host route or an external probe. It might be coupled badly. A covering prefix might remain announced while one of several services fails. A repair might suppress a healthy service alongside an unhealthy one. Each choice belongs to deployment design, not to the bit’s semantics.

RFC 4786 separately asks operators to consider transaction duration, route stability, data synchronization, node identification and monitoring from representative points in the routing system. RFC 7094 goes further: an anycast architecture should be prepared for packets to reach different service instances, with consequences for hard state, middleboxes and long-lived transports.

These sources yield at least four independent questions after the flag is read:

Are multiple nodes actually originating reachability now?
Is the intended service ready behind each node that attracts traffic?
Do the nodes return policy-equivalent and sufficiently synchronized results?
What do clients observe from relevant locations and over relevant transactions?

A routing-property answer cannot fill the other cells. A health probe from one node cannot fill the client-vantage cell. A successful request from one city cannot establish the current membership of the set. Evidence must remain indexed to the question it can answer.

The management plane can change the assertion

RFC 9983 does more than allocate a wire bit. It defines the ietf-ospf-anycast-flag YANG module, augmenting the OSPF and routing management models. The data node is writable, creatable and deletable. Unauthorized modification can cause a prefix to be interpreted as anycast or node-specific. Unauthorized reading may disclose anycast-property information about OSPF prefixes on a device.

The RFC therefore points to secure transport, mutual authentication and the Network Configuration Access Control Model. It also encodes the AC/N conflict as a YANG must constraint. That prevents one malformed combination at the configuration interface; it does not guarantee that all devices support the module, that every configuration path is controlled, or that the deployed service matches the declared property.

This makes the management operation part of the evidence chain. Who was allowed to set the bit? Under which configuration revision? Did the candidate configuration pass its constraint? Was it committed on every intended device? Did the resulting LSAs appear? A screenshot of the final checkbox is not a durable answer. Neither is a BGP-LS snapshot detached from the configuration change that produced it.

Read access also deserves restraint. A governance record need not copy a complete YANG datastore or private topology. It can retain the policy identifier, device-role pseudonym, prefix scope, configuration version, actor or automation identity, approval reference, commit time and a bounded result hash. Accountability should not become a new topology leak.

A layered anycast-property receipt

I propose a receipt that treats the AC-Flag as the first layer rather than the final verdict. This is editorial guidance, not an extension to RFC 9983.

The configuration layer records the prefix, intended anycast scope, policy version, AC/N validation, authorized change identity and commit status. The origination layer records which expected device roles emitted an Extended Prefix LSA and the relevant sequence and age observations. The reception layer records collector, area, time, bit value, conflict state and lineage through re-advertisement or BGP-LS.

The service layer is deliberately separate. For each node or service zone it records the health method, probe target, freshness window, dependency state and withdrawal coupling. The client layer records vantage class, transaction type, selected instance where discoverable, outcome and time. Synchronization checks belong beside the service observation, not inside the routing assertion.

The receipt should preserve anomalies, not average them away. A single flagged origin beside clear origins, a flag that outlives the intended configuration, an advertised node whose application probe fails and a healthy node that is not attracting traffic are different conditions. Each demands a different owner and remedy.

It should also expire evidence honestly. LSAs age; configurations change; probes have observation windows; client outcomes are local to a path and moment. A receipt with no freshness semantics becomes the stale configuration RFC 9983 tells operators to monitor.

The bit remains valuable precisely because it is modest. It replaces inference with an explicit declaration. Governance preserves that value by refusing to make the declaration answer questions it was never designed to answer.

RFC 9983’s Anycast Flag Marks Intent, Not Service Health

Why it matters

Summary

The light is on, but what room does it describe?

One bit, one meaning

Precedence creates a duty to remember dissent

Propagation is continuity, not corroboration

An anycast property is not an anycast service

The management plane can change the assertion

A layered anycast-property receipt

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing