OSPF unreachable links: Advertising Unreachable Links in OSPF
How OSPF can advertise a link that the normal route calculation must ignore, using the metric 0xffff.
Gong, L., Cheng, W., Lin, C., Lindem, A., and R. Chen, "Advertising Unreachable Links in OSPF", RFC 10041, DOI 10.17487/RFC10041, September 2026, <https://www.rfc-editor.org/info/rfc10041>.
@misc{rfc10041,
series = {Request for Comments},
number = 10041,
howpublished = {RFC 10041},
publisher = {RFC Editor},
doi = {10.17487/RFC10041},
url = {https://www.rfc-editor.org/info/rfc10041},
author = {L. Gong and W. Cheng and C. Lin and A. Lindem and R. Chen},
title = {{Advertising Unreachable Links in OSPF}},
pagetotal = 22,
year = 2026,
month = sep,
} RFC text
Contents
Internet Engineering Task Force (IETF) L. Gong
Request for Comments: 10041 W. Cheng
Updates: 5443, 6987, 8379, 8770 China Mobile
Category: Standards Track C. Lin
ISSN: 2070-1721 New H3C Technologies
A. Lindem
Arrcus, Inc.
R. Chen
ZTE Corporation
September 2026
Advertising Unreachable Links in OSPF
Abstract
OSPF Router Link State Advertisements (LSAs) use fixed-format
encodings that always include advertised links in the default
Shortest Path First (SPF) computation. For non-default SPF
computations, e.g., Flexible Algorithms as described in RFC 9350,
advertised OSPF links are used in the default SPF computation even if
this is not intended. In order to advertise these links and not use
them in the base SPF calculation, the metric LSLinkInfinity (0xffff)
is used to specify that the link is unreachable. If all OSPF routers
in an OSPF area support this functionality and have advertised the
capability via 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.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc10041.
Copyright Notice
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 Link State Advertisements (LSAs) use fixed-format
encodings that always include advertised links in the default
Shortest Path First (SPF) computation. For example, a link may be
required for Traffic Engineering (TE) paths but not intended for hop-
by-hop routing. Another example is an OSPF link used exclusively by
a Flexible Algorithm [RFC9350] but excluded from the default
algorithm.
In order to advertise these links as unreachable, the metric
LSLinkInfinity (0xffff) is used to specify that the link is
unreachable and OSPF routers supporting 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 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
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 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
3.1. Unreachable Link Advertisement
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:
* The Router-LSA [RFC2328] [RFC5340]
* The Router-Link TLV of OSPFv3 E-Router-LSA [RFC8362]
3.2. Unreachable Link Backward Compatibility
Prior to this specification, OSPF treated links with an advertised
metric of LSLinkInfinity as reachable [RFC2328]. Hence, partial
deployment of this specification may result in routing loops due to
inconsistent interpretation of LSLinkInfinity. For example, in the
network shown in Figure 5, link D-F is advertised with LSLinkInfinity
(65535/0xffff). Router B supports LSLinkInfinity as unreachable, but
router A doesn't. Router A considers link D-F as reachable, and the
shortest path to F is A->B->D->F. Router B considers link D-F as
unreachable, and the shortest path to F is B->A->C->E->F. As a
result, A forwards the packets to B, but B returns them to A, which
results in a 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 provide backward compatibility, this document specifies that
routers supporting LSLinkInfinity for unreachable links support
advertisement of an area-scoped Router Information LSA with a Router
Functional Capabilities TLV [RFC7770] that includes the following
Router Functional Capability Bit. The value of the bit is controlled
by configuration as specified in Section 4.1.
+=====+==================+
| Bit | Capabilities |
+=====+==================+
| 0 | Unreachable Link |
+-----+------------------+
Table 1
OSPF routers MUST NOT treat links with an advertised metric of
LSLinkInfinity as unreachable unless all routers in the OSPF area,
i.e., 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 all
OSPF routers in the area have advertised this capability, then links
with an advertised metric of LSLinkInfinity MUST be treated as
unreachable. 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 operation, it is possible that an area-scoped OSPF Router
Information LSA will fail to reach all routers in an area in a timely
manner. For example, if a new router not supporting the Unreachable
Link capability joins an area that previously only had OSPF routers
advertising support of the Unreachable Link capability, then it may
take some time for the OSPF Router Information LSA to propagate to
all routers. While it is propagating, the routers in the area will
gradually detect the presence of a router that does not support the
capability and will revert to treating links with MaxLinkMetric as
being reachable. During the propagation time, this inconsistency of
MaxLinkMetric interpretation between OSPF routers can result in
transient routing loops.
3.3. Stub Router Advertisement Backward Compatibility
Stub Router Advertisement [RFC6987] defines MaxLinkMetric (0xffff) to
indicate a router-LSA link should not be used for transit traffic.
When an OSPF router supports the Unreachable Link capability defined
in this document, the OSPF stub router MaxLinkMetric (0xffff) MUST be
updated to MaxReachableLinkMetric (0xfffe). This document updates
[RFC6987] and [RFC8770] with respect to the advertisement of
MaxReachableLinkMetric rather than MaxLinkMetric.
When an OSPF router supports OSPF Stub Router Advertisement [RFC6987]
and the Unreachable Link capability defined in this document, it MUST
support advertisement of all its non-stub links with a link cost of
MaxReachableLinkMetric (0xfffe). Since MaxLinkMetric will not be
used to indicate that a link is unreachable unless all OSPF routers
in the area support this specification as specified in Section 3.2,
all routers in the area will also support the usage of
MaxReachableLinkMetric to discourage the usage of stub router links
for transit traffic. If there are any OSPF routers in the area that
do not support the Unreachable Link capability, then all OSPF routers
in the area will treat links advertised with a cost 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 has not been synchronized between the two
neighbors and transit IP traffic is discouraged. When an OSPF router
supports the Unreachable Link capability defined in this document,
the usage of OSPF MaxLinkMetric (0xffff) to discourage usage of the
link until LDP is "fully operational" MUST be updated to
MaxReachableLinkMetric (0xfffe). It is important to keep the link in
the topology to allow IP traffic to use the link as a last resort in
case of LDP packets between OSPF router loopbacks addresses or a
network failure. This document updates [RFC5443] with respect to the
advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.
3.5. OSPF Graceful Link Shutdown Backward Compatibility
OSPF Graceful Link [RFC8379] specifies OSPF advertisement of
MaxLinkMetric (0xffff) to indicate that the link is going to be taken
down and transit traffic is discouraged. When an OSPF router
supports the Unreachable Link capability defined in this document,
the usage of OSPF MaxLinkMetric (0xffff) to discourage usage of a
link prior to it being taken out of service MUST be updated to
MaxReachableLinkMetric (0xfffe). It is important to keep the link in
the topology to allow IP traffic to use the link as a last resort
prior to planned shutdown. This document updates [RFC8379] with
respect to the advertisement of MaxReachableLinkMetric rather than
MaxLinkMetric.
4. Operational Considerations
4.1. Configuration Parameters
Support of the Unreachable Link capability MUST be configurable. The
default MUST be to not advertise the capability, i.e., the functional
capability in the area-scoped OSPF Router Information LSA is false.
In some networks, the operator may still want links with maximum
metric (0xffff) to be treated as reachable. For example, when the
cost of links is automatically computed based on the inverse of the
link's bandwidth and there is a mix of low-speed and high-speed
links, the computation may result in the maximum metric. Hence,
implementations supporting this document and auto-costing MUST limit
the maximum computed cost to MaxReachableLinkMetric (0xfffe). An
example of auto-costing would be to automatically set the link metric
to be inversely proportional to the link bandwidth (refer to 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 as per 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 usage of OSPF LSLinkInfinity for unreachable
links as defined in this document, which augments 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
The following shows the tree diagram of the module for OSPF
Functional Capability:
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
4.2.2. Tree for OSPF Advertising Unreachable Links
The following shows the tree diagram of the module for OSPF
Advertising Unreachable Links:
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
IANA has created the "OSPF Router Functional Capability Bits"
registry within the "Open Shortest Path First (OSPF) Parameters"
registry group to identify OSPF Router Functional Capabilities. This
document defines the initial version of the IANA-maintained "iana-
ospf-functional-cap-bits" module, which mirrors the IANA "OSPF Router
Functional Capability Bits" registry [IANA-OSPF-FC-Bits]. The module
will be updated as the "OSPF Router Functional Capability Bits"
registry changes. The latest version of this YANG module is
available in the "YANG Module Names” registry
<https://www.iana.org/assignments/yang-parameters>.
4.2.4. YANG Module for OSPF Functional Capability
The following is the YANG module for OSPF Functional Capability:
<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>
4.2.5. YANG Module for OSPF Advertising Unreachable Links
The following is the YANG module for OSPF Advertising Unreachable
Links:
<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
A compromised OSPF router could advertise changes to its Unreachable
Link capability rapidly resulting in repeated route recalculations on
routers in the area supporting this specification (Section 3.2).
Hence, 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] are also applicable to this protocol extension.
The "ietf-ospf-unreachable-links" YANG module and the "ietf-ospf-
functional-capability" YANG module each define a data model that is
designed to be accessed via YANG-based management protocols, such as
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]
provides the means to restrict access for particular NETCONF or
RESTCONF users to a pre-configured subset of all available NETCONF or
RESTCONF protocol operations and content.
There are a number of data nodes defined in the "ietf-ospf-
unreachable-links" YANG module that are writable/creatable/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 to these data nodes without proper protection or
authentication can have a negative effect on network operations. The
modification of these data nodes without proper protection can
prevent interpretation of the OSPF LSLinkInfinity metric as
unreachable or result in a link being advertised as unreachable.
/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. Exposure of the OSPF unreachable link configuration
may be useful in 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 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
[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
[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
Thanks to Yingzhen Qu for providing the YANG data models.
Thanks to Dhruv Dhody for OPS Directorate review and comments.
Thanks to Gunter Van de Velde for review and comments.
Thanks to Mohamed Boucadair for review and comments.
Thanks to Mike Bishop, Mahesh Jethanadani, and Ketan Taulaulikar for
review and comments.
Contributors
The following individuals have 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
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
ISO Plain Language
On this page
§1The Problem with the Link Metric
OSPF Router Link State Advertisements use fixed-format encodings that always include advertised links in the default shortest path calculation. A link may be required for Traffic Engineering paths but not intended for hop-by-hop routing, or it may be used exclusively by a Flexible Algorithm, as described in RFC 9350, while being excluded from the default algorithm.
To advertise such links as unreachable, the metric LSLinkInfinity (0xffff) is used, and routers that support this specification exclude the link from the shortest path calculation, subject to the backward compatibility rules in Section 3.2.
The same value is already in use for other purposes, which is why the document also introduces MaxReachableLinkMetric (0xfffe). The Stub Router Advertisement specification, RFC 6987, defines MaxLinkMetric (0xffff) to indicate that a router LSA link should only be used for transit IP traffic as a last resort. When a router supports the Unreachable Link capability, its stub router links are advertised as 0xfffe instead. The LDP IGP Synchronization specification, RFC 5443, specifies advertising 0xffff to say that although the OSPF adjacency is in FULL state, LDP has not synchronized between the neighbours and transit traffic is discouraged; that too becomes 0xfffe. And OSPF Graceful Link Shutdown, RFC 8379, specifies advertising 0xffff to say that the link is about to be taken out of service and transit traffic is discouraged, which again becomes 0xfffe.
The value 0xffff already means something in OSPF: a link that is reachable but discouraged for through traffic. This RFC gives that same number a new meaning for one specific case, and moves the old meaning to the next value down, 0xfffe.
§2Two Use Cases
The first case is Traffic Engineering. In the topology in the RFC, the link between nodes A and E is only to be used for Traffic Engineering. Because the link is advertised by default, it is included in the base shortest path calculation for the default topology, and it may be used for hop-by-hop routing there.
The second case is a Flexible Algorithm. The links between nodes A and B and between C and D are to be used exclusively for a Flexible Algorithm devoted to specific traffic, and they carry an Extended Administrative Group attribute specifying the Red colour. Flex-Algorithm 128 is enabled on nodes A, B, C and D, with an EAG rule that includes Red, and the Metric-Type is designated to be a type other than the OSPF metric, so OSPF computes routes for Flex-Algorithm 128 using these links.
The problem is that the Red links are also included in the default algorithm calculation, because they are reachable. If the OSPF metrics for all the Red links are advertised as unreachable, they are excluded from the default shortest path calculation, and the Red links from A to B and from C to D can then be used exclusively by the Flex-Algorithm 128 calculation.
The RFC gives two examples. A link kept for traffic engineering would otherwise pull ordinary traffic onto it, and a link reserved for one Flexible Algorithm would also be offered to the default algorithm. Advertising it as unreachable keeps it out of the default calculation.
- Traffic EngineeringA link kept only for traffic engineering paths is advertised by default, so it is included in the base shortest path calculation and may carry hop-by-hop traffic.
- Flexible AlgorithmLinks reserved for Flex-Algorithm 128, marked with the Red Extended Administrative Group, are also used by the default algorithm because they are reachable.
- The fixAdvertising their OSPF metrics as unreachable removes them from the default calculation, so they are used only by the computation that wants them.
§3.1Advertising an Unreachable Link
The rule is that if the OSPF metric of a link is advertised as LSLinkInfinity (0xffff), it must not be considered during the associated shortest path computation. This applies both to the Flexible Algorithm computation of RFC 9350 and to the base shortest path, as long as LSLinkInfinity is specified for the OSPF metric.
While the interpretation of LSLinkInfinity is only required in the base topology, because interpretation in other topologies is optional under RFC 4915, routers that support this specification must interpret LSLinkInfinity as unreachable consistently during the associated computation. The interpretation also applies to Flexible Algorithm computations that use the OSPF link metric.
An OSPF metric of LSLinkInfinity meaning that a link is unreachable applies to the Router-LSA of RFC 2328 and RFC 5340, and to the Router-Link TLV of the OSPFv3 E-Router-LSA of RFC 8362.
A link advertised with the metric 0xffff is left out of the route calculation, both in the default topology and in the Flexible Algorithm computation that uses the OSPF metric. The rule covers both OSPFv2 router LSAs and the OSPFv3 router link TLV.
| Value | Name | Meaning |
|---|---|---|
| 0xffff | LSLinkInfinity | Unreachable, but only when every router in the area advertises the Unreachable Link capability. Otherwise the link stays reachable. |
| 0xfffe | MaxReachableLinkMetric | The link stays reachable but is discouraged for transit traffic. This is what the updated specifications now advertise. |
| 0xffff | MaxLinkMetric | The older meaning, used by the stub router, LDP IGP synchronization and graceful link shutdown specifications before this document. |
§3.2Backward Compatibility and the Capability Bit
Before this specification, OSPF treated links advertised with LSLinkInfinity as reachable, so a partial deployment can cause routing loops through inconsistent interpretation. In the example in the RFC, link D-F is advertised with LSLinkInfinity. Router B supports the new meaning and router A does not. A considers D-F reachable, so its shortest path to F is A, B, D, F, and it forwards the packet to B. B considers D-F unreachable, so its shortest path to F is B, A, C, E, F, and it sends the packet back to A. The result is a loop.
To avoid that, routers that support the new meaning advertise an area-scoped Router Information LSA with a Router Functional Capabilities TLV, as defined in RFC 7770, that includes a Router Functional Capability bit numbered 0 and named Unreachable Link. The value of the bit is under configuration.
The rule is that routers must not treat links with an advertised metric of LSLinkInfinity as unreachable unless all routers in the area, meaning all routers with router LSAs in the area link state database, have advertised this capability in an OSPFv2 Router Information Opaque LSA or an OSPFv3 Router Information LSA. When every router in the area has advertised it, such links must be treated as unreachable. When the number of routers in the area that do not support the capability changes to zero, or from zero to more than zero, all routers in the area must recalculate their routes.
The RFC also describes what happens while the capability is propagating. If a new router that does not support the capability joins an area, it takes some time for its Router Information LSA to reach every router. During that time the routers in the area gradually notice the router that lacks the capability and revert to treating links with the maximum metric as reachable, and that inconsistency can cause transient routing loops.
Because 0xffff used to mean something else, routers may only act on the new meaning when every router in the area has said it understands it. Each router says so with a capability bit in a Router Information LSA. Until every router has said so, the old meaning applies.
- Packet for FA considers link D-F reachable, so its shortest path to F is A, B, D, F.
- Packet returnedB considers link D-F unreachable, so its shortest path to F is B, A, C, E, F, and it sends the packet back to A.
§3.3Updating the Other Specifications
Three specifications that use 0xffff to mean a link that stays reachable but is discouraged for transit traffic are changed to use 0xfffe instead, because the value 0xffff now has the stronger unreachable meaning.
For the Stub Router Advertisement of RFC 6987, the stub router maximum metric must be updated to MaxReachableLinkMetric (0xfffe), and a router that supports both the stub router advertisement and the Unreachable Link capability must be able to advertise all of its non-stub links with a link cost of 0xfffe. The RFC explains why this is safe: MaxLinkMetric only indicates an unreachable link when every router in the area supports this specification, and in that case every router in the area also supports the use of 0xfffe for the stub router links. If any router in the area lacks the capability, all routers treat links advertised with 0xffff as reachable, as Section 3.2 requires. This document updates RFC 6987 and RFC 8770.
For LDP IGP Synchronization in RFC 5443, the use of 0xffff to discourage the use of a link until LDP is fully operational must be updated to 0xfffe. The link is kept in the topology so that IP traffic can still use it as a last resort, for example when LDP packets between OSPF router loopback addresses are lost or when there is a network failure.
For OSPF Graceful Link Shutdown in RFC 8379, the use of 0xffff to discourage the use of a link before it is taken out of service must be updated to 0xfffe, again so that the link stays in the topology and can be used as a last resort before a planned shutdown.
Three other specifications used 0xffff to mean that a link stays reachable but should not carry through traffic. They now use 0xfffe, so that 0xffff can be reserved for the new meaning. In each case the link stays in the topology and can still be used if there is no alternative.
- Stub Router AdvertisementRFC 6987 and RFC 8770. The stub router maximum metric becomes 0xfffe, and a router that supports both features advertises all of its non-stub links with that cost.
- LDP IGP SynchronizationRFC 5443. The metric used while LDP is not yet synchronized becomes 0xfffe, so the link stays in the topology as a last resort.
- OSPF Graceful Link ShutdownRFC 8379. The metric used before a planned shutdown becomes 0xfffe, so the link stays in the topology as a last resort.
§4Configuration and the YANG Model
Support of the Unreachable Link capability must be configurable, and the default must be to not advertise the capability, so the functional capability in the area-scoped OSPF Router Information LSA is false by default.
Some networks still want links with the maximum metric to be treated as reachable. The RFC gives the example of a network where the cost of a link is computed automatically from the inverse of its bandwidth, and a mix of low-speed and high-speed links can make that computation produce the maximum metric. Implementations that support this document and use auto-costing must therefore limit the maximum computed cost to MaxReachableLinkMetric (0xfffe).
Three YANG modules are defined. The iana-ospf-functional-cap-bits module holds the identities for the OSPF Router Functional Capabilities in the IANA registry, and is updated as that registry changes. The ietf-ospf-functional-capability and ietf-ospf-unreachable-links modules configure and manage the use of LSLinkInfinity for unreachable links, and augment the OSPF YANG data model of RFC 9129 and the routing management model of RFC 8349.
The first of the two operational modules augments the Router Capabilities TLV in the OSPFv2 and OSPFv3 Router Information structures, at area, link and autonomous system scope, with a read-only list of functional capabilities. The second augments the OSPF area with a read-write container for unreachable link advertisement, holding a read-write boolean enabled, and augments the OSPF interface with a read-write boolean advertise-unreachable-link.
The capability is off by default, so a network only changes behaviour when an operator turns it on. The RFC also adds YANG modules so that management software can read the capability and switch the per-area and per-interface settings.
/ospf:ospf/ospf:areas/ospf:area:
+--rw unreachable-link-advertisement
+--rw enabled? boolean
/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface:
+--rw advertise-unreachable-link? boolean§5Security Considerations
A compromised OSPF router could advertise changes to its Unreachable Link capability rapidly, which would cause repeated route recalculations on the routers in the area that support this specification. Routers that support this specification are therefore recommended to support the shortest path back-off delay algorithm of RFC 8405. The security considerations of RFC 2328, RFC 5340, RFC 6987 and RFC 7770 also apply to this extension.
The two YANG modules define data models meant to be reached over a management protocol such as NETCONF or RESTCONF. Such protocols have to use a secure transport layer, such as SSH, TLS or QUIC, and they have to use mutual authentication. The Network Configuration Access Control Model of RFC 8341 provides the means to restrict particular users to a pre-configured subset of operations and content.
The RFC lists the writable data nodes, which are the enabled boolean under the area's unreachable link advertisement container and the advertise-unreachable-link boolean under an interface. Write or delete operations on them without proper protection can have a negative effect on network operations, because an unprotected change can prevent the LSLinkInfinity metric from being interpreted as unreachable, or cause a link to be advertised as unreachable. The RFC also notes that the readable data nodes may be sensitive, because exposing the unreachable link configuration can be useful in mounting a denial-of-service attack.
A router that lies about its capability could make the whole area recalculate its routes repeatedly, so the RFC recommends the standard back-off delay for route computation. Management access to the new settings must be protected, because a change to them can alter how the whole area routes traffic.
§6IANA Considerations
The document defines a new bit in the OSPF Router Functional Capability Bits registry: bit number 0, with the capability name Unreachable Link.
Three new URIs are registered in the ns registry of the IETF XML Registry, for the XML namespaces of the modules iana-ospf-functional-cap-bits, ietf-ospf-functional-capability and ietf-ospf-unreachable-links. Three new module names are registered in the YANG Module Names registry: iana-ospf-functional-cap-bits, which is maintained by IANA, and ietf-ospf-functional-capability and ietf-ospf-unreachable-links, which are not.
The IANA-maintained module mirrors the OSPF Router Functional Capability Bits registry and carries a note that new values must not be added to the module directly, but to the registry instead. When a value is added to the registry, a new identity statement is added to the module, named after the registry entry in lowercase with spaces replaced by hyphens, and carrying a base of functional-capability, the unabbreviated capability name as its description and the registry references.
The capability gets a number in IANA's registry of OSPF router capabilities, and the three YANG modules are registered with their own names and namespaces so that management software can find them.
- 0Unreachable Link — Bit 0 of the OSPF Router Functional Capability Bits registry, advertised in the Router Functional Capabilities TLV.
- iana-ospf-functional-cap-bitsYANG module, maintained by IANA — Holds the identities for the OSPF Router Functional Capabilities and mirrors the IANA registry.
- ietf-ospf-functional-capabilityYANG module — Gives the operational state of functional capability in OSPF.
- ietf-ospf-unreachable-linksYANG module — Configures and manages the use of LSLinkInfinity for unreachable links.