RFC 9983

OSPFv2 Anycast Property Advertisement

📅 published May 2026, from ietf

OSPFv2 Anycast Property Advertisement 🎀

RFC 9983, by Ran Chen and Detao Zhao (ZTE Corporation), Peter Psenak and Ketan Talaulikar (Cisco Systems), and Changwang Lin (New H3C Technologies). It's a Standards Track document from the IETF, dated May 2026, and it's in the ISSN 2070-1721 series. The header doesn't list anything it obsoletes or updates. 💖

Abstract ✨

Okay so, an IP prefix can be set up as anycast, which means the same value can get advertised by a bunch of routers at once. 🦋 Other routers need to be able to tell that an advertisement is for an anycast prefix. This doc adds a new flag to the OSPFv2 Extended Prefix TLV Flags so the anycast property can be advertised, and it also comes with a companion YANG module for managing it. 💅

Status of This Memo 🌸

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), it reflects the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on Internet Standards, check out Section 2 of RFC 7841.

For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9983. 🧚

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read them closely, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes. 👑

Table of Contents 📋

1.  Introduction
  1.1.  Requirements Language
2.  OSPFv2 Anycast Property Advertisement
3.  BGP-LS Advertisement
4.  YANG Data Model
  4.1.  Tree for the YANG Data Model
  4.2.  YANG Data Model for OSPFv2 Anycast Property Advertisement
5.  IANA Considerations
  5.1.  OSPFv2 Extended Prefix TLV Flags Registry
  5.2.  OSPFv2 Anycast Flag YANG Module Registration
6.  Security Considerations
  6.1.  Protocol Security Considerations
  6.2.  YANG Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 💫

Same deal as the abstract: an IP prefix can be configured as anycast, so the same value can be advertised by several routers, and other routers want to know the advertisement is for an anycast prefix. 🦋

[RFC7684] defines OSPFv2 Opaque Link State Advertisements (LSAs). They're built out of Type-Length-Value (TLV) tuples, and those tuples can attach extra attributes to prefixes or links. The OSPFv2 Extended Prefix TLV, which lives inside the OSPFv2 Extended Prefix Opaque LSA, is what carries extra attributes for a prefix. ✨

Anycast extensions already exist for IS-IS [RFC9352] and OSPFv3 [RFC9513]. Those docs are about Segment Routing over IPv6, but the anycast property applies to any IP prefix advertisement, so this doc adds a flag for OSPFv2. It goes in the Flags field of the OSPFv2 Extended Prefix TLV Flags (Section 2.1 of [RFC7684]). This doc also specifies a companion YANG module for managing the feature. 💅

1.1. Requirements Language 🔥

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀

2. OSPFv2 Anycast Property Advertisement 🦋

An IP prefix can be configured as anycast, and other routers need to know the advertisement is for an anycast prefix. 🌸

For the flags in this doc, "set" means the bit is 1, and "clear" means the bit is 0. 💖

A new flag gets added to the "OSPFv2 Extended Prefix TLV Flags" IANA registry (see [RFC7684]) for the anycast property:

Value:  0x10

Description:  Anycast Flag (AC-Flag)

The only thing the AC-Flag means is that the prefix is meant to be advertised by multiple nodes. 🧚

When a prefix is configured as anycast, the AC-Flag MUST be set. If it isn't, the flag MUST be clear. 🔥

The AC-Flag and the N-flag (Section 2.1 of [RFC7684]) MUST NOT both be set. If a router receives an advertisement with both the N-flag and the AC-Flag set, that MUST be considered a configuration anomaly, and the N-flag MUST be ignored. On top of that, spotting one of these conflicting advertisements SHOULD be logged as an operational error, subject to rate-limiting. 💀

The AC-Flag MUST be preserved when the OSPFv2 Extended Prefix Opaque LSA gets re-advertised into other areas. 🫶

The same prefix can be advertised by several routers. If at least one of them sets the AC-Flag in its advertisement, the prefix counts as anycast. ✨

A prefix that a single node advertises without an AC-Flag is treated as a node-specific prefix. 🙈

Anycast prefixes SHOULD be consistently managed throughout the network. An AC-Flag that's set wins when it comes to identifying the anycast property, so stale configurations should be strictly monitored. 👑

3. BGP-LS Advertisement 🌈

[RFC9085] defines the Prefix Attribute Flags TLV for Border Gateway Protocol - Link State (BGP-LS), which carries prefix attribute flag information. The Flags field of that TLV is read according to OSPFv2 [RFC7684]. So the Flags field of the BGP-LS Prefix Attribute Flags TLV also carries the anycast property this doc introduces. 🦋

4. YANG Data Model 💜

YANG [RFC7950] is a data definition language. It defines the contents of a conceptual data store so networked devices can be managed through the Network Configuration Protocol (NETCONF) [RFC6241] or RESTCONF [RFC8040]. 🧚

This section defines a YANG data model for managing the OSPFv2 Anycast Property as this doc defines it. It augments the OSPF YANG data model [RFC9129] and the YANG Data Model for Routing Management [RFC8349]. 🌸

4.1. Tree for the YANG Data Model 🌳

This doc uses the graphical representation of data models from [RFC8340]. Here's the tree diagram for the module:

module: ietf-ospf-anycast-flag

  augment /rt:routing/rt:control-plane-protocols
         /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
        /ospf:interfaces/ospf:interface:
    +--rw anycast-flag?   boolean

4.2. YANG Data Model for OSPFv2 Anycast Property Advertisement 🎀

The "ietf-ospf-anycast-flag" module in this doc imports typedefs from [RFC8349] and [RFC9129]. 💖

<CODE BEGINS> file "ietf-ospf-anycast-flag@2026-05-19.yang"
module ietf-ospf-anycast-flag {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag";
  prefix ospf-anycast-flag;

  import ietf-routing {
    prefix rt;
    reference
      "RFC 8349: A YANG Data Model for Routing
       Management (NMDA Version)";
  }
  import ietf-ospf {
    prefix ospf;
    reference
      "RFC 9129: YANG Data Model for the OSPF Protocol";
  }

  organization
    "IETF LSR - Link State Routing Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/lsr/>
     WG List:  <mailto:lsr@ietf.org>

     Author:   Ran Chen
               <mailto:chen.ran@zte.com.cn>
     Author:   Detao Zhao
               <mailto:zhao.detao@zte.com.cn>
     Author:   Peter Psenak
               <mailto:ppsenak@cisco.com>
     Author:   Ketan Talaulikar
               <mailto:ketant.ietf@gmail.com>
     Author:   Changwang Lin
               <mailto:linchangwang.04414@h3c.com>";

  description
    "This YANG module adds the support of managing an OSPFv2
     prefix as anycast.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2026 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     All revisions of IETF and IANA published modules can
     be found at the YANG Parameters registry group
     (https://www.iana.org/assignments/yang-parameters);

     This version of this YANG module is part of RFC 9983;
     see the RFC itself for full legal notices.";

  revision 2026-05-19 {
    description
      "Initial version";
    reference
      "RFC 9983: OSPFv2 Anycast Property Advertisement";
  }

  identity ac-flag {
    base ospf:ospfv2-extended-prefix-flag;
    description
      "Indicates that the prefix is configured as anycast.";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/ospf:ospf/"
        + "ospf:areas/ospf:area/ospf:interfaces/ospf:interface" {
    when "derived-from(/rt:routing/rt:control-plane-protocols/"
       + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" {
      description
        "This augments the OSPFv2 interface.";
    }
    description
      "This augments OSPFv2 interface with anycast
       property advertisement.";
    leaf anycast-flag {
      type boolean;
      must "not(../anycast-flag = 'true' and "
         + "/rt:routing/rt:control-plane-protocols/"
         + "rt:control-plane-protocol/ospf:ospf/"
         + "ospf:areas/ospf:area/ospf:interfaces/"
         + "ospf:interface/ospf:node-flag = 'true')" {
        error-message "The anycast-flag and the node-flag MUST "
                    + "NOT both be set to 1 (true).";
        description
          "Ensures architectural consistency by preventing a prefix
           from being marked as both anycast and node-specific.";
      }
      default "false";
      description
        "Indicates that the prefix is an anycast address,
         if set to 1 (true).";
    }
  }
}
<CODE ENDS>

5. IANA Considerations 🧾

IANA has allocated and/or registered the following values in their respective registries. 💅

5.1. OSPFv2 Extended Prefix TLV Flags Registry 🦋

IANA has allocated the following value in the "OSPFv2 Extended Prefix TLV Flags" registry:

0x10: AC-Flag (Anycast Flag)

5.2. OSPFv2 Anycast Flag YANG Module Registration ✨

okay so IANA registered a URI in the "ns" registry inside the "IETF XML Registry" registry group (see [RFC3688]) 💖:

ID:  yang:ietf-ospf-anycast-flag
URI:  urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag
Registrant Contact:  The IESG
XML:  N/A; the requested URI is an XML namespace

and they also registered the YANG module in the "YANG Module Names" registry ([RFC6020]) inside the "YANG Parameters" registry group 🎀:

Name:  ietf-ospf-anycast-flag
Maintained by IANA?  N
Namespace:  urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag
Prefix:  ospf-anycast-flag
Reference:  RFC 9983

6. Security Considerations 🔒😭

bestie, this section is seriously important, so read it carefully 🫶

6.1. Protocol Security Considerations

the procedures and protocol extensions in this document do not affect the OSPFv2 security model 💅 if you want the OSPFv2 security discussion, check the "Security Considerations" section of [RFC7684].

the newly introduced AC-Flag MUST be either set or clear 🦋 and it creates operational dependencies that affect whether the advertised prefix makes semantic sense. reading the AC-Flag correctly depends on two things: router implementations that support the flag, and an operator who has configured the anycast route accurately. so receivers MUST consider the possibility of misconfiguration or inconsistent implementation when they rely on the AC-Flag for forwarding or security decisions. not me trusting it blindly 💀

6.2. YANG Security Considerations

this section is modeled after the template described in Section 3.7 of [RFC9907] 🌸

the "ietf-ospf-anycast-flag" YANG module is a data model meant to be accessed through YANG-based management protocols, like Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040] 🧚 these management protocols (1) have to use a secure transport layer (for example SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication. no shortcuts, periodt 🔥

the Network Configuration Access Control Model (NACM) [RFC8341] lets you restrict particular NETCONF or RESTCONF users to a preconfigured subset of the available protocol operations and content. very useful, very iconic ✨

there is a writable, creatable, and deletable data node in this module (config true, which is the default) 🍓 it can be sensitive or vulnerable in some network environments. write operations (for example edit-config) and delete operations on this data node without proper protection or authentication can have a negative effect on network operations. the subtree and data node with the particular sensitivities and vulnerabilities are:

/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/
ospf-anycast-flag:anycast-flag

as specified in Section 2, the AC-Flag and the N-flag MUST NOT both be set to 1 🙈 this rule is enforced by a "must" constraint in the YANG module to prevent configuration anomalies, and the handling of those anomalies is defined in Section 2. if this data node gets modified without proper protection, it could stop the IPv4 prefix from being interpreted as anycast or node-specific. yikes 😭

the readable data node in this module may also be considered sensitive or vulnerable in some network environments, so it's important to control read access to it (for example through get, get-config, or notification) 👑 the subtree and data node with the particular sensitivities and vulnerabilities are:

/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/
ospf-anycast-flag:anycast-flag

unauthorized access to this subtree can disclose specific anycast property information for OSPF prefixes on a device. that's a private diary situation 🤫

there are no particularly sensitive RPC or action operations 🌈

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 🫶

the authors would like to thank Acee Lindem for aligning the terminology with existing OSPF documents and for editorial improvements 💜

Contributors 🎀

this document has the following contributor:

Yingzhen Qu Futurewei Technologies Email: yingzhen.ietf@gmail.com

Authors' Addresses 🦋

Ran Chen ZTE Corporation Nanjing China Email: chen.ran@zte.com.cn

Detao Zhao ZTE Corporation Nanjing China Email: zhao.detao@zte.com.cn

Peter Psenak Cisco Systems Email: ppsenak@cisco.com

Ketan Talaulikar Cisco Systems Email: ketant.ietf@gmail.com

Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com

📦 where this page comes from