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 ***** -->
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<!-- The abbreviated title is used in the page header - it is only necessary tf-lsr-anycast-flag-13"
if the number="9983" consensus="true" ipr="trust200902" obsoletes="" updates="" submiss
full title is longer than 39 characters --> ionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortR
efs="true" version="3">
<title abbrev="Anycast Property advertisement">OSPFv2 Anycast Property Advert <front>
isement</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lsr-anycast-flag-13"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor --> <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>Routing</area>
<workgroup>LSR</workgroup>
<!-- 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> <area>RTG</area>
<!-- Keywords will be incorporated into HTML output <workgroup>lsr</workgroup>
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 <t><xref target="RFC7684" format="default"/> defines OSPFv2 Opaque Link Sta
nal attributes with prefixes or links. The OSPFv2 Extended Prefix TLV that is co te Advertisements (LSAs) based on Type-Length-Value (TLV) tuples that can be use
ntained in the OSPFv2 Extended Prefix Opaque LSA is used to advertise additional d to associate additional attributes with prefixes or links. The OSPFv2 Extended
attributes associated with a prefix.</t> Prefix TLV that is contained in the OSPFv2 Extended Prefix Opaque LSA is used t
<t>Extensions related to the anycast property of prefixes have been spec o advertise additional attributes associated with a prefix.</t>
ified for IS-IS <xref target="RFC9352" format="default"></xref> and OSPFv3 <xref <t>Extensions related to the anycast property of prefixes have been spec
target="RFC9513" format="default"></xref>, even though those documents are rela ified for IS-IS <xref target="RFC9352" format="default"/> and OSPFv3 <xref targe
ted to Segment Routing over IPv6, the anycast property applies to any IP prefix t="RFC9513" format="default"/>, even though those documents are related to Segme
advertisement. This document defines a flag to advertise the anycast property fo nt Routing over IPv6, the anycast property applies to any IP prefix advertisemen
r a prefix advertisement in OSPFv2 in the Flags field of the OSPFv2 Extended Pre t. This document defines a flag to advertise the anycast property for a prefix a
fix TLV Flags (section 2.1 of <xref target="RFC7684" format="default"></xref>). dvertisement in OSPFv2 in the Flags field of the OSPFv2 Extended Prefix TLV Flag
The document also specifies a companion YANG module for managing this function.< s (<xref target="RFC7684" section="2.1"/>). The document also specifies a compan
/t> 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[
<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[ <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
Management (NMDA Version)"; Management (NMDA Version)";
} }
import ietf-ospf { import ietf-ospf {
prefix ospf; prefix ospf;
skipping to change at line 254 skipping to change at line 181
<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 248
"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
signed to be accessed via YANG-based management protocols, such as NETCONF <xref <t>The "ietf-ospf-anycast-flag" YANG module defines a data model that is de
target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These protocols have signed to be accessed via YANG-based management protocols, such as Network Confi
to use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref t guration Protocol (NETCONF) <xref target="RFC6241"/> and RESTCONF <xref target="
arget="RFC8446"/>, and QUIC <xref target="RFC9000"/>) and have to use mutual aut RFC8040"/>. These YANG-based management protocols (1) have to use a secure trans
hentication.</t> 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 <t>There is a data node defined in this YANG module that is writable/creata
onsidered sensitive or vulnerable in some network environments. Write operations ble/deletable (i.e., config true, which is the default). This data node can be c
(e.g., edit-config) to this data node without proper protection can have a nega onsidered sensitive or vulnerable in some network environments. Write operations
tive effect on network operations. Specifically, the following subtree and data (e.g., edit-config) and delete operations to this data node without proper prot
node have particular sensitivities/vulnerabilities:</t> ection or authentication can have a negative effect on network operations. Speci
<ul empty="true" spacing="normal"> fically, the following subtree and data node have particular sensitivities/vulne
<li>/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf- rabilities:</t>
anycast-flag:anycast-flag</li>
</ul> <t indent="3">/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interfac
<t>As specified in Section 2, the AC-flag and the N-flag MUST NOT both be s e/ospf-anycast-flag:anycast-flag</t>
et to 1. This rule is enforced by a "must" constraint in the YANG module to prev
ent configuration anomalies. The handling of such anomalies is defined in Sectio <t>As specified in <xref target="sect-2"/>, the AC-Flag and the N-flag <bcp
n 2. Modifications to this data node without proper protection could prevent int 14>MUST NOT</bcp14> both be set to 1. This rule is enforced by a "must" constrai
erpreting the IPv4 prefix as anycast or node-specific.</t> nt in the YANG module to prevent configuration anomalies. The handling of such a
<t>The readable data node in this YANG module may be considered sensitiv nomalies is defined in <xref target="sect-2"/>. Modifications to this data node
e or vulnerable in some network environments. It is thus important to control re without proper protection could prevent interpreting the IPv4 prefix as anycast
ad access (e.g., via get, get-config, or notification) to this data node. Specif or node-specific.</t>
ically, the following subtree and data node have particular sensitivities/vulner <t>The readable data node in this YANG module may be considered sensitive o
abilities:</t> r vulnerable in some network environments. It is thus important to control read
<ul empty="true" spacing="normal"> access (e.g., via get, get-config, or notification) to this data node. Specifica
<li>/ospf:ospf/ospf:areas/ospf:area/ospf:interfaces/ospf:interface/ospf- lly, the following subtree and data node have particular sensitivities/vulnerabi
anycast-flag:anycast-flag</li> lities:</t>
</ul>
<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>
</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
:
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. <references>
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'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.99
<?rfc include="reference.RFC.4252.xml"?> 07.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.42
<?rfc include="reference.RFC.9000.xml"?> 52.xml"/>
<?rfc include="reference.RFC.9513.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.83
<?rfc include="reference.RFC.9352.xml"?> 40.xml"/>
<?rfc include="reference.RFC.6241.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include="reference.RFC.8040.xml"?> 446.xml"/>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</references> 000.xml"/>
<section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC=" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.95
false" pn="section-appendix.a"> 13.xml"/>
<name slugifiedName="name-acknowledgements">Acknowledgements</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
<t indent="0" pn="section-appendix.a-1">The authors would like to thank <c 52.xml"/>
ontact fullname="Acee Lindem"/> for aligning the terminology with existing OSPF <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.62
documents and for editorial improvements. </t> 41.xml"/>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
<section numbered="false" toc="include" removeInRFC="false" pn="section-appendi 40.xml"/>
x.b"> </references>
<name slugifiedName="name-contributors">Contributors</name> </references>
<t indent="0" pn="section-appendix.b-1">This document has the following co
ntributor:</t> <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
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
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
italization.
Modified comments around figure to reflect non-implementati
on of
figure indent control. Put in reference using anchor="DOMI
NATION".
Fixed up the date specification comments to reflect current
truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and
alternative
images. Removed meta-characters from comments (causes probl
ems).
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. 57 change blocks. 
352 lines changed or deleted 253 lines changed or added

This html diff was produced by rfcdiff 1.48.