Advertising Unreachable Links in OSPFChina MobileChinagongliyan@chinamobile.comChina MobileChinachengweiqiang@chinamobile.comNew H3C TechnologiesChinalinchangwang.04414@h3c.comArrcus, Inc.United States of Americaacee.ietf@gmail.comZTE CorporationChinachen.ran@zte.com.cn
RTG
lsrOSPFls
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
.
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
() 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
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 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 ).
Stub Router Advertisement 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 and
with respect to the advertisement of MaxReachableLinkMetric rather than MaxLinkMetric.
Similarly, Label Distribution Protocol (LDP) IGP Synchronization
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 with respect to the advertisement of MaxReachableLinkMetric
rather than MaxLinkMetric.
Finally, OSPF Graceful Link Shutdown 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 with respect to the advertisement of
MaxReachableLinkMetric rather than MaxLinkMetric.
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
when, and only when, they appear in all capitals, as shown here.
Use CasesCase 1: Traffic Engineering
A network topology is shown in . 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.
Network Topology
TE Link
---------
/ \
/ \
A------C------E
| | |
| | |
| | |
B------D------FCase 2: Flexible Algorithm
A network topology is shown in . The links between Nodes A
and B and between C and D are to be used exclusively for a
Flex-Algorithm devoted to specific traffic.
These links have an Extended
Administrative Group (EAG) attribute specifying
the "Red" color.
Network Topology
******
A------C------E
|* |* |
|* |* | ******: "Red" link
|* |* |
B------D------F
******
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 .
Topology of Flex-Algorithm 128
A******C
* *
* *
* *
B******D
The "Red" links are used by Flex-Algorithm
128 calculation. However, these
"Red" links are also included in the default algorithm
calculation since they are reachable.
Note that links used by the default algorithm are omitted from
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 . This allows the "Red" links from A to B and C to D
to be used exclusively by the Flex-Algorithm 128 calculation.
Base SPF Topology Excluding Unreachable Links
A------C------E
|
|
|
B------D------FLSLinkInfinity-Based SolutionUnreachable 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 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 ,
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 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
The Router-Link TLV of OSPFv3 E-Router-LSA
Unreachable Link Backward Compatibility
Prior to this specification, OSPF treated links with an advertised metric of
LSLinkInfinity as reachable . Hence, partial deployment of
this specification may result in routing loops due to inconsistent
interpretation of LSLinkInfinity. For example, in the network shown
in , 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.
Inconsistent LSLinkInfinity Interpretation Causing Loops
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
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 that includes the following
Router Functional Capability Bit. The value of the bit is controlled by
configuration as specified in .
Bit
Capabilities
0
Unreachable Link
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.
Stub Router Advertisement Backward Compatibility
Stub Router Advertisement 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 and
with respect to the advertisement of MaxReachableLinkMetric rather than
MaxLinkMetric.
When an OSPF router supports OSPF Stub Router Advertisement 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
, 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
().
Label Distribution Protocol (LDP) IGP Synchronization Backward Compatibility
LDP IGP Synchronization 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
with respect to the advertisement of MaxReachableLinkMetric rather than
MaxLinkMetric.
OSPF Graceful Link Shutdown Backward Compatibility
OSPF Graceful Link 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
with respect to the advertisement of MaxReachableLinkMetric rather than
MaxLinkMetric.
Operational ConsiderationsConfiguration 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 ).
YANG Data Model
This section defines three YANG 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 .
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
and the YANG data model for Routing Management .
This document uses the graphical representation of data models per .Tree for OSPF Functional CapabilityThe 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* identityrefTree for OSPF Advertising Unreachable LinksThe 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? booleanIANA 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 .
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
<>.
YANG Module for OSPF Functional CapabilityThe following is the YANG module for OSPF Functional Capability:
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";
}
}
YANG Module for OSPF Advertising Unreachable LinksThe following is the YANG module for OSPF Advertising Unreachable Links:
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.";
}
}
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
().
Hence, it is RECOMMENDED that routers supporting this specification also
support the SPF back-off delay algorithm described in .
The security considerations for , ,
, and 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 and RESTCONF . These
YANG-based management protocols (1) have to use a secure transport layer
(e.g., SSH , TLS , and
QUIC ) and (2) have to use mutual authentication.
The Network Configuration Access Control Model (NACM) 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-linkIANA ConsiderationsRegistering OSPF Router Functional Capability Bits
This document defines a new bit in the "OSPF Router Functional Capability Bits"
registry
:
Bit Number
Capability Name
Reference
0
Unreachable Link
RFC 10041
Registering YANG ModulesIANA has registered the following three new URIs in the "ns" registry within the "IETF XML
Registry" :
IANA Module for OSPF Functional Capability BitsThis document defines the initial version of the IANA-maintained
"iana-ospf-functional-cap-bits" YANG module ().
The most recent version of the YANG module is available in
the "YANG Parameters" registry .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 .
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
:
When this registry is modified, the YANG module "iana-ospf-functional-cap-bits"
must be updated as defined in RFC 10041.
ReferencesNormative ReferencesOSPF Router Functional Capability BitsIANAYANG Module NamesIANAKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.OSPF Version 2This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Multi-Topology (MT) Routing in OSPFThis document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]OSPF for IPv6This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]LDP IGP SynchronizationIn certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This memo provides information for the Internet community.YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]OSPF Stub Router AdvertisementThis document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.This document obsoletes RFC 3137.Extensions to OSPF for Advertising Optional Router CapabilitiesIt is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Network Configuration Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536.A YANG Data Model for Routing Management (NMDA Version)This document specifies three YANG modules and one submodule. Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, Routing Information Bases (RIBs), and control-plane protocols.The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). This document obsoletes RFC 8022.OSPFv3 Link State Advertisement (LSA) ExtensibilityOSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.OSPF Graceful Link ShutdownWhen a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link. Increasing the metric to the highest value on one side of the link is not sufficient to divert the traffic flowing in the other direction.It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link as being in a graceful-shutdown state to indicate impending maintenance activity on the link. This information can be used by the network devices to reroute the traffic effectively.This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3.Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPsThis document defines a standard algorithm to temporarily postpone or "back off" link-state IGP Shortest Path First (SPF) computations. This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations.Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally close IGP events.Host Router Support for OSPFv2The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit called the Host-bit (H-bit). This bit enables a router to advertise that it is a non-transit router. This document also describes the changes needed to support the H-bit in the domain. In addition, this document updates RFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA) Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively.YANG Data Model for the OSPF ProtocolThis document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342.IGP Flexible AlgorithmIGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.Informative ReferencesThe Secure Shell (SSH) Authentication ProtocolThe Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).YANG Tree DiagramsThis document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.QUIC: A UDP-Based Multiplexed and Secure TransportThis document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations.AcknowledgmentsThanks to for providing the YANG data models.Thanks to for OPS Directorate review and comments.Thanks to for review and comments.Thanks to for review and comments.Thanks to , , and for review and comments.ContributorsThe following individuals have contributed to this document:New H3C TechnologiesChinachen.mengxiao@h3c.comRuijie Networks Co., Ltd.Chinaliangyanrong@ruijie.com.cnAuthors' AddressesChina MobileChinagongliyan@chinamobile.comChina MobileChinachengweiqiang@chinamobile.comNew H3C TechnologiesChinalinchangwang.04414@h3c.comArrcus, Inc.United States of Americaacee.ietf@gmail.comZTE CorporationChinachen.ran@zte.com.cn