Extensions to OSPF for Advertising Prefix Administrative TagsLabN Consulting, L.L.C.301 Midenhall WayCaryNCUnited States of America27513acee.ietf@gmail.comCisco SystemsApollo Business CenterMlynske nivy 43Bratislava821 09Slovakiappsenak@cisco.comFuturewei Technologies2330 Central ExpresswaySanta ClaraCA95050United States of Americayingzhen.ietf@gmail.com
RTG
lsrIt is useful for routers in OSPFv2 and OSPFv3 routing domains to be able to
associate tags with prefixes.
Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous
System (AS) External and Not-So-Stubby-Area (NSSA) prefixes.
With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement
and OSPFv3 Extended Link State Advertisements (LSAs), multiple administrative
tags may be advertised for all types of prefixes. These administrative
tags can be used for many applications including route redistribution policy, selective
prefix prioritization, selective IP Fast Reroute (IPFRR) prefix protection, and many
others.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) 2025 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
. Requirements Language
. Administrative Tag Sub-TLV
. Administrative Tag Applicability
. Protocol Operation
. Equal-Cost Multipath Applicability
. BGP-LS Advertisement
. Management Considerations
. YANG Data Model
. Tree for the YANG Data Model
. YANG Data Model for OSPF Prefix Administrative Tags
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
Introduction
It is useful for routers in OSPFv2
and OSPFv3 routing domains to be able to associate tags with prefixes.
Previously, OSPFv2 and OSPFv3 were relegated to a single tag and only for Autonomous System (AS)
External and Not-So-Stubby-Area (NSSA) prefixes.
With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement
and OSPFv3 Extended Link State Advertisement (LSA) ,
multiple administrative tags may be advertised for all types of prefixes. These administrative
tags can be used in many applications including (but not limited to):
Controlling which routes are redistributed into other protocols for
re-advertisement.
Prioritizing selected prefixes for faster convergence and installation in the
forwarding plane.
Identifying selected prefixes for Loop-Free Alternative (LFA) protection.
Throughout this document, "OSPF" is used when the text applies to both
OSPFv2 and OSPFv3. "OSPFv2" or "OSPFv3" is used when the text is
specific to one version of the OSPF protocol.The definition of the 64-bit tag was considered but discarded, given that
there is no strong requirement or use case.The IS-IS protocol supports a similar mechanism that is described in
.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.
Administrative Tag Sub-TLVThis document creates a new Administrative Tag Sub-TLV for OSPFv2 and
OSPFv3. This sub-TLV specifies one or
more 32-bit unsigned integers that may be associated with an
OSPF advertised prefix. The precise usage of these tags is beyond
the scope of this document.
The format of the Administrative Tag Sub-TLV is as follows:
Administrative Tag Sub-TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Administrative Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |
o
| o |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Administrative Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
A 16-bit field set to:
13:
"OSPFv2 Extended Prefix TLV Sub-TLVs" registry
39:
"OSPFv3 Extended-LSA Sub-TLVs" registry
6:
"OSPFv3 SRv6 Locator LSA Sub-TLVs" registry
Length:
A 16-bit field that indicates the length of the value
portion in octets and MUST be a multiple of 4 octets
dependent on the number of administrative tags
advertised. At least one administrative tag MUST be
advertised.
Value:
A variable length list of one or more administrative
tags.
This sub-TLV will carry one or more 32-bit unsigned integer values
that will be used as administrative tags. If the length is 0 or not
a multiple of 4 octets, the sub-TLV MUST be ignored, and the reception
SHOULD be logged for further analysis (subject to rate-limiting).
Administrative Tag Applicability
The Administrative Tag Sub-TLV specified herein will be valid as a sub-TLV of
the following TLVs specified in :
Extended Prefix TLV advertised in the OSPFv2 Extended Prefix Opaque LSA
The Administrative Tag Sub-TLV specified herein will be valid as a sub-TLV of
the following TLVs specified in :
Inter-Area-Prefix TLV advertised in the E-Inter-Area-Prefix-LSA
Intra-Area-Prefix TLV advertised in the E-Intra-Area-Prefix-LSA
External-Prefix TLV advertised in the E-AS-External-LSA and the E-NSSA-LSA
The Administrative Tag Sub-TLV specified herein will be valid as a sub-TLV of
the following TLVs specified in :
SRv6 Locator TLV advertised in the SRv6 Locator LSA
Protocol OperationAn OSPF router supporting this specification MUST be able to advertise and interpret
at least one tag for all types of prefixes. An OSPF router supporting this
specification MAY be able to advertise prefixes with multiple tags and propagate prefixes
with multiple tags between areas. The
maximum tags that an implementation supports is a local matter depending upon supported
applications using prefix tags. Depending on the application, the number of tags supported
by the OSPF routers in the OSPF routing domain may limit the deployment of that application.
When tags are advertised for AS External or NSSA LSA prefixes, the existing tag in
the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA encodings MUST be utilized for
the first tag. Additional tags MAY be advertised using the Administrative Tag
Sub-TLV specified in this document. This will facilitate backward compatibility with
implementations that do not support this specification.
An OSPF router supporting this specification SHOULD propagate administrative tags
when acting as an Area Border Router (ABR) and when originating summary advertisements into other
areas (unless inhibited by local policy ()). Similarly, an OSPF
router supporting this specification and acting as an ABR for a NSSA
SHOULD propagate tags when translating NSSA routes to AS External
advertisements (also subject to local
policy ()).
There is no implied meaning to the ordering of the tags that
indicates a certain operation or set of operations need to be performed
based on the order of the tags. Each tag SHOULD be treated as an
autonomous identifier that MAY be used in policy to perform a policy
action. Whether or not tag A precedes or succeeds, tag B SHOULD NOT
change the meaning of the tags.
The number of tags supported by an ABR MAY limit the number
of tags that are propagated. When propagating multiple tags between areas as
previously described, the order of the tags MUST be preserved so
that implementations supporting fewer tags will have a consistent view
across areas.
For configured area ranges, NSSA ranges, and configured aggregation of redistributed
routes, tags from component routes SHOULD NOT be propagated to the summary. Implementations
SHOULD provide a mechanism to configure multiple tags for area ranges, NSSA ranges, and
redistributed route summaries.
Equal-Cost Multipath Applicability
When multiple LSAs contribute to an OSPF route, it is possible that these
LSAs will all have different tags. In this situation, the OSPF ABR propagating the
route to other areas with inter-area LSAs MUST associate
the tags from one of the LSAs contributing a path and, if the implementation supports
multiple tags, MAY associate tags from multiple contributing LSAs up to the maximum
number of tags supported. It is RECOMMENDED that tags from LSAs are added to the path
in ascending order of the LSA originator Router-ID.
BGP-LS Advertisement
Border Gateway Protocol - Link State (BGP-LS) introduced the support for advertising
administrative tags associated with prefixes using the BGP-LS IGP Route
Tag TLV (TLV 1153). This BGP-LS TLV is used to advertise the OSPF
Administrative Tags specified in this document.
Management Considerations
Implementations MAY include configuration of policies to modify the advertisement of
tags for redistributed prefixes. Implementations MAY also include configuration of
policies to modify the propagation of administrative tags between areas
(OSPFv2 Extended Prefix Opaque LSAs, OSPFv3 E-Inter-Area-Prefix-LSAs, and
translated OSPFv3 E-AS-External-LSAs).
However, the default behavior SHOULD be to advertise or propagate
the lesser number of all the tags associated with the prefix or the maximum number of
tags supported by the implementation.
Both the support of this specification and the number of tags supported
by OSPF routers within an OSPF routing domain will limit the usefulness and
deployment of applications utilizing tags.
YANG Data Model
YANG is a data definition language
used to define the contents of a conceptual data store
that allows networked devices to be managed using Network Configuration Protocol (NETCONF)
or RESTCONF .
This section defines a YANG data model that can be used to configure
and manage the prefix administrative tags defined in this document,
which augments the OSPF YANG data model ,
the OSPFv3 Extended LSA YANG data model ,
and the Routing Management YANG data model .
Additionally, the YANG data models defined in
are imported.
Tree for the YANG Data ModelThis document uses the graphical representation of data models per
.The following shows the tree diagram of the module:
module: ietf-ospf-admin-tags
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:ranges/ospf:range:
+--rw admin-tags
+--rw admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:interfaces/ospf:interface:
+--rw local-prefix-admin-tags
+--rw default-admin-tag* uint32
+--rw specific-prefix-admin-tag* [prefix]
+--rw prefix inet:ip-prefix
+--rw admin-tag* uint32
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:local-rib
/ospf:route/ospf:next-hops/ospf:next-hop:
+--ro admin-tag* uint32
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:extended-prefix-opaque
/ospf:extended-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
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:extended-prefix-opaque/ospf:extended-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
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:extended-prefix-opaque
/ospf:extended-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
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
/ospfv3-e-lsa:e-inter-area-prefix
/ospfv3-e-lsa:e-inter-prefix-tlvs
/ospfv3-e-lsa:inter-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
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
/ospfv3-e-lsa:e-intra-area-prefix
/ospfv3-e-lsa:e-intra-prefix-tlvs
/ospfv3-e-lsa:intra-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
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/ospfv3-e-lsa:e-as-external
/ospfv3-e-lsa:e-external-tlvs
/ospfv3-e-lsa:external-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32
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/ospfv3-e-lsa:e-nssa
/ospfv3-e-lsa:e-external-tlvs
/ospfv3-e-lsa:external-prefix-tlv:
+--ro prefix-admin-tag-sub-tlv
+--ro admin-tag* uint32YANG Data Model for OSPF Prefix Administrative TagsThe following is the YANG module:
module ietf-ospf-admin-tags {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags";
prefix ospf-admin-tags;
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 ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-ospfv3-extended-lsa {
prefix ospfv3-e-lsa;
reference
"RFC 9587: YANG Data Model for OSPFv3 Extended Link
State Advertisements (LSAs)";
}
organization
"IETF LSR - Link State Routing Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/lsr/>
WG List: <mailto:lsr@ietf.org>
Author: Yingzhen Qu
<mailto:yingzhen.ietf@gmail.com>
Author: Acee Lindem
<mailto:acee.ietf@gmail.com>
Author: Peter Psenak
<mailto:ppsenak@cisco.com>";
description
"This YANG module defines the configuration
and operational state for OSPF administrative tags.
This YANG data model conforms to the Network Management
Datastore Architecture (NMDA) as described in RFC 8342.
Copyright (c) 2025 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).
This version of this YANG module is part of RFC 9825;
see the RFC itself for full legal notices.";
reference
"RFC 9825: Extensions to OSPF for Advertising Prefix
Administrative Tags.";
revision 2025-07-31 {
description
"Initial revision.";
reference
"RFC 9825: Extensions to OSPF for Advertising Prefix
Administrative Tags.";
}
grouping prefix-admin-tag-sub-tlv {
description
"Prefix Administrative Tag Sub-TLVs.";
container prefix-admin-tag-sub-tlv {
config false;
description
"Prefix Administrative Tag Sub-TLV.";
leaf-list admin-tag {
type uint32;
description
"Administrative tags.";
}
}
}
/* Configuration */
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/ospf:ospf"
+ "/ospf:areas/ospf:area/ospf:ranges/ospf:range" {
when "derived-from-or-self(../../../../.."
+ "/rt:type, 'ospf:ospf')" {
description
"This augments the OSPF routing protocol area range
configuration.";
}
description
"This augments the OSPF protocol area range configuration
with administrative tags. The configured tags will be
advertised with summary prefix when it is active.";
container admin-tags {
when "../ospf:advertise = 'true'";
leaf-list admin-tag {
type uint32;
description
"Administrative tags.";
}
description
"OSPF prefix administrative tags.";
}
}
augment "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/ospf:ospf"
+ "/ospf:areas/ospf:area/ospf:interfaces/ospf:interface" {
when "derived-from-or-self(../../../../.."
+ "/rt:type, 'ospf:ospf')" {
description
"This augments the OSPF routing protocol interface
configuration.";
}
description
"This augments the OSPF protocol interface configuration
with Administrative Tags. The configured tags will be
advertised with local prefixes configured for the interface.";
container local-prefix-admin-tags {
leaf-list default-admin-tag {
type uint32;
description
"Administrative tags that will be associated with
local prefixes if the prefix is not specified explicitly.
If omitted, no administrative tags are associated with
local prefixes by default.";
}
list specific-prefix-admin-tag {
key "prefix";
leaf prefix {
type inet:ip-prefix;
description
"IPv4 or IPv6 prefix.";
}
leaf-list admin-tag {
type uint32;
description
"Administrative tags that will be associated with
the specified local prefix. If omitted, no
administrative tags are associated with the specified
local prefix.";
}
description
"Administrative tags that are explicitly associated with
the specified prefix.";
}
description
"List of administrative tags that are to be advertised
with interface local prefixes.";
}
}
/* Local-RIB */
augment "/rt:routing"
+ "/rt:control-plane-protocols/rt:control-plane-protocol"
+ "/ospf:ospf/ospf:local-rib/ospf:route/ospf:next-hops"
+ "/ospf:next-hop" {
description
"This augments local-rib next-hop with administrative tags.";
leaf-list admin-tag {
type uint32;
description
"Administrative tags.";
}
}
/* Database */
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:extended-prefix-opaque/ospf:extended-prefix-tlv" {
when "derived-from-or-self(../../../../../../../../../.."
+ "/../../../../rt:type, 'ospf:ospfv2')" {
description
"This augmentation is only valid for OSPFv2.";
}
description
"Prefix Administrative Tag Sub-TLVs for OSPFv2 extended prefix
TLV in type 9 opaque LSA.";
uses prefix-admin-tag-sub-tlv;
}
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:extended-prefix-opaque/ospf:extended-prefix-tlv" {
when "derived-from-or-self(../../../../../../../../../.."
+ "/../../rt:type, 'ospf:ospfv2')" {
description
"This augmentation is only valid for OSPFv2.";
}
description
"Prefix Administrative Tag Sub-TLVs for OSPFv2 extended prefix
TLV in type 10 opaque LSA.";
uses prefix-admin-tag-sub-tlv;
}
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:extended-prefix-opaque/ospf:extended-prefix-tlv" {
when "derived-from-or-self(../../../../../../../.."
+ "/../../rt:type, 'ospf:ospfv2')" {
description
"This augmentation is only valid for OSPFv2.";
}
description
"Prefix Administrative Tag Sub-TLVs for OSPFv2 extended prefix
TLV in type 11 opaque LSA.";
uses prefix-admin-tag-sub-tlv;
}
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/ospfv3-e-lsa:e-inter-area-prefix"
+ "/ospfv3-e-lsa:e-inter-prefix-tlvs"
+ "/ospfv3-e-lsa:inter-prefix-tlv" {
when "derived-from-or-self(../../../../../../../../../.."
+ "/../../rt:type, 'ospf:ospfv3')" {
description
"This augmentation is only valid for OSPFv3.";
}
description
"Augment OSPFv3 Inter-Area-Prefix TLV in the
E-Inter-Area-Prefix-LSA.";
uses prefix-admin-tag-sub-tlv;
}
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/ospfv3-e-lsa:e-intra-area-prefix"
+ "/ospfv3-e-lsa:e-intra-prefix-tlvs"
+ "/ospfv3-e-lsa:intra-prefix-tlv" {
when "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/rt:type = 'ospf:ospfv3'" {
description
"This augmentation is only valid for OSPFv3.";
}
description
"Augment OSPFv3 Intra-Area-Prefix TLV in the
E-Intra-Area-Prefix-LSA.";
uses prefix-admin-tag-sub-tlv;
}
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/ospfv3-e-lsa:e-as-external"
+ "/ospfv3-e-lsa:e-external-tlvs"
+ "/ospfv3-e-lsa:external-prefix-tlv" {
when "derived-from-or-self(../../../../../../../.."
+ "/../../rt:type, 'ospf:ospfv3')" {
description
"This augmentation is only valid for OSPFv3.";
}
description
"Augment OSPFv3 External-Prefix TLV in the E-AS-External-LSA.";
uses prefix-admin-tag-sub-tlv;
}
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/ospfv3-e-lsa:e-nssa"
+ "/ospfv3-e-lsa:e-external-tlvs"
+ "/ospfv3-e-lsa:external-prefix-tlv" {
when "/rt:routing/rt:control-plane-protocols"
+ "/rt:control-plane-protocol/rt:type = 'ospf:ospfv3'" {
description
"This augmentation is only valid for OSPFv3.";
}
description
"Augment OSPFv3 External-Prefix TLV in the E-NSSA-LSA.";
uses prefix-admin-tag-sub-tlv;
}
}Security Considerations
This document describes a generic mechanism for advertising
administrative tags for OSPF prefixes.
The administrative tags are generally less critical
than the topology information currently advertised by the base
OSPF protocol.
The security considerations for the generic mechanism are dependent
on their application. One such application is to control leaking of OSPF
routes to other protocols (e.g., BGP ). If an attacker
were able to modify
the administrative tags associated with OSPF routes, and they were being used for this
application, such routes could be prevented from being advertised in routing
domains where they are required (subtle denial of service) or they could be
advertised into routing domains where they shouldn't be advertised (routing
vulnerability).
Security considerations for the base OSPF protocol are covered
in and .
The "ietf-ospf-admin-tag" YANG module defines 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
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in this 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 following subtrees and data nodes have particular sensitivities/vulnerabilities:
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. Thus, it is
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Exposure of the OSPF link state
database may be useful in mounting a Denial-of-Service (DoS) attack.
Specifically, the following subtrees and data nodes have particular
sensitivities:
IANA Considerations
The following value has been allocated in the "OSPFv2 Extended Prefix TLV
Sub-TLVs" registry in the "Open Shortest Path First v2 (OSPFv2)
Parameters" registry group:
13:
Administrative Tag
The following value has been allocated in the "OSPFv3 Extended-LSA Sub-TLVs"
registry in the "Open Shortest Path First v3 (OSPFv3) Parameters"
registry group:
39:
Administrative TagSince this sub-TLV only applies to prefixes and not links, the value of
the Layer-2 Bundle Member (L2BM) field will be "X".
The following value has been allocated in the "OSPFv3 SRv6 Locator LSA
Sub-TLVs" registry in the "Open Shortest Path First v3 (OSPFv3)
Parameters" registry group:
6:
Administrative Tag
IANA has assigned one new URI in the "IETF XML Registry"
:
URI:
urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags
Registrant Contact:
The IESG.
XML:
N/A; the requested URI is an XML namespace.
This document also registers one new YANG module name in the "YANG Module
Names" registry with the
following:
Name:
ietf-ospf-admin-tags
Namespace:
urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags
Prefix:
ospf-admin-tags
Reference:
RFC 9825
ReferencesNormative ReferencesKey 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.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]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]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.OSPFv2 Prefix/Link Attribute AdvertisementOSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible.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.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.OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane.Distribution of Link-State and Traffic Engineering Information Using BGPIn many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control.Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752.YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs)This document defines a YANG data model augmenting the IETF OSPF YANG data model (RFC 9129) to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340.Informative ReferencesThe OSPF Not-So-Stubby Area (NSSA) OptionThis memo documents an optional type of Open Shortest Path First (OSPF) area that is somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and of RFC 1587 will interoperate. [STANDARDS-TRACK]The 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]A Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]A Policy Control Mechanism in IS-IS Using Administrative TagsThis document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. [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]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.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 updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.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.AcknowledgmentsThe authors of are acknowledged, since this
document draws upon both the IS-IS specification and deployment
experience. The text in is adopted from
.Thanks to for his comments and
questions.Thanks to for his comments and
providing the BGP-LS text.Thanks to and for discussions on tag selection.Thanks to for his Routing Directorate
review.Thanks to and for working group last call comments.Thanks to for has AD review
and comments.Thanks to for IANA review and
comments.Thanks to , , and for IESG review and
comments.Thanks to for an extensive
IESG review of the YANG data model.Authors' AddressesLabN Consulting, L.L.C.301 Midenhall WayCaryNCUnited States of America27513acee.ietf@gmail.comCisco SystemsApollo Business CenterMlynske nivy 43Bratislava821 09Slovakiappsenak@cisco.comFuturewei Technologies2330 Central ExpresswaySanta ClaraCA95050United States of Americayingzhen.ietf@gmail.com