rfc9983.original.xml   rfc9983.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!ENTITY zwsp "&#8203;">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!ENTITY nbhy "&#8209;">
<!-- used by XSLT processors --> <!ENTITY wj "&#8288;">
<!-- For a complete list and description of processing instructions (PIs), ]>
please see http://xml.resource.org/authoring/README.html. -->
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
docName="draft-ietf-lsr-anycast-flag-13"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
tocInclude="true"
tocDepth="4"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.38.1 -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-lsr-anycast-flag-13"
number="9983" consensus="true" ipr="trust200902" obsoletes="" updates="" submiss
ionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortR
efs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <!-- [rfced] We had the following question about the title of the
if the document:
full title is longer than 39 characters -->
<title abbrev="Anycast Property advertisement">OSPFv2 Anycast Property Advert We note that most of the recently published RFCs containing YANG
isement</title> modules format their titles as "A YANG Data Model for...", for
<seriesInfo name="Internet-Draft" value="draft-ietf-lsr-anycast-flag-13"/> example:
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor --> RFC 9094 - A YANG Data Model for Wavelength Switched Optical Networks (WSONs
)
RFC 9093 - A YANG Data Model for Layer 0 Types
RFC 9067 - A YANG Data Model for Routing Policy
Please consider whether the title of this document should be similarly
updated.
-->
<title abbrev="Anycast Property Advertisement">OSPFv2 Anycast Property Advert
isement</title>
<seriesInfo name="RFC" value="9983"/>
<author fullname="Ran Chen" initials="R." surname="Chen"> <author fullname="Ran Chen" initials="R." surname="Chen">
<organization>ZTE Corporation</organization> <organization>ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<street/> <city>Nanjing</city>
<!-- Reorder these if your country does things differently -->
<city>Nanjing</city>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>chen.ran@zte.com.cn</email> <email>chen.ran@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Detao Zhao" initials="D." surname="Zhao"> <author fullname="Detao Zhao" initials="D." surname="Zhao">
<organization>ZTE Corporation</organization> <organization>ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<street/> <city>Nanjing</city>
<!-- Reorder these if your country does things differently -->
<city>Nanjing</city>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhao.detao@zte.com.cn</email> <email>zhao.detao@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Peter Psenak" initials="P." surname="Psenak"> <author fullname="Peter Psenak" initials="P." surname="Psenak">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal>
<street/>
<!-- Reorder these if your country does things differently -->
<city/>
<region/>
<code/>
<country></country>
</postal>
<email>ppsenak@cisco.com</email> <email>ppsenak@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K." surname="Tala ulikar"> <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal>
<street/>
<!-- Reorder these if your country does things differently -->
<city/>
<region/>
<code/>
<country></country>
</postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Changwang Lin" initials="C." surname="Lin"> <author fullname="Changwang Lin" initials="C." surname="Lin">
<organization>New H3C Technologies</organization> <organization>New H3C Technologies</organization>
<address> <address>
<postal> <postal>
<street/> <city>Beijing</city>
<!-- Reorder these if your country does things differently -->
<city>Beijing</city>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>linchangwang.04414@h3c.com</email> <email>linchangwang.04414@h3c.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2026"/> <date month="May" year="2026"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2r
fc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations --> <area>RTG</area>
<workgroup>lsr</workgroup>
<area>Routing</area> <!-- [rfced] Please insert any keywords (beyond those that appear in
<workgroup>LSR</workgroup> the title) for use on https://www.rfc-editor.org/search. -->
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Internet Draft</keyword> <keyword>example</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>An IP prefix may be configured as anycast and as such the same value ca <t>An IP prefix may be configured as anycast and, as such, the same value
n be advertised by multiple routers. It is useful for other routers to know that can be advertised by multiple routers. It is useful for other routers to know th
the advertisement is for an anycast prefix.</t> at the advertisement is for an anycast prefix.</t>
<t>This document defines a new flag in the OSPFv2 Extended Prefix TLV F <t>This document defines a new flag in the OSPFv2 Extended Prefix TLV Flag
lags to advertise the anycast property. The document also specifies a companion s to advertise the anycast property. The document also specifies a companion YAN
YANG module for managing this function.</t> G module for managing this function.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>An IP prefix may be configured as anycast and as such the same value <t>An IP prefix may be configured as anycast and, as such, the same value
can be advertised by multiple routers. It is useful for other routers to know t can be advertised by multiple routers. It is useful for other routers to know th
hat the advertisement is for an anycast prefix.</t> at the advertisement is for an anycast prefix.</t>
<t><xref target="RFC7684" format="default"></xref> defines OSPFv2 Opaque LS
As based on Type-Length-Value (TLV) tuples that can be used to associate additio <!--[rfced] Should "Flag" be added to this text to match use in the
nal attributes with prefixes or links. The OSPFv2 Extended Prefix TLV that is co Abstract?
ntained in the OSPFv2 Extended Prefix Opaque LSA is used to advertise additional
attributes associated with a prefix.</t> Original:
<t>Extensions related to the anycast property of prefixes have been spec The OSPFv2 Extended Prefix TLV that is contained in the OSPFv2
ified for IS-IS <xref target="RFC9352" format="default"></xref> and OSPFv3 <xref Extended Prefix Opaque LSA is used to advertise additional attributes
target="RFC9513" format="default"></xref>, even though those documents are rela associated with a prefix.
ted to Segment Routing over IPv6, the anycast property applies to any IP prefix
advertisement. This document defines a flag to advertise the anycast property fo Perhaps:
r a prefix advertisement in OSPFv2 in the Flags field of the OSPFv2 Extended Pre The OSPFv2 Extended Prefix TLV Flag that is contained in the OSPFv2
fix TLV Flags (section 2.1 of <xref target="RFC7684" format="default"></xref>). Extended Prefix Opaque LSA is used to advertise additional attributes
The document also specifies a companion YANG module for managing this function.< associated with a prefix.
/t>
-->
<t><xref target="RFC7684" format="default"/> defines OSPFv2 Opaque Link Sta
te Advertisements (LSAs) based on Type-Length-Value (TLV) tuples that can be use
d to associate additional attributes with prefixes or links. The OSPFv2 Extended
Prefix TLV that is contained in the OSPFv2 Extended Prefix Opaque LSA is used t
o advertise additional attributes associated with a prefix.</t>
<t>Extensions related to the anycast property of prefixes have been spec
ified for IS-IS <xref target="RFC9352" format="default"/> and OSPFv3 <xref targe
t="RFC9513" format="default"/>, even though those documents are related to Segme
nt Routing over IPv6, the anycast property applies to any IP prefix advertisemen
t. This document defines a flag to advertise the anycast property for a prefix a
dvertisement in OSPFv2 in the Flags field of the OSPFv2 Extended Prefix TLV Flag
s (<xref target="RFC7684" section="2.1"/>). The document also specifies a compan
ion YANG module for managing this function.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"MAY", and "OPTIONAL" in this document are to be interpreted as IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
described in BCP 14 <xref target="RFC2119" format="default"/> <xref targ NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
et="RFC8174" format="default"/> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default" anchor="sect-2">
<name>OSPFv2 Anycast Property Advertisement</name> <name>OSPFv2 Anycast Property Advertisement</name>
<t>An IP prefix may be configured as anycast and it is useful for other <t>An IP prefix may be configured as anycast; it is useful for other rou
routers to know that the advertisement is for an anycast prefix.</t> ters to know that the advertisement is for an anycast prefix.</t>
<t>In the context of the flags defined in this document, the term <t>In the context of the flags defined in this document, the term "set" m
'set' means the bit is set to 1, and the term 'clear' means the bit is set to 0 eans the bit is set to 1; "clear" means the bit is set to 0.</t>
.</t> <t>A flag is introduced in the "OSPFv2 Extended Prefix TLV Flags" IANA re
<t>A flag is introduced in OSPFv2 Extended Prefix TLV Flags <xref gistry (see <xref target="RFC7684" format="default"/>) to advertise the anycast
target="RFC7684" format="default"></xref> to advertise the anycast property:</t property:</t>
> <dl spacing="normal" newline="false">
<t>Value: TBD</t> <dt>Value:</dt><dd>0x10</dd>
<t>Description: Anycast Flag (AC-flag)</t> <dt>Description:</dt><dd>Anycast Flag (AC-Flag)</dd>
<t>The only meaning of the AC-flag is that the prefix is intended </dl>
to be advertised by multiple nodes.</t> <t>The only meaning of the AC-Flag is that the prefix is intended to be a
<t>When a prefix is configured as anycast, the AC-flag MUST be se dvertised by multiple nodes.</t>
t. Otherwise, this flag MUST be clear.</t> <t>When a prefix is configured as anycast, the AC-Flag <bcp14>MUST</bcp14
<t>The AC-flag and the N-flag (section 2.1 of <xref target="RFC76 > be set. Otherwise, this flag <bcp14>MUST</bcp14> be clear.</t>
84" format="default"></xref>) MUST NOT both be set. The reception of an advertis <t>The AC-Flag and the N-flag (<xref section="2.1" target="RFC768
ement with both the N-flag and AC-flag set MUST be considered a configuration an 4"/>) <bcp14>MUST NOT</bcp14> both be set. The reception of an advertisement wit
omaly, and N-flag MUST be ignored. Additionally, the detection of such a conflic h both the N-flag and AC-Flag set <bcp14>MUST</bcp14> be considered a configurat
ting advertisement SHOULD be logged as an operational error(subject to rate-limi ion anomaly, and the N-flag <bcp14>MUST</bcp14> be ignored. Additionally, the de
ting).</t> tection of such a conflicting advertisement <bcp14>SHOULD</bcp14> be logged as a
<t>The AC-flag MUST be preserved when the OSPFv2 Extended Prefix n operational error (subject to rate-limiting).</t>
Opaque LSA is re-advertised into other areas.</t> <t>The AC-Flag <bcp14>MUST</bcp14> be preserved when the OSPFv2 E
<t>The same prefix can be advertised by multiple routers, and tha xtended Prefix Opaque LSA is re-advertised into other areas.</t>
t if at least one of them sets the AC-flag in its advertisement, the prefix is c <t>The same prefix can be advertised by multiple routers, and, if
onsidered as anycast.</t> at least one of them sets the AC-Flag in its advertisement, the prefix is consi
<t>A prefix that is advertised by a single node and without an AC dered to be anycast.</t>
-flag is considered a node-specific prefix.</t> <t>A prefix that is advertised by a single node and without an AC
<t>Anycast prefixes SHOULD be consistently managed throughout the -Flag is considered to be a node-specific prefix.</t>
network. Since an AC-flag set takes precedence in identifying anycast property, <t>Anycast prefixes <bcp14>SHOULD</bcp14> be consistently managed
stale configurations should be strictly monitored.</t> throughout the network. Since an AC-Flag set takes precedence in identifying th
e anycast property, stale configurations should be strictly monitored.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>BGP-LS Advertisement</name> <name>BGP-LS Advertisement</name>
<t><xref target="RFC9085"/> defines the Prefix Attribute Flags TLV for BG P-LS that carries prefix attribute flags information, and the Flags field of thi s TLV is interpreted according to OSPFv2 <xref target="RFC7684" format="default" ></xref>. Thus the Flags field of the BGP-LS Prefix Attribute Flags TLV also con veys the anycast property introduced by this document.</t> <t><xref target="RFC9085"/> defines the Prefix Attribute Flags TLV for Bo rder Gateway Protocol - Link State (BGP-LS) that carries prefix attribute flags information. The Flags field of this TLV is interpreted according to OSPFv2 <xre f target="RFC7684" format="default"/>. Thus, the Flags field of the BGP-LS Prefi x Attribute Flags TLV also conveys the anycast property introduced by this docum ent.</t>
</section> </section>
<section title="YANG Data Model"> <section>
<name>YANG Data Model</name>
<t> <t>
YANG <xref target="RFC7950"></xref> is a data definition language YANG <xref target="RFC7950"/> is a data definition language
used to define the contents of a conceptual data store used to define the contents of a conceptual data store
that allows networked devices to be managed using NETCONF that allows networked devices to be managed using Network Configuration Protocol (NETCONF)
<xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
</t> </t>
<t> <t>
This section defines a YANG data model that can be used to manage the us age of OSPFv2 Anycast Property as defined in this document, which augments the O SPF YANG data model <xref target="RFC9129"/> and the YANG Data Model for Routing Management <xref target="RFC8349"/>. This section defines a YANG data model that can be used to manage the us age of the OSPFv2 Anycast Property as defined in this document, which augments t he OSPF YANG data model <xref target="RFC9129"/> and the YANG Data Model for Rou ting Management <xref target="RFC8349"/>.
</t> </t>
<section title="Tree for the YANG Data Model"> <section>
<name>Tree for the YANG Data Model</name>
<t>This document uses the graphical representation of data models per <x ref target="RFC8340"/>.</t> <t>This document uses the graphical representation of data models per <x ref target="RFC8340"/>.</t>
<t>The following shows the tree diagram of the module:</t> <t>The following shows the tree diagram of the module:</t>
<artwork align="left" name="" type="" alt=""><![CDATA[
<!--[rfced] FYI: we have put the YANG Tree in the "Tree for the YANG
Data Model" section in <sourcecode> with type="yangtree". -->
<sourcecode type="yangtree"><![CDATA[
module: ietf-ospf-anycast-flag module: ietf-ospf-anycast-flag
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area /rt:control-plane-protocol/ospf:ospf/ospf:areas/ospf:area
/ospf:interfaces/ospf:interface: /ospf:interfaces/ospf:interface:
+--rw anycast-flag? boolean +--rw anycast-flag? boolean]]></sourcecode>
]]></artwork>
</section> </section>
<section title="YANG Data Model for OSPFv2 Anycast Property Advertisement" <section>
> <name>YANG Data Model for OSPFv2 Anycast Property Advertisement</name>
<t>The "ietf-ospf-anycast-flag" module defined in this document imports <t>The "ietf-ospf-anycast-flag" module defined in this document imports
typedefs from <xref target="RFC8349"/>and <xref target="RFC9129"/>.</t> typedefs from <xref target="RFC8349"/> and <xref target="RFC9129"/>.</t>
<sourcecode name="ietf-ospf-anycast-flag@2026-01-14.yang" type="" marker
s="true"><![CDATA[ <!--[rfced] We had the following questions, comments, concerns
regarding the YANG Data Model in Section 4.2 itself:
a) Please note that we have added the BCP 14 keywords paragraph as we
see at least one use of MUST NOT in the description fields.
-->
<sourcecode name="ietf-ospf-anycast-flag@2026-05-12.yang" type="yang" ma
rkers="true"><![CDATA[
module ietf-ospf-anycast-flag { module ietf-ospf-anycast-flag {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag"; "urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag";
prefix ospf-anycast-flag; prefix ospf-anycast-flag;
import ietf-routing { import ietf-routing {
prefix rt; prefix rt;
reference reference
"RFC 8349: A YANG Data Model for Routing "RFC 8349: A YANG Data Model for Routing
skipping to change at line 254 skipping to change at line 228
<mailto:ppsenak@cisco.com> <mailto:ppsenak@cisco.com>
Author: Ketan Talaulikar Author: Ketan Talaulikar
<mailto:ketant.ietf@gmail.com> <mailto:ketant.ietf@gmail.com>
Author: Changwang Lin Author: Changwang Lin
<mailto:linchangwang.04414@h3c.com>"; <mailto:linchangwang.04414@h3c.com>";
description description
"This YANG module adds the support of managing an OSPFv2 "This YANG module adds the support of managing an OSPFv2
prefix as anycast. prefix as anycast.
Copyright (c) 2025 IETF Trust and the persons identified as 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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can All revisions of IETF and IANA published modules can
be found at the YANG Parameters registry group be found at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters); (https://www.iana.org/assignments/yang-parameters);
This version of this YANG module is part of RFC XXXX; This version of this YANG module is part of RFC 9983;
see the RFC itself for full legal notices."; see the RFC itself for full legal notices.";
revision 2026-01-14 { revision 2026-05-12 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: OSPFv2 Anycast Property Advertisement"; "RFC 9983: OSPFv2 Anycast Property Advertisement";
} }
identity ac-flag { identity ac-flag {
base ospf:ospfv2-extended-prefix-flag; base ospf:ospfv2-extended-prefix-flag;
description description
"Indicates that the prefix is configured as anycast."; "Indicates that the prefix is configured as anycast.";
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/ospf:ospf/" + "rt:control-plane-protocol/ospf:ospf/"
skipping to change at line 315 skipping to change at line 295
"Ensures architectural consistency by preventing a prefix "Ensures architectural consistency by preventing a prefix
from being marked as both anycast and node-specific."; from being marked as both anycast and node-specific.";
} }
default "false"; default "false";
description description
"Indicates that the prefix is an anycast address, "Indicates that the prefix is an anycast address,
if set to 1 (true)."; if set to 1 (true).";
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document requests allocation for the following registry.</t> <t>IANA has allocated and/or registered the following values in their re spective registries.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>OSPFv2 Extended Prefix TLV Flags Registry</name> <name>OSPFv2 Extended Prefix TLV Flags Registry</name>
<t>This document requests the allocation of new value in the "OSPFv2 Exten <t>IANA has allocated the following value in the "OSPFv2 Extended Prefix T
ded Prefix TLV Flags" registry:</t> LV Flags" registry:</t>
<t>TBD:AC-flag (Anycast Flag).</t> <t>0x10: AC-Flag (Anycast Flag)</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>OSPFv2 Anycast Flag YANG Module Registry</name> <name>OSPFv2 Anycast Flag YANG Module Registration</name>
<t>IANA is requested to register the following URI in the "ns" registry wi <t>IANA has registered the following URI in the "ns" registry within the "
thin the "IETF XML Registry" group (<xref target="RFC3688" format="default"/>):< IETF XML Registry" registry group (see <xref target="RFC3688" format="default"/>
/t> ):</t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <dl spacing="compact" newline="false">
URI: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag <dt>ID:</dt><dd>yang:ietf-ospf-anycast-flag</dd>
Registrant Contact: The IESG. <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag</dd>
XML: N/A, the requested URI is an XML namespace <dt>Registrant Contact:</dt><dd>The IESG</dd>
]]></artwork> <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace</dd>
<t>IANA is requested to register the following YANG module in the "YANG Mo </dl>
dule Names" registry (<xref target="RFC6020" format="default"/>) within the "YAN <t>IANA has registered the following YANG module in the "YANG Module Names
G Parameters" registry group.</t> " registry (<xref target="RFC6020" format="default"/>) within the "YANG Paramete
<artwork align="left" name="" type="" alt=""><![CDATA[ rs" registry group.</t>
name: ietf-ospf-anycast-flag <dl spacing="compact" newline="false">
Maintained by IANA? N <dt>Name:</dt><dd>ietf-ospf-anycast-flag</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag <dt>Maintained by IANA?</dt><dd>N</dd>
prefix: ospf-anycast-flag <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ospf-anycast-flag
reference: RFC XXXX </dd>
]]></artwork> <dt>Prefix:</dt><dd>ospf-anycast-flag</dd>
<dt>Reference:</dt><dd>RFC 9983</dd>
</dl>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default"> <section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Protocol Security Considerations</name> <name>Protocol Security Considerations</name>
<t>Procedures and protocol extensions defined in this document do not affec <t>Procedures and protocol extensions defined in this document do not affec
t the OSPFv2 security model. See the "Security Considerations"section of <xref t t the OSPFv2 security model. See the "Security Considerations" section of <xref
arget="RFC7684" format="default"></xref> for a discussion of OSPFv2 security.</t target="RFC7684" format="default"/> for a discussion of OSPFv2 security.</t>
> <t>The newly introduced AC-Flag, which <bcp14>MUST</bcp14> be either set
<t>The newly introduced AC-flag, which MUST be either set or clear, intr or clear, introduces operational dependencies that impact the semantic validity
oduces operational dependencies that impact the semantic validity of the adverti of the advertised prefix. The correct semantic interpretation of the AC-Flag re
sed prefix. The correct semantic interpretation of the AC-flag relies on both ro lies on both router implementation support for the flag and accurate operator co
uter implementation support for the flag and accurate operator configuration of nfiguration of the anycast route. Consequently, receivers <bcp14>MUST</bcp14> co
the anycast route. Consequently, receivers MUST consider the possibility of misc nsider the possibility of misconfiguration or inconsistent implementation when r
onfiguration or inconsistent implementation when relying on the AC-flag for forw elying on the AC-Flag for forwarding or security decisions.</t>
arding or security decisions.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>YANG Security Considerations</name> <name>YANG Security Considerations</name>
<t>This section is modeled after the template described in Section 3.7 of < <t>This section is modeled after the template described in <xref section="3.
xref target="I-D.ietf-netmod-rfc8407bis"/>.</t> 7" target="RFC9907"/>.</t>
<t>The "ietf-ospf-anycast-flag" YANG module defines a data model that is de <!--[DNE Begins] Security Boilerplate -->
signed to be accessed via YANG-based management protocols, such as NETCONF <xref
target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These protocols have <t>The "ietf-ospf-anycast-flag" YANG module defines a data model that is de
to use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref t signed to be accessed via YANG-based management protocols, such as Network Confi
arget="RFC8446"/>, and QUIC <xref target="RFC9000"/>) and have to use mutual aut guration Protocol (NETCONF) <xref target="RFC6241"/> and RESTCONF <xref target="
hentication.</t> RFC8040"/>. These YANG-based management protocols (1) have to use a secure trans
port layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, an
d QUIC <xref target="RFC9000"/>) and (2) have to use mutual authentication.</t>
<t>The Network Configuration Access Control Model (NACM) <xref target="RFC8 341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol op erations and content.</t> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC8 341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol op erations and content.</t>
<t>There is a data node defined in this YANG module that is writable/creata
ble/deletable (i.e., config true, which is the default). This data node can be c <!--[rfced] We note the following deviations from the template at
onsidered sensitive or vulnerable in some network environments. Write operations https://wiki.ietf.org/group/ops/yang-security-guidelines:
(e.g., edit-config) to this data node without proper protection can have a nega
tive effect on network operations. Specifically, the following subtree and data a) All writable data nodes vs. This data node
node have particular sensitivities/vulnerabilities:</t>
<ul empty="true" spacing="normal"> Template:
<li>/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf- All writable data nodes are likely to be reasonably sensitive or
anycast-flag:anycast-flag</li> vulnerable...
</ul>
<t>As specified in Section 2, the AC-flag and the N-flag MUST NOT both be s This document:
et to 1. This rule is enforced by a "must" constraint in the YANG module to prev This data node can be considered sensitive or vulnerable...
ent configuration anomalies. The handling of such anomalies is defined in Sectio
n 2. Modifications to this data node without proper protection could prevent int Please let us know if/how to update.
erpreting the IPv4 prefix as anycast or node-specific.</t>
<t>The readable data node in this YANG module may be considered sensitiv b) We have added "and delete operations" and "or authentication" in
e or vulnerable in some network environments. It is thus important to control re the text below. Please let us know any objections.
ad access (e.g., via get, get-config, or notification) to this data node. Specif
ically, the following subtree and data node have particular sensitivities/vulner Original:
abilities:</t> Write operations (e.g., edit-config) to this
<ul empty="true" spacing="normal"> data node without proper protection can have a negative effect on
<li>/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf- network operations.
anycast-flag:anycast-flag</li>
</ul> Current (matches template):
Write operations (e.g., edit-config) and delete operations to this
data node without proper protection or authentication can have a
negative effect on network operations.
c) FYI - We have left this variance as was. Please let us know
objections.
At the template:
The following subtrees and data nodes...
In the doc:
Specifically, the following subtree and data node...
d) FYI - We have left this variance as was. Please let us know objections.
At the template:
Some of the readable data nodes...
In the doc:
The readable data node...
-->
<t>There is a data node defined in this YANG module that is writable/creata
ble/deletable (i.e., config true, which is the default). This data node can be c
onsidered sensitive or vulnerable in some network environments. Write operations
(e.g., edit-config) and delete operations to this data node without proper prot
ection or authentication can have a negative effect on network operations. Speci
fically, the following subtree and data node have particular sensitivities/vulne
rabilities:</t>
<t indent="3">/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interfac
e/ospf-anycast-flag:anycast-flag</t>
<t>As specified in <xref target="sect-2"/>, the AC-Flag and the N-flag <bcp
14>MUST NOT</bcp14> both be set to 1. This rule is enforced by a "must" constrai
nt in the YANG module to prevent configuration anomalies. The handling of such a
nomalies is defined in <xref target="sect-2"/>. Modifications to this data node
without proper protection could prevent interpreting the IPv4 prefix as anycast
or node-specific.</t>
<t>The readable data node in this YANG module may be considered sensitive o
r vulnerable in some network environments. It is thus important to control read
access (e.g., via get, get-config, or notification) to this data node. Specifica
lly, the following subtree and data node have particular sensitivities/vulnerabi
lities:</t>
<t indent="3">/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interfac
e/ospf-anycast-flag:anycast-flag</t>
<t>Unauthorized access to the data node of this subtree can disclose specif ic anycast property information for OSPF prefixes on a device.</t> <t>Unauthorized access to the data node of this subtree can disclose specif ic anycast property information for OSPF prefixes on a device.</t>
<t>There are no particularly sensitive RPC or action operations.</t> <t>There are no particularly sensitive RPC or action operations.</t>
<!--[DNE ENDS -->
</section> </section>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries <references>
:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (
as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml
"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
ml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included fil
es in the same
directory as the including file. You can also define the XML_LIBRARY environ
ment variable
with a value containing a set of directories to search. These can be either
in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RF <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
C.2119.xml"?--> 119.xml"/>
<?rfc include="reference.RFC.2119.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<?rfc include="reference.RFC.3688.xml"?> 688.xml"/>
<?rfc include="reference.RFC.6020.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<?rfc include="reference.RFC.7684.xml"?> 020.xml"/>
<?rfc include="reference.RFC.7950.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.76
<?rfc include="reference.RFC.8174.xml"?> 84.xml"/>
<?rfc include="reference.RFC.8341.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include="reference.RFC.8349.xml"?> 950.xml"/>
<?rfc include="reference.RFC.9085.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<?rfc include="reference.RFC.9129.xml"?> 74.xml"/>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<references> 341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
349.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
85.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
129.xml"/>
</references>
<references>
<name>Informative References</name> <name>Informative References</name>
<?rfc include='reference.I-D.ietf-netmod-rfc8407bis'?> <!-- [I-D.ietf-netmod-rfc8407bis] published as RFC 9907
<?rfc include="reference.RFC.4252.xml"?> -->
<?rfc include="reference.RFC.8340.xml"?>
<?rfc include="reference.RFC.8446.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.99
<?rfc include="reference.RFC.9000.xml"?> 07.xml"/>
<?rfc include="reference.RFC.9513.xml"?>
<?rfc include="reference.RFC.9352.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.42
<?rfc include="reference.RFC.6241.xml"?> 52.xml"/>
<?rfc include="reference.RFC.8040.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
</references> 40.xml"/>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC=" 446.xml"/>
false" pn="section-appendix.a"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<name slugifiedName="name-acknowledgements">Acknowledgements</name> 000.xml"/>
<t indent="0" pn="section-appendix.a-1">The authors would like to thank <c <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
ontact fullname="Acee Lindem"/> for aligning the terminology with existing OSPF 13.xml"/>
documents and for editorial improvements. </t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
</section> 52.xml"/>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appendi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
x.b"> 41.xml"/>
<name slugifiedName="name-contributors">Contributors</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
<t indent="0" pn="section-appendix.b-1">This document has the following co 40.xml"/>
ntributor:</t> </references>
</references>
<section anchor="Acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Acee Lindem"/> for al
igning the terminology with existing OSPF documents and for editorial improvemen
ts.</t>
</section>
<section numbered="false">
<name>Contributors</name>
<t>This document has the following contributor:</t>
<contact fullname="Yingzhen Qu"> <contact fullname="Yingzhen Qu">
<organization showOnFrontPage="true">Futurewei Technologies</organizatio n> <organization>Futurewei Technologies</organization>
<address> <address>
<email>yingzhen.ietf@gmail.com</email> <email>yingzhen.ietf@gmail.com</email>
</address> </address>
</contact> </contact>
</section> </section>
<!-- Change Log
v00 2006-03-15 EBD Initial version <!--[rfced] We had the following questions/comments related to
terminology use throughout the document:
v01 2006-04-03 EBD Moved PI location back to position 1 - a) We have updated to use AC-Flag consistently throughout to match the
v3.1 of XMLmind is better with them at this location. use in the IANA section.
v02 2007-03-07 AH removed extraneous nested_list attribute, -->
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading cap <!--[rfced] We had the following questions/comments related to
italization. abbreviation use throughout the document:
Modified comments around figure to reflect non-implementati
on of a) Please note that we have expanded abbreviations on first use.
figure indent control. Put in reference using anchor="DOMI Please review for accuracy.
NATION".
Fixed up the date specification comments to reflect current -->
truth. <!-- [rfced] Please review the "Inclusive Language" portion of the
v04 2007-03-09 AH Major changes: shortened discussion of PIs, online Style Guide
added discussion of rfc include. <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and and let us know if any changes are needed. Updates of this
alternative nature typically result in more precise language, which is
images. Removed meta-characters from comments (causes probl helpful for readers.
ems).
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->
v06 2010-04-01 TT Changed ipr attribute values to latest ones. Changed date
to
year only, to be consistent with the comments. Updated the
IANA guidelines reference from the I-D to the finished RFC.
v07 2020-01-21 HL Converted the template to use XML schema version 3.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 61 change blocks. 
343 lines changed or deleted 369 lines changed or added

This html diff was produced by rfcdiff 1.48.