RFC 10041

Advertising Unreachable Links in OSPF

📅 published September 2026, from ietf

okay bestie, let's do the paperwork first 📋 This is an IETF (Internet Engineering Task Force) doc, and it's a Standards Track one, dated September 2026 ✨. The ISSN is 2070-1721 🌸.

It was written by L. Gong and W. Cheng from China Mobile, C. Lin from New H3C Technologies, A. Lindem from Arrcus, Inc., and R. Chen from ZTE Corporation 🫶. It updates RFC 5443, RFC 6987, RFC 8379, and RFC 8770 💅, and we'll get into exactly what that means soon.

Abstract ✨

okay so OSPF Router Link State Advertisements (LSAs) have these fixed-format encodings, and they always include the advertised links in the default Shortest Path First (SPF) computation 🙈. For non-default SPF computations, like the Flexible Algorithms in RFC 9350, advertised OSPF links end up in the default SPF computation even when nobody meant for that to happen 💀.

To advertise a link without using it in the base SPF calculation, you use the metric LSLinkInfinity (0xffff) to say the link is unreachable. If all OSPF routers in an OSPF area support this and have advertised the capability through an area-scoped OSPF Router Information LSA, then links advertised with a metric of LSLinkInfinity are considered unreachable 🦋.

MaxReachableLinkMetric (0xfffe) is defined to provide backward compatible reachability in specifications that previously specified advertisement of MaxLinkMetric (0xffff). This document updates RFC 5443, RFC 6987, RFC 8379, and RFC 8770 with respect to the advertisement of MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff) 🌈.

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. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

For info on the current status of this document, any errata, and how to give feedback on it, check https://www.rfc-editor.org/info/rfc10041 🧚

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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents 🗺️

1.  Introduction
  1.1.  Requirements Language
2.  Use Cases
  2.1.  Case 1: Traffic Engineering
  2.2.  Case 2: Flexible Algorithm
3.  LSLinkInfinity-Based Solution
  3.1.  Unreachable Link Advertisement
  3.2.  Unreachable Link Backward Compatibility
  3.3.  Stub Router Advertisement Backward Compatibility
  3.4.  Label Distribution Protocol (LDP) IGP Synchronization
        Backward Compatibility
  3.5.  OSPF Graceful Link Shutdown Backward Compatibility
4.  Operational Considerations
  4.1.  Configuration Parameters
  4.2.  YANG Data Model
    4.2.1.  Tree for OSPF Functional Capability
    4.2.2.  Tree for OSPF Advertising Unreachable Links
    4.2.3.  IANA Module for OSPF Functional Capability Bits
    4.2.4.  YANG Module for OSPF Functional Capability
    4.2.5.  YANG Module for OSPF Advertising Unreachable Links
5.  Security Considerations
6.  IANA Considerations
  6.1.  Registering OSPF Router Functional Capability Bits
  6.2.  Registering YANG Modules
  6.3.  IANA Module for OSPF Functional Capability Bits
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction 🌸

OSPF Router LSAs use fixed-format encodings, and they always bring the advertised links along into the default SPF computation. For example, a link might be needed for Traffic Engineering (TE) paths but not meant for hop-by-hop routing. Another example is an OSPF link used only by a Flexible Algorithm [RFC9350] but kept out of the default algorithm 💖

To advertise these links as unreachable, you use the metric LSLinkInfinity (0xffff) to say the link is unreachable. OSPF routers that support this specification will exclude the link from SPF calculations (subject to backward-compatibility, refer to Section 3.2) 🦋

Stub Router Advertisement [RFC6987] defines MaxLinkMetric (0xffff) to indicate that a router-LSA link should only be used for transit IP traffic as a last resort 🙃 When an OSPF router supports the Unreachable Link capability defined in this document, OSPF stub router links are advertised as MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff). This document updates [RFC6987] and [RFC8770] with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.

Similarly, Label Distribution Protocol (LDP) IGP Synchronization [RFC5443] specifies OSPF advertisement of MaxLinkMetric (0xffff) to indicate that while the OSPF adjacency is in FULL state, LDP has not been synchronized between the two neighbors and transit traffic is discouraged 😬 This document updates [RFC5443] with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.

Finally, OSPF Graceful Link Shutdown [RFC8379] specifies OSPF advertisement of MaxLinkMetric (0xffff) to indicate that the OSPF link will be taken out of service and transit traffic is discouraged 🫠 This document updates [RFC8379] with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.

1.1. Requirements Language 🤓

okay so here are the key words. 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. Use Cases 💅

2.1. Case 1: Traffic Engineering 🛣️

A network topology is shown in Figure 1. The OSPF link between Node A and E is only to be used for Traffic Engineering. Since the OSPF link is advertised by default, it will be included in the base SPF calculation for the default topology and may be used for hop-by-hop routing in the default topology 👀

                              TE Link
                             ---------
                            /         \
                           /           \
                          A------C------E
                          |      |      |
                          |      |      |
                          |      |      |
                          B------D------F

Figure 1: Network Topology

2.2. Case 2: Flexible Algorithm 🎀

A network topology is shown in Figure 2. The links between Nodes A and B and between C and D are to be used exclusively for a Flex-Algorithm [RFC9350] devoted to specific traffic. These links have an Extended Administrative Group (EAG) [RFC7308] attribute specifying the "Red" color 🔴

              ******
             A------C------E
             |*     |*     |
             |*     |*     |        ******: "Red" link
             |*     |*     |
             B------D------F
              ******

Figure 2: Network Topology

Flex-Algorithm 128 is enabled on Nodes A, B, C, and D, with an EAG rule including "Red", and the Metric-Type is designated to be a type other than the OSPF metric. OSPF will compute routes for Flex-Algorithm 128 using these links. The topology associated with Flex-Algorithm 128 is shown in Figure 3 ✨

                             A******C
                             *      *
                             *      *
                             *      *
                             B******D

Figure 3: Topology of Flex-Algorithm 128

The "Red" links are used by the Flex-Algorithm 128 calculation. However, these "Red" links are also included in the default algorithm calculation [RFC9350] since they are reachable 🤯 Note that links used by the default algorithm are omitted from Figure 3 for clarity.

If the OSPF metrics for all the "Red" links are advertised as unreachable, they will be excluded from the default SPF calculation as shown in Figure 4. This allows the "Red" links from A to B and C to D to be used exclusively by the Flex-Algorithm 128 calculation 🫶

                          A------C------E
                                        |
                                        |
                                        |
                          B------D------F

Figure 4: Base SPF Topology Excluding Unreachable Links

3. LSLinkInfinity-Based Solution 🦋

This document specifies that if the OSPF metric of a link is advertised as LSLinkInfinity (0xffff), it MUST NOT be considered during the associated SPF computation. This applies to both the Flex-Algorithm SPF [RFC9350] and the base SPF as long as LSLinkInfinity is specified for the OSPF metric 🔥

While the interpretation of LSLinkInfinity is only required in the base topology as other topologies are optional [RFC4915], OSPF routers supporting this specification MUST consistently interpret LSLinkInfinity as unreachable during the associated SPF computation. Interpretation of LSLinkInfinity as unreachable is also applicable to Flex-Algorithm SPF computations [RFC9350] that use the OSPF link metric 🌸

An OSPF metric with LSLinkInfinity indicating a link is unreachable is applicable to the following TLVs/LSAs:

okay so, before this spec, OSPF treated any link with an advertised metric of LSLinkInfinity as reachable 🫠 [RFC2328]. which means if only some routers get the upgrade, things can go sideways fast 💀 partial deployment could cause routing loops because the routers are reading LSLinkInfinity differently, bestie 😭

check out Figure 5 🦋 link D-F is advertised with LSLinkInfinity (65535/0xffff). Router B treats it as unreachable, but Router A doesn't. so A thinks D-F is totally fine and its shortest path to F is A->B->D->F. meanwhile B thinks D-F is dead and its shortest path to F is B->A->C->E->F. so A sends the packets to B, B sends them right back to A, and boom, routing loop 🌀

   40000  40000      Traffic: A->F
 A------C------E       A considers link D-F as reachable
 |             |         A's shortest path to F: A->B->D->F
5|             |5      B considers link D-F as unreachable
 |             |         B's shortest path to F: B->A->C->E->F
 B------D------F
     5    65535

Figure 5: Inconsistent LSLinkInfinity Interpretation Causing Loops

to fix the backward compat issue 🎀 routers that support LSLinkInfinity for unreachable links are supposed to advertise an area-scoped Router Information LSA with a Router Functional Capabilities TLV [RFC7770] that includes the Router Functional Capability Bit below. the value of that bit is controlled by config, as explained in Section 4.1.

+=====+==================+
| Bit | Capabilities     |
+=====+==================+
| 0   | Unreachable Link |
+-----+------------------+

Table 1

here's the big rule 👑 OSPF routers MUST NOT treat links with an advertised metric of LSLinkInfinity as unreachable unless all routers in the OSPF area (aka all routers with router-LSAs in the area Link State Database (LSDB)) have advertised this capability in an OSPFv2 Router Information Opaque LSA or an OSPFv3 Router Information LSA. if everyone in the area has advertised it, then links with an advertised metric of LSLinkInfinity MUST be treated as unreachable. and when the number of routers in the area not supporting the Unreachable Link capability changes to 0 or from 0 to greater than 0, all OSPF routers in the area MUST recalculate their routes ✨

in normal life, an area-scoped OSPF Router Information LSA might not reach every router in the area right away 🐢 for example, if a new router that doesn't support the Unreachable Link capability joins an area where everyone else does, it can take a little while for the OSPF Router Information LSA to spread around. during that time, routers will slowly notice there's a non-supporting router and go back to treating links with MaxLinkMetric as reachable. that mismatch in how MaxLinkMetric is read between routers can cause transient routing loops, and that's the tea ☕

3.3. Stub Router Advertisement Backward Compatibility

Stub Router Advertisement [RFC6987] defines MaxLinkMetric (0xffff) to say a router-LSA link should not be used for transit traffic 🚫

when an OSPF router supports the Unreachable Link capability from this document, the OSPF stub router MaxLinkMetric (0xffff) MUST be updated to MaxReachableLinkMetric (0xfffe) 💖 this document updates [RFC6987] and [RFC8770] with respect to advertising MaxReachableLinkMetric instead of MaxLinkMetric 🎀

and if an OSPF router supports both OSPF Stub Router Advertisement [RFC6987] and the Unreachable Link capability from this document, it MUST support advertising all of its non-stub links with a link cost of MaxReachableLinkMetric (0xfffe) 🫶 since MaxLinkMetric won't be used to mark a link as unreachable unless every OSPF router in the area supports this spec (see Section 3.2), all routers in the area will also support using MaxReachableLinkMetric to discourage transit use of stub router links. if there are any OSPF routers in the area that don't support the Unreachable Link capability, then all OSPF routers in the area will treat links advertised with a cost of MaxLinkMetric as reachable (Section 3.2) 🌸

3.4. Label Distribution Protocol (LDP) IGP Synchronization Backward Compatibility

LDP IGP Synchronization [RFC5443] specifies OSPF advertisement of MaxLinkMetric (0xffff) to indicate that while the OSPF adjacency is in FULL state, LDP hasn't synced between the two neighbors yet, and transit IP traffic is discouraged 🙈 when an OSPF router supports the Unreachable Link capability from this document, using OSPF MaxLinkMetric (0xffff) to discourage use of the link until LDP is "fully operational" MUST be updated to MaxReachableLinkMetric (0xfffe) 💅 it's important to keep the link in the topology so IP traffic can still use it as a last resort, in case of LDP packets between OSPF router loopback addresses or a network failure 🧚 this document updates [RFC5443] with respect to advertising MaxReachableLinkMetric instead of MaxLinkMetric 🦋

OSPF Graceful Link [RFC8379] specifies OSPF advertisement of MaxLinkMetric (0xffff) to show that the link is about to be taken down and transit traffic is discouraged 🚧 when an OSPF router supports the Unreachable Link capability from this document, using OSPF MaxLinkMetric (0xffff) to discourage use of a link before it's taken out of service MUST be updated to MaxReachableLinkMetric (0xfffe) 🍓 same vibes as before: keep the link in the topology so IP traffic can use it as a last resort before a planned shutdown ✨ this document updates [RFC8379] with respect to advertising MaxReachableLinkMetric instead of MaxLinkMetric 💜

4. Operational Considerations 🎀

4.1. Configuration Parameters

okay, config time 🛠️ support for the Unreachable Link capability MUST be configurable. the default MUST be to not advertise the capability, which means the functional capability in the area-scoped OSPF Router Information LSA is false 🙅‍♀️

sometimes operators still want links with maximum metric (0xffff) to be treated as reachable 🌈 for example, when link costs are auto-computed based on the inverse of the link's bandwidth and the network has a mix of low-speed and high-speed links, the math can land on the maximum metric 🤯 so, implementations that support this document and do auto-costing MUST limit the maximum computed cost to MaxReachableLinkMetric (0xfffe) 🔥 an example of auto-costing would be automatically setting the link metric to be inversely proportional to link bandwidth (check the auto-cost feature in the "ietf-ospf" module [RFC9129]) 💅

4.2. YANG Data Model

this section defines three YANG [RFC7950] modules 🧚 the "iana-ospf-functional-cap-bits" module defines the identities for OSPF Router Functional Capabilities, matching the "OSPF Router Functional Capability Bits" IANA registry [IANA-OSPF-FC-Bits]. the "ietf-ospf-functional-capability" and "ietf-ospf-unreachable-links" modules can be used to configure and manage the use of OSPF LSLinkInfinity for unreachable links as defined in this document. they augment the OSPF YANG data model [RFC9129] and the YANG data model for Routing Management [RFC8349] 💖

this document uses the graphical representation of data models per [RFC8340] 🦋

4.2.1. Tree for OSPF Functional Capability

here's the tree diagram for the OSPF Functional Capability module 🌳

module: ietf-ospf-functional-capability
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas
            /ospf:area/ospf:interfaces/ospf:interface
            /ospf:database/ospf:link-scope-lsa-type
            /ospf:link-scope-lsas/ospf:link-scope-lsa/ospf:version
            /ospf:ospfv2/ospf:ospfv2/ospf:body/ospf:opaque
            /ospf:ri-opaque/ospf:router-capabilities-tlv:
    +--ro router-functional-capabilities
       +--ro functional-capability*   identityref
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas
            /ospf:area/ospf:database/ospf:area-scope-lsa-type
            /ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
            /ospf:ospfv2/ospf:ospfv2/ospf:body/ospf:opaque
            /ospf:ri-opaque/ospf:router-capabilities-tlv:
    +--ro router-functional-capabilities
       +--ro functional-capability*   identityref
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:database
            /ospf:as-scope-lsa-type/ospf:as-scope-lsas
            /ospf:as-scope-lsa/ospf:version/ospf:ospfv2
            /ospf:ospfv2/ospf:body/ospf:opaque/ospf:ri-opaque
            /ospf:router-capabilities-tlv:
    +--ro router-functional-capabilities
       +--ro functional-capability*   identityref
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas
            /ospf:area/ospf:interfaces/ospf:interface
            /ospf:database/ospf:link-scope-lsa-type
            /ospf:link-scope-lsas/ospf:link-scope-lsa/ospf:version
            /ospf:ospfv3/ospf:ospfv3/ospf:body
            /ospf:router-information/ospf:router-capabilities-tlv:
    +--ro router-functional-capabilities
       +--ro functional-capability*   identityref
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:database
            /ospf:as-scope-lsa-type/ospf:as-scope-lsas
            /ospf:as-scope-lsa/ospf:version/ospf:ospfv3
            /ospf:ospfv3/ospf:body/ospf:router-information
            /ospf:router-capabilities-tlv:
    +--ro router-functional-capabilities
       +--ro functional-capability*   identityref
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas
            /ospf:area/ospf:database/ospf:area-scope-lsa-type
            /ospf:area-scope-lsas/ospf:area-scope-lsa/ospf:version
            /ospf:ospfv3/ospf:ospfv3/ospf:body
            /ospf:router-information/ospf:router-capabilities-tlv:
    +--ro router-functional-capabilities
       +--ro functional-capability*   identityref

and last but not least, the tree diagram for the OSPF Advertising Unreachable Links module ✨

module: ietf-ospf-unreachable-links

  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas
            /ospf:area:
    +--rw unreachable-link-advertisement
       +--rw enabled?   boolean
  augment /rt:routing/rt:control-plane-protocols
            /rt:control-plane-protocol/ospf:ospf/ospf:areas
            /ospf:area/ospf:interfaces/ospf:interface:
    +--rw advertise-unreachable-link?   boolean

4.2.3. IANA Module for OSPF Functional Capability Bits ✨

okay so IANA made a registry called "OSPF Router Functional Capability Bits" 🎀 and it lives inside the "Open Shortest Path First (OSPF) Parameters" registry group 🧚. Its whole job is to identify OSPF Router Functional Capabilities 💅

This document defines the very first version of the IANA-maintained "iana-ospf-functional-cap-bits" module, and it basically mirrors that registry [IANA-OSPF-FC-Bits] 🦋 Whenever the registry changes, the module gets updated too, so they stay in sync, bestie 🫶 The newest version of this YANG module is over in the "YANG Module Names” registry <https://www.iana.org/assignments/yang-parameters> 🌸

4.2.4. YANG Module for OSPF Functional Capability 👑

Here's the YANG module for OSPF Functional Capability, and it is giving everything 😭🔥

<CODE BEGINS> file "ietf-ospf-functional-capability@2026-09-16.yang"
module ietf-ospf-functional-capability {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:"
          + "ietf-ospf-functional-capability";
  prefix ospf-fc;

  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";
  }
  import iana-ospf-functional-cap-bits {
    prefix iana-ospf-fc-bits;
    reference
      "https://www.iana.org/assignments/ospf-parameters"
    + "#router-functional-capability";
  }

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

     Author:   Yingzhen Qu
               <mailto:yqu@futurewei.com>
     Author:   Acee Lindem
               <mailto:acee.ietf@gmail.com>
     Author:   Liyan Gong
               <mailto:gongliyan@chinamobile.com>
     Author:   Weiqiang Cheng
               <mailto:chengweiqiang@chinamobile.com>
     Author:   Changwang Lin
               <mailto:linchangwang.04414@h3c.com>
     Author:   Ran Chen
               <mailto:chen.ran@zte.com.cn>";
  description
    "This YANG module defines the operational state for
     Functional Capability in OSPF as defined in RFC 7770.

     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 10041; see
     the RFC itself for full legal notices.";

  revision 2026-09-16 {
    description
      "Initial revision.";
    reference
      "RFC 10041: Advertising Unreachable Links in OSPF";
  }

  grouping router-functional-capabilities {
    description
      "Grouping for OSPF router capabilities TLV types.";
    reference
      "RFC 7770: Extensions to OSPF for Advertising Optional
                 Router Capabilities";
    container router-functional-capabilities {
      leaf-list functional-capability {
        type identityref {
          base iana-ospf-fc-bits:functional-capability;
        }
        description
          "List of Router Functional Capabilities.  This list
           contains the identities for functional capabilities
           supported by the router.";
      }
      description
        "OSPF Router Functional identity definitions.";
    }
  }

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol/"
        + "ospf:ospf/ospf:areas/ospf:area/"
        + "ospf:interfaces/ospf:interface/ospf:database/"
        + "ospf:link-scope-lsa-type/ospf:link-scope-lsas/"
        + "ospf:link-scope-lsa/ospf:version/ospf:ospfv2/"
        + "ospf:ospfv2/ospf:body/ospf:opaque/ospf:ri-opaque/"
        + "ospf:router-capabilities-tlv" {
    when "derived-from-or-self(/rt:routing/"
       + "rt:control-plane-protocols/"
       + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" {
      description
        "This augmentation is only valid for OSPFv2.";
    }
    description
      "OSPFv2 Opaque Link-Scoped Router-Information LSA Router
       Functional Capabilities.";
    uses router-functional-capabilities;
    reference
      "RFC 7770: Extensions to OSPF for Advertising Optional
                 Router Capabilities";
  }

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol/"
        + "ospf:ospf/ospf:areas/"
        + "ospf:area/ospf:database/"
        + "ospf:area-scope-lsa-type/ospf:area-scope-lsas/"
        + "ospf:area-scope-lsa/ospf:version/ospf:ospfv2/"
        + "ospf:ospfv2/ospf:body/ospf:opaque/"
        + "ospf:ri-opaque/ospf:router-capabilities-tlv" {
    when "derived-from-or-self(/rt:routing/"
       + "rt:control-plane-protocols/"
       + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" {
      description
        "This augmentation is only valid for OSPFv2.";
    }
    description
      "OSPFv2 Opaque Area-Scoped Router-Information LSA Router
       Functional Capabilities.";
    uses router-functional-capabilities;
    reference
      "RFC 7770: Extensions to OSPF for Advertising Optional
                 Router Capabilities";
  }

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol/"
        + "ospf:ospf/ospf:database/"
        + "ospf:as-scope-lsa-type/ospf:as-scope-lsas/"
        + "ospf:as-scope-lsa/ospf:version/ospf:ospfv2/"
        + "ospf:ospfv2/ospf:body/ospf:opaque/"
        + "ospf:ri-opaque/ospf:router-capabilities-tlv" {
    when "derived-from-or-self(/rt:routing/"
       + "rt:control-plane-protocols/"
       + "rt:control-plane-protocol/rt:type, 'ospf:ospfv2')" {
      description
        "This augmentation is only valid for OSPFv2.";
    }
    description
      "OSPFv2 Opaque AS-Scoped Router-Information LSA Router
       Functional Capabilities.";
    uses router-functional-capabilities;
    reference
      "RFC 7770: Extensions to OSPF for Advertising Optional
                 Router Capabilities";
  }

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol/"
        + "ospf:ospf/ospf:areas/ospf:area/"
        + "ospf:interfaces/ospf:interface/ospf:database/"
        + "ospf:link-scope-lsa-type/ospf:link-scope-lsas/"
        + "ospf:link-scope-lsa/ospf:version/ospf:ospfv3/"
        + "ospf:ospfv3/ospf:body/ospf:router-information/"
        + "ospf:router-capabilities-tlv" {
    when "derived-from-or-self(/rt:routing/"
       + "rt:control-plane-protocols/"
       + "rt:control-plane-protocol/rt:type, 'ospf:ospfv3')" {
      description
        "This augmentation is only valid for OSPFv3.";
    }
    description
      "OSPFv3 Link-Scoped Router-Information LSA Router
       Functional Capabilities.";
    uses router-functional-capabilities;
    reference
      "RFC 7770: Extensions to OSPF for Advertising Optional
                 Router Capabilities";
  }

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol/"
        + "ospf:ospf/ospf:database/"
        + "ospf:as-scope-lsa-type/ospf:as-scope-lsas/"
        + "ospf:as-scope-lsa/ospf:version/ospf:ospfv3/"
        + "ospf:ospfv3/ospf:body/ospf:router-information/"
        + "ospf:router-capabilities-tlv" {
    when "derived-from-or-self(/rt:routing/"
       + "rt:control-plane-protocols/"
       + "rt:control-plane-protocol/rt:type, 'ospf:ospfv3')" {
      description
        "This augmentation is only valid for OSPFv3.";
    }
    description
      "OSPFv3 AS-Scoped Router-Information LSA Router
       Functional Capabilities.";
    uses router-functional-capabilities;
    reference
      "RFC 7770: Extensions to OSPF for Advertising Optional
                 Router Capabilities";
  }

  augment "/rt:routing/"
        + "rt:control-plane-protocols/rt:control-plane-protocol/"
        + "ospf:ospf/ospf:areas/"
        + "ospf:area/ospf:database/"
        + "ospf:area-scope-lsa-type/ospf:area-scope-lsas/"
        + "ospf:area-scope-lsa/ospf:version/ospf:ospfv3/"
        + "ospf:ospfv3/ospf:body/ospf:router-information/"
        + "ospf:router-capabilities-tlv" {
    when "derived-from-or-self(/rt:routing/"
       + "rt:control-plane-protocols/"
       + "rt:control-plane-protocol/rt:type, 'ospf:ospfv3')" {
      description
        "This augmentation is only valid for OSPFv3.";
    }
    description
      "OSPFv3 Area-Scoped Router-Information LSA Router
       Functional Capabilities.";
    uses router-functional-capabilities;
    reference
      "RFC 7770: Extensions to OSPF for Advertising Optional
                 Router Capabilities";
  }
}
<CODE ENDS>

okay so here's the YANG module for OSPF Advertising Unreachable Links 💖 this is the actual code, so every character stays exactly as it is 🫶

<CODE BEGINS> file "ietf-ospf-unreachable-links@2026-09-16.yang"
module ietf-ospf-unreachable-links {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:"
          + "ietf-ospf-unreachable-links";
  prefix ospf-unreach-link;

  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 Link State Routing (LSR) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/lsr/>
     WG List:  <mailto:lsr@ietf.org>

     Author:   Yingzhen Qu
               <mailto:yqu@futurewei.com>
     Author:   Acee Lindem
               <mailto:acee.ietf@gmail.com>
     Author:   Liyan Gong
               <mailto:gongliyan@chinamobile.com>
     Author:   Weiqiang Cheng
               <mailto:chengweiqiang@chinamobile.com>
     Author:   Changwang Lin
               <mailto:linchangwang.04414@h3c.com>
     Author:   Ran Chen
               <mailto:chen.ran@zte.com.cn>";
  description
    "This YANG module defines the configuration and operational
     state for Advertising Unreachable Links in OSPF as defined
     in RFC 10041.

     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 10041; see
     the RFC itself for full legal notices.";

  revision 2026-09-16 {
    description
      "Initial revision.";
    reference
      "RFC 10041: Advertising Unreachable Links in OSPF";
  }

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol/ospf:ospf/"
        + "ospf:areas/ospf:area" {
    when
      "derived-from-or-self(../../../rt:type, 'ospf:ospfv2') or "
    + "derived-from-or-self(../../../rt:type, 'ospf:ospfv3')" {
      description
        "This augments the OSPF routing protocol when used.";
    }
    description
      "This augments the OSPF protocol with Unreachable Link
       advertisement.";
    container unreachable-link-advertisement {
      leaf enabled {
        type boolean;
        default "false";
        description
          "Controls the interpretation of MaxLinkMetric as
           unreachable and the advertisement of the Unreachable
           Link capability for the area.  It is enabled when set
           to true and disabled when set to false.";
      }
      description
        "OSPF Unreachable Link advertisement parameters.";
    }
  }

  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') or "
       + "derived-from(/rt:routing/rt:control-plane-protocols/"
       + "rt:control-plane-protocol/rt:type, 'ospf:ospfv3')" {
      description
        "This augments the OSPF interfaces.";
    }
    leaf advertise-unreachable-link {
      type boolean;
      must "not(../advertise-unreachable-link = 'true' and "
         + "/rt:routing/rt:control-plane-protocols/"
         + "rt:control-plane-protocol/ospf:ospf/ospf:areas/"
         + "ospf:area/"
         + "ospf-unreach-link:unreachable-link-advertisement/"
         + "ospf-unreach-link:enabled = 'false')" {
        error-message
          "The interface cannot be advertised "
        + "as unreachable (true) unless the "
        + "unreachable-link-advertisement capability is "
        + "enabled (true).";
        description
          "Ensures an interface isn't explicitly advertised as
           unreachable unless the OSPF area level capability is
           enabled.";
      }
      default "false";
      description
        "Specifies that the link should be advertised with a metric
         of MaxLinkMetric (0xffff) in the default topology.";
    }
    description
      "Augment OSPF interfaces with an option to advertise the link
       as unreachable.";
  }
}
<CODE ENDS>

5. Security Considerations 🔒

bestie, this section is serious, so read it carefully 😭 a compromised OSPF router could flip its Unreachable Link capability over and over really fast, and that would make routers in the area that support this specification (Section 3.2) keep recalculating their routes again and again 💀 so it is RECOMMENDED that routers supporting this specification also support the SPF back-off delay algorithm described in [RFC8405].

the security considerations for [RFC2328], [RFC5340], [RFC6987], and [RFC7770] apply to this protocol extension too 🦋

the "ietf-ospf-unreachable-links" YANG module and the "ietf-ospf-functional-capability" YANG module each define a data model that is meant to be accessed through YANG-based management protocols, like NETCONF [RFC6241] and RESTCONF [RFC8040]. these YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC9846], and QUIC [RFC9000]) and (2) have to use mutual authentication 🔐

the Network Configuration Access Control Model (NACM) [RFC8341] gives you the tools to restrict access for particular NETCONF or RESTCONF users, so they only get a pre-configured subset of the available NETCONF or RESTCONF protocol operations and content 💅

there are a bunch of data nodes in the "ietf-ospf-unreachable-links" YANG module that are writable, creatable, and deletable (i.e., "config true", which is the default). all writable data nodes are likely to be sensitive or vulnerable in some network environments 👀 write operations (e.g., edit-config) and delete operations on these data nodes without proper protection or authentication can seriously mess with network operations. changing these data nodes without proper protection can stop the OSPF LSLinkInfinity metric from being interpreted as unreachable, or get a link advertised as unreachable when it shouldn't be 😱 these are the writable data nodes:

   /ospf:ospf/ospf:areas/ospf:area/ospf-unreach-link:unreachable-
   link-advertisement/ospf-unreach-link:enabled

   /ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/
   ospf-unreach-link:advertise-unreachable-link

some of the readable data nodes in the "ietf-ospf-unreachable-links" YANG module may be considered sensitive or vulnerable in some network environments too 🙈 exposing the OSPF unreachable link configuration may be useful for mounting Denial-of-Service (DoS) attacks 💀 these are the readable data nodes:

   /ospf:ospf/ospf:areas/ospf:area/ospf-unreach-link:unreachable-
   link-advertisement/ospf-unreach-link:enabled

   /ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/
   ospf-unreach-link:advertise-unreachable-link

6. IANA Considerations 🌸

6.1. Registering OSPF Router Functional Capability Bits 🍓

this document defines a new bit in the "OSPF Router Functional Capability Bits" registry <https://www.iana.org/assignments/ospf-parameters>:

            +============+==================+===========+
            | Bit Number | Capability Name  | Reference |
            +============+==================+===========+
            | 0          | Unreachable Link | RFC 10041 |
            +------------+------------------+-----------+

                               Table 2

6.2. Registering YANG Modules 🧚

IANA has registered the following three new URIs in the "ns" registry within the "IETF XML Registry" [RFC3688]:

URI:  urn:ietf:params:xml:ns:yang:iana-ospf-functional-cap-bits
Registrant Contact:  The IESG.
XML:  N/A; the requested URI is an XML namespace.

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

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

IANA has also registered the following three new YANG module names in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group:

Name:  iana-ospf-functional-cap-bits
Maintained by IANA?  Y
Namespace:  urn:ietf:params:xml:ns:yang:iana-ospf-functional-cap-bits
Prefix:  iana-ospf-fc-bits
Reference:  RFC 10041

Name:  ietf-ospf-functional-capability
Maintained by IANA?  N
Namespace:
   urn:ietf:params:xml:ns:yang:ietf-ospf-functional-capability
Prefix:  ospf-fc
Reference:  RFC 10041

Name:  ietf-ospf-unreachable-links
Maintained by IANA?  N
Namespace:  urn:ietf:params:xml:ns:yang:ietf-ospf-unreachable-links
Prefix:  ospf-unreach-link
Reference:  RFC 10041

6.3. IANA Module for OSPF Functional Capability Bits 💜

this document defines the initial version of the IANA-maintained "iana-ospf-functional-cap-bits" YANG module (Section 4.2). the most recent version of the YANG module is available in the "YANG Parameters" registry [IANA-YANG-Parameters].

IANA has added the following note to the registry:

|  New values must not be directly added to the "iana-ospf-
|  functional-cap-bits" YANG module.  They must instead be added to
|  the "OSPF Router Functional Capability Bits" registry in the "Open
|  Shortest Path First (OSPF) Parameters" registry group
|  [IANA-OSPF-FC-Bits].

when a value is added to the "OSPF Router Functional Capability Bits" registry, a new "identity" statement needs to be added to the "iana-ospf-functional-cap-bits" YANG module 🎀 the name of the "identity" is the lowercase name provided in the registry with all spaces replaced with "-". the "identity" statement should have the following sub-statements defined:

  • "base": Contains 'functional-capability'.
  • "description": Contains the non-abbreviated OSPF capability bit name from the registry.
  • "reference": Replicates the reference(s) from the registry with the title of the document(s) added.

IANA has added this note to [IANA-OSPF-FC-Bits]:

|  When this registry is modified, the YANG module "iana-ospf-
|  functional-cap-bits" must be updated as defined in RFC 10041.

7. References 📚

7.1. Normative References 📚✨

Okay bestie, first up are the normative references. These are the ones you really need to read, because the spec leans on them. Look at all that OSPF goodness 🍓

   [IANA-OSPF-FC-Bits]
              IANA, "OSPF Router Functional Capability Bits",
              <https://www.iana.org/assignments/ospf-parameters>.

   [IANA-YANG-Parameters]
              IANA, "YANG Module Names",
              <https://www.iana.org/assignments/yang-parameters>.

   [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>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
              RFC 4915, DOI 10.17487/RFC4915, June 2007,
              <https://www.rfc-editor.org/info/rfc4915>.

   [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>.

   [RFC5443]  Jork, M., Atlas, A., and L. Fang, "LDP IGP
              Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
              2009, <https://www.rfc-editor.org/info/rfc5443>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [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>.

   [RFC7770]  Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
              S. Shaffer, "Extensions to OSPF for Advertising Optional
              Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
              February 2016, <https://www.rfc-editor.org/info/rfc7770>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [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>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8349]  Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
              Routing Management (NMDA Version)", RFC 8349,
              DOI 10.17487/RFC8349, March 2018,
              <https://www.rfc-editor.org/info/rfc8349>.

   [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>.

   [RFC8379]  Hegde, S., Sarkar, P., Gredler, H., Nanduri, M., and L.
              Jalil, "OSPF Graceful Link Shutdown", RFC 8379,
              DOI 10.17487/RFC8379, May 2018,
              <https://www.rfc-editor.org/info/rfc8379>.

   [RFC8405]  Decraene, B., Litkowski, S., Gredler, H., Lindem, A.,
              Francois, P., and C. Bowers, "Shortest Path First (SPF)
              Back-Off Delay Algorithm for Link-State IGPs", RFC 8405,
              DOI 10.17487/RFC8405, June 2018,
              <https://www.rfc-editor.org/info/rfc8405>.

   [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>.

   [RFC9129]  Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
              "YANG Data Model for the OSPF Protocol", RFC 9129,
              DOI 10.17487/RFC9129, October 2022,
              <https://www.rfc-editor.org/info/rfc9129>.

   [RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
              and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
              DOI 10.17487/RFC9350, February 2023,
              <https://www.rfc-editor.org/info/rfc9350>.

7.2. Informative References 🧚💜

Now the informative references. These are the extra-credit reads if you want the deeper lore, iykyk 🙈

   [RFC4252]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
              January 2006, <https://www.rfc-editor.org/info/rfc4252>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC7308]  Osborne, E., "Extended Administrative Groups in MPLS
              Traffic Engineering (MPLS-TE)", RFC 7308,
              DOI 10.17487/RFC7308, July 2014,
              <https://www.rfc-editor.org/info/rfc7308>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9846]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
              <https://www.rfc-editor.org/info/rfc9846>.

Acknowledgments 🫶

Okay, the thank-you list is my favorite part 🥹 Huge love to Yingzhen Qu for providing the YANG data models 💖

Big shoutout to Dhruv Dhody for OPS Directorate review and comments ✨ Gunter Van de Velde also reviewed and commented, and so did Mohamed Boucadair 🌸

Last but definitely not least, Mike Bishop, Mahesh Jethanadani, and Ketan Taulaulikar gave review and comments too 👑

Contributors 🌈

These lovely people contributed to this document 🦋

   Mengxiao Chen
   New H3C Technologies
   China
   Email: chen.mengxiao@h3c.com


   Yanrong Liang
   Ruijie Networks Co., Ltd.
   China
   Email: liangyanrong@ruijie.com.cn

Authors' Addresses 🎀

And here's the squad who wrote it, with all their contact details 💅

   Liyan Gong
   China Mobile
   China
   Email: gongliyan@chinamobile.com


   Weiqiang Cheng
   China Mobile
   China
   Email: chengweiqiang@chinamobile.com


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


   Acee Lindem
   Arrcus, Inc.
   United States of America
   Email: acee.ietf@gmail.com


   Ran Chen
   ZTE Corporation
   China
   Email: chen.ran@zte.com.cn
📦 where this page comes from