<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" docName="draft-ietf-lsr-igp-ureach-prefix-announce-11" number="9929" ipr="trust200902" obsoletes="" updates="" consensus="true" xml:lang="en" submissionType="IETF" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2026-02-27T15:03:15" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce-11" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9929" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IGP Unreachable Prefix Announcement">IGP Unreachable Prefix Announcement</title>
    <seriesInfo name="RFC" value="9929" stream="IETF"/>
    <author fullname="Peter Psenak" initials="P" role="editor" surname="Psenak">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <street>Pribinova Street 10</street>
          <city>Bratislava 81109</city>
          <country>Slovakia</country>
        </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <postal>
          <city>Brussels</city>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Daniel Voyer" initials="D" surname="Voyer">
      <organization showOnFrontPage="true">Cisco Systems</organization>
      <address>
        <email>davoyer@cisco.com</email>
      </address>
    </author>
    <author fullname="Shraddha Hegde" initials="S" surname="Hegde">
      <organization showOnFrontPage="true">HPE</organization>
      <address>
        <email>shraddha.hegde@hpe.com</email>
      </address>
    </author>
    <author fullname="Gyan Mishra" initials="G." surname="Mishra">
      <organization showOnFrontPage="true">Verizon Inc.</organization>
      <address>
        <email>hayabusagsm@gmail.com</email>
      </address>
    </author>
    <date month="02" year="2026"/>
    <area>RTG</area>
    <workgroup>lsr</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">Summarization is often used in multi-area or multi-domain networks to improve 
      network efficiency and scalability. With summarization in place, there is a need 
      to signal loss of reachability to an individual prefix covered by the summary. 
      This enables fast convergence by steering traffic, when applicable, away from the 
      node which owns the prefix and is no longer reachable.</t>
      <t indent="0" pn="section-abstract-2">This document specifies protocol mechanisms in IS-IS and OSPF, together with 
      two new flags, to advertise such prefix reachability loss.</t>
      <t indent="0" pn="section-abstract-3">The term "OSPF" in this document is used to refer to both OSPFv2 and OSPFv3.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9929" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2026 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generation-of-the-upa">Generation of the UPA</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-supporting-upa-in-is-is">Supporting UPA in IS-IS</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advertisement-of-upa-in-is-">Advertisement of UPA in IS-IS</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signaling-upa-in-is-is">Signaling UPA in IS-IS</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-propagation-of-upa-in-is-is">Propagation of UPA in IS-IS</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-supporting-upa-in-ospf">Supporting UPA in OSPF</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advertisement-of-upa-in-osp">Advertisement of UPA in OSPF</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signaling-upa-in-ospf">Signaling UPA in OSPF</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signaling-upa-in-ospfv2">Signaling UPA in OSPFv2</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signaling-upa-in-ospfv3">Signaling UPA in OSPFv3</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-propagation-of-upa-in-ospf">Propagation of UPA in OSPF</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-processing-of-the-upa">Processing of the UPA</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-area-and-domain-partition">Area and Domain Partition</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-is-is-prefix-attribute-flag">IS-IS Prefix Attribute Flags Sub-TLV</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ospfv2-and-ospfv3-prefix-ex">OSPFv2 and OSPFv3 Prefix Extended Flags</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Link-state Interior Gateway Protocols (IGPs) like Intermediate
      System to Intermediate System (IS-IS) <xref target="ISO10589" format="default" sectionFormat="of" derivedContent="ISO10589"/>, Open Shortest Path 
      First version 2 (OSPFv2)) <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>, and Open Shortest Path 
      First version 3 (OSPFv3) <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/> are primarily used to
      distribute routing information between routers belonging to a single
      Autonomous System (AS) and to calculate the reachability for IPv4 or
      IPv6 prefixes advertised by the individual nodes inside the AS. Each
      node advertises the state of its local adjacencies, connected prefixes,
      capabilities, etc. The collection of these states from all the routers
      inside the area form a Link State Database (LSDB) that describes the
      topology of the area and holds additional state information about the
      prefixes, router capabilities, etc.</t>
      <t indent="0" pn="section-1-2">The growth of networks running a link-state routing protocol results
      in the addition of more state, which leads to scalability and convergence
      challenges. The organization of networks into levels/areas and IGP
      domains helps limit the scope of link-state information within certain
      boundaries. However, the state related to prefix reachability often
      requires propagation across a multi-area/level and/or multi-domain IGP
      network. IGP summarization is a network engineering technique for combining 
      multiple smaller, contiguous IP networks into a single, larger summary route.
      Techniques such as summarization have been used to address the scaling 
      challenges associated with advertising prefix state outside of the local area/domain. 
      However, this results in suppression of the individual prefix state that is useful 
      for triggering fast-convergence mechanisms outside of the IGPs -- e.g., 
      Border Gateway Protocol (BGP) Prefix-Independent Convergence (PIC) 
      <xref target="I-D.ietf-rtgwg-bgp-pic" format="default" sectionFormat="of" derivedContent="BGP-PIC"/>.</t>
      <t indent="0" pn="section-1-3">Similarly, when a router needs to be taken out of service for maintenance,
      the traffic is drained from the node before taking it down. This is typically 
      achieved by setting the OVERLOAD bit together with using a high metric for all prefixes 
      advertised by the node in IS-IS.
The mechanisms available for that purpose are (in OSPFv2) using the cost 
of MaxLinkMetric for all non-stub links in the router-LSA <xref target="RFC6987" format="default" sectionFormat="of" derivedContent="RFC6987"/> or using 
the H-bit <xref target="RFC8770" format="default" sectionFormat="of" derivedContent="RFC8770"/>, or (in OSPFv3 <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>) using the R-bit.
</t>
      <t indent="0" pn="section-1-4">When prefixes from such nodes are summarized
      by an Area Border Router (ABR) or Autonomous System Boundary Router (ASBR), 
      nodes outside of the area or domain are unaware of these summarized 
      prefixes becoming unreachable. This document proposes protocol extensions to carry
      information about such prefixes in a backward-compatible manner.</t>
      <t indent="0" pn="section-1-5">This document does not define how to advertise a prefix that is not reachable for 
      routing. That has been defined for IS-IS in <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/> and
      <xref target="RFC5308" format="default" sectionFormat="of" derivedContent="RFC5308"/>, for OSPFv2 in <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>, and for OSPFv3 
      in <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>.</t>
      <t indent="0" pn="section-1-6">This document defines a method to signal a specific reason for which the
      prefix was advertised with the metric that excludes it from the route calculation. 
      This is done to distinguish it from any other possible cases, where such 
      metric advertisement may be used.</t>
      <t indent="0" pn="section-1-7">IGPs typically only advertise the reachability of the prefix. A prefix that was 
      previously advertised as reachable is made unreachable just by withdrawing the
      previous advertisement of the prefix. Some of the use cases mentioned earlier in this 
      section require that unreachability be signaled for a prefix for which the reachability 
      was not explicitly signaled previously, because it was covered by the 
      reachability of the summary prefix.</t>
      <t indent="0" pn="section-1-8">This document defines two new flags in IS-IS, OSPFv2, and OSPFv3.  
      These flags provide the support for advertising prefix unreachability, 
      together with the reason for which the unreachability is advertised. The 
      functionality being described is called Unreachable Prefix Announcement (UPA).</t>
      <t indent="0" pn="section-1-9">This document also defines how the UPA is propagated across IS-IS levels and 
      OSPF areas.</t>
      <t indent="0" pn="section-1-10">The term "OSPF" in this document is used to cover both OSPFv2 and OSPFv3 protocols.</t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-1.1-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
    </section>
    <section anchor="UPA-GEN" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-generation-of-the-upa">Generation of the UPA</name>
      <t indent="0" pn="section-2-1">UPA <bcp14>MAY</bcp14> be generated by an ABR or ASBR for a prefix that is summarized by the 
      summary prefix originated by an ABR or ASBR in the following cases:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-2-2">

	<li pn="section-2-2.1" derivedCounter="1.">A prefix that was reachable earlier becomes unreachable.</li>
        <li pn="section-2-2.2" derivedCounter="2.">
          <t indent="0" pn="section-2-2.2.1">For any of the planned maintenance cases:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2-2.2.2">
            <li pn="section-2-2.2.2.1">the node originating the prefix is signaling the overload
          state in IS-IS, or the H-bit in OSPFv2 <xref target="RFC8770" format="default" sectionFormat="of" derivedContent="RFC8770"/>, or
          the R-bit in OSPFv3 <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>, or</li>
            <li pn="section-2-2.2.2.2">the metric to reach the prefix from an ABR or ASBR crosses the
          configured threshold.</li>
          </ul>
        </li>
      </ol>
      <t indent="0" pn="section-2-3">Generation as well as propagation of the UPA at an ABR or ASBR is optional 
      and <bcp14>SHOULD</bcp14> be controlled by a configuration knob. It <bcp14>SHOULD</bcp14> be disabled by default.</t>
      <t indent="0" pn="section-2-4">Implementations <bcp14>MAY</bcp14> limit the UPA generation as well as propagation to specific 
      prefixes, e.g. host prefixes, Segment Routing over IPv6 (SRv6) locators, or similar. Such filtering is optional
      and <bcp14>SHOULD</bcp14> be controlled via configuration.</t>
      <t indent="0" pn="section-2-5">The intent of UPA is to provide an event-driven signal of the transition of 
      a destination from reachable to unreachable. It is not intended to advertise 
      a persistent state.</t>
      <t indent="0" pn="section-2-6">ABR or ASBR <bcp14>MUST</bcp14> withdraw the previously advertised UPA when the reason for which 
      the UPA was generated ceases, e.g., prefix reachability was restored or its metric 
      has changed such that it is below a configured threshold value.</t>
      <t indent="0" pn="section-2-7">Even if the reasons persist, UPA advertisements <bcp14>SHOULD</bcp14> be withdrawn after some 
      amount of time, that would provide sufficient time for UPA to be flooded 
      network-wide and acted upon by receiving nodes, but limits the presence of UPA 
      in the network.  The time the UPA is kept in the network <bcp14>SHOULD</bcp14> also reflect the 
      intended use case for which the UPA was advertised. Not withdrawing the UPA 
      would result in stale information being kept in the link state databases of all 
      routers in the area.</t>
      <t indent="0" pn="section-2-8">Implementations <bcp14>SHOULD</bcp14> provide a configuration option to specify the UPA lifetime at 
      the originating ABR or ASBR.</t>
      <t indent="0" pn="section-2-9">As UPA advertisements in IS-IS are advertised in existing Link State PDUs
      (LSPs) and the unit of flooding in IS-IS is an LSP, it is <bcp14>RECOMMENDED</bcp14> that, when 
      possible, UPAs are advertised in LSPs dedicated to this type of advertisement.  
      This will minimize the number of LSPs that need to be updated when UPAs are 
      advertised and withdrawn.</t>
      <t indent="0" pn="section-2-10">In OSPFv2 and OSPFv3, each inter-area and external prefix is advertised in its 
      own LSA, so the above consideration does not apply to OSPFv2 and OSPFv3.</t>
      <t indent="0" pn="section-2-11">It is also <bcp14>RECOMMENDED</bcp14> that implementations limit the number of UPA advertisements 
      that can be originated at a given time to limit the number of UPAs present
      in the network at any given point of time. UPA implementations <bcp14>SHOULD</bcp14> provide a 
      configuration option to limit the number of such UPAs.</t>
    </section>
    <section anchor="UPA-IS-IS" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-supporting-upa-in-is-is">Supporting UPA in IS-IS</name>
      <t indent="0" pn="section-3-1"><xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/> defines the encoding for advertising IPv4
      prefixes using 4 octets of metric information, and <xref target="RFC5305" section="4" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc5305#section-4" derivedContent="RFC5305"/> specifies:</t>
      <blockquote pn="section-3-2">
        <t indent="0" pn="section-3-2.1">If a prefix is advertised with a metric larger than MAX_PATH_METRIC
      (0xFE000000, see paragraph 3.0), this prefix <bcp14>MUST NOT</bcp14> be considered
      during the normal SPF computation. This allows advertisement of a prefix
      for purposes other than building the normal IP routing table.</t>
      </blockquote>
      <t indent="0" pn="section-3-3">Similarly, <xref target="RFC5308" format="default" sectionFormat="of" derivedContent="RFC5308"/> defines the encoding for
      advertising IPv6 prefixes using 4 octets of metric information and
      <xref target="RFC5308" section="2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc5308#section-2" derivedContent="RFC5308"/> states:</t>
      <blockquote pn="section-3-4">
        <t indent="0" pn="section-3-4.1">...if a prefix is advertised with a metric larger than
      MAX_V6_PATH_METRIC (0xFE000000), this prefix <bcp14>MUST NOT</bcp14> be considered
      during the normal Shortest Path First (SPF) computation. This will allow
      advertisement of a prefix for purposes other than building the normal
      IPv6 routing table.</t>
      </blockquote>
      <t indent="0" pn="section-3-5">This functionality can be used to advertise a prefix (IPv4 or IPv6)
      in a manner that indicates that reachability has been lost -- and to do
      so without requiring all nodes in the network to be upgraded to support
      the functionality.</t>
      <section anchor="UPA-IS-IS-ADV" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-advertisement-of-upa-in-is-">Advertisement of UPA in IS-IS</name>
        <t indent="0" pn="section-3.1-1">Existing nodes in a network that do not support UPA will not use UPAs 
        during the route calculation but will continue to flood them within the area. 
        This allows flooding of such advertisements to occur without the need to 
        upgrade all nodes in a network to support this specification.</t>
        <t indent="0" pn="section-3.1-2"> Those ABRs or ASBRs that are responsible for propagating UPA advertisements 
        into other areas or domains are also expected to recognize UPA advertisements.</t>
        <t indent="0" pn="section-3.1-3">As per the definitions referenced in <xref target="UPA-IS-IS" format="default" sectionFormat="of" derivedContent="Section 3"/>, any 
        prefix advertisement with a metric value greater than 0xFE000000 can
        be used for purposes other than normal routing calculations. Such a metric 
        <bcp14>MUST</bcp14> be used when advertising UPA in IS-IS.</t>
        <t indent="0" pn="section-3.1-4"><xref target="RFC7370" format="default" sectionFormat="of" derivedContent="RFC7370"/> introduced the "IS-IS Sub-TLVs for TLVs Advertising Prefix 
        Reachability" registry, which lists TLVs for advertising different types of prefix
        reachability. (The list at the time of publication of this document is below.)
        UPA in IS-IS is supported for prefixes advertised in all such TLVs identified 
        by that registry, for example:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-5">
          <li pn="section-3.1-5.1">SRv6 Locator <xref target="RFC9352" format="default" sectionFormat="of" derivedContent="RFC9352"/></li>
          <li pn="section-3.1-5.2">Extended IP reachability <xref target="RFC5305" format="default" sectionFormat="of" derivedContent="RFC5305"/></li>
          <li pn="section-3.1-5.3">Multi-Topology (MT) IP Reach <xref target="RFC5120" format="default" sectionFormat="of" derivedContent="RFC5120"/></li>
          <li pn="section-3.1-5.4">IPv6 IP Reach <xref target="RFC5308" format="default" sectionFormat="of" derivedContent="RFC5308"/></li>
          <li pn="section-3.1-5.5">MT IPv6 IP Reach <xref target="RFC5120" format="default" sectionFormat="of" derivedContent="RFC5120"/></li>
          <li pn="section-3.1-5.6">IPv4 Algorithm Prefix Reachability TLV <xref target="RFC9502" format="default" sectionFormat="of" derivedContent="RFC9502"/></li>
          <li pn="section-3.1-5.7">IPv6 Algorithm Prefix Reachability TLV  <xref target="RFC9502" format="default" sectionFormat="of" derivedContent="RFC9502"/></li>
        </ul>
      </section>
      <section anchor="UPA-SIGN-IS-IS" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-signaling-upa-in-is-is">Signaling UPA in IS-IS</name>
        <t indent="0" pn="section-3.2-1">
   In IS-IS, a prefix can be advertised with a metric higher than
   0xFE000000, for various reasons.
   While IS-IS specifies the treatment of such metrics, explicit 
   signaling is required to distinguish UPA from other high-metric 
   advertisements.
        </t>
        <t indent="0" pn="section-3.2-2">Two new bits in the IPv4/IPv6 Extended Reachability Attribute Flags 
       <xref target="RFC7794" format="default" sectionFormat="of" derivedContent="RFC7794"/> are defined:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.2-3">
          <dt pn="section-3.2-3.1">U-Flag:</dt>
          <dd pn="section-3.2-3.2">Unreachable Prefix Flag (bit 5). When set, it indicates that the 
      prefix is unreachable.</dd>
          <dt pn="section-3.2-3.3">UP-Flag:</dt>
          <dd pn="section-3.2-3.4">Unreachable Planned Prefix Flag (bit 6). When set, this flag 
      indicates that the prefix is unreachable due to a planned event 
      (e.g., planned maintenance).</dd>
        </dl>
        <t indent="0" pn="section-3.2-4">The originating node <bcp14>MUST NOT</bcp14> set the UP-flag without setting the U-flag.</t>
        <t indent="0" pn="section-3.2-5">The receiving node <bcp14>MUST</bcp14> ignore the UP-flag in the advertisement if the U-flag is not set.</t>
        <t indent="0" pn="section-3.2-6">The prefix that is advertised with the U-flag <bcp14>MUST</bcp14> have the metric
      set to a value larger than 0xFE000000.  If the prefix metric is less
      than or equal 0xFE000000, both of these flags <bcp14>MUST</bcp14> be ignored.</t>
      </section>
      <section anchor="UPA-IS-IS-PROP" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-propagation-of-upa-in-is-is">Propagation of UPA in IS-IS</name>
        <t indent="0" pn="section-3.3-1">IS-IS L1/L2 routers, which would be responsible for propagating UPA 
        advertisements between levels, need to recognize such advertisements.
        Failure to do so would prevent UPA from reaching the routers in the remote areas.</t>
        <t indent="0" pn="section-3.3-2">IS-IS allows propagation of IP prefixes in both directions between level 1 and level 2. Propagation is only done if the prefix is reachable in the source level, 
        i.e., the prefix is only propagated from a level in which the prefix is reachable.
        Such requirement of reachability <bcp14>MUST NOT</bcp14> be applied for UPAs, as they are 
        propagating unreachability.</t>
        <t indent="0" pn="section-3.3-3">IS-IS L1/L2 routers may wish to advertise received UPAs into other areas (upwards
        and/or downwards). When propagating UPAs, the original metric value
        <bcp14>MUST</bcp14> be preserved. The cost to reach the originator of the received
        UPA <bcp14>MUST NOT</bcp14> be considered when readvertising the UPA.</t>
      </section>
    </section>
    <section anchor="UPA-OSPF" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-supporting-upa-in-ospf">Supporting UPA in OSPF</name>
      <t indent="0" pn="section-4-1"><xref section="B" target="RFC2328" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc2328#appendix-B" derivedContent="RFC2328"/> defines the following
      architectural constant for OSPFv2:</t>
      <blockquote pn="section-4-2">
        <dl newline="true" indent="3" spacing="normal" pn="section-4-2.1">
          <dt pn="section-4-2.1.1">LSInfinity</dt>
          <dd pn="section-4-2.1.2">The metric value indicating that the destination described
      by an LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
      an alternative to premature aging (see Section 14.1). It is defined to be the 24-bit
      binary value of all ones: 0xffffff.</dd>
        </dl>
      </blockquote>
      <t indent="0" pn="section-4-3"><xref section="B" target="RFC5340" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc5340#appendix-B" derivedContent="RFC5340"/> states:</t>
      <blockquote pn="section-4-4">
        <t indent="0" pn="section-4-4.1">Architectural constants for the OSPF protocol are defined in
      Appendix B of [OSPFV2].</t>
      </blockquote>
      <t indent="0" pn="section-4-5">indicating that these same constants are applicable to OSPFv3.</t>
      <t indent="0" pn="section-4-6"><xref target="RFC2328" section="14.1" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-14.1" derivedContent="RFC2328"/> also
      describes the usage of LSInfinity as a way to indicate loss of prefix
      reachability:</t>
      <blockquote pn="section-4-7">
        <t indent="0" pn="section-4-7.1">Premature aging can also be used when, for example, one of the
        router's previously advertised external routes is no longer
        reachable.  In this circumstance, the router can flush its AS-
        external-LSA from the routing domain via premature aging. This
        procedure is preferable to the alternative, which is to
        originate a new LSA for the destination specifying a metric of
        LSInfinity.</t>
      </blockquote>
      <t indent="0" pn="section-4-8">In addition, the NU-bit is defined for OSPFv3 <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>. Prefixes having 
     the NU-bit set in their PrefixOptions field are not included in the routing 
     calculation.</t>
      <t indent="0" pn="section-4-9">UPA in OSPFv2 is supported for prefix reachability advertised via 
      OSPFv2 Summary-LSA <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>, 
      AS-external-LSAs <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>, Not-So-Stubby Area (NSSA) AS-external-LSA <xref target="RFC3101" format="default" sectionFormat="of" derivedContent="RFC3101"/>, 
      and OSPFv2 IP Algorithm Prefix Reachability Sub-TLV <xref target="RFC9502" format="default" sectionFormat="of" derivedContent="RFC9502"/>.</t>
      <t indent="0" pn="section-4-10">UPA in OSPFv3 is supported for prefix reachability advertised via OSPFv3 
      E-Inter-Area-Prefix-LSA <xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC8362"/>, 
      E-AS-External-LSA <xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC8362"/>, E-Type-7-LSA <xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC8362"/>, 
      and SRv6 Locator LSA <xref target="RFC9513" format="default" sectionFormat="of" derivedContent="RFC9513"/>.</t>
      <t indent="0" pn="section-4-11">For prefix reachability advertised via Inter-Area-Prefix-LSA <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>, 
      AS-External-LSA <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>, NSSA-LSA <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>,
      UPA is signaled using their corresponding extended LSAs. This requires support of the  
      OSPFv3 Extended LSAs in a sparse mode as specified in <xref target="RFC8362" section="6.2" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8362#section-6.2" derivedContent="RFC8362"/>.</t>
      <section anchor="UPA-OSPF-ADV" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-advertisement-of-upa-in-osp">Advertisement of UPA in OSPF</name>
        <t indent="0" pn="section-4.1-1">If an ABR or ASBR advertises UPA in an advertisement of an inter-area or
      external prefix inside OSPFv2 or OSPFv3, then it <bcp14>MUST</bcp14> set the age
      to a value lower than MaxAge and set the metric to LSInfinity.</t>
        <t indent="0" pn="section-4.1-2">UPA flooding inside the area follows the existing standard procedures defined 
      by OSPFv2 <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/> and OSPFv3 <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>.</t>
      </section>
      <section anchor="UPA-SIGN-OSPF" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-signaling-upa-in-ospf">Signaling UPA in OSPF</name>
        <t indent="0" pn="section-4.2-1">
   A prefix can be advertised (in OSPFv2) with the LSInfinity metric or
   (in OSPFv3) with the NU-bit set in PrefixOptions, for various reasons.
   While OSPFv2 and OSPFv3 specify the treatment of the LSInfinity metric
   and the NU-bit, explicit signaling is required to distinguish UPA
   from other scenarios using the LSInfinity metric or NU-bit.
        </t>
        <t indent="0" pn="section-4.2-2">OSPFv2 and OSPFv3 Prefix Extended Flags Sub-TLVs been defined in 
       <xref target="RFC9792" format="default" sectionFormat="of" derivedContent="RFC9792"/> for advertising additional 
       prefix attribute flags in OSPFv2 and OSPFv3.</t>
        <t indent="0" pn="section-4.2-3">Two new bits in the Prefix Attribute Flags Sub-TLV are defined:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-4.2-4">
          <dt pn="section-4.2-4.1">U-Flag:</dt>
          <dd pn="section-4.2-4.2">Unreachable Prefix Flag (bit 0). When set, it indicates that the 
      prefix is unreachable.</dd>
          <dt pn="section-4.2-4.3">UP-Flag:</dt>
          <dd pn="section-4.2-4.4">Unreachable Planned Prefix Flag (bit 1). When set, this flag 
      indicates that the prefix is unreachable due to a planned event 
      (e.g., planned maintenance).</dd>
        </dl>
        <t indent="0" pn="section-4.2-5">The originating node <bcp14>MUST NOT</bcp14> set the UP-flag without setting the U-flag.</t>
        <t indent="0" pn="section-4.2-6">The receiving node <bcp14>MUST</bcp14> ignore the UP-flag in the advertisement if the U-flag is not set.</t>
        <section anchor="UPA-SIGN-OSPFv2" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.1">
          <name slugifiedName="name-signaling-upa-in-ospfv2">Signaling UPA in OSPFv2</name>
          <t indent="0" pn="section-4.2.1-1">The OSPFv2 Prefix Extended Flags Sub-TLV <xref target="RFC9792" format="default" sectionFormat="of" derivedContent="RFC9792"/> is a sub-TLV of 
     the OSPFv2 Extended Prefix TLV <xref target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/>.</t>
          <t indent="0" pn="section-4.2.1-2">
The prefix that is advertised with U-Flag or UP-Flag <bcp14>MUST</bcp14> have the metric set to a value LSInfinity. 
If the prefix metric is not equal to LSInfinity, both of these flags <bcp14>MUST</bcp14> be ignored. Therefore, for the prefixes in default algorithm 0 that are advertised with U-Flag, or Up-Flag, it is REQUIRED to advertise the unreachable prefix in the base OSPFv2 LSA, e.g., 
     e.g., OSPFv2 Summary-LSA <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>, or AS-external-LSAs 
     <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>, or NSSA AS-external LSA <xref target="RFC3101" format="default" sectionFormat="of" derivedContent="RFC3101"/>.</t>
        </section>
        <section anchor="UPA-SIGN-OSPFv3" numbered="true" removeInRFC="false" toc="include" pn="section-4.2.2">
          <name slugifiedName="name-signaling-upa-in-ospfv3">Signaling UPA in OSPFv3</name>
          <t indent="0" pn="section-4.2.2-1">OSPFv3 Prefix Extended Flags Sub-TLV is defined as a sub-TLV of the 
    following OSPFv3 TLVs that are defined in <xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC8362"/>:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.2-2">
            <li pn="section-4.2.2-2.1">Intra-Area-Prefix TLV</li>
            <li pn="section-4.2.2-2.2">Inter-Area-Prefix TLV</li>
            <li pn="section-4.2.2-2.3">External-Prefix TLV</li>
          </ul>
          <t indent="0" pn="section-4.2.2-3">The prefix that is advertised with U-Flag or UP-flag <bcp14>MUST</bcp14> have the metric set to 
    a value LSInfinity. For default algorithm 0 prefixes, the LSInfinity <bcp14>MUST</bcp14> be set 
    in the parent TLV. For IP Algorithm Prefixes <xref target="RFC9502" format="default" sectionFormat="of" derivedContent="RFC9502"/>,
    the LSInfinity <bcp14>MUST</bcp14> be set in OSPFv3 IP Algorithm Prefix Reachability sub-TLV. 
    If the prefix metric is not equal to LSInfinity, both of these flags <bcp14>MUST</bcp14> be ignored.</t>
          <t indent="0" pn="section-4.2.2-4">The prefix that is advertised with U-Flag or UP-Flag <bcp14>MUST</bcp14> have the NU-bit set 
    in the PrefixOptions of the parent TLV. If the NU-bit in PrefixOptions of the parent
    TLV is not set, both of these flags <bcp14>MUST</bcp14> be ignored.</t>
        </section>
      </section>
      <section anchor="UPA-OSPF-PROP" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-propagation-of-upa-in-ospf">Propagation of UPA in OSPF</name>
        <t indent="0" pn="section-4.3-1">OSPF ABRs, which would be responsible for propagating 
       UPA advertisements into other areas, need to recognize such advertisements. 
       Failure to do so would prevent UPA from reaching the routers in the remote areas.</t>
        <t indent="0" pn="section-4.3-2">Advertising prefix reachability between OSPF areas assumes prefix reachability 
       in a source area. Such a requirement of reachability <bcp14>MUST NOT</bcp14> be applied 
       for UPAs, as they are propagating unreachability.</t>
        <t indent="0" pn="section-4.3-3">OSPF ABRs or ASBRs <bcp14>MAY</bcp14> advertise received UPAs between connected 
       areas or domains.  When doing so, the original LSInfinity metric value in 
       UPA <bcp14>MUST</bcp14> be preserved. The cost to reach the originator of the received
       UPA <bcp14>MUST NOT</bcp14> be considered when readvertising the UPA to connected areas.</t>
      </section>
    </section>
    <section anchor="UPA-RXPROCESS" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-processing-of-the-upa">Processing of the UPA</name>
      <t indent="0" pn="section-5-1">Processing of the received UPAs is optional and <bcp14>SHOULD</bcp14> be controlled by the 
       configuration at the receiver. The receiver itself, based on its configuration, 
       decides what the UPA will be used for and what applications, if any, will be notified 
       when UPA is received. Usage of the UPA at the receiver is outside of the scope of this 
       document.</t>
      <t indent="0" pn="section-5-2">As an example, UPA may be used to trigger BGP PIC Edge at the receiving router
       <xref target="I-D.ietf-rtgwg-bgp-pic" format="default" sectionFormat="of" derivedContent="BGP-PIC"/>.</t>
      <t indent="0" pn="section-5-3">Applications using the UPA cannot use the absence of the UPA to infer that the 
       reachability of the prefix is back. They must rely on their own mechanisms to verify 
       the reachability of the remote endpoints.</t>
    </section>
    <section anchor="UPA-PARTITION" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-area-and-domain-partition">Area and Domain Partition</name>
      <t indent="0" pn="section-6-1">UPA is not meant to address an area/domain partition. When an area or domain partitions,
        while multiple ABRs or ASBRs advertise the same summary, each of them can only reach a portion
        of the summarized prefix. As a result, depending on which ABR or ASBR the traffic is using
        to enter a partitioned area, the traffic could be either dropped or delivered to its
        final destination. UPA does not make the problem of an area partition any worse. 
        In case of an area partition, each ABR or ASBR will generate UPAs for the 
        destinations for which the reachability was lost locally. As the UPA propagates to the 
        nodes outside a partitioned area, it may result in such nodes picking
        an alternative egress node for the traffic, if such a node exists.
        If such an alternative egress node resides outside a partitioned area, traffic will
        be restored. If such an alternative egress node resides in a partitioned area and is 
        covered by the summary, the traffic will be dropped if it enters a partitioned 
        area via an ABR or ASBR that cannot reach that node. This will result in 
        similar behavior as without the UPA. The above statements are also applicable to a
        domain partition.</t>
    </section>
    <section anchor="IANA" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="UBIT-IS-IS" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-is-is-prefix-attribute-flag">IS-IS Prefix Attribute Flags Sub-TLV</name>
        <t indent="0" pn="section-7.1-1">This document adds two new bits in the "IS-IS Bit Values for Prefix Attribute 
       Flags Sub-TLV" registry:</t>
        <dl newline="false" spacing="compact" indent="3" pn="section-7.1-2">
          <dt pn="section-7.1-2.1">Bit #:</dt>
          <dd pn="section-7.1-2.2">5</dd>
          <dt pn="section-7.1-2.3">Name:</dt>
          <dd pn="section-7.1-2.4">U-Flag</dd>
          <dt pn="section-7.1-2.5">Reference:</dt>
          <dd pn="section-7.1-2.6">RFC 9929 (<xref target="UPA-SIGN-IS-IS" format="default" sectionFormat="of" derivedContent="Section 3.2"/>)</dd>
        </dl>
        <dl newline="false" spacing="compact" indent="3" pn="section-7.1-3">
          <dt pn="section-7.1-3.1">Bit #:</dt>
          <dd pn="section-7.1-3.2">6</dd>
          <dt pn="section-7.1-3.3">Name:</dt>
          <dd pn="section-7.1-3.4">UP-Flag</dd>
          <dt pn="section-7.1-3.5">Reference:</dt>
          <dd pn="section-7.1-3.6">RFC 9929 (<xref target="UPA-SIGN-IS-IS" format="default" sectionFormat="of" derivedContent="Section 3.2"/>)</dd>
        </dl>
      </section>
      <section anchor="UBIT-OSPF" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-ospfv2-and-ospfv3-prefix-ex">OSPFv2 and OSPFv3 Prefix Extended Flags</name>
        <t indent="0" pn="section-7.2-1">This document adds two new bits in the "OSPFv2 Prefix Extended Flags" 
       and "OSPFv3 Prefix Extended Flags" registries:</t>
        <dl newline="false" spacing="compact" indent="3" pn="section-7.2-2">
          <dt pn="section-7.2-2.1">Bit:</dt>
          <dd pn="section-7.2-2.2">0</dd>
          <dt pn="section-7.2-2.3">Description:</dt>
          <dd pn="section-7.2-2.4">U-Flag</dd>
          <dt pn="section-7.2-2.5">Reference:</dt>
          <dd pn="section-7.2-2.6">RFC 9929 (<xref target="UPA-SIGN-OSPF" format="default" sectionFormat="of" derivedContent="Section 4.2"/>)</dd>
        </dl>
        <dl newline="false" spacing="compact" indent="3" pn="section-7.2-3">
          <dt pn="section-7.2-3.1">Bit:</dt>
          <dd pn="section-7.2-3.2">1</dd>
          <dt pn="section-7.2-3.3">Description:</dt>
          <dd pn="section-7.2-3.4">UP-Flag</dd>
          <dt pn="section-7.2-3.5">Reference:</dt>
          <dd pn="section-7.2-3.6">RFC 9929 (<xref target="UPA-SIGN-OSPF" format="default" sectionFormat="of" derivedContent="Section 4.2"/>)</dd>
        </dl>
      </section>
    </section>
    <section anchor="SEC_ISIS" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">The use of UPAs introduces the possibility that an attacker could
      inject a false, but apparently valid, UPA. However, the risk of this
      occurring is no greater than the risk today of an attacker injecting any
      other type of false advertisement.</t>
      <t indent="0" pn="section-8-2">The risks can be reduced by the use of existing security extensions
      as described in:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-3">
        <li pn="section-8-3.1">
          <xref target="RFC5304" format="default" sectionFormat="of" derivedContent="RFC5304"/>, <xref target="RFC5310" format="default" sectionFormat="of" derivedContent="RFC5310"/>, and <xref target="RFC7794" format="default" sectionFormat="of" derivedContent="RFC7794"/> for IS-IS.</li>
        <li pn="section-8-3.2">
          <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>, <xref target="RFC7474" format="default" sectionFormat="of" derivedContent="RFC7474"/>, and <xref target="RFC7684" format="default" sectionFormat="of" derivedContent="RFC7684"/> for OSPFv2.</li>
        <li pn="section-8-3.3">
          <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>, <xref target="RFC4552" format="default" sectionFormat="of" derivedContent="RFC4552"/>, and <xref target="RFC8362" format="default" sectionFormat="of" derivedContent="RFC8362"/> for OSPFv3.</li>
      </ul>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-rtgwg-bgp-pic" to="BGP-PIC"/>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="ISO10589" target="https://www.iso.org/en/contents/data/standard/03/09/30932.html" quoteTitle="true" derivedAnchor="ISO10589">
          <front>
            <title>Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)</title>
            <author>
              <organization abbrev="ISO/IEC" showOnFrontPage="true">International Organization for Standardization/International Electrotechnical Commission</organization>
            </author>
            <date month="Nov" year="2002"/>
          </front>
          <seriesInfo name="ISO/IEC" value="10589:2002"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2328" quoteTitle="true" derivedAnchor="RFC2328">
          <front>
            <title>OSPF Version 2</title>
            <author fullname="J. Moy" initials="J." surname="Moy"/>
            <date month="April" year="1998"/>
            <abstract>
              <t indent="0">This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="54"/>
          <seriesInfo name="RFC" value="2328"/>
          <seriesInfo name="DOI" value="10.17487/RFC2328"/>
        </reference>
        <reference anchor="RFC3101" target="https://www.rfc-editor.org/info/rfc3101" quoteTitle="true" derivedAnchor="RFC3101">
          <front>
            <title>The OSPF Not-So-Stubby Area (NSSA) Option</title>
            <author fullname="P. Murphy" initials="P." surname="Murphy"/>
            <date month="January" year="2003"/>
            <abstract>
              <t indent="0">This 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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3101"/>
          <seriesInfo name="DOI" value="10.17487/RFC3101"/>
        </reference>
        <reference anchor="RFC4552" target="https://www.rfc-editor.org/info/rfc4552" quoteTitle="true" derivedAnchor="RFC4552">
          <front>
            <title>Authentication/Confidentiality for OSPFv3</title>
            <author fullname="M. Gupta" initials="M." surname="Gupta"/>
            <author fullname="N. Melam" initials="N." surname="Melam"/>
            <date month="June" year="2006"/>
            <abstract>
              <t indent="0">This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4552"/>
          <seriesInfo name="DOI" value="10.17487/RFC4552"/>
        </reference>
        <reference anchor="RFC5120" target="https://www.rfc-editor.org/info/rfc5120" quoteTitle="true" derivedAnchor="RFC5120">
          <front>
            <title>M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)</title>
            <author fullname="T. Przygienda" initials="T." surname="Przygienda"/>
            <author fullname="N. Shen" initials="N." surname="Shen"/>
            <author fullname="N. Sheth" initials="N." surname="Sheth"/>
            <date month="February" year="2008"/>
            <abstract>
              <t indent="0">This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5120"/>
          <seriesInfo name="DOI" value="10.17487/RFC5120"/>
        </reference>
        <reference anchor="RFC5304" target="https://www.rfc-editor.org/info/rfc5304" quoteTitle="true" derivedAnchor="RFC5304">
          <front>
            <title>IS-IS Cryptographic Authentication</title>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="R. Atkinson" initials="R." surname="Atkinson"/>
            <date month="October" year="2008"/>
            <abstract>
              <t indent="0">This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.</t>
              <t indent="0">This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5304"/>
          <seriesInfo name="DOI" value="10.17487/RFC5304"/>
        </reference>
        <reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5305" quoteTitle="true" derivedAnchor="RFC5305">
          <front>
            <title>IS-IS Extensions for Traffic Engineering</title>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="H. Smit" initials="H." surname="Smit"/>
            <date month="October" year="2008"/>
            <abstract>
              <t indent="0">This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5305"/>
          <seriesInfo name="DOI" value="10.17487/RFC5305"/>
        </reference>
        <reference anchor="RFC5308" target="https://www.rfc-editor.org/info/rfc5308" quoteTitle="true" derivedAnchor="RFC5308">
          <front>
            <title>Routing IPv6 with IS-IS</title>
            <author fullname="C. Hopps" initials="C." surname="Hopps"/>
            <date month="October" year="2008"/>
            <abstract>
              <t indent="0">This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5308"/>
          <seriesInfo name="DOI" value="10.17487/RFC5308"/>
        </reference>
        <reference anchor="RFC5310" target="https://www.rfc-editor.org/info/rfc5310" quoteTitle="true" derivedAnchor="RFC5310">
          <front>
            <title>IS-IS Generic Cryptographic Authentication</title>
            <author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
            <author fullname="V. Manral" initials="V." surname="Manral"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="R. Atkinson" initials="R." surname="Atkinson"/>
            <author fullname="R. White" initials="R." surname="White"/>
            <author fullname="M. Fanto" initials="M." surname="Fanto"/>
            <date month="February" year="2009"/>
            <abstract>
              <t indent="0">This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.</t>
              <t indent="0">Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5310"/>
          <seriesInfo name="DOI" value="10.17487/RFC5310"/>
        </reference>
        <reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5340" quoteTitle="true" derivedAnchor="RFC5340">
          <front>
            <title>OSPF for IPv6</title>
            <author fullname="R. Coltun" initials="R." surname="Coltun"/>
            <author fullname="D. Ferguson" initials="D." surname="Ferguson"/>
            <author fullname="J. Moy" initials="J." surname="Moy"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <date month="July" year="2008"/>
            <abstract>
              <t indent="0">This 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).</t>
              <t indent="0">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).</t>
              <t indent="0">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.</t>
              <t indent="0">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]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5340"/>
          <seriesInfo name="DOI" value="10.17487/RFC5340"/>
        </reference>
        <reference anchor="RFC6987" target="https://www.rfc-editor.org/info/rfc6987" quoteTitle="true" derivedAnchor="RFC6987">
          <front>
            <title>OSPF Stub Router Advertisement</title>
            <author fullname="A. Retana" initials="A." surname="Retana"/>
            <author fullname="L. Nguyen" initials="L." surname="Nguyen"/>
            <author fullname="A. Zinin" initials="A." surname="Zinin"/>
            <author fullname="R. White" initials="R." surname="White"/>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <date month="September" year="2013"/>
            <abstract>
              <t indent="0">This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.</t>
              <t indent="0">This document obsoletes RFC 3137.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6987"/>
          <seriesInfo name="DOI" value="10.17487/RFC6987"/>
        </reference>
        <reference anchor="RFC7370" target="https://www.rfc-editor.org/info/rfc7370" quoteTitle="true" derivedAnchor="RFC7370">
          <front>
            <title>Updates to the IS-IS TLV Codepoints Registry</title>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <date month="September" year="2014"/>
            <abstract>
              <t indent="0">This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7370"/>
          <seriesInfo name="DOI" value="10.17487/RFC7370"/>
        </reference>
        <reference anchor="RFC7474" target="https://www.rfc-editor.org/info/rfc7474" quoteTitle="true" derivedAnchor="RFC7474">
          <front>
            <title>Security Extension for OSPFv2 When Using Manual Key Management</title>
            <author fullname="M. Bhatia" initials="M." surname="Bhatia"/>
            <author fullname="S. Hartman" initials="S." surname="Hartman"/>
            <author fullname="D. Zhang" initials="D." surname="Zhang"/>
            <author fullname="A. Lindem" initials="A." role="editor" surname="Lindem"/>
            <date month="April" year="2015"/>
            <abstract>
              <t indent="0">The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.</t>
              <t indent="0">This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7474"/>
          <seriesInfo name="DOI" value="10.17487/RFC7474"/>
        </reference>
        <reference anchor="RFC7684" target="https://www.rfc-editor.org/info/rfc7684" quoteTitle="true" derivedAnchor="RFC7684">
          <front>
            <title>OSPFv2 Prefix/Link Attribute Advertisement</title>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <author fullname="H. Gredler" initials="H." surname="Gredler"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <date month="November" year="2015"/>
            <abstract>
              <t indent="0">OSPFv2 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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7684"/>
          <seriesInfo name="DOI" value="10.17487/RFC7684"/>
        </reference>
        <reference anchor="RFC7794" target="https://www.rfc-editor.org/info/rfc7794" quoteTitle="true" derivedAnchor="RFC7794">
          <front>
            <title>IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability</title>
            <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="X. Xu" initials="X." surname="Xu"/>
            <author fullname="U. Chunduri" initials="U." surname="Chunduri"/>
            <date month="March" year="2016"/>
            <abstract>
              <t indent="0">This document introduces new sub-TLVs to support advertisement of IPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7794"/>
          <seriesInfo name="DOI" value="10.17487/RFC7794"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8362" target="https://www.rfc-editor.org/info/rfc8362" quoteTitle="true" derivedAnchor="RFC8362">
          <front>
            <title>OSPFv3 Link State Advertisement (LSA) Extensibility</title>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="A. Roy" initials="A." surname="Roy"/>
            <author fullname="D. Goethals" initials="D." surname="Goethals"/>
            <author fullname="V. Reddy Vallem" initials="V." surname="Reddy Vallem"/>
            <author fullname="F. Baker" initials="F." surname="Baker"/>
            <date month="April" year="2018"/>
            <abstract>
              <t indent="0">OSPFv3 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.</t>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8362"/>
          <seriesInfo name="DOI" value="10.17487/RFC8362"/>
        </reference>
        <reference anchor="RFC8770" target="https://www.rfc-editor.org/info/rfc8770" quoteTitle="true" derivedAnchor="RFC8770">
          <front>
            <title>Host Router Support for OSPFv2</title>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-Esnault"/>
            <author fullname="M. Bhardwaj" initials="M." surname="Bhardwaj"/>
            <author fullname="S. Bayraktar" initials="S." surname="Bayraktar"/>
            <date month="April" year="2020"/>
            <abstract>
              <t indent="0">The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit called the Host-bit (H-bit). This bit enables a router to advertise that it is a non-transit router. This document also describes the changes needed to support the H-bit in the domain. In addition, this document updates RFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA) Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8770"/>
          <seriesInfo name="DOI" value="10.17487/RFC8770"/>
        </reference>
        <reference anchor="RFC9352" target="https://www.rfc-editor.org/info/rfc9352" quoteTitle="true" derivedAnchor="RFC9352">
          <front>
            <title>IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane</title>
            <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="A. Bashandy" initials="A." surname="Bashandy"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <date month="February" year="2023"/>
            <abstract>
              <t indent="0">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 the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane.</t>
              <t indent="0">This document updates RFC 7370 by modifying an existing registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9352"/>
          <seriesInfo name="DOI" value="10.17487/RFC9352"/>
        </reference>
        <reference anchor="RFC9502" target="https://www.rfc-editor.org/info/rfc9502" quoteTitle="true" derivedAnchor="RFC9502">
          <front>
            <title>IGP Flexible Algorithm in IP Networks</title>
            <author fullname="W. Britto" initials="W." surname="Britto"/>
            <author fullname="S. Hegde" initials="S." surname="Hegde"/>
            <author fullname="P. Kaneriya" initials="P." surname="Kaneriya"/>
            <author fullname="R. Shetty" initials="R." surname="Shetty"/>
            <author fullname="R. Bonica" initials="R." surname="Bonica"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">This document extends IGP Flexible Algorithm so that it can be used with regular IPv4 and IPv6 forwarding.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9502"/>
          <seriesInfo name="DOI" value="10.17487/RFC9502"/>
        </reference>
        <reference anchor="RFC9513" target="https://www.rfc-editor.org/info/rfc9513" quoteTitle="true" derivedAnchor="RFC9513">
          <front>
            <title>OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)</title>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <author fullname="Z. Hu" initials="Z." surname="Hu"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <date month="December" year="2023"/>
            <abstract>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9513"/>
          <seriesInfo name="DOI" value="10.17487/RFC9513"/>
        </reference>
        <reference anchor="RFC9792" target="https://www.rfc-editor.org/info/rfc9792" quoteTitle="true" derivedAnchor="RFC9792">
          <front>
            <title>Prefix Flag Extension for OSPFv2 and OSPFv3</title>
            <author fullname="R. Chen" initials="R." surname="Chen"/>
            <author fullname="D. Zhao" initials="D." surname="Zhao"/>
            <author fullname="P. Psenak" initials="P." surname="Psenak"/>
            <author fullname="K. Talaulikar" initials="K." surname="Talaulikar"/>
            <author fullname="L. Gong" initials="L." surname="Gong"/>
            <date month="June" year="2025"/>
            <abstract>
              <t indent="0">Each OSPF prefix can be advertised with an 8-bit field to indicate specific properties of that prefix. However, all the OSPFv3 Prefix Options bits have already been assigned, and only a few bits remain unassigned in the Flags field of the OSPFv2 Extended Prefix TLV.</t>
              <t indent="0">This document solves this problem by defining a variable-length Prefix Extended Flags sub-TLV for OSPF. This sub-TLV is applicable to OSPFv2 and OSPFv3.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9792"/>
          <seriesInfo name="DOI" value="10.17487/RFC9792"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-rtgwg-bgp-pic" target="https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-bgp-pic-23" quoteTitle="true" derivedAnchor="BGP-PIC">
          <front>
            <title>BGP Prefix Independent Convergence</title>
            <author fullname="Ahmed Bashandy" initials="A." surname="Bashandy" role="editor">
              <organization showOnFrontPage="true">HPE</organization>
            </author>
            <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Prodosh Mohapatra" initials="P." surname="Mohapatra">
              <organization showOnFrontPage="true">Sproute Networks</organization>
            </author>
            <author fullname="Yingzhen Qu" initials="Y." surname="Qu">
              <organization showOnFrontPage="true">Futurewei Technologies</organization>
            </author>
            <date day="15" month="February" year="2026"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-bgp-pic-23"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Kamran Raza"/>, <contact fullname="Michael MacKenzie"/>,
      and <contact fullname="Luay Jalil"/> for their contributions and support of the overall solution 
      proposed in this document.</t>
    </section>
    <section anchor="CONTR" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.b-1">The following people contributed to the content of this document and should be 
    considered coauthors:</t>
      <contact fullname="Stephane Litkowski" initials="S." surname="Litkowski">
        <address>
          <email>slitkows@cisco.com</email>
        </address>
      </contact>
      <contact fullname="Amit Dhamija" initials="A." surname="Dhamija">
        <address>
          <email>amitd@arrcus.com</email>
        </address>
      </contact>
      <contact fullname="Gunter Van de Velde" initials="G." surname="Van de Velde">
        <address>
          <email>gunter.van_de_velde@nokia.com</email>
        </address>
      </contact>
      <t indent="0" pn="section-appendix.b-2">The following people contributed to the problem statement and the solution 
    requirement discussion:</t>
      <contact fullname="Aijun Wang" initials="A." surname="Wang">
        <address>
          <email>wangaj3@chinatelecom.cn</email>
        </address>
      </contact>
      <contact fullname="Zhibo Hu" initials="Z." surname="Hu">
        <address>
          <email>huzhibo@huawei.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Peter Psenak" initials="P" role="editor" surname="Psenak">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <street>Pribinova Street 10</street>
            <city>Bratislava 81109</city>
            <country>Slovakia</country>
          </postal>
          <email>ppsenak@cisco.com</email>
        </address>
      </author>
      <author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <postal>
            <city>Brussels</city>
            <country>Belgium</country>
          </postal>
          <email>cfilsfil@cisco.com</email>
        </address>
      </author>
      <author fullname="Daniel Voyer" initials="D" surname="Voyer">
        <organization showOnFrontPage="true">Cisco Systems</organization>
        <address>
          <email>davoyer@cisco.com</email>
        </address>
      </author>
      <author fullname="Shraddha Hegde" initials="S" surname="Hegde">
        <organization showOnFrontPage="true">HPE</organization>
        <address>
          <email>shraddha.hegde@hpe.com</email>
        </address>
      </author>
      <author fullname="Gyan Mishra" initials="G." surname="Mishra">
        <organization showOnFrontPage="true">Verizon Inc.</organization>
        <address>
          <email>hayabusagsm@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
