OSPFv2 Anycast Property Advertisement
Extracted elements (15)
Extensions for anycast property advertisement already existed for IS-IS (RFC 9352) and OSPFv3 (RFC 9513) in the context of Segment Routing over IPv6; this document extends the same concept to OSPFv2 because the anycast property applies to any IP prefix advertisement, not just SR/IPv6.
If at least one router advertising the same prefix sets the AC-Flag, the prefix is considered anycast. A prefix advertised by a single node without an AC-Flag is considered node-specific. This asymmetric rule means a single AC-Flag setter overrides the absence of the flag from other advertisers.
The BGP-LS Prefix Attribute Flags TLV (RFC 9085) carries prefix attribute flags interpreted according to OSPFv2 (RFC 7684), so the AC-Flag introduced here is automatically conveyed through BGP-LS without further extension.
Anycast prefixes SHOULD be consistently managed throughout the network. Since an AC-Flag set takes precedence in identifying the anycast property, stale configurations should be strictly monitored.
Detection of a conflicting advertisement where both N-flag and AC-Flag are set SHOULD be logged as an operational error, subject to rate-limiting.
The AC-Flag and the N-flag MUST NOT both be set. Reception of an advertisement with both flags set MUST be considered a configuration anomaly, and the N-flag MUST be ignored.
The AC-Flag MUST be preserved when the OSPFv2 Extended Prefix Opaque LSA is re-advertised into other areas.
When a prefix is configured as anycast, the AC-Flag MUST be set. Otherwise, this flag MUST be clear.
A new flag, the AC-Flag (Anycast Flag), with value 0x10, is introduced in the OSPFv2 Extended Prefix TLV Flags field to advertise the anycast property of a prefix. Its sole meaning is that the prefix is intended to be advertised by multiple nodes.
The YANG module 'ietf-ospf-anycast-flag' augments the OSPFv2 interface with a boolean leaf 'anycast-flag' (default false), and enforces a 'must' constraint preventing anycast-flag and node-flag from both being true simultaneously.
IANA has allocated value 0x10 (AC-Flag, Anycast Flag) in the 'OSPFv2 Extended Prefix TLV Flags' registry.
IANA has registered the YANG module 'ietf-ospf-anycast-flag' in the 'YANG Module Names' registry and the corresponding URI 'urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag' in the IETF XML Registry.
The AC-Flag introduces operational dependencies on both router implementation support and accurate operator configuration. Receivers MUST consider the possibility of misconfiguration or inconsistent implementation when relying on the AC-Flag for forwarding or security decisions.
The YANG data node 'anycast-flag' is writable and sensitive; unauthorized write operations could prevent correct interpretation of a prefix as anycast or node-specific. YANG management protocols must use secure transport (SSH, TLS, QUIC) with mutual authentication, and NACM should restrict access.
Unauthorized read access to the anycast-flag data node can disclose anycast property information for OSPF prefixes on a device, which may be sensitive in some network environments.