<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std"
consensus="true" docName="draft-ietf-lsr-ospfv3-srv6-extensions-15"
     ipr="trust200902"> number="9513" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3"
symRefs="true" sortRefs="true" version="3">

<!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title abbrev="OSPFv3 Extensions for SRV6 ">OSPFv3 Extensions for
    SRv6</title>
    Segment Routing over IPv6 (SRv6)</title>
    <seriesInfo name="RFC" value="9513"/>
    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>
        <email>lizhenbin@huawei.com</email>
      </address>
    </author>
    <author fullname="Zhibo Hu" initials="Z." surname="Hu">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>
        <email>huzhibo@huawei.com</email>
      </address>
    </author>
    <author fullname="Ketan Talaulikar" initials="K" role="editor" surname="Talaulikar">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <country>India</country>
        </postal>
        <email>ketant.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Peter Psenak" initials="P." surname="Psenak">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>
          <country>Slovakia</country>
        </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    <date year=""/>

    <area>Routing</area>

    <workgroup>Link State Routing</workgroup> year="2023" month="November" />
    <area>rtg</area>
    <workgroup>lsr</workgroup>
    <keyword>OSPF</keyword>
    <keyword>OSPFv3</keyword>
    <keyword>Segment Routing</keyword>
    <keyword>SRv6</keyword>
    <abstract>
      <t>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
      Segment Routing
      SR over the IPv6 data plane (SRv6).</t> plane.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Segment Routing (SR) architecture <xref target="RFC8402"/> target="RFC8402" format="default"/>
      specifies how a node can steer a packet using an ordered list of
      instructions,
      instructions called segments. These segments are identified using
      Segment Identifiers (SIDs).</t>

      <t>Segment Routing
      <t>SR can be instantiated on the IPv6 data plane through
      the use of the Segment Routing Header (SRH) defined in <xref
      target="RFC8754"/>. Segment Routing target="RFC8754" format="default"/>. SR instantiation on the IPv6 dataplane data plane
      is referred to as SRv6.</t>
      <t>The network programming paradigm for SRv6 is specified in <xref
      target="RFC8986"/>. target="RFC8986" format="default"/>. It describes how any behavior can be bound to a SID
      and how any network program can be expressed as a combination of SIDs.
      It also describes several well-known behaviors that can be bound to SRv6
      SIDs.</t>
      <t>This document specifies OSPFv3 extensions to support SRv6
      capabilities as defined in <xref target="RFC8986"/>, target="RFC8986" format="default"/>, <xref
      target="RFC8754"/>, target="RFC8754" format="default"/>, and <xref target="RFC9259"/>. target="RFC9259" format="default"/>. The extensions include
      advertisement of an OSPFv3 router's SRv6 capabilities, SRv6 Locators,
      and required SRv6 SIDs along with their supported endpoint Endpoint behaviors.
      Familiarity with <xref target="RFC8986"/> target="RFC8986" format="default"/> is necessary to understand the
      extensions specified in this document.</t>
      <t>At a high level, the extensions to OSPFv3 are comprised of the
      following:<list style="numbers">
          <t>An
      following:</t>
      <ol spacing="normal" type="1"><li>An SRv6 Capabilities TLV to advertise the SRv6 features and SRH
          operations supported by an OSPFv3 router</t>

          <t>Several router.</li>
        <li>Several sub-TLVs to advertise various SRv6 Maximum SID
          Depths.</t>

          <t>An
          Depths.</li>
        <li>An SRv6 Locator TLV using an SRv6 Locator Link-State Link State
          Advertisement (LSA) to advertise the SRv6 Locator - -- a form of
          summary address for the IGP algorithm-specific SIDs instantiated on
          an OSPFv3 router</t>

          <t>TLVs router.</li>
        <li>TLVs and Sub-TLVs sub-TLVs to advertise the SRv6 SIDs instantiated on an
          OSPFv3 router along with their endpoint behaviors</t>
        </list></t> Endpoint behaviors.</li>
      </ol>
      <section title="Requirements Language">
        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="capability" title="SRv6 numbered="true" toc="default">
      <name>SRv6 Capabilities TLV"> TLV</name>
      <t>The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise
      its support for the SR Segment Endpoint Node <xref target="RFC8754"/> target="RFC8754" format="default"/>
      functionality along with its SRv6-related capabilities. This is an
      optional top level top-level TLV of the OSPFv3 Router Information LSA <xref
      target="RFC7770"/> which MUST target="RFC7770" format="default"/> that <bcp14>MUST</bcp14> be advertised by an SRv6-enabled
      router.</t>
      <t>This TLV MUST <bcp14>MUST</bcp14> be advertised only once in the OSPFv3 Router
      Information LSA. When multiple SRv6 Capabilities TLVs are received from
      a given router, the receiver MUST <bcp14>MUST</bcp14> use the first occurrence of the TLV in
      the OSPFv3 Router Information LSA. If the SRv6 Capabilities TLV appears
      in multiple OSPFv3 Router Information LSAs that have different flooding
      scopes, the TLV in the OSPFv3 Router Information LSA with the
      area-scoped flooding scope MUST <bcp14>MUST</bcp14> be used. If the SRv6 Capabilities TLV
      appears in multiple OSPFv3 Router Information LSAs that have the same
      flooding scope, the TLV in the OSPFv3 Router Information LSA with the
      numerically smallest Link State ID MUST <bcp14>MUST</bcp14> be used used, and subsequent instances
      of the TLV MUST <bcp14>MUST</bcp14> be ignored.</t>
      <t>The OSPFv3 Router Information LSA can be advertised at any of the
      defined flooding scopes (link, area, or Autonomous System (AS)).
For the
      purpose of SRv6 Capabilities TLV advertisement, area-scoped flooding is
      REQUIRED.
      <bcp14>REQUIRED</bcp14>. Link and AS-scoped flooding is OPTIONAL.</t> <bcp14>OPTIONAL</bcp14>.</t>
      <t>The format of the OSPFv3 SRv6 Capabilities TLV is shown below:</t>
      <figure anchor="SRV6CAPFMT" title="SRv6 anchor="SRV6CAPFMT">
        <name>SRv6 Capabilities TLV">
        <artwork><![CDATA[ TLV</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Flags             |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t>Where:<list style="symbols">
          <t>Type: 2-octet

<t>where:</t>
<dl newline="false">
        <dt>Type:</dt><dd>2-octet field. The value for this type is 20.</t>

          <t>Length: 2-octet 20.</dd>
        <dt>Length:</dt><dd>2-octet field. The total length (in octets) of the value
          portion of the TLV TLV, including nested Sub-TLVs.</t>

          <t>Reserved: 2-octet sub-TLVs.</dd>
        <dt>Reserved:</dt><dd>2-octet field. It MUST <bcp14>MUST</bcp14> be set to 0 on transmission and
          MUST
          <bcp14>MUST</bcp14> be ignored on receipt.</t>

          <t>Flags: 2-octet receipt.</dd>
          <dt>Flags:</dt><dd><t>2-octet field. The flags are defined as follows: <figure>
              <artwork><![CDATA[ follows:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |O|                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
            </figure> where: <list style="symbols">
              <t>O-flag: If

<t>where:</t>

<dl newline="false">
            <dt>O-flag:</dt><dd>If set, then the router is capable of supporting the
              O-bit
              O-flag in the SRH flags, as specified in <xref
              target="RFC9259"/>.</t>

              <t>Other target="RFC9259" format="default"/>.</dd>
              <dt>Other flags are not defined and are reserved for future use.
              They MUST <bcp14>MUST</bcp14> be set to 0 on transmission and MUST
              <bcp14>MUST</bcp14> be ignored on
              receipt.</t>
            </list></t>
        </list></t> receipt.</dt><dd></dd>
</dl>
</dd>
</dl>
      <t>The SRv6 Capabilities TLV may contain optional Sub-TLVs. sub-TLVs. No Sub-TLVs sub-TLVs
      are defined in this specification.</t>
    </section>
    <section anchor="algorithm" title="Advertisement numbered="true" toc="default">
      <name>Advertisement of Supported Algorithms"> Algorithms</name>
      <t>An SRv6-enabled OSPFv3 router advertises its algorithm support using
      the SR-Algorithm TLV defined in <xref target="RFC8665"/> target="RFC8665" format="default"/> and as described in
      <xref target="RFC8666"/>.</t> target="RFC8666" format="default"/>.</t>
    </section>
    <section anchor="SRH-limits"
             title="Advertisement numbered="true" toc="default">
      <name>Advertisement of Maximum SRv6 SID Depths"> Depths</name>
      <t>An SRv6-enabled router may have different capabilities and limits
      related to SRH processing and these processing. These need to be advertised to other
      OSPFv3 routers in the SRv6 domain.</t>
      <t><xref target="RFC8476"/> target="RFC8476" format="default"/> defines the means to advertise node node- and link
      specific link-specific values for Maximum SID Depth (MSD) types. Node MSDs are
      advertised using the Node MSD TLV in the OSPFv3 Router Information LSA
      <xref target="RFC7770"/> target="RFC7770" format="default"/>, while Link MSDs are advertised using the Link
      MSD Sub-TLV sub-TLV of the Router-Link TLV <xref target="RFC8362"/>. target="RFC8362" format="default"/>. The format
      of the MSD types for OSPFv3 is defined in <xref target="RFC8476"/>.</t> target="RFC8476" format="default"/>.</t>
      <t>The MSD types for SRv6 that are defined in section 4 of <xref
      target="RFC9352"/> target="RFC9352" sectionFormat="of" section="4"/> for IS-IS are also used by OSPFv3. These MSD Types types
      are allocated under in the IGP MSD Types "IGP MSD-Types" registry maintained by IANA that and
      are shared by IS-IS and OSPF. They are described below:</t> in the subsections below.</t>
      <section title="Maximum numbered="true" toc="default">
        <name>Maximum Segments Left MSD Type"> Type</name>
        <t>The Maximum Segments Left MSD Type signals the maximum value of the
        "Segments Left"
        Segments Left field of the SRH of a received packet before applying
        the Endpoint behavior associated with a SID. If no value is
        advertised, the supported value is assumed to be 0.</t>
      </section>
      <section title="Maximum numbered="true" toc="default">
        <name>Maximum End Pop MSD Type"> Type</name>
        <t>The Maximum End Pop MSD Type signals the maximum number of SIDs in
        the SRH to which the router can apply "Penultimate Segment Pop (PSP)
        of the SRH" or "Ultimate Segment Pop (USP) of the SRH", as which are flavors defined in
        <xref target="RFC8986"/> flavors. target="RFC8986" format="default"/>. If the advertised value is zero or
        no value is advertised, then the router cannot apply the PSP or USP
        flavors.</t>
      </section>
      <section title="Maximum numbered="true" toc="default">
        <name>Maximum H.Encaps MSD Type"> Type</name>
        <t>The Maximum H.Encaps MSD Type signals the maximum number of SIDs
        that can be added as part of the "H.Encaps" H.Encaps behavior as defined in
        <xref target="RFC8986"/>. target="RFC8986" format="default"/>. If the advertised value is zero or no value
        is advertised advertised, then the headend can apply an SR Policy that only
        contains one segment, segment without inserting any SRH. A non-zero SRH Max
        H.encaps
        H.Encaps MSD indicates that the headend can insert an SRH with SIDs up
        to the advertised value.</t>
      </section>
      <section title="Maximum numbered="true" toc="default">
        <name>Maximum End D MSD Type"> Type</name>
        <t>The Maximum End D MSD Type specifies the maximum number of SIDs
        present in an SRH when performing decapsulation. These include, but
        are not limited to, End.DX6, End.DT4, End.DT46, End with USD, and
        End.X with USD as defined in <xref target="RFC8986"/>. target="RFC8986" format="default"/>. If the
        advertised value is zero or no value is advertised, then the router
        cannot apply any behavior that results in decapsulation and forwarding
        of the inner packet when the outer IPv6 header contains an SRH.</t>
      </section>
    </section>
    <section anchor="SRv6-SID" title="SRv6 numbered="true" toc="default">
      <name>SRv6 SIDs and Reachability"> Reachability</name>
      <t>An SRv6 Segment Identifier (SID) SID is 128 bits and consists of Locator,
      Function, locator,
      function, and Argument argument parts as described in <xref
      target="RFC8986"/>.</t> target="RFC8986" format="default"/>.</t>
      <t>An OSPFv3 router is provisioned with algorithm-specific locators for
      each algorithm supported by that router. Each locator is a covering
      prefix for all SIDs provisioned on that router that have the matching
      algorithm.</t>
      <t>Locators MUST <bcp14>MUST</bcp14> be advertised within an SRv6 Locator TLV (see <xref
      target="LOCTLV"/>) target="LOCTLV" format="default"/>) using an SRv6 Locator LSA (see <xref
      target="LOCLSA"/>). target="LOCLSA" format="default"/>). The SRv6 Locator LSA is introduced instead of
      reusing the respective Extended Prefix LSAs <xref target="RFC8362"/> target="RFC8362" format="default"/> for
      a clear distinction between the two different types of reachability
      advertisements (viz., the base OSPFv3 prefix reachability advertisements
      and the SRv6 Locator reachability advertisements).</t>
      <t>Forwarding entries for the locators advertised in the SRv6 Locator
      TLV MUST <bcp14>MUST</bcp14> be installed in the forwarding plane of receiving SRv6-capable
      routers when the associated algorithm is supported by the receiving
      OSPFv3 router. Locators can be of different route types that map to
      existing OSPFv3 LSA types - types: Intra-Area, Inter-Area, External, and NSSA. Not-So-Stubby Area (NSSA).
      The advertisement and propagation of the SRv6 Locator LSAs also follow
      the OSPFv3 <xref target="RFC5340"/> target="RFC5340" format="default"/> specifications for the respective
      LSA types. The processing of the prefix advertised in the SRv6 Locator
      TLV, the calculation of its reachability, and the installation in the
      forwarding plane follows the OSPFv3 <xref target="RFC5340"/> target="RFC5340" format="default"/>
      specifications for the respective LSA types.</t>
      <t>Locators associated with algorithms 0 and 1 (refer section 3.1.1 of to <xref target="RFC8402"/>) SHOULD target="RFC8402" sectionFormat="of" section="3.1.1"/>) <bcp14>SHOULD</bcp14> also be advertised using OSPFv3 Extended LSA types with extended TLVs <xref target="RFC8362"/> target="RFC8362" format="default"/> so that
      routers that do not support SRv6 will install a forwarding entry for
      SRv6 traffic matching those locators. When operating in Extended LSA
      sparse-mode <xref target="RFC8362"/>, target="RFC8362" format="default"/>, these locators SHOULD be <bcp14>SHOULD</bcp14> also be
      advertised using legacy OSPFv3 Legacy LSAs <xref target="RFC5340"/>.</t> target="RFC5340" format="default"/>.</t>
      <t>When SRv6 Locators are also advertised as Intra-Area-Prefix-LSAs
      and/or E-Intra-Area-Prefix-LSAs, the SRv6 Locator MUST <bcp14>MUST</bcp14> be considered as
      a prefix associated with the router router, and the referenced LSA type MUST <bcp14>MUST</bcp14>
      point to the Router LSA of the advertising router as specified in
      Section 4.4.3.9 of
      <xref target="RFC5340"/>.</t> target="RFC5340" sectionFormat="of" section="4.4.3.9"/>.</t>
      <t>In cases where a locator advertisement is received both in a prefix
      reachability advertisement (i.e., via legacy OSPFv3 Legacy LSAs and/or Extended
      Prefix TLVs using OSPFv3 Extended LSAs) and an SRv6 Locator TLV, the
      prefix reachability advertisement in the OSPFv3 legacy Legacy LSA or Extended
      LSA MUST <bcp14>MUST</bcp14> be preferred over the advertisement in the SRv6 Locator TLV
      when installing entries in the forwarding plane. This is to prevent prevents
      inconsistent forwarding entries between SRv6 capable SRv6-capable and SRv6 incapable SRv6-incapable
      OSPFv3 routers. Such preference for prefix reachability advertisement
      does not have any impact on the rest of the data advertised in the SRv6
      Locator TLV.</t>
      <t>SRv6 SIDs are advertised as Sub-TLVs sub-TLVs in the SRv6 Locator TLV except
      for SRv6 End.X SIDs/LAN End.X SIDs and LAN End.X SIDs, which are associated with a specific
      Neighbor/Link
      neighbor/link and are therefore advertised as Sub-TLVs sub-TLVs of the
      E-Router-Link TLV.</t>
      <t>SRv6 SIDs received from other OSFPv3 routers are not directly
      routable and MUST NOT <bcp14>MUST NOT</bcp14> be installed in the forwarding plane. Reachability
      to SRv6 SIDs depends upon the existence of a covering locator.</t>
      <t>Adherence to the rules defined in this section will ensure that SRv6
      SIDs associated with a supported algorithm will be forwarded correctly,
      while SRv6 SIDs associated with an unsupported algorithm will be
      dropped. NOTE:
      dropped.</t>
      <aside><t>NOTE: The drop behavior depends on the absence of a
      default/summary route matching the locator prefix.</t> prefix.</t></aside>
      <t>If the locator associated with SRv6 SID advertisements is the longest
      prefix match installed in the forwarding plane for those SIDs, this will
      ensure correct forwarding. Network operators should take steps to make
      sure that this requirement is not compromised. For example, the
      following situations should be avoided:</t>

      <t><list style="symbols">
          <t>Another
      <ul spacing="normal">
        <li>Another locator associated with a different algorithm is the
          longest prefix match</t>

          <t>Another match.</li>
        <li>Another prefix advertised via OSPFv3 legacy Legacy or Extended LSA
          advertisement is the longest prefix match</t>
        </list></t> match.</li>
      </ul>
      <section anchor="SRV6FA" title="SRv6 numbered="true" toc="default">
        <name>SRv6 Flexible Algorithm"> Algorithm</name>
        <t><xref target="RFC9350"/> target="RFC9350" format="default"/> specifies IGP Flexible Algorithm
        mechanisms for OSPFv3. Section 14.2 of
<xref target="RFC9350"/> target="RFC9350" sectionFormat="of" section="14.2"/>
        explains SRv6 forwarding for Flexible Algorithm Algorithms, and analogous
        procedures apply for supporting SRv6 Flexible Algorithm Algorithms using OSPFv3.
        When the algorithm value that is advertised in the SRv6 Locator TLV
        (refer to <xref target="LOCTLV"/>) target="LOCTLV" format="default"/>) represents a Flexible Algorithm,
        the procedures described in section 14.2 of <xref target="RFC9350"/> target="RFC9350" sectionFormat="of" section="14.2"/>
        are followed for the programming of those specific SRv6 Locators.</t>
        <t>Locators associated with Flexible Algorithms SHOULD NOT <bcp14>SHOULD NOT</bcp14> be
        advertised in the base OSPFv3 prefix reachability advertisements.
        Advertising the Flexible Algorithm locator in a regular prefix
        reachability advertisement would make it available for non-Flexible
        Algorithm forwarding (i.e., algorithm 0).</t>
<t>The procedures for OSPFv3 Flexible Algorithm for SR-MPLS, as specified in <xref target="RFC9350"/>, like target="RFC9350" format="default"/>, also apply for SRv6; these procedures include a) ASBR reachability,
b) inter-area, external, and NSSA prefix advertisements advertisements, and their c) the use of
those prefix advertisements in Flexible Algorithm route computation also apply for SRv6.</t> computation.</t>
      </section>
    </section>
    <section anchor="ANYCAST" title="Advertisement numbered="true" toc="default">
      <name>Advertisement of Anycast Property"> Property</name>
      <t>Both prefixes and SRv6 Locators may be configured as anycast anycast, and as
      such
      such, the same value can be advertised by multiple routers. It is useful
      for other routers to know that the advertisement is for an anycast
      identifier.</t>

      <t>A new bit
      <t>The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field <xref target="RFC5340"/> target="RFC5340" format="default"/> is defined
      to advertise the anycast property:</t>

      <t><figure anchor="PFXOPTIONS" title="OSPFv3
      <figure anchor="PFXOPTIONS">
        <name>OSPFv3 Prefix Options Field">
          <artwork><![CDATA[ Field</name>
        <artwork name="" type="" alt="" align="center"><![CDATA[
 0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+
|AC|EL| N|DN| P| x|LA|NU|
+--+--+--+--+--+--+--+--+
]]></artwork>
        </figure></t>

      <t>Value: 0x80</t>

      <t>Description: Anycast (AC-bit)</t>
      </figure>

      <t>When the prefix/SRv6 Locator is configured as anycast, the AC-bit
      MUST
      <bcp14>MUST</bcp14> be set. Otherwise, this flag MUST <bcp14>MUST</bcp14> be clear.</t>
      <t>The AC-bit MUST <bcp14>MUST</bcp14> be preserved when re-advertising the prefix/SRv6
      Locator across areas.</t>
      <t>The AC-bit and the N-bit MUST NOT <bcp14>MUST NOT</bcp14> both be set. If both the N-bit and
      AC-bit are both set in the prefix/SRv6 Locator advertisement, the receiving
      routers MUST <bcp14>MUST</bcp14> ignore the N-bit.</t>
      <t>The same prefix/SRv6 Locator can be advertised by multiple routers.
      If at least one of them sets the AC-bit in its advertisement, the
      prefix/SRv6 Locator is considered as anycast.</t>
      <t>A prefix/SRv6 Locator that is advertised by a single node and without
      an AC-bit is considered node-specific.</t>
      <t>All the nodes advertising the same anycast SRv6 Locator MUST <bcp14>MUST</bcp14>
      instantiate the exact same set of SIDs under that anycast SRv6 Locator.
      Failure to do so may result in traffic being dropped or misrouted.</t>
      <t>The PrefixOptions field is common to the prefix reachability
      advertisements (i.e., the base OSPFv3 prefix LSA types defined in <xref
      target="RFC5340"/> and target="RFC5340" format="default"/>, the OSPFv3 Extended Prefix TLV types defined in
      <xref target="RFC8362"/>) target="RFC8362" format="default"/>), and the SRv6 Locator TLV advertisements
      specified in <xref target="LOCTLV"/> target="LOCTLV" format="default"/> of this document. When a router
      originates both the prefix reachability advertisement and the SRv6
      Locator advertisement for a given prefix, the router SHOULD <bcp14>SHOULD</bcp14> advertise
      the same PrefixOptions bits in both advertisements. In the case of any
      inconsistency between the PrefixOptions advertised in the SRv6 Locator
      and in the prefix reachability advertisements, the ones advertised in
      the prefix reachability advertisement MUST <bcp14>MUST</bcp14> be preferred.</t>
    </section>
    <section anchor="LOCLSA" title="SRv6 numbered="true" toc="default">
      <name>SRv6 Locator LSA"> LSA</name>
      <t>The SRv6 Locator LSA has a function code of 42. The S1/S2 bits are
      dependent on the desired flooding scope for the LSA. The flooding scope
      of the SRv6 Locator LSA depends on the scope of the advertised SRv6
      Locator and is under the control of the advertising router. The U-bit
      will be set indicating that the LSA should be flooded even if it is not
      understood.</t>
      <t>Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router router, and
      they are distinguished by their Link State IDs (which are chosen
      arbitrarily by the originating router).</t>
      <t>The format of the SRv6 Locator LSA is shown below:</t>

      <t><figure anchor="LOCLSAFMT" title="SRv6
      <figure anchor="LOCLSAFMT">
        <name>SRv6 Locator LSA">
          <artwork><![CDATA[ LSA</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            LS age             |U|S12|   Function Code         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Link State ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Advertising Router                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       LS sequence number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        LS checksum            |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-                            TLVs                             -+
|                             ...                               |
]]></artwork>
        </figure></t>
      </figure>
      <t>The format of the TLVs within the body of the SRv6 Locator LSA is the
      same as the format used by <xref target="RFC3630"/>. target="RFC3630" format="default"/>. The variable TLV
      section consists of one or more nested TLV tuples. Nested TLVs are also
      referred to as Sub-TLVs. sub-TLVs. The format of each TLV is:</t>

      <t><figure anchor="TLVFMT" title="SRv6
      <figure anchor="TLVFMT">
        <name>SRv6 Locator LSA TLV Format">
          <artwork><![CDATA[ Format</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Value...                           |
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure></t>
      </figure>
      <t>The Length field defines the length of the value portion in octets
      (thus, a TLV with no value portion would have a length of 0). The TLV is
      padded to 4-octet alignment; padding is not included in the Length field
      (so a 3-octet value would have a length of 3, but the total size of the
      TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For
      example, a 1-byte value would have the Length field set to 1 1, and 3
      octets of padding would be added to the end of the value portion of the
      TLV. The padding is composed of zeros.</t>
      <section anchor="LOCTLV" title="SRv6 numbered="true" toc="default">
        <name>SRv6 Locator TLV"> TLV</name>
        <t>The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA
        that is used to advertise an SRv6 Locator, its attributes, and SIDs
        associated with it. Multiple SRv6 Locator TLVs MAY <bcp14>MAY</bcp14> be advertised in
        each SRv6 Locator LSA. However, since the S12 bits define the flooding
        scope, the LSA flooding scope has to satisfy the application-specific
        requirements for all the locators included in a single SRv6 Locator
        LSA.</t>
        <t>When multiple SRv6 Locator TLVs are received from a given router in
        an SRv6 Locator LSA for the same Locator, locator, the receiver MUST <bcp14>MUST</bcp14> use the
        first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for
        the same Locator locator appears in multiple SRv6 Locator LSAs that have
        different flooding scopes, the TLV in the SRv6 Locator LSA with the
        area-scoped flooding scope MUST <bcp14>MUST</bcp14> be used. If the SRv6 Locator TLV for
        the same Locator locator appears in multiple SRv6 Locator LSAs that have the
        same flooding scope, the TLV in the SRv6 Locator LSA with the
        numerically smallest Link-State Link State ID MUST <bcp14>MUST</bcp14> be used used, and subsequent
        instances of the TLV MUST <bcp14>MUST</bcp14> be ignored.</t>
        <t>The format of the SRv6 Locator TLV is shown below:</t>

        <t><figure anchor="LOCTLVFMT" title="SRv6
        <figure anchor="LOCTLVFMT">
          <name>SRv6 Locator TLV">
            <artwork><![CDATA[ TLV</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Route Type   |  Algorithm    | Locator Length| PrefixOptions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Locator (up to 16 octets) ...                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... Locator continued ...                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... Locator continued ...                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... Locator concluded                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sub-TLVs (variable)                      |
+-                                                             -+
|                             ...                               |
]]></artwork>
          </figure>Where:<list>
            <t>Type: 2-octet
        </figure>

        <t>where:</t>
<dl newline="false" spacing="normal">
          <dt>Type:</dt><dd>2-octet field. The value for this type is 1.</t>

            <t>Length: 2-octet 1.</dd>
          <dt>Length:</dt><dd>2-octet field. The total length (in octets) of the
            value portion of the TLV TLV, including nested Sub-TLVs.</t>

            <t>Route Type: 1-octet sub-TLVs.</dd>
            <dt>Route Type:</dt><dd><t>1-octet field. The type of the locator route. The
            only supported types are the ones listed below below, and the SRv6
            Locator TLV MUST <bcp14>MUST</bcp14> be ignored on receipt of any other type. <figure>
                <artwork><![CDATA[
        1 - Intra-Area
        2 - Inter-Area
        3 - AS type.</t>
<dl newline="false" spacing="compact">
<dt>1:</dt><dd>Intra-Area</dd>
<dt>2:</dt><dd>Inter-Area</dd>
<dt>3:</dt><dd>AS External Type 1
        4 - AS 1</dd>
<dt>4:</dt><dd>AS External Type 2
        5 - NSSA 2</dd>
<dt>5:</dt><dd>NSSA External Type 1
        6 - NSSA 1</dd>
<dt>6:</dt><dd>NSSA External Type 2
 ]]></artwork>
              </figure></t>

            <t>Algorithm: 1-octet 2</dd></dl>
</dd>
          <dt>Algorithm:</dt><dd>1-octet field. The algorithm associated with the
            SRv6 Locator. Algorithm values are defined in the IGP "IGP Algorithm
            Type
            Types" registry <xref target="RFC8665"/>.</t>

            <t>Locator Length: 1-octet target="RFC8665" format="default"/>.</dd>
          <dt>Locator Length:</dt><dd>1-octet field. Specifies the length of the
            Locator
            locator prefix as the number of locator bits from the range
            (1-128).</t>

            <t>PrefixOptions: 1-octet
            (1-128).</dd>
          <dt>PrefixOptions:</dt><dd>1-octet field. Specifies the prefix options
            bits/flags as specified in <xref target="RFC5340"/> target="RFC5340" format="default"/> and further
            extended by <xref target="RFC8362"/> target="RFC8362" format="default"/> and <xref target="ANYCAST"/> target="ANYCAST" format="default"/>
            of this document.</t>

            <t>Metric: 4-octet document.</dd>
          <dt>Metric:</dt><dd>4-octet field. The metric value associated with the
            SRv6 Locator. The metric value of 0xFFFFFFFF MUST <bcp14>MUST</bcp14> be considered as
            unreachable.</t>

            <t>Locator: Up to 16-octet field.
            unreachable.</dd>
            <dt>Locator:</dt><dd>1-16 octets. This field encodes the
          advertised SRv6 Locator as an IPv6 Prefix as specified in section
            A.4.1 of <xref target="RFC5340"/>.</t>

            <t>Sub-TLVs: Used
          target="RFC5340" sectionFormat="of" section="A.4.1"/>.</dd>
          <dt>Sub-TLVs:</dt><dd>Used to advertise Sub-TLVs sub-TLVs that provide additional
            attributes for the given SRv6 Locator and SRv6 SIDs associated
            with the SRv6 Locator.</t>
          </list></t> Locator.</dd>
        </dl>

      </section>
      <section anchor="LOCSUBTLVS" title="SRv6 numbered="true" toc="default">
        <name>SRv6 Locator Sub-TLVs"> Sub-TLVs</name>
        <t>The following OSPFv3 Extended-LSA sub-TLVs corresponding to the
        Extended Prefix LSAs are also applicable for use as sub-TLVs of the
        SRv6 Locator TLV using code points as specified in <xref
        target="IANALLSTLVS"/>:</t>

        <t><list style="symbols">
            <t>IPv6-Forwarding-Address target="IANALLSTLVS" format="default"/>:</t>
        <ul spacing="normal">
          <li>IPv6-Forwarding-Address sub-TLV <xref target="RFC8362"/></t>

            <t>Route-Tag target="RFC8362" format="default"/></li>
          <li>Route-Tag sub-TLV <xref target="RFC8362"/></t>

            <t>Prefix target="RFC8362" format="default"/></li>
          <li>Prefix Source OSPF Router-ID sub-TLV <xref
            target="RFC9084"/></t>

            <t>Prefix target="RFC9084" format="default"/></li>
          <li>Prefix Source Router Address sub-TLV <xref
            target="RFC9084"/></t>
          </list></t> target="RFC9084" format="default"/></li>
        </ul>
      </section>
    </section>
    <section anchor="END" title="Advertisement numbered="true" toc="default">
      <name>Advertisement of SRv6 End SIDs"> SIDs</name>
      <t>The SRv6 End SID Sub-TLV sub-TLV is a Sub-TLV sub-TLV of the SRv6 Locator TLV in the
      SRv6 Locator LSA (defined in <xref target="LOCLSA"/>). target="LOCLSA" format="default"/>). It is used to
      advertise the SRv6 SIDs belonging to the router along with their
      associated endpoint Endpoint behaviors. SIDs associated with adjacencies are
      advertised as described in <xref target="SRv6-Neighbor"/>. target="SRv6-Neighbor" format="default"/>. Every
      SRv6-enabled OSPFv3 router SHOULD <bcp14>SHOULD</bcp14> advertise at least one SRv6 SID
      associated with an END End behavior for itself as specified in <xref
      target="RFC8986"/>, target="RFC8986" format="default"/>, although it MAY <bcp14>MAY</bcp14> omit doing so if that node is not
      going to be used as a Segment Endpoint (e.g., for TE or TI-LFA) Topology Independent Loop-Free Alternate (TI-LFA)) by any
      SR Source Node.</t>
      <t>SRv6 End SIDs inherit the algorithm from the parent locator. The SRv6
      End SID MUST <bcp14>MUST</bcp14> be allocated from its associated locator. SRv6 End SIDs
      that are NOT allocated from the associated locator MUST <bcp14>MUST</bcp14> be ignored.</t>
      <t>The router MAY <bcp14>MAY</bcp14> advertise multiple instances of the SRv6 End SID
      Sub-TLV
      sub-TLV within the SRv6 Locator TLV - -- one for each of the SRv6 SIDs to
      be advertised. When multiple SRv6 End SID Sub-TLVs sub-TLVs are received in the
      SRv6 Locator TLV from a given router for the same SRv6 SID value, the
      receiver MUST <bcp14>MUST</bcp14> use the first occurrence of the Sub-TLV sub-TLV in the SRv6
      Locator TLV.</t>
      <t>The format of the SRv6 End SID Sub-TLV sub-TLV is shown below</t>
      <figure anchor="NODESIDTLV" title="SRv6 anchor="NODESIDTLV">
        <name>SRv6 End SID Sub-TLV">
        <artwork><![CDATA[ Sub-TLV</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Flags     |   Reserved    |        Endpoint Behavior      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   SID (128 bits) ...                                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... SID continued ...                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... SID continued ...                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... SID concluded                                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

      <t>Where:<list>
          <t>Type: 2-octet

      <t>where:</t>
<dl>
        <dt>Type:</dt><dd>2-octet field. The value for this type is 1.</t>

          <t>Length: 2-octet 1.</dd>
        <dt>Length:</dt><dd>2-octet field. The total length (in octets) of the value
          portion of the Sub-TLV sub-TLV, including its further nested Sub-TLVs.</t>

          <t>Flags: 1-octet sub-TLVs.</dd>
        <dt>Flags:</dt><dd>1-octet field. It specifies Specifies the flags associated
        with the SID. No flags are currently defined defined, and this field MUST
        <bcp14>MUST</bcp14> be set to 0 on transmission and MUST
        <bcp14>MUST</bcp14> be ignored on receipt.</t>

          <t>Reserved: 1-octet receipt.</dd>
        <dt>Reserved:</dt><dd>1-octet field. It MUST <bcp14>MUST</bcp14> be set to 0 on transmission and
          MUST
          <bcp14>MUST</bcp14> be ignored on receipt.</t>

          <t>Endpoint Behavior: 2 octets receipt.</dd>
        <dt>Endpoint Behavior:</dt><dd>2-octet field. The endpoint Endpoint behavior code point for this SRv6 SID as defined in <xref target="RFC8986"/>. target="RFC8986" format="default"/>.
          Supported behavior values for this sub-TLV are defined in <xref
          target="AdvtEndBeh"/> target="AdvtEndBeh" format="default"/> of this document. Unsupported or unrecognized
          behavior values are ignored by the receiver.</t>

          <t>SID: 16-octet receiver.</dd>
        <dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv6
          SID.</t>

          <t>Sub-TLVs: Used
          SID.</dd>
        <dt>Sub-TLVs:</dt><dd>Used to advertise Sub-TLVs sub-TLVs that provide additional
          attributes for the given SRv6 SID.</t>
        </list></t> SID.</dd>
      </dl>

    </section>
    <section anchor="SRv6-Neighbor"
             title="Advertisement numbered="true" toc="default">
      <name>Advertisement of SRv6 SIDs Associated with Adjacencies"> Adjacencies</name>
      <t>The SRv6 endpoint Endpoint behaviors defined in <xref target="RFC8986"/> target="RFC8986" format="default"/>
      include certain behaviors that are specific to links or adjacencies. The
      most basic of these, which these (which is critical for link-state routing protocols
      like OSPFv3, OSPFv3) is the End.X behavior that behavior, which is an instruction to forward to
      a specific neighbor on a specific link. These SRv6 SIDs and others that
      are defined in <xref target="RFC8986"/> target="RFC8986" format="default"/>, which are specific to links or
      adjacencies
      adjacencies, need to be advertised to OSPFv3 routers within an area to
      steer SRv6 traffic over a specific link or adjacency.</t>
      <t>Therefore, SRv6 SIDs that are specific to a particular neighbor, such
      as End.X, are not advertised as a sub-TLVs of the SRv6 Locator TLV but TLV. Instead, they are advertised via two different optional Sub-TLVs sub-TLVs of the E-Router-Link TLV defined in
      <xref target="RFC8362"/>:</t>

      <t><list style="symbols">
          <t>SRv6 target="RFC8362" format="default"/>:</t>
     <dl>
        <dt>SRv6 End.X SID Sub-TLV: Used sub-TLV:</dt><dd>Used for OSPFv3 adjacencies over
          point-to-point or point-to-multipoint links and for the adjacency to
          the Designated Router (DR) over broadcast and
          Non-Broadcast-Multi-Access (NBMA) links.</t>

          <t>SRv6 links.</dd>
        <dt>SRv6 LAN End.X SID Sub-TLV: Used sub-TLV:</dt><dd>Used for OSPFv3 adjacencies on
          broadcast and NBMA links to the Backup DR and DR-Other neighbors.
          This Sub-TLV sub-TLV includes the OSPFv3 Router-ID of the neighbor and thus
          allows for an instance of this Sub-TLV sub-TLV for each neighbor to be
          explicitly advertised as a Sub-TLV sub-TLV of the E-Router-Link TLV for the
          same link.</t>
        </list>Every SRv6 enabled link.</dd>
      </dl>
      <t>Every SRv6-enabled OSPFv3 router SHOULD <bcp14>SHOULD</bcp14> instantiate at least
      one unique SRv6 End.X SID corresponding to each of its neighbors,
      although it MAY <bcp14>MAY</bcp14> omit doing so if features like traffic engineering TE or
      Topology-Independent Loop Free Alternate (TI-LFA)
      TI-LFA that require End.X SID
      are not in use. A router MAY <bcp14>MAY</bcp14> instantiate more than one SRv6 End.X SID
      for a single neighbor. The same SRv6 End.X SID MAY <bcp14>MAY</bcp14> be advertised for
      more than one neighbor. Thus Thus, multiple instances of the SRv6 End.X SID
      and SRv6 LAN End.X SID Sub-TLVs MAY sub-TLVs <bcp14>MAY</bcp14> be advertised within the
      E-Router-Link TLV for a single link.</t>
      <t>All End.X and LAN End.X SIDs MUST <bcp14>MUST</bcp14> be subsumed by the subnet of a
      Locator
      locator with the matching algorithm which that is advertised by the same
      OSPFv3 router in an SRv6 Locator TLV. End.X SIDs which that do not meet this
      requirement MUST <bcp14>MUST</bcp14> be ignored. This ensures that the OSPFv3 router
      advertising the End.X or LAN End.X SID is also advertising its
      corresponding Locator locator with the algorithm that will be used for computing
      paths destined to the SID.</t>
      <section anchor="P2P" title="SRv6 numbered="true" toc="default">
        <name>SRv6 End.X SID Sub-TLV"> Sub-TLV</name>
        <t>The format of the SRv6 End.X SID Sub-TLV sub-TLV is shown below</t> below:</t>
        <figure anchor="ADJSIDTLV" title="SRv6 anchor="ADJSIDTLV">
          <name>SRv6 End.X SID Sub-TLV">
          <artwork><![CDATA[ Sub-TLV</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Endpoint Behavior      |     Flags     |   Reserved1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Algorithm   |    Weight     |           Reserved2           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   SID (128 bits) ...                                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... SID continued ...                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... SID continued ...                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... SID concluded                                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>

        <t>Where:</t>

        <t><list>
            <t>Type: 2-octet

        <t>where:</t>
<dl newline="false">
          <dt>Type:</dt><dd>2-octet field. The value for this type is 31.</t>

            <t>Length: 2-octet 31.</dd>
          <dt>Length:</dt><dd>2-octet field. The total length (in octets) of the
            value portion of the Sub-TLV sub-TLV, including its further nested
            Sub-TLVs.</t>

            <t>Endpoint Behavior: 2-octet
            sub-TLVs.</dd>
          <dt>Endpoint Behavior:</dt><dd>2-octet field. The endpoint Endpoint behavior code point for this SRv6 SID as defined in <xref target="RFC8986"/>. target="RFC8986" format="default"/>.
            Supported behavior values for this sub-TLV are defined in <xref
            target="AdvtEndBeh"/> target="AdvtEndBeh" format="default"/> of this document. Unsupported or
            unrecognized behavior values are ignored by the receiver.</t>

            <t>Flags: receiver.</dd>
          <dt>Flags:</dt><dd><t> 1-octet field. The flags are defined as follows: <figure>
                <artwork><![CDATA[ follows:</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
]]></artwork>
              </figure> <list style="symbols">
                <t>B-Flag: Backup
<dl newline="false">
              <dt>B-Flag:</dt><dd>Backup Flag. If set, the SID refers to a path that
                is eligible for protection.</t>

                <t>S-Flag: Set protection.</dd>
              <dt>S-Flag:</dt><dd>Set Flag. When set, the S-Flag indicates that the
                End.X SID refers to a set of adjacencies (and therefore MAY <bcp14>MAY</bcp14> be
                assigned to other adjacencies as well).</t>

                <t>P-Flag: Persistent Flag: well).</dd>
              <dt>P-Flag:</dt><dd>Persistent Flag. If set, the SID is persistently
                allocated, i.e., the SID value remains consistent across
                router restart and session/interface flap.</t>

                <t>Other flap.</dd>
              <dt>Other flags are not defined and are reserved for future
                use. They MUST <bcp14>MUST</bcp14> be set to 0 on transmission and MUST <bcp14>MUST</bcp14> be ignored
                on receipt.</t>
              </list></t>

            <t>Reserved1: 1-octet receipt.</dt><dd></dd>
</dl>
</dd>
</dl>
<dl>
          <dt>Reserved1:</dt><dd>1-octet field. It MUST <bcp14>MUST</bcp14> be set to 0 on transmission
            and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>Algorithm: 1-octet receipt.</dd>
          <dt>Algorithm:</dt><dd>1-octet field. The algorithm associated with the
            SRv6 Locator from which the SID is allocated. Algorithm values are
            defined in the IGP "IGP Algorithm Type Types" registry <xref
            target="RFC8665"/>.</t>

            <t>Weight: 1-octet target="RFC8665" format="default"/>.</dd>
          <dt>Weight:</dt><dd>1-octet field. Its value represents the weight of the
            End.X SID for load-balancing. The use of the weight is defined in
            <xref target="RFC8402"/>.</t>

            <t>Reserved2: 2-octet target="RFC8402" format="default"/>.</dd>
          <dt>Reserved2:</dt><dd>2-octet field. It MUST <bcp14>MUST</bcp14> be set to 0 on transmission
            and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>SID: 16-octet receipt.</dd>
          <dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv6
            SID.</t>

            <t>Sub-TLVs: Used
            SID.</dd>
          <dt>Sub-TLVs:</dt><dd>Used to advertise Sub-TLVs sub-TLVs that provide additional
            attributes for the given SRv6 End.X SID.</t>
          </list></t> SID.</dd>
        </dl>
      </section>
      <section anchor="LAN" title="SRv6 numbered="true" toc="default">
        <name>SRv6 LAN End.X SID Sub-TLV"> Sub-TLV</name>
        <t>The format of the SRv6 LAN End.X SID Sub-TLV sub-TLV is as shown below:</t>

        <t><figure anchor="LADJSIDTLV" title="SRv6
        <figure anchor="LADJSIDTLV">
          <name>SRv6 LAN End.X SID Sub-TLV">
            <artwork><![CDATA[ Sub-TLV</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Endpoint Behavior        |     Flags     |   Reserved1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Algorithm   |    Weight     |           Reserved2           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Neighbor Router-ID                                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   SID (128 bits) ...                                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... SID continued ...                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... SID continued ...                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ... SID concluded                                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          </figure>Where:</t>

        <t><list style="symbols">
            <t>Type: 2-octet
        </figure>

        <t>where:</t>
          <dl spacing="normal" newline="false">
          <dt>Type:</dt><dd>2-octet field. The value for this type is 32.</t>

            <t>Length: 2-octet 32.</dd>
          <dt>Length:</dt><dd>2-octet field. The total length (in octets) of the
            value portion of the Sub-TLV sub-TLV, including its further nested
            Sub-TLVs.</t>

            <t>Endpoint Behavior: 2-octet
            sub-TLVs.</dd>
          <dt>Endpoint Behavior:</dt><dd>2-octet field. The code point for the
            endpoint
          Endpoint behavior for this SRv6 SID as defined in section 9.2 of <xref target="RFC8986"/>.</t>

            <t>Flags: 1-octet
          target="RFC8986" sectionFormat="of" section="9.2"/>.</dd>
          <dt>Flags:</dt><dd><t>1-octet field. The flags are defined as follows:<figure>
                <artwork><![CDATA[ follows:</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
]]></artwork>
              </figure><list style="symbols">
                <t>B-Flag: Backup
            <dl spacing="normal" newline="false">
              <dt>B-Flag:</dt><dd>Backup Flag. If set, the SID refers to a path that
                is eligible for protection.</t>

                <t>S-Flag: Set protection.</dd>
              <dt>S-Flag:</dt><dd>Set Flag. When set, the S-Flag indicates that the
                End.X SID refers to a set of adjacencies (and therefore MAY <bcp14>MAY</bcp14> be
                assigned to other adjacencies as well).</t>

                <t>P-Flag: Persistent Flag: well).</dd>
              <dt>P-Flag:</dt><dd>Persistent Flag. If set, the SID is persistently
                allocated, i.e., the SID value remains consistent across
                router restart and session/interface flap.</t>

                <t>Other flap.</dd>
              <dt>Other flags are not defined and are reserved for future
                use. They MUST <bcp14>MUST</bcp14> be set to 0 on transmission and MUST <bcp14>MUST</bcp14> be ignored
                on receipt.</t>
              </list></t>

            <t>Reserved1: 1-octet receipt.</dt><dd></dd>
            </dl>
          </dd>
          <dt>Reserved1:</dt><dd>1-octet field. It MUST <bcp14>MUST</bcp14> be set to 0 on transmission
            and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>Algorithm: 1-octet receipt.</dd>
          <dt>Algorithm:</dt><dd>1-octet field. The algorithm associated with the
            SRv6 Locator from which the SID is allocated. Algorithm values are
            defined in the IGP "IGP Algorithm Type Types" registry <xref
            target="RFC8665"/>.</t>

            <t>Weight: 1-octet target="RFC8665" format="default"/>.</dd>
          <dt>Weight:</dt><dd>1-octet field. Its value represents the weight of the
            End.X SID for load balancing. The use of the weight is defined in
            <xref target="RFC8402"/>.</t>

            <t>Reserved2: 2-octet target="RFC8402" format="default"/>.</dd>
          <dt>Reserved2:</dt><dd>2-octet field. It MUST <bcp14>MUST</bcp14> be set to 0 on transmission
            and MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

            <t>Neighbor Router-ID: 4-octet receipt.</dd>
          <dt>Neighbor Router-ID:</dt><dd>4-octet field. It specifies the OSPFv3
            Router-id
            Router-ID of the neighbor.</t>

            <t>SID: 16-octet neighbor.</dd>
          <dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv6
            SID.</t>

            <t>Sub-TLVs: Used
            SID.</dd>
          <dt>Sub-TLVs:</dt><dd>Used to advertise Sub-TLVs sub-TLVs that provide additional
            attributes for the given SRv6 SID.</t>
          </list></t> SID.</dd>
        </dl>
      </section>
    </section>
    <section anchor="SRSTRUCTTLV" title="SRv6 numbered="true" toc="default">
      <name>SRv6 SID Structure Sub-TLV">
      <t>SRv6 Sub-TLV</name>
      <t>The SRv6 SID Structure Sub-TLV sub-TLV is used to advertise the structure of the
      SRv6 SID as defined in <xref target="RFC8986"/>. target="RFC8986" format="default"/>. It is used as an
      optional Sub-TLV sub-TLV of the following:<list style="symbols">
          <t>SRv6 following:</t>
      <ul spacing="normal">
        <li>SRv6 End SID Sub-TLV sub-TLV (refer to <xref target="END"/>)</t>

          <t>SRv6 target="END" format="default"/>)</li>
        <li>SRv6 End.X SID Sub-TLV sub-TLV (refer to <xref target="P2P"/>)</t>

          <t>SRv6 target="P2P" format="default"/>)</li>
        <li>SRv6 LAN End.X SID Sub-TLV sub-TLV (refer to <xref target="LAN"/>)</t>
        </list> The Sub-TLV target="LAN" format="default"/>)</li>
      </ul>
      <t>The sub-TLV has the following format:</t>

      <t><figure anchor="SRSIDSTRUCT" title="SRv6
      <figure anchor="SRSIDSTRUCT">
        <name>SRv6 SID Structure Sub-TLV">
          <artwork><![CDATA[ Sub-TLV</name>
        <artwork name="" type="" align="center" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    LB Length  |  LN Length    | Fun. Length   |  Arg. Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>Where:<list>
          <t>Type: 2-octet
      </figure>

      <t>where:</t>
<dl newline="false">
        <dt>Type:</dt><dd>2-octet field. The value for this type is 30.</t>

          <t>Length: 2-octet 30.</dd>
        <dt>Length:</dt><dd>2-octet field. The value MUST <bcp14>MUST</bcp14> be 4.</t>

          <t>LB Length: 1-octet 4.</dd>
        <dt>LB Length:</dt><dd>1-octet field. SRv6 SID Locator Block length in
          bits.</t>

          <t>LN Length: 1-octet bit
          bits.</dd>
        <dt>LN Length:</dt><dd>1-octet field. SRv6 SID Locator Node length in
          bits.</t>

          <t>Function Length: 1-octet
          bits.</dd>
        <dt>Function Length:</dt><dd>1-octet field. SRv6 SID Function length in
          bits.</t>

          <t>Argument Length: 1-octet
          bits.</dd>
        <dt>Argument Length:</dt><dd>1-octet field. SRv6 SID Argument length in
          bits.</t>
        </list></t>
          bits.</dd>
      </dl>

      <t>The SRv6 SID Structure Sub-TLV MUST NOT sub-TLV <bcp14>MUST NOT</bcp14> appear more than once in its
      parent Sub-TLV. sub-TLV. If it appears more than once in its parent Sub-TLV, sub-TLV, the
      parent Sub-TLV MUST sub-TLV <bcp14>MUST</bcp14> be ignored by the receiver.</t>
      <t>The sum of all four sizes advertised in SRv6 SID Structure Sub-TLV
      MUST sub-TLV
      <bcp14>MUST</bcp14> be less than or equal to 128 bits. If the sum of all four sizes
      advertised in the SRv6 SID Structure Sub-TLV sub-TLV is larger than 128 bits,
      the parent TLV/Sub-TLV MUST TLV or sub-TLV <bcp14>MUST</bcp14> be ignored by the receiver.</t>
      <t>The SRv6 SID Structure Sub-TLV sub-TLV is intended for informational use by
      the control and management planes. It MUST NOT <bcp14>MUST NOT</bcp14> be used at a transit node
      (as defined in <xref target="RFC8754"/>) target="RFC8754" format="default"/>) for forwarding packets. As an
      example, this information could be used for: <list style="symbols">
          <t>validation for the following: </t>
      <ul spacing="normal">
        <li>Validation of SRv6 SIDs being instantiated in the network and
        advertised via OSPFv3. These can be learned by controllers via BGP-LS
        <xref target="I-D.ietf-idr-bgpls-srv6-ext"/> target="RFC9514" format="default"/> and then be monitored for
        conformance to the SRv6 SID allocation scheme chosen by the operator
        as described in Section 3.2 of <xref
          target="RFC8986"/>.</t>

          <t>verification target="RFC8986"
        sectionFormat="of" section="3.2"/>.</li>
        <li>Verification and the automation for securing the SRv6 domain by
          provisioning filtering rules at SR domain boundaries as described in
          Section 5 of
          <xref target="RFC8754"/>.</t>
        </list></t> target="RFC8754" sectionFormat="of" section="5"/>.</li>
      </ul>
      <t>The details of these potential applications are outside the scope of
      this document.</t>
    </section>
    <section anchor="AdvtEndBeh" title="Advertising numbered="true" toc="default">
      <name>Advertising Endpoint Behaviors"> Behaviors</name>
      <t>Endpoint behaviors are defined in <xref target="RFC8986"/>. target="RFC8986" format="default"/>. The
      codepoints
      code points for the Endpoint behaviors are defined in the "SRv6 Endpoint
      Behaviors" registry of <xref target="RFC8986"/>. target="RFC8986" format="default"/>. This section lists the
      Endpoint behaviors and their codepoints, code points, which MAY <bcp14>MAY</bcp14> be advertised by
      OSPFv3 and the Sub-TLVs sub-TLVs in which each type MAY <bcp14>MAY</bcp14> appear.</t>

      <t><figure anchor="EndBehTable"
          title="SRv6
<table anchor="EndBehTable">
	<name>SRv6 Endpoint Behaviors in OSPFv3">
          <artwork><![CDATA[
|-----------------------|--------------------|-----|-------|-----------|
| Endpoint              | Endpoint           | End | End.X | LAN End.X |
| OSPFv3</name>
	<thead>
	<tr>
		<th>Endpoint Behavior</th>
		<th>Endpoint Behavior              | Behavior Codepoint | SID | SID   |   SID     |
|-----------------------|--------------------|-----|-------|-----------|
| End Code Point</th>
		<th>End SID</th>
		<th>End.X SID</th>
		<th>LAN End.X SID</th>
	</tr>
	</thead>
	<tbody>
	<tr>
		<td>End   (PSP, USP, USD) | 1-4, 28-31         |  Y  |   N   |    N      |
|-----------------------|--------------------|-----|-------|-----------|
| End.X USD)</td>
		<td>1-4, 28-31</td>
		<td>Y</td>
		<td>N</td>
		<td>N</td>
	</tr>
	<tr>
		<td>End.X (PSP, USP, USD) | 5-8, 32-35         |  N  |   Y   |    Y      |
|-----------------------|--------------------|-----|-------|-----------|
| End.DX6               | 16                 |  N  |   Y   |    Y      |
|-----------------------|--------------------|-----|-------|-----------|
| End.DX4               | 17                 |  N  |   Y   |    Y      |
|-----------------------|--------------------|-----|-------|-----------|
| End.DT6               | 18                 |  Y  |   N   |    N      |
|-----------------------|--------------------|-----|-------|-----------|
| End.DT4               | 19                 |  Y  |   N   |    N      |
|-----------------------|--------------------|-----|-------|-----------|
| End.DT64              | 20                 |  Y  |   N   |    N      |
|-----------------------|--------------------|-----|-------|-----------|

]]></artwork>
        </figure></t> USD)</td>
		<td>5-8, 32-35</td>
		<td>N</td>
		<td>Y</td>
		<td>Y</td>
	</tr>
	<tr>
		<td>End.DX6</td>
		<td>16</td>
		<td>N</td>
		<td>Y</td>
		<td>Y</td>
	</tr>
	<tr>
		<td>End.DX4</td>
		<td>17</td>
		<td>N</td>
		<td>Y</td>
		<td>Y</td>
	</tr>
	<tr>
		<td>End.DT6</td>
		<td>18</td>
		<td>Y</td>
		<td>N</td>
		<td>N</td>
	</tr>
	<tr>
		<td>End.DT4</td>
		<td>19</td>
		<td>Y</td>
		<td>N</td>
		<td>N</td>
	</tr>
	<tr>
		<td>End.DT64</td>
		<td>20</td>
		<td>Y</td>
		<td>N</td>
		<td>N</td>
	</tr>
	</tbody>
</table>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document introduces extensions to the OSPFv3 protocol and and, as
      such such,
      does not affect existing security considerations for OSPFv3 as
      documented in <xref target="RFC5340"/>. target="RFC5340" format="default"/>. <xref target="RFC7166"/> target="RFC7166" format="default"/>
      describes an alternative and improved authentication mechanism to IPsec
      for OSPFv3. The use of authentication is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for OSPFv3
      deployment.</t>
      <t>Reception of a malformed TLV or Sub-TLV SHOULD sub-TLV <bcp14>SHOULD</bcp14> be counted and/or logged
      in a rate-limited manner for further analysis.</t>
      <t>This document describes the OSPFv3 extensions required to support
      Segment Routing
      SR over an IPv6 data plane. The security considerations for
      Segment Routing
      SR are discussed in <xref target="RFC8402"/>. target="RFC8402" format="default"/>. <xref
      target="RFC8986"/> target="RFC8986" format="default"/> defines the SRv6 Network Programming concept and
      specifies the main Segment Routing SR behaviors to enable the creation of
      interoperable overlays; the overlays. The security considerations from that document
      apply too.</t> as well.</t>
      <t>The advertisement of an incorrect MSD value may have negative
      consequences, see
      consequences. See <xref target="RFC8476"/> target="RFC8476" format="default"/> for additional
      considerations.</t>
      <t>Security concerns associated with the setting of the O-flag are
      described in <xref target="RFC9259"/>.</t> target="RFC9259" format="default"/>.</t>
      <t>Security concerns associated with the usage of Flexible Algorithms
      are described in <xref target="RFC9350"/>.</t> target="RFC9350" format="default"/>.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>This document requests numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Per this document, IANA to perform has made allocations from OSPF in OSPF- and
      OSPFv3 related
      OSPFv3-related registries as well as creating of and created new registries registries, as
      follows.</t>
      detailed in the following subsections.</t>
      <section anchor="IANARI" title="OSPF numbered="true" toc="default">
        <name>OSPF Router Information TLVs"> TLVs</name>
        <t>IANA has allocated a the following code point via the early allocation process in the "OSPF Router
        Information (RI) TLVs" registry under within the "OSPF "Open Shortest Path First
        (OSPF) Parameters" registry group for the new TLV below that needs to be made
        permanent:</t>

        <t><list style="empty">
            <t>Type 20: SRv6-Capabilities TLV: Refer to <xref
            target="capability"/> of this document.</t>
          </list></t> group:</t>
<table anchor="iana1">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>TLV Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>20</td>
      <td>SRv6 Capabilities</td>
      <td>RFC 9513, <xref target="capability"/></td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="IANALSA" title="OSPFv3 numbered="true" toc="default">
        <name>OSPFv3 LSA Function Codes"> Codes</name>
        <t>IANA has allocated a the following code point via the early allocation process in
        the "OSPFv3 LSA Function Codes" registry under within the "OSPFv3 "Open Shortest Path First v3 (OSPFv3) Parameters"
        registry group for the new LSA below that needs to be made
        permanent:</t>

        <t><list style="symbols">
            <t>Type 42: SRv6 Locator LSA: Refer to <xref target="LOCLSA"/> of
            this document.</t>
          </list></t> group:
        </t>
<table anchor="iana2">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>LSA Function Code Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>42</td>
      <td>SRv6 Locator LSA</td>
      <td>RFC 9513, <xref target="LOCLSA"/></td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="IANAPO" title="OSPFv3 numbered="true" toc="default">
        <name>OSPFv3 Prefix Options"> Options</name>
        <t>IANA has allocated a the following code point via the early allocation process in the "OSPFv3 Prefix Options"
        Options (8 bits)" registry under within the "OSPFv3 "Open Shortest Path First v3
        (OSPFv3) Parameters" registry group as below that needs to be made permanent:</t>

        <t><list style="symbols">
            <t>Value 0x80: AC-bit: Refer to <xref target="ANYCAST"/> of this
            document.</t>
          </list></t> group:</t>
<table anchor="iana3">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0x80</td>
      <td>AC-bit</td>
      <td>RFC 9513, <xref target="ANYCAST"/></td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="IANASRV6CAP" title="OSPFv3 numbered="true" toc="default">
        <name>OSPFv3 SRv6 Capabilities TLV Flags">
        <t>This document requests Flags</name>
        <t>IANA has created a new IANA sub-registry name subregistry named "OSPFv3 SRv6
        Capabilities TLV Flags" be created under within the "OSPFv3 "Open Shortest Path First v3 (OSPFv3) Parameters"
        registry group to control the assignment of bits 0 to 15 in the Flags
        field of the OSPFv3 SRv6 Capabilities TLV specified in this document.
        The registration procedure is "Standards Action" as defined in <xref
        target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>The following assignments are assignment has been made by per this document:<list
            style="symbols">
            <t>Bit 1: Description: O-flag. Reference: <xref
            target="capability"/> of this document.</t>
          </list></t> document:</t>
<table anchor="iana4">
  <name></name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>O-flag</td>
      <td>RFC 9513, <xref target="capability"/></td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="IANASRV6END" title="OSPFv3 numbered="true" toc="default">
        <name>OSPFv3 SRv6 End SID Sub-TLV Flags">
        <t>This document requests Flags</name>
        <t>IANA has created a new IANA sub-registry name subregistry named "OSPFv3 SRv6
        End SID Sub-TLV Flags" be created under within the "OSPFv3 "Open Shortest Path First v3 (OSPFv3) Parameters"
        registry group to control the assignment of bits 0 to 7 in the Flags
        field of the OSPFv3 SRv6 End SID Sub-TLV sub-TLV specified in this document.
        The registration procedure is "Standards Action" as defined in <xref
        target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>No assignments are made by this document.</t>
      </section>
      <section anchor="IANASRV6ENDX"
               title="OSPFv3 numbered="true" toc="default">
        <name>OSPFv3 SRv6 Adjacency SID Sub-TLV Flags">
        <t>This document requests Flags</name>
        <t>IANA has created a new IANA sub-registry name subregistry named "OSPFv3 SRv6
        Adjacency SID Sub-TLV Flags" be created under within the "OSPFv3 "Open Shortest Path First v3 (OSPFv3) Parameters"
        registry group to control the assignment of bits 0 to 7 in the Flags
        field of the OSPFv3 SRv6 End.X SID and OSPFv3 SRv6 LAN End.X SID
        Sub-TLVs
        sub-TLVs specified in this document. The registration procedure is
        "Standards Action" as defined in <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>The following assignments are have been made by this document:<list
            style="symbols">
            <t>Bit 0: Description: B-flag. Reference: <xref target="P2P"/> and
            <xref target="LAN"/> of per this document.</t>

            <t>Bit 1: Description: S-flag. Reference: <xref target="P2P"/> and
            <xref target="LAN"/> of this document.</t>

            <t>Bit 2: Description: P-flag. Reference: <xref target="P2P"/> and
            <xref target="LAN"/> of this document.</t>
          </list></t> document:</t>
<table anchor="iana5">
  <name></name>
  <thead>
    <tr>
      <th>Bit</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>B-flag</td>
      <td>RFC 9513, Sections <xref target="P2P" format="counter"/> and <xref target="LAN" format="counter"/></td>
    </tr>
    <tr>
      <td>1</td>
      <td>S-flag</td>
      <td>RFC 9513, Sections <xref target="P2P" format="counter"/> and <xref target="LAN" format="counter"/></td>
    </tr>
    <tr>
      <td>2</td>
      <td>P-flag</td>
      <td>RFC 9513, Sections <xref target="P2P" format="counter"/> and <xref target="LAN" format="counter"/></td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="IANAELSTLVS" title="OSPFv3 numbered="true" toc="default">
        <name>OSPFv3 Extended-LSA Sub-TLVs"> Sub-TLVs</name>
        <t>IANA has allocated the following code points via the early
        allocation process
        in the "OSPFv3 Extended-LSA Sub-TLVs" registry
        under
        within the "OSPFv3 "Open Shortest Path First v3 (OSPFv3) Parameters" registry group for the new Sub-TLVs
        below that need to be made permanent:</t>

        <t><list style="symbols">
            <t>Type 30: SRv6 SID Structure Sub-TLV: Refer to <xref
            target="SRSTRUCTTLV"/> of this document.</t>

            <t>Type 31: SRv6 group:</t>
<table anchor="iana6">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>L2BM</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>30</td>
      <td>SRv6 SID Structure</td>
      <td>Y</td>
      <td>RFC 9513, <xref target="SRSTRUCTTLV"/></td>
    </tr>
    <tr>
      <td>31</td>
      <td>SRv6 End.X SID Sub-TLV: Refer to <xref target="P2P"/>
            of this document.</t>

            <t>Type 32: SRv6 SID</td>
      <td>Y</td>
      <td>RFC 9513, <xref target="P2P"/></td>
    </tr>
    <tr>
      <td>32</td>
      <td>SRv6 LAN End.X SID Sub-TLV: Refer to <xref
            target="LAN"/> of this document.</t>
          </list></t>

        <t>For all 3 of these sub-TLVs the column L2BM in the registry is set
        to "Y".</t> SID</td>
      <td>Y</td>
      <td>RFC 9513, <xref target="LAN"/></td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="IANALLTLVS" title="OSPFv3 numbered="true" toc="default">
        <name>OSPFv3 SRv6 Locator LSA TLVs">
        <t>This document requests the creation of an TLVs</name>
        <t>IANA has created a new subregistry named "OSPFv3 SRv6 Locator LSA
        TLVs" registry, that defines within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry group to define top-level TLVs for the OSPFv3 SRv6
        Locator LSA, under the "OSPFv3 Parameters" registry group. LSA. The initial
        code-points assignment is as
        assignments are below:</t>

        <t><list style="symbols">
            <t>Type 0: Reserved.</t>

            <t>Type 1: SRv6 Locator TLV: Refer to <xref target="LOCTLV"/> of
            this document.</t>
          </list></t>
<table anchor="iana7">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved</td>
      <td>RFC 9513</td>
    </tr>
    <tr>
      <td>1</td>
      <td>SRv6 Locator</td>
      <td>RFC 9513, <xref target="LOCTLV"/></td>
    </tr>
  </tbody>
</table>
        <t>Types in the range 2-32767 0-32767 are allocated via IETF Review or IESG
        Approval <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>Types in the range 32768-33023 are Reserved for Experimental Use;
        these will not be registered with IANA and MUST NOT <bcp14>MUST NOT</bcp14> be mentioned by
        RFCs.</t>
        <t>Types in the range 33024-45055 are to be assigned on a First Come
        First Served (FCFS) basis.</t>
        <t>Types in the range 45056-65535 are not to be assigned at this time.
        Before any assignments can be made in the 45056-65535 range, there
        MUST
        <bcp14>MUST</bcp14> be an IETF specification that specifies IANA Considerations that
        cover the range being assigned.</t>
      </section>
      <section anchor="IANALLSTLVS" title="OSPFv3 numbered="true" toc="default">
        <name>OSPFv3 SRv6 Locator LSA Sub-TLVs">
        <t>This document requests the creation of an Sub-TLVs</name>
        <t>IANA has created a new subregistry named "OSPFv3 SRv6 Locator LSA
        Sub-TLVs" registry, that defines Sub-TLVs within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry
group to define sub-TLVs at any level of nesting for
        the SRv6 Locator LSA, to be added under the "OSPFv3 Parameters"
        registry group. LSA TLV.
        The initial code-points assignment is as are below:</t>

        <t><list style="symbols">
            <t>Type 0: Reserved.</t>

            <t>Type 1: SRv6
<table anchor="iana8">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved</td>
      <td>RFC 9513</td>
    </tr>
    <tr>
      <td>1</td>
      <td>SRv6 End SID Sub-TLV: Refer to <xref target="END"/> of
            this document.</t>

            <t>Type 2: IPv6-Forwarding-Address sub-TLV: Refer to <xref
            target="RFC8362"/> and <xref target="LOCSUBTLVS"/> of this
            document.</t>

            <t>Type 3: Route-Tag sub-TLV: Refer to <xref target="RFC8362"/>
            and <xref target="LOCSUBTLVS"/> of this document.</t>

            <t>Type 4: Prefix SID</td>
      <td>RFC 9513, <xref target="END"/></td>
    </tr>
    <tr>
      <td>2</td>
      <td>IPv6-Forwarding-Address</td>
<td><xref target="RFC8362"
      format="default"/>; RFC 9513, <xref target="LOCSUBTLVS"/></td>
    </tr>
    <tr>
      <td>3</td>
      <td>Route-Tag</td>
      <td><xref target="RFC8362" format="default"/>; RFC 9513, <xref target="LOCSUBTLVS"/></td>
    </tr>
    <tr>
      <td>4</td>
      <td>Prefix Source OSPF Router-ID sub-TLV: Refer to <xref
            target="RFC9084"/> and <xref target="LOCSUBTLVS"/> of this
            document.</t>

            <t>Type 5: Prefix Router-ID</td>
      <td><xref target="RFC9084" format="default"/>; RFC 9513, <xref target="LOCSUBTLVS"/></td>
    </tr>
    <tr>
      <td>5</td>
      <td>Prefix Source Router Address sub-TLV: Refer to <xref
            target="RFC9084"/> and <xref target="LOCSUBTLVS"/> of this
            document.</t>

            <t>Type 10: SRv6 SID Structure Sub-TLV: Refer to <xref
            target="SRSTRUCTTLV"/> of this document.</t>
          </list></t> Address</td>
      <td><xref target="RFC9084" format="default"/>; RFC 9513, <xref target="LOCSUBTLVS"/></td>
   </tr>
    <tr>
      <td>10</td>
      <td>SRv6 SID Structure</td>
    <td>RFC 9513, <xref target="SRSTRUCTTLV"/></td>
  </tr> </tbody>

  </table>
        <t>Types in the range 6-9 and 11-32767 0-32767 are allocated via IETF Review
        or IESG Approval <xref target="RFC8126"/>.</t> target="RFC8126" format="default"/>.</t>
        <t>Types in the range 32768-33023 are Reserved for Experimental Use;
        these will not be registered with IANA and MUST NOT <bcp14>MUST NOT</bcp14> be mentioned by
        RFCs.</t>
        <t>Types in the range 33024-45055 are to be assigned on a First Come
        First Served (FCFS) FCFS basis.</t>
        <t>Types in the range 45056-65535 are not to be assigned at this time.
        Before any assignments can be made in the 45056-65535 range, there
        MUST
        <bcp14>MUST</bcp14> be an IETF specification that specifies IANA Considerations that
        cover the range being assigned.</t>
        <t>The following note indicated below needs to be has been added under to this registry to
        ensure that any document requesting allocations under in this registry
        for sub-TLVs of any of the OSPFv3 SRv6 Locator TLVs checks if
        allocations are also applicable for the "OSPFv3 Extended-LSA Sub-TLVs"
        registry.</t>

<blockquote>
        <t>Note: Allocations made under in this registry for any sub-TLVs that
        are associated with OSPFv3 SRv6 Locator TLVs MUST <bcp14>MUST</bcp14> be also
        evaluated for their applicability as OSPFv3 Extended-LSA Sub-TLVs and,
        therefore, also requiring allocation under sub-TLVs,
        which are required to be allocated in the "OSPFv3 Extended-LSA
        Sub-TLVs" registry.</t>
</blockquote>
      </section>
      <section anchor="IANAOSPFV3EXTLSA" title="OSPFv3 numbered="true" toc="default">
        <name>OSPFv3 Extended-LSA Sub-TLVs">
        <t>This document requests IANA to add Sub-TLVs</name>
        <t>IANA has added the following note indicated below under to
        the "OSPFv3 Extended-LSA Sub-TLVs" registry under within the "OSPFv3 "Open Shortest Path First v3 (OSPFv3) Parameters" registry group. The purpose of this note is to ensure that
        any document requesting allocations under in this registry for sub-TLVs
        of any of the OSPFv3 Extended Prefix TLVs checks if allocations are
        also applicable for the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry
        that is created by
        defined in this document.</t>
<blockquote>
        <t>Note: Allocations made under in this registry for any sub-TLVs that
        are associated with OSPFv3 Extended TLVs related to prefix
        advertisements MUST <bcp14>MUST</bcp14> be also evaluated for their
        applicability as OSPFv3 SRv6 Locator Sub-TLVs and, therefore, also requiring allocation
        under sub-TLVs, which are
        required to be allocated in the "OSPFv3 SRv6 Locator LSA Sub-TLVs"
        registry.</t>
</blockquote>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7770.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9259.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8666.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8476.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9084.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9350.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9352.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/>

<!-- [I-D.ietf-idr-bgpls-srv6-ext] in REF state as of 09/20/23; companion document RFC 9514 -->

<reference anchor="RFC9514" target="https://www.rfc-editor.org/info/rfc9514">
<front>
<title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)</title>
<author initials="G." surname="Dawra" fullname="Gaurav Dawra">
<organization>LinkedIn</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="M." surname="Chen" fullname="Mach Chen">
<organization>Huawei</organization>
</author>
<author initials="D." surname="Bernier" fullname="Daniel Bernier">
<organization>Bell Canada</organization>
</author>
<author initials="B." surname="Decraene" fullname="Bruno Decraene">
<organization>Orange</organization>
</author>
<date month="November" year="2023"/>
</front>
<seriesInfo name="RFC" value="9514"/>
<seriesInfo name="DOI" value="10.17487/RFC9514"/>
</reference>
      </references>
    </references>

    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to acknowledge the contributions of Dean Cheng <contact fullname="Dean Cheng"/>
      in the early draft versions of this document. The authors would like to thank
      Ran Chen and Detao Zhao
      <contact fullname="Ran Chen"/> and <contact fullname="Detao Zhao"/> for their suggestions related to the extension
      of PrefixOptions for the signaling of the anycast property.</t>
      <t>The authors would like to thank Chenzichao, Dirk Goethals, Baalajee
      S, Yingzhen Qu, Shraddha Hegde, Dhruv Dhody, Martin Vigoureux, and Reese
      Enghardt <contact fullname="Chenzichao"/>,
      <contact fullname="Dirk Goethals"/>, <contact fullname="Baalajee S"/>,
      <contact fullname="Yingzhen Qu"/>, <contact fullname="Shraddha Hegde"/>,
      <contact fullname="Dhruv Dhody"/>, <contact fullname="Martin
      Vigoureux"/>, and <contact fullname="Reese Enghardt"/> for their review
      and comments on this document. The authors would like to thank Acee Lindem <contact
      fullname="Acee Lindem"/> for his detailed shepherd review and feedback
      for improvement of this document. The authors would like to thank John Scudder
      <contact fullname="John Scudder"/> for his AD review and suggestions to
      improve this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8126'?>

      <?rfc include='reference.RFC.8174'?>

      <?rfc include='reference.RFC.5340'?>

      <?rfc include='reference.RFC.7166'?>

      <?rfc include='reference.RFC.7770'?>

      <?rfc include='reference.RFC.8362'?>

      <?rfc include='reference.RFC.8402'?>

      <?rfc include='reference.RFC.8986'?>

      <?rfc include='reference.RFC.9259'?>

      <?rfc include='reference.RFC.8666'?>

      <?rfc include='reference.RFC.8665'?>

      <?rfc include='reference.RFC.8476'?>

      <?rfc include='reference.RFC.8754'?>

      <?rfc include='reference.RFC.9084'?>

      <?rfc include='reference.RFC.9350'?>

      <?rfc include='reference.RFC.9352'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.3630'?>

      <?rfc include='reference.I-D.ietf-idr-bgpls-srv6-ext'?>
    </references>
    </back>
</rfc>