RFC 9929

IGP Unreachable Prefix Announcement

📅 published February 2026, from ietf

RFC 9929: IGP Unreachable Prefix Announcement ✨

Okay bestie, RFC 9929 is here 🦋 and it's all about IGP Unreachable Prefix Announcement, which the IETF shortens to UPA 💅. It's dated February 2026, and it's a Standards Track document, so it's on its way to becoming a real Internet Standard 👑. It came from the Internet Engineering Task Force (IETF), and its ISSN is 2070-1721.

The authors are P. Psenak (Ed.) and C. Filsfils and D. Voyer from Cisco Systems, S. Hegde from HPE, and G. Mishra from Verizon Inc. 🫶 The title block doesn't list anything this document obsoletes or updates 🙈.

Abstract

Okay so summarization is literally how big multi-area and multi-domain networks stay efficient and scalable 💖. The catch is that once you summarize, you lose the ability to say "hey, this one specific prefix inside the summary is gone." That's the gap this doc fills ✨. Signaling loss of reachability for an individual prefix covered by a summary lets the network converge fast by steering traffic away from the node that owns the prefix (when that makes sense) and that node is no longer reachable 🏃‍♀️💨.

This document specifies protocol mechanisms in IS-IS and OSPF, plus two new flags, to advertise that prefix reachability loss 🌸.

The term "OSPF" here is used to refer to both OSPFv2 and OSPFv3 🧚.

Status of This Memo

This is an Internet Standards Track document 💜.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 🎀.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9929 🔗.

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

This document is subject to 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. Read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 🍓.

Table of Contents

1.  Introduction
  1.1.  Requirements Language
2.  Generation of the UPA
3.  Supporting UPA in IS-IS
  3.1.  Advertisement of UPA in IS-IS
  3.2.  Signaling UPA in IS-IS
  3.3.  Propagation of UPA in IS-IS
4.  Supporting UPA in OSPF
  4.1.  Advertisement of UPA in OSPF
  4.2.  Signaling UPA in OSPF
    4.2.1.  Signaling UPA in OSPFv2
    4.2.2.  Signaling UPA in OSPFv3
  4.3.  Propagation of UPA in OSPF
5.  Processing of the UPA
6.  Area and Domain Partition
7.  IANA Considerations
  7.1.  IS-IS Prefix Attribute Flags Sub-TLV
  7.2.  OSPFv2 and OSPFv3 Prefix Extended Flags
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction ✨

Okay so link-state IGPs like Intermediate System to Intermediate System (IS-IS) [ISO10589], Open Shortest Path First version 2 (OSPFv2)) [RFC2328], and Open Shortest Path First version 3 (OSPFv3) [RFC5340] are the ones that pass routing info between routers inside a single Autonomous System (AS) 🦋. They work out reachability for IPv4 or IPv6 prefixes that each node advertises inside the AS 💅. Every node shares the state of its local adjacencies, connected prefixes, capabilities, and more. When you gather all of that from every router in an area, you get the Link State Database (LSDB), which maps the area's topology and holds extra info about prefixes, router capabilities, and so on 🧠.

Now, the more links you have running a link-state protocol, the more state piles up, and that's where the scalability and convergence headaches start 😭. Splitting networks into levels, areas, and IGP domains keeps link-state info in its lane. Prefix reachability, though, often has to travel across a multi-area or multi-level network, or across multiple domains too 🌸. IGP summarization is the trick where you squish several smaller contiguous IP networks into one bigger summary route 🍓. People use summarization to handle the scaling problems of sharing prefix state outside a local area or domain. The downside is that it hides individual prefix state, and that state is exactly what fast-convergence mechanisms outside the IGPs need. Border Gateway Protocol (BGP) Prefix-Independent Convergence (PIC) [BGP-PIC] is one example 🚀.

Another thing: when a router has to go out of service for maintenance, you drain traffic off it first 🛠️. Usually that means setting the OVERLOAD bit and giving every prefix the node advertises in IS-IS a high metric. For OSPFv2, the options are using the cost of MaxLinkMetric on all non-stub links in the router-LSA [RFC6987] or using the H-bit [RFC8770]. For OSPFv3 [RFC5340], you use the R-bit 💜.

When an Area Border Router (ABR) or Autonomous System Boundary Router (ASBR) summarizes prefixes from those nodes, nodes outside that area or domain have no idea those summarized prefixes just became unreachable 😱. This document proposes protocol extensions that carry info about those prefixes in a backward-compatible way 🫶.

This document does not define how to advertise a prefix that isn't reachable for routing. That's already covered for IS-IS in [RFC5305] and [RFC5308], for OSPFv2 in [RFC2328], and for OSPFv3 in [RFC5340].

This document defines a way to signal the specific reason a prefix was advertised with the metric that excludes it from the route calculation 🔍. That's how you tell it apart from every other case where that kind of metric advertisement might show up 🎀.

IGPs usually only advertise that a prefix is reachable. To make a prefix unreachable, you just withdraw the earlier advertisement 🙈. Some of the use cases above need unreachability signaled for a prefix that was never explicitly announced as reachable, because a summary prefix was covering it 💀.

This document defines two new flags in IS-IS, OSPFv2, and OSPFv3 ✨. The flags let you advertise prefix unreachability along with the reason it's unreachable. The whole functionality is called Unreachable Prefix Announcement (UPA) 🦋.

This document also defines how UPA gets propagated across IS-IS levels and OSPF areas 🌈.

The term "OSPF" in this document covers both the OSPFv2 and OSPFv3 protocols 💖.

1.1. Requirements Language

Here's the deal with the key words: the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they're written in all capitals, exactly like this 🎀 (lowercase ones are just regular words, no cap).

2. Generation of the UPA 💖

Okay so an ABR or ASBR UPA MAY be generated for a prefix that's summarized by a summary prefix that an ABR or ASBR originated, in these cases 🫶:

  1. A prefix that was reachable earlier becomes unreachable.
  2. For any of the planned maintenance cases:
    • the node originating the prefix is signaling the overload state in IS-IS, or the H-bit in OSPFv2 [RFC8770], or the R-bit in OSPFv3 [RFC5340], or
    • the metric to reach the prefix from an ABR or ASBR crosses the configured threshold.

Generation and propagation of the UPA at an ABR or ASBR is optional, and it SHOULD be controlled by a configuration knob 🔧. Honestly it SHOULD be disabled by default too 🙈, so you have to opt in.

Implementations MAY limit UPA generation and propagation to specific prefixes, like host prefixes, Segment Routing over IPv6 (SRv6) locators, or similar things 🍓. That kind of filtering is optional too, and it SHOULD be controlled via configuration ⚙️.

The whole point of UPA is to give an event-driven signal when a destination goes from reachable to unreachable ⚡. It is not meant to be a persistent state, so don't treat it like one 💅.

An ABR or ASBR MUST withdraw a previously advertised UPA once the reason it was generated goes away. For example, the prefix became reachable again, or its metric changed so it's now below the configured threshold value 🌸.

Even if the reasons stick around, UPA advertisements SHOULD be withdrawn after some amount of time 🕰️. That gives UPA enough time to flood across the whole network and get acted on by receiving nodes, but it also keeps UPA from hanging around forever 💜. The time UPA stays in the network SHOULD also match the use case it was advertised for 🎯. If you don't withdraw UPA, stale info ends up stuck in the link state databases of every router in the area 😭.

Implementations SHOULD provide a configuration option to set the UPA lifetime at the originating ABR or ASBR 🔧.

In IS-IS, UPA rides along in existing Link State PDUs (LSPs), and the unit of flooding in IS-IS is an LSP 🧚. So it's RECOMMENDED that, when possible, UPAs go in LSPs dedicated to this kind of advertisement 🌈. That keeps the number of LSPs you have to update low every time UPAs get advertised and withdrawn ✨.

In OSPFv2 and OSPFv3, each inter-area and external prefix gets its own LSA, so that LSP consideration doesn't apply to OSPFv2 and OSPFv3 🙅‍♀️.

It's also RECOMMENDED that implementations limit how many UPA advertisements can be originated at once 🛑. That caps how many UPAs are floating around the network at any given moment 🫶. And UPA implementations SHOULD provide a configuration option to limit the number of such UPAs 💅.

3. Supporting UPA in IS-IS ✨

okay so IS-IS is up first, bestie 🦋 [RFC5305] is where the encoding for advertising IPv4 prefixes using 4 octets of metric info lives, and Section 4 of [RFC5305] says:

If a prefix is advertised with a metric larger than MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered during the normal SPF computation. This allows advertisement of a prefix for purposes other than building the normal IP routing table.

same energy for IPv6 🌈 [RFC5308] does the 4-octet metric thing too, and Section 2 of [RFC5308] states:

...if a prefix is advertised with a metric larger than MAX_V6_PATH_METRIC (0xFE000000), this prefix MUST NOT be considered during the normal Shortest Path First (SPF) computation. This will allow advertisement of a prefix for purposes other than building the normal IPv6 routing table.

the whole point 💅 is that you can advertise a prefix (IPv4 or IPv6) to say reachability has been lost, and you don't need every node in the network upgraded to pull it off. iconic, honestly 👑

3.1. Advertisement of UPA in IS-IS

existing nodes that don't support UPA won't use UPAs during route calculation, but they'll keep flooding them within the area 🫶 so the advertisements spread without needing everyone upgraded. no cap, that's the glow-up.

the ABRs or ASBRs that push UPA advertisements into other areas or domains are also expected to recognize UPA advertisements 💜

as per the definitions referenced in Section 3, any prefix advertisement with a metric value greater than 0xFE000000 can be used for purposes other than normal routing calculations. Such a metric MUST be used when advertising UPA in IS-IS. (yes it's a MUST, bestie, don't skip it 😭)

[RFC7370] introduced the "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability" registry, which lists TLVs for advertising different types of prefix reachability. (The list at the time of publication of this document is below.) UPA in IS-IS is supported for prefixes advertised in all such TLVs identified by that registry, for example:

  • SRv6 Locator [RFC9352]
  • Extended IP reachability [RFC5305]
  • Multi-Topology (MT) IP Reach [RFC5120]
  • IPv6 IP Reach [RFC5308]
  • MT IPv6 IP Reach [RFC5120]
  • IPv4 Algorithm Prefix Reachability TLV [RFC9502]
  • IPv6 Algorithm Prefix Reachability TLV [RFC9502]

3.2. Signaling UPA in IS-IS

in IS-IS a prefix can be advertised with a metric higher than 0xFE000000 for all kinds of reasons 🎀 IS-IS already defines how to treat those metrics, but we still need explicit signaling to tell UPA apart from the other high-metric ads. lowkey the whole plot twist 🙈

two new bits in the IPv4/IPv6 Extended Reachability Attribute Flags [RFC7794] are defined:

  • U-Flag: Unreachable Prefix Flag (bit 5). When set, it indicates that the prefix is unreachable.
  • UP-Flag: Unreachable Planned Prefix Flag (bit 6). When set, this flag indicates that the prefix is unreachable due to a planned event (e.g., planned maintenance).

the originating node MUST NOT set the UP-flag without setting the U-flag. 💀

the receiving node MUST ignore the UP-flag in the advertisement if the U-flag is not set.

the prefix advertised with the U-flag MUST have the metric set to a value larger than 0xFE000000. If the prefix metric is less than or equal 0xFE000000, both of these flags MUST be ignored. ✨

3.3. Propagation of UPA in IS-IS

IS-IS L1/L2 routers are the ones responsible for passing UPA advertisements between levels, so they need to recognize them 👑 If they don't, UPA never reaches routers in the remote areas. yikes 😭

IS-IS lets IP prefixes propagate in both directions between level 1 and level 2. Propagation only happens if the prefix is reachable in the source level, i.e., the prefix only gets propagated from a level where it's reachable. That reachability requirement MUST NOT be applied for UPAs, because they're propagating *un*reachability 🙃

IS-IS L1/L2 routers may wish to advertise received UPAs into other areas (upwards and/or downwards). When propagating UPAs, the original metric value MUST be preserved. The cost to reach the originator of the received UPA MUST NOT be considered when readvertising the UPA. 💅

4. Supporting UPA in OSPF 🧚

[RFC2328] Appendix B defines this architectural constant for OSPFv2:

LSInfinity
   The metric value indicating that the destination described by
   an LSA is unreachable.  Used in summary-LSAs and AS-external-
   LSAs as an alternative to premature aging (see Section 14.1).
   It is defined to be the 24-bit binary value of all ones:
   0xffffff.

Appendix B of [RFC5340] says:

Architectural constants for the OSPF protocol are defined in Appendix B of [OSPFV2].

which basically means those same constants apply to OSPFv3 too 🌸

[RFC2328], Section 14.1 also uses LSInfinity as a way to signal loss of prefix reachability:

Premature aging can also be used when, for example, one of the router's previously advertised external routes is no longer reachable. In this circumstance, the router can flush its AS-external-LSA from the routing domain via premature aging. This procedure is preferable to the alternative, which is to originate a new LSA for the destination specifying a metric of LSInfinity.

also, the NU-bit is defined for OSPFv3 [RFC5340]. Prefixes with the NU-bit set in their PrefixOptions field are not included in the routing calculation. 🙈

UPA in OSPFv2 is supported for prefix reachability advertised via OSPFv2 Summary-LSA [RFC2328], AS-external-LSAs [RFC2328], Not-So-Stubby Area (NSSA) AS-external-LSA [RFC3101], and OSPFv2 IP Algorithm Prefix Reachability Sub-TLV [RFC9502].

UPA in OSPFv3 is supported for prefix reachability advertised via OSPFv3 E-Inter-Area-Prefix-LSA [RFC8362], E-AS-External-LSA [RFC8362], E-Type-7-LSA [RFC8362], and SRv6 Locator LSA [RFC9513].

For prefix reachability advertised via Inter-Area-Prefix-LSA [RFC5340], AS-External-LSA [RFC5340], NSSA-LSA [RFC5340], UPA is signaled using their corresponding extended LSAs. This requires support of the OSPFv3 Extended LSAs in a sparse mode as specified in Section 6.2 of [RFC8362]. ✨

4.1. Advertisement of UPA in OSPF

if an ABR or ASBR advertises UPA in an advertisement of an inter-area or external prefix inside OSPFv2 or OSPFv3, then it MUST set the age to a value lower than MaxAge and set the metric to LSInfinity. 💖

UPA flooding inside the area follows the existing standard procedures defined by OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. 🌈

4.2. Signaling UPA in OSPF

a prefix can be advertised (in OSPFv2) with the LSInfinity metric, or (in OSPFv3) with the NU-bit set in PrefixOptions, for various reasons. OSPFv2 and OSPFv3 already specify how to treat the LSInfinity metric and the NU-bit, but explicit signaling is still needed to tell UPA apart from other LSInfinity or NU-bit scenarios 🫶

OSPFv2 and OSPFv3 Prefix Extended Flags Sub-TLVs been defined in [RFC9792] for advertising additional prefix attribute flags in OSPFv2 and OSPFv3.

two new bits in the Prefix Attribute Flags Sub-TLV are defined:

  • U-Flag: Unreachable Prefix Flag (bit 0). When set, it indicates that the prefix is unreachable.
  • UP-Flag: Unreachable Planned Prefix Flag (bit 1). When set, this flag indicates that the prefix is unreachable due to a planned event (e.g., planned maintenance).

the originating node MUST NOT set the UP-flag without setting the U-flag.

the receiving node MUST ignore the UP-flag in the advertisement if the U-flag is not set.

4.2.1. Signaling UPA in OSPFv2

The OSPFv2 Prefix Extended Flags Sub-TLV [RFC9792] is a sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684].

the prefix advertised with U-Flag or UP-Flag MUST have the metric set to a value LSInfinity. If the prefix metric is not equal to LSInfinity, both of these flags MUST be ignored. Therefore, for the prefixes in default algorithm 0 that are advertised with U-Flag, or Up-Flag, it is REQUIRED to advertise the unreachable prefix in the base OSPFv2 LSA, e.g., e.g., OSPFv2 Summary-LSA [RFC2328], or AS-external-LSAs [RFC2328], or NSSA AS-external LSA [RFC3101]. 🎀

4.2.2. Signaling UPA in OSPFv3

OSPFv3 Prefix Extended Flags Sub-TLV is defined as a sub-TLV of the following OSPFv3 TLVs that are defined in [RFC8362]:

  • Intra-Area-Prefix TLV
  • Inter-Area-Prefix TLV
  • External-Prefix TLV

the prefix advertised with U-Flag or UP-Flag MUST have the metric set to a value LSInfinity. For default algorithm 0 prefixes, the LSInfinity MUST be set in the parent TLV. For IP Algorithm Prefixes [RFC9502], the LSInfinity MUST be set in OSPFv3 IP Algorithm Prefix Reachability sub-TLV. If the prefix metric is not equal to LSInfinity, both of these flags MUST be ignored.

the prefix advertised with U-Flag or UP-Flag MUST have the NU-bit set in the PrefixOptions of the parent TLV. If the NU-bit in PrefixOptions of the parent TLV is not set, both of these flags MUST be ignored. 🦋

4.3. Propagation of UPA in OSPF

OSPF ABRs are responsible for passing UPA advertisements into other areas, so they need to recognize them 💜 If they don't, UPA never makes it to routers in the remote areas.

advertising prefix reachability between OSPF areas assumes reachability in a source area. That reachability requirement MUST NOT be applied for UPAs, because they're propagating *un*reachability 🙃

OSPF ABRs or ASBRs MAY advertise received UPAs between connected areas or domains. When doing so, the original LSInfinity metric value in UPA MUST be preserved. The cost to reach the originator of the received UPA MUST NOT be considered when readvertising the UPA to connected areas. 👑

5. Processing of the UPA 💅

processing received UPAs is optional and SHOULD be controlled by the configuration at the receiver. The receiver itself, based on its configuration, decides what the UPA will be used for and what applications, if any, will be notified when UPA is received. Usage of the UPA at the receiver is outside the scope of this document. 🫶

as an example, UPA may be used to trigger BGP PIC Edge at the receiving router [BGP-PIC] 🌈

applications using the UPA cannot use the absence of the UPA to infer that the reachability of the prefix is back. They must rely on their own mechanisms to verify the reachability of the remote endpoints. ✨

6. Area and Domain Partition ✨

okay so UPA is NOT here to fix area or domain partitions 🙈 bestie, when an area or domain splits in two, multiple ABRs or ASBRs can all advertise the same summary, but each one can only reach part of the summarized prefix 💀. so depending on which ABR or ASBR your traffic walks into the partitioned area through, it could get dropped or it could make it to its destination 😭

the good news is that UPA doesn't make an area partition any worse 🫶 when a partition happens, each ABR or ASBR generates UPAs for the destinations it lost reachability to, locally. as the UPA travels to the nodes outside the partitioned area, those nodes might switch to a different egress node for the traffic, if one exists 🦋 if that alternative egress node is outside the partitioned area, the traffic gets restored, periodt 👑

if the alternative egress node is inside the partitioned area and it's covered by the summary, then the traffic gets dropped whenever it enters the partitioned area through an ABR or ASBR that can't reach that node 💅 so yeah, that ends up acting pretty much the same as it would without UPA, no cap 🌸

and all of this applies to a domain partition too ✨

7. IANA Considerations 🎀

7.1. IS-IS Prefix Attribute Flags Sub-TLV 🌈

this document adds two new bits to the "IS-IS Bit Values for Prefix Attribute Flags Sub-TLV" registry 💜

Bit #:  5
Name:  U-Flag
Reference:  RFC 9929 (Section 3.2)

Bit #:  6
Name:  UP-Flag
Reference:  RFC 9929 (Section 3.2)

7.2. OSPFv2 and OSPFv3 Prefix Extended Flags 🦋

this document also adds two new bits, this time to the "OSPFv2 Prefix Extended Flags" and "OSPFv3 Prefix Extended Flags" registries 🧚

Bit:  0
Description:  U-Flag
Reference:  RFC 9929 (Section 4.2)

Bit:  1
Description:  UP-Flag
Reference:  RFC 9929 (Section 4.2)

8. Security Considerations 🔥

okay bestie, serious moment incoming 😭🫶 using UPAs opens the door to an attacker injecting a false UPA that looks totally legit 💀 BUT the risk of that happening is no greater than the risk we already have today of an attacker injecting any other kind of false advertisement, so it's not a brand-new danger, just the same old villain in a new outfit 🙈

you can lower the risk by using the existing security extensions, which are:

⚠️ these are the security extensions that help reduce the risk. use them 💅

9. References 📚

9.1. Normative References 💖

[ISO10589] ISO/IEC, "Information technology -- Telecommunications and
           information exchange between systems -- Intermediate
           System to Intermediate System intra-domain routeing
           information exchange protocol for use in conjunction with
           the protocol for providing the connectionless-mode network
           service (ISO 8473)", ISO/IEC 10589:2002, November 2002,
           <https://www.iso.org/en/contents/data/
           standard/03/09/30932.html>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
           DOI 10.17487/RFC2328, April 1998,
           <https://www.rfc-editor.org/info/rfc2328>.

[RFC3101]  Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
           RFC 3101, DOI 10.17487/RFC3101, January 2003,
           <https://www.rfc-editor.org/info/rfc3101>.

[RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
           for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
           <https://www.rfc-editor.org/info/rfc4552>.

[RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
           Topology (MT) Routing in Intermediate System to
           Intermediate Systems (IS-ISs)", RFC 5120,
           DOI 10.17487/RFC5120, February 2008,
           <https://www.rfc-editor.org/info/rfc5120>.

[RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
           Authentication", RFC 5304, DOI 10.17487/RFC5304, October
           2008, <https://www.rfc-editor.org/info/rfc5304>.

[RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
           Engineering", RFC 5305, DOI 10.17487/RFC5305, October
           2008, <https://www.rfc-editor.org/info/rfc5305>.

[RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
           DOI 10.17487/RFC5308, October 2008,
           <https://www.rfc-editor.org/info/rfc5308>.

[RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
           and M. Fanto, "IS-IS Generic Cryptographic
           Authentication", RFC 5310, DOI 10.17487/RFC5310, February
           2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
           for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
           <https://www.rfc-editor.org/info/rfc5340>.

[RFC6987]  Retana, A., Nguyen, L., Zinin, A., White, R., and D.
           McPherson, "OSPF Stub Router Advertisement", RFC 6987,
           DOI 10.17487/RFC6987, September 2013,
           <https://www.rfc-editor.org/info/rfc6987>.

[RFC7370]  Ginsberg, L., "Updates to the IS-IS TLV Codepoints
           Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014,
           <https://www.rfc-editor.org/info/rfc7370>.

[RFC7474]  Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
           "Security Extension for OSPFv2 When Using Manual Key
           Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
           <https://www.rfc-editor.org/info/rfc7474>.

[RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
           Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
           Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
           2015, <https://www.rfc-editor.org/info/rfc7684>.

[RFC7794]  Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
           U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
           and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
           March 2016, <https://www.rfc-editor.org/info/rfc7794>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8362]  Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
           F. Baker, "OSPFv3 Link State Advertisement (LSA)
           Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
           2018, <https://www.rfc-editor.org/info/rfc8362>.

[RFC8770]  Patel, K., Pillay-Esnault, P., Bhardwaj, M., and S.
           Bayraktar, "Host Router Support for OSPFv2", RFC 8770,
           DOI 10.17487/RFC8770, April 2020,
           <https://www.rfc-editor.org/info/rfc8770>.

[RFC9352]  Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
           and Z. Hu, "IS-IS Extensions to Support Segment Routing
           over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
           February 2023, <https://www.rfc-editor.org/info/rfc9352>.

[RFC9502]  Britto, W., Hegde, S., Kaneriya, P., Shetty, R., Bonica,
           R., and P. Psenak, "IGP Flexible Algorithm in IP
           Networks", RFC 9502, DOI 10.17487/RFC9502, November 2023,
           <https://www.rfc-editor.org/info/rfc9502>.

[RFC9513]  Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak,
           "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)",
           RFC 9513, DOI 10.17487/RFC9513, December 2023,
           <https://www.rfc-editor.org/info/rfc9513>.

[RFC9792]  Chen, R., Zhao, D., Psenak, P., Talaulikar, K., and L.
           Gong, "Prefix Flag Extension for OSPFv2 and OSPFv3",
           RFC 9792, DOI 10.17487/RFC9792, June 2025,
           <https://www.rfc-editor.org/info/rfc9792>.

9.2. Informative References 🌸

[BGP-PIC]  Bashandy, A., Ed., Filsfils, C., Mohapatra, P., and Y. Qu,
           "BGP Prefix Independent Convergence", Work in Progress,
           Internet-Draft, draft-ietf-rtgwg-bgp-pic-23, 15 February
           2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
           rtgwg-bgp-pic-23>.

Acknowledgements 🫶

the authors would like to thank Kamran Raza, Michael MacKenzie, and Luay Jalil for their contributions and support of the overall solution proposed in this document 💖

Contributors 🧚

the following people contributed to the content of this document and should be considered coauthors ✨

Stephane Litkowski
Email: slitkows@cisco.com


Amit Dhamija
Email: amitd@arrcus.com


Gunter Van de Velde
Email: gunter.van_de_velde@nokia.com

the following people contributed to the problem statement and the solution requirement discussion 💜

Aijun Wang
Email: wangaj3@chinatelecom.cn


Zhibo Hu
Email: huzhibo@huawei.com

Authors' Addresses 💅

Peter Psenak (editor)
Cisco Systems
Pribinova Street 10
Bratislava 81109
Slovakia
Email: ppsenak@cisco.com


Clarence Filsfils
Cisco Systems
Brussels
Belgium
Email: cfilsfil@cisco.com


Daniel Voyer
Cisco Systems
Email: davoyer@cisco.com


Shraddha Hegde
HPE
Email: shraddha.hegde@hpe.com


Gyan Mishra
Verizon Inc.
Email: hayabusagsm@gmail.com
📦 where this page comes from