<?xml version="1.0" encoding="US-ASCII"?>
<!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"?>
<rfc category="std" docName="draft-bonica-spring-sr-mapped-six-04"
     ipr="trust200902">
  <front>
    <title abbrev="SRm6">Segment Routing Mapped To IPv6 (SRm6)</title>

    <author fullname="Ron Bonica" initials="R." surname="Bonica">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street/>

          <city>Herndon</city>

          <code>20171</code>

          <region>Virginia</region>

          <country>USA</country>
        </postal>

        <email>rbonica@juniper.net</email>
      </address>
    </author>

    <author fullname="Shraddha Hegde" initials="S." surname="Hegde">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>Embassy Business Park</street>

          <city>Bangalore</city>

          <region>KA</region>

          <code>560093</code>

          <country>India</country>
        </postal>

        <email>shraddha@juniper.net</email>
      </address>
    </author>

    <author fullname="Yuji Kamite" initials="Y. " surname="Kamite">
      <organization>NTT Communications Corporation</organization>

      <address>
        <postal>
          <street>3-4-1 Shibaura, Minato-ku</street>

          <city>Tokyo</city>

          <code>108-8118</code>

          <country>Japan</country>
        </postal>

        <email>y.kamite@ntt.com</email>
      </address>
    </author>

    <author fullname="Andrew Alston" initials="A." surname="Alston">
      <organization>Liquid Telecom</organization>

      <address>
        <postal>
          <street/>

          <city>Nairobi</city>

          <country>Kenya</country>
        </postal>

        <email>Andrew.Alston@liquidtelecom.com</email>
      </address>
    </author>

    <author fullname="Daniam Henriques" initials="D." surname="Henriques">
      <organization>Liquid Telecom</organization>

      <address>
        <postal>
          <street/>

          <city>Johannesburg</city>

          <country>South Africa</country>
        </postal>

        <email>daniam.henriques@liquidtelecom.com</email>
      </address>
    </author>

    <author fullname="Luay Jalil" initials="L. " surname="Jalil">
      <organization>Verizon</organization>

      <address>
        <postal>
          <street/>

          <city>Richardson</city>

          <region>Texas</region>

          <country>USA</country>
        </postal>

        <email>luay.jalil@one.verizon.com</email>
      </address>
    </author>

    <author fullname="Joel Halpern" initials="J." surname="Halpern">
      <organization>Ericsson</organization>

      <address>
        <postal>
          <street>P. O. Box 6049</street>

          <city>Leesburg</city>

          <region>Virginia</region>

          <code>20178</code>

          <country>USA</country>
        </postal>

        <email>joel.halpern@ericsson.com</email>
      </address>
    </author>

    <author fullname="Jen Linkova" initials="J." surname="Linkova">
      <organization>Google</organization>

      <address>
        <postal>
          <street/>

          <city>Mountain View</city>

          <region>California</region>

          <code>94043</code>

          <country>USA</country>
        </postal>

        <email>furry@google.com</email>
      </address>
    </author>

    <author fullname="Gang Chen" initials="G." surname="Chen">
      <organization>Baidu</organization>

      <address>
        <postal>
          <street>No.10 Xibeiwang East Road Haidian District</street>

          <city>Beijing</city>

          <code>100193</code>

          <country>P.R. China</country>
        </postal>

        <email>phdgang@gmail.com</email>
      </address>
    </author>

    <date day="27" month="September" year="2021"/>

    <area>Routing Area</area>

    <workgroup>SPRING Working Group</workgroup>

    <keyword>Segment Routing</keyword>

    <keyword>IPv6</keyword>

    <abstract>
      <t>This document describes Segment Routing Mapped to IPv6 (SRm6). SRm6
      is a Segment Routing (SR) solution that supports a wide variety of
      use-cases while complying with IPv6 specifications. SRm6 is optimized
      for ASIC-based routers that operate at high data rates.</t>
    </abstract>
  </front>

  <middle>
    <section title="Overview">
      <t>Network operators deploy <xref target="RFC8402">Segment Routing (SR)
      </xref> so they can forward packets through SR paths. An SR path
      provides connectivity from its ingress node to its egress node. While an
      SR path can follow the least-cost path from ingress to egress, it can
      also follow any other path.</t>

      <t>An SR path contains one or more segments. A segment provides
      connectivity from its ingress node to its egress node. It includes a
      topological instruction that controls its behavior.</t>

      <t>The topological instruction is executed on the segment ingress node.
      It determines the segment egress node and the method by which the
      segment ingress node sends packets to the segment egress node.</t>

      <t>SR nodes can also execute service instructions. Segment egress nodes
      execute Per Segment Service Instructions (PSSI). Likewise, path egress
      nodes execute Per Path Service Instructions (PPSI). <xref
      target="sectRefTopo"> </xref> of this document describes the
      relationship between SR paths, segments and instructions.</t>

      <t>A Segment Identifier (SID) identifies each segment. Because there is
      a one-to-one relationship between segments and the topological
      instructions that control them, the SID that identifies a segment also
      identifies the topological instruction that controls it.</t>

      <t>A SID is shorter than the topological instruction that it identifies.
      While a SID is 16 or 32 bits long, the topological instruction that it
      identifies is at least 128 bits long.</t>

      <t>To forward a packet through an SR path, the SR ingress node encodes a
      list of SIDs in the packet header. It can also encode service
      instructions in the packet header.</t>

      <t>Because the SR ingress node is also the first segment ingress node,
      it executes the first segment's topological instruction and sends the
      packet to the first segment egress node. When the first segment egress
      node receives the packet, it executes the first segment's PSSI, if one
      is present.</t>

      <t>If the SR path contains only one segment, the first segment egress
      node is also the path egress node. In this case, that node executes the
      PPSI, if one is present.</t>

      <t>If the SR path contains multiple segments, the first segment's egress
      node is also the second segment's ingress node. In this case, that node
      executes the second segment's topological instruction. This procedure
      continues until the packet arrives at the path egress node. If the
      packet includes a PPSI, the path egress node executes it.</t>

      <t>In SR, only the path ingress node maintains path information. The
      segment ingress node maintains a topological instruction, but it does
      not maintain path information unless it is also a path ingress node.</t>

      <t>SR can use either an <xref target="RFC3031">MPLS</xref> data plane or
      an <xref target="RFC8200">IPv6</xref> data plane. <xref
      target="RFC8660">SR-MPLS</xref> uses MPLS. <xref
      target="RFC8986">SRv6</xref> uses IPv6.</t>

      <t>This document describes Segment Routing Mapped to IPv6 (SRm6). SRm6
      is an SR solution that also uses IPv6. It supports a wide variety of
      use-cases while adhering to IPv6 specifications.</t>

      <t><xref target="sectDifference"/> of this document describes the
      differences between SRv6 and SRm6.</t>
    </section>

    <section anchor="sectRefTopo" title="Paths, Segments And Instructions">
      <figure align="center" anchor="figRefTopo"
              title="Paths, Segments And Instructions">
        <artwork><![CDATA[  ----      ----      ----      ----      ----      ----
 |Node|----|Node|----|Node|----|Node|----|Node|----|Node|
 | A  |    | B  |    | C  |    | D  |    | E  |    | F  |
  ----      ----      ----      ----      ----      ----
    |                   |         |                   |         
     -------------------|         |-------------------|
        Segment A-C     |---------|    Segment D-F
                        Segment C-D
    |                                                 |
     -------------------------------------------------
                          SRm6 Path 
]]></artwork>
      </figure>

      <t><xref target="figRefTopo"/> depicts an SRm6 path. The path provides
      connectivity from its ingress node (i.e., Node A) to its egress node
      (i.e., Node F). It contains Segments A-C, C-D and D-F.</t>

      <t>In Segment A-C, Node A is the ingress node, Node B is a transit node,
      and Node C is the egress node. So, Node A executes the segment's
      topological instruction. If the packet includes a PSSI for the segment,
      Node C executes it.</t>

      <t>In Segment C-D, Node C is the ingress node and Node D is the egress
      node. So, Node C executes the segment's topological instruction. If the
      packet includes a PSSI for the segment, Node D executes it.</t>

      <t>In Segment D-F, Node D is the ingress node, Node E is a transit node,
      and Node F is the egress node. So, Node D executes the segment's
      topological instruction. If the packet includes a PSSI for the segment,
      Node F executes it.</t>

      <t>Node F is also the path egress node. So, if the packet includes a
      PPSI, Node F executes it.</t>

      <t>Other paths that are not included in the figure also include Segments
      A-C, C-D, and D-F.</t>
    </section>

    <section anchor="sectSegs" title="Topological Instructions">
      <t>SRm6 supports the following topological instruction types:</t>

      <t><list style="symbols">
          <t>Adjacency.</t>

          <t>Node.</t>

          <t>Binding.</t>
        </list></t>

      <section title="Adjacency Instructions">
        <t>Adjacency instructions send packets through a single link that
        connects the segment ingress node to the segment egress node. An
        adjacency instruction includes the following information:</t>

        <t><list style="symbols">
            <t>SE-ADDR: The IPv6 address of an interface on the segment egress
            node.</t>

            <t>IFACE: An interface identifier.</t>
          </list></t>

        <t>The instruction behaves as follows:</t>

        <t><list style="symbols">
            <t>If the interface identified by IFACE is not operational,
            discard the packet and send an <xref
            target="RFC4443">ICMPv6</xref> Destination Unreachable message to
            the packet's source node.</t>

            <t>Overwrite the packet's Destination Address with SE-ADDR.</t>

            <t>Send the packet through the interface identified by IFACE.</t>
          </list></t>
      </section>

      <section title="Node Instructions">
        <t>Node instructions send packets through the least-cost path from the
        segment ingress node to the segment egress node. A node instruction
        includes an SE-ADDR. The SE-ADDR is the IPv6 address of an interface
        on the segment egress node.</t>

        <t>The instruction behaves as follows:</t>

        <t><list style="symbols">
            <t>If the segment ingress node does not have a viable route to
            SE-ADDR, discard the packet and send an ICMPv6 Destination
            Unreachable message to the packet's source node.</t>

            <t>Overwrite the packet's Destination Address with SE-ADDR.</t>

            <t>Send the packet to the next-hop along the least-cost path to
            SE-ADDR.</t>
          </list></t>
      </section>

      <section title="Binding Instructions">
        <t>Binding instructions send packets through tunnels that connect the
        segment ingress node to the segment egress node. Because the tunnel is
        also an SRm6 path, it is called an SRm6 tunnel.</t>

        <t>A binding instruction includes the following information:</t>

        <t><list style="symbols">
            <t>SE-ADDR: The IPv6 address of an interface on the segment egress
            node.</t>

            <t>Tunnel-SID-List: A SID list that determines the path of the
            SRm6 tunnel.</t>
          </list></t>

        <t>The instruction behaves as follows:<list style="symbols">
            <t>Overwrite the packet's Destination Address with SE-ADDR.</t>

            <t>Prepend an SRm6 tunnel header to the packet. The SRm6 tunnel
            header includes the Tunnel-SID-List.</t>

            <t>If the SRm6 tunnel is not operational, discard the packet and
            send an ICMPv6 Destination Unreachable message to the packet's
            source node.</t>

            <t>Send the packet through the SRm6 tunnel.</t>
          </list></t>
      </section>
    </section>

    <section anchor="SectServiceInstructions" title="Service Instructions">
      <t>SRm6 supports the following service instruction types:</t>

      <t><list style="symbols">
          <t>Per-Segment Service Instructions (PSSI).</t>

          <t>Per-Path Service Instructions (PPSI).</t>
        </list></t>

      <section title="PSSI">
        <t>The PSSI, if present, is executed on the segment egress node.
        Because the path egress node is also a segment egress node, it can
        execute a PSSI.</t>

        <t>The following are examples of PSSIs:</t>

        <t><list style="symbols">
            <t>Expose a packet to a firewall policy.</t>

            <t>Expose a packet to a sampling policy.</t>
          </list></t>
      </section>

      <section title="PPSI">
        <t>A PPSI, if present, is executed on the path egress node.</t>

        <t>The following are examples of PPSIs:</t>

        <t><list style="symbols">
            <t>De-encapsulate a packet and forward its newly exposed payload
            through a specified interface.</t>

            <t>De-encapsulate a packet and forward its newly exposed payload
            using a specified routing table.</t>
          </list></t>
      </section>
    </section>

    <section anchor="sectSID" title="Segment Identifiers (SID)">
      <t>A Segment Identifier (SID) is an unsigned integer that identifies a
      segment. It can be either 16 or 32 bits long. Because there is a
      one-to-one relationship between segments and the topological
      instructions that control them, the SID that identifies a segment also
      identifies the topological instruction that controls it.</t>

      <t>A SID is shorter than the topological instruction that it identifies.
      While a SID is 16 or 32 bits long, the topological instruction that it
      identifies is at least 128 bits long.</t>

      <t>SIDs have node-local significance. This means that a segment ingress
      node identifies each segment that it originates with a unique SID.
      However, a single SID value can be used to identify:</t>

      <t><list style="symbols">
          <t>A segment whose ingress is Node A and whose egress is Node Z.</t>

          <t>Another segment whose ingress is Node B and whose egress is also
          node Z.</t>
        </list></t>

      <t>A single SID value can identify both segments because they originate
      on different nodes.</t>

      <t>SID values 0 through 15 are reserved for future use.</t>

      <t>SIDs can be assigned in a manner that simplifies network operations.
      See <xref target="sectSRSID"/> for details.</t>

      <section anchor="sectRange" title="16-Bit SIDs Versus 32-Bit SIDs">
        <t>The maximum 16-bit SID value is 65,535. Because SIDs 0 through 15
        are reserved for future use, a 16-bit SID offers 65,520 usable
        values.</t>

        <t>The maximum 32-bit SID value is 4,294,967,295. Because SIDs 0
        through 15 are reserved for future use, a 32-bit SID offers
        4,294,967,280 usable values.</t>

        <t>To minimize packet length, network operators should use 16-bit SIDs
        whenever possible. However, when more than 65,520 SIDs are required,
        network operators must use 32-bit SIDs.</t>

        <t>Consider a network that contains 60,000 nodes. Each node connects
        to 200 or fewer neighbors through point-to-point links. In this
        network, we will determine how many SIDs are required under the
        following conditions:</t>

        <t><list style="symbols">
            <t>If the network contains adjacency segments only.</t>

            <t>If the network contains node segments only.</t>

            <t>If the network contains both adjacency and node segments.</t>
          </list>If the network contains adjacency segments only, and each
        node originates an adjacency segment to each of its neighbors, each
        node originates 200 segments or fewer. Because SIDs have node-local
        significance (i.e., they can be reused across nodes), the network
        requires only 200 SIDs. The network operator can use 16-bit SIDs, so
        long as each node supports 65,520 point-to-point links or fewer.</t>

        <t>If the network contains node segments only, and every node
        originates a node segment to every other node, every node originates
        59,999 segments. Because SIDs have node-local significance, the
        network requires only 59,999 SIDs. The network operator can use 16-bit
        SIDs so long as the number of nodes is less than 65,520.</t>

        <t>If the network contains both adjacency and node segments, each node
        will originate 60,199 segments or fewer. This value is the sum of:</t>

        <t><list style="symbols">
            <t>The number of node segments that each node originates (i.e.,
            59,999).</t>

            <t>The number of adjacency segments that each node originates
            (i.e., 200 or fewer).</t>
          </list>Because SIDs have node-local significance, only 60,199 SIDs
        are required. The network operator can use 16-bit SIDs so long as the
        number of nodes plus the maximum number of links per node is less than
        65,520.</t>
      </section>

      <section anchor="sectSRSID" title="Assigning SIDs">
        <t>Network operators can establish conventions for assigning SIDs to
        segments. These conventions can simplify network operations.</t>

        <t>For example, a network operator who uses 16-bit SIDs can:</t>

        <t><list style="symbols">
            <t>Assign SIDs 16 - 1000 to adjacency segments</t>

            <t>Assign SIDs 1001 - 62,000 to node segments</t>

            <t>Assign SIDs 62,001 to 65,535 to binding segments</t>
          </list>The network operator can also assign node SIDs so that all
        node segments ending on a node have the same SID (i.e., all node
        instructions that include the same information are identified by the
        same SID).</t>

        <texttable anchor="nodeseg" style="full" title="Node SID Assignments">
          <ttcol align="center">Segment Ingress Node</ttcol>

          <ttcol align="center">Segment Egress Node</ttcol>

          <ttcol align="center">SID</ttcol>

          <c>2</c>

          <c>1</c>

          <c>1001</c>

          <c>3</c>

          <c>1</c>

          <c>1001</c>

          <c>1</c>

          <c>2</c>

          <c>1002</c>

          <c>3</c>

          <c>2</c>

          <c>1002</c>

          <c>1</c>

          <c>3</c>

          <c>1003</c>

          <c>2</c>

          <c>3</c>

          <c>1003</c>
        </texttable>

        <t><xref target="nodeseg"/> illustrates this convention for Nodes 1, 2
        and 3.</t>
      </section>
    </section>

    <section anchor="sectEncode" title="Forwarding Plane">
      <t/>

      <figure align="center" anchor="figTunnel" title="SRm6 Path As Tunnel">
        <artwork><![CDATA[                  SRm6 Path from node B to node C
                   <------------------------>
                 SR Path                    SR Path
                 Ingress                    Egress
                 Node                       Node
  +-+            +-+                        +-+            +-+
  |A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D|
  +-+            +-+                        +-+            +-+
  Original                                                 Original
  Packet                                                   Packet
  Source                                                   Destination
  Node                                                     Node]]></artwork>
      </figure>

      <t>SRm6 is an application of <xref target="RFC2473">IPv6
      tunneling</xref>. <xref target="figTunnel"/> illustrates how an SRm6
      ingress node receives an original packet, encapsulates it in an SRm6
      header, and forwards the resulting SRm6 packet through an SRm6 path to
      an SRm6 egress node. The SRm6 egress node removes the SRm6 header and
      forwards the original packet to its destination.</t>

      <t/>

      <figure align="center" anchor="figheader" title="SRm6 Encapsulation">
        <artwork><![CDATA[                          +----------------------------------//-----+
                            | Original |                              |
                            |          |   Original Packet Payload    |
                            | Header   |                              |
                            +----------------------------------//-----+
                             <            Original Packet            >
                                              |
                                              v
       <     SRm6 Header    > <       Original Packet                 >
      +---------+ - - - - - +-------------------------//--------------+
      | IPv6    | IPv6      |                                         |
      |         | Extension |        Original Packet                  |
      | Header  | Headers   |                                         |
      +---------+ - - - - - +-------------------------//--------------+
       <                              SRm6 Packet                     >]]></artwork>
      </figure>

      <t><xref target="figheader"/> illustrates SRm6 encapsulation. In the
      figure, the SRm6 header contains:</t>

      <t><list style="symbols">
          <t>An IPv6 header.</t>

          <t>One or more IPv6 extension headers.</t>
        </list></t>

      <t>The following rules govern the use of extension headers in the SRm6
      header:</t>

      <t><list style="symbols">
          <t>The SRm6 header can contain any valid combination of extension
          headers.</t>

          <t>Extension headers are arranged in the order recommended by
          Section 4.1 of <xref target="RFC8200"/>.</t>

          <t>Extension headers are processed in the order that the appear in
          the packet, as described in Section 4.1 of <xref
          target="RFC8200"/>.</t>

          <t>If the SR path contains multiple segments, the SID list is
          encoded in a <xref target="I-D.bonica-6man-comp-rtg-hdr">Compressed
          Routing Header (CRH) </xref>.</t>

          <t>If the SRm6 header contains a PSSI, it is encoded in a
          Destination Option header that precedes the CRH. Destination options
          will be defined as needed.</t>

          <t>If the SRm6 header contains a PPSI, it is encoded in the <xref
          target="I-D.bonica-6man-vpn-dest-opt">IPv6 Tunnel Payload Forwarding
          (TPF) Option</xref>. The TPF option appears in a Destination Options
          header that immediately precedes the upper-layer header.</t>
        </list>Therefore, PSSI's are processed at each segment egress node,
      while the PPSI is processed at the path egress node only.</t>

      <t>An SRm6 header contains only the extension headers that it needs. For
      example, an SRm6 header can contain:</t>

      <t><list style="symbols">
          <t>A CRH and a TPF Option - This packet traverses an SRm6 path that
          contains multiple segments and executes a PPSI at the path egress
          node.</t>

          <t>A CRH only - This packet traverses an SRm6 path that contains
          multiple segments and does not execute a PPSI at the path egress
          node.</t>

          <t>A TPF Option only - This packet traverses an SRm6 path that
          contains a single segment and executes a PPSI at the path egress
          node.</t>
        </list>SRm6 inherits Hop Limit, traffic class and Flow Label
      processing procedures from <xref target="RFC2473">I</xref>.</t>
    </section>

    <section title="Control Plane">
      <t>The following documents describe control plane extensions that
      support the CRH and the TPF Option:</t>

      <t><list style="symbols">
          <t><xref target="I-D.bonica-lsr-crh-isis-extensions">IS-IS Support
          for CRH</xref></t>

          <t><xref target="I-D.ssangli-idr-bgp-vpn-srv6-plus">BGP Support for
          the IPv6 TPF Option </xref>, <xref
          target="I-D.alston-spring-crh-bgp-signalling"/></t>
        </list></t>
    </section>

    <section anchor="sectDifference" title="Differences Between SRm6 and SRv6">
      <section title="Instruction Encoding">
        <t>SRm6 encodes topological instructions in 16 or 32-bit SIDs that
        appear in the CRH. It also encodes service instructions in IPv6
        Destination Options.</t>

        <t>SRv6 encodes all instructions in the low-order bits of the IPv6
        Destination Address.</t>
      </section>

      <section title="IPv6 Address Semantics">
        <t>In SRm6 an IPv6 address always represents a network interface, as
        per <xref target="RFC4291"/>.</t>

        <t>In SRv6, an IPv6 Destination Address can represent either of the
        following:</t>

        <t><list style="symbols">
            <t>A network interface</t>

            <t>An SRv6 SID, whose high-order bits are used for routing and
            low-order bits represent an instruction.</t>
          </list></t>
      </section>

      <section title="OAM">
        <t>SRm6 does not require any new OAM mechanisms. Because SRv6 modifies
        IPv6 address semantics, it requires the OAM mechanisms described in
        <xref target="I-D.ietf-6man-spring-srv6-oam"/>.</t>
      </section>

      <section title="Routing Extension Header Size">
        <t/>

        <texttable align="center" anchor="tabRHSize" style="full"
                   title="Routing Header Size (in Bytes) As A Function Of Routing Header Type and Number Of SIDs">
          <ttcol align="center">SIDs</ttcol>

          <ttcol align="center">SRv6 SRH (128-bit SID)</ttcol>

          <ttcol align="center">SRm6 CRH-16</ttcol>

          <ttcol align="center">SRm6 CRH-32</ttcol>

          <c>1</c>

          <c>24</c>

          <c>8</c>

          <c>8</c>

          <c>2</c>

          <c>40</c>

          <c>8</c>

          <c>16</c>

          <c>3</c>

          <c>56</c>

          <c>16</c>

          <c>16</c>

          <c>4</c>

          <c>72</c>

          <c>16</c>

          <c>24</c>

          <c>5</c>

          <c>88</c>

          <c>16</c>

          <c>24</c>

          <c>6</c>

          <c>104</c>

          <c>16</c>

          <c>32</c>

          <c>7</c>

          <c>120</c>

          <c>24</c>

          <c>32</c>

          <c>8</c>

          <c>136</c>

          <c>24</c>

          <c>40</c>

          <c>9</c>

          <c>152</c>

          <c>24</c>

          <c>40</c>

          <c>10</c>

          <c>168</c>

          <c>24</c>

          <c>48</c>

          <c>11</c>

          <c>184</c>

          <c>32</c>

          <c>48</c>

          <c>12</c>

          <c>200</c>

          <c>32</c>

          <c>52</c>

          <c>13</c>

          <c>216</c>

          <c>32</c>

          <c>52</c>

          <c>14</c>

          <c>232</c>

          <c>32</c>

          <c>56</c>

          <c>15</c>

          <c>248</c>

          <c>40</c>

          <c>56</c>

          <c>16</c>

          <c>264</c>

          <c>40</c>

          <c>60</c>

          <c>17</c>

          <c>280</c>

          <c>40</c>

          <c>60</c>

          <c>18</c>

          <c>296</c>

          <c>40</c>

          <c>64</c>
        </texttable>

        <t>SRv6 and SRm6 both encode path information in a Routing extension
        header. SRv6 uses the <xref target="RFC8754">Segment Routing Header
        (SRH)</xref>, while SRm6 uses either the 16 or 32-bit version of the
        CRH. <xref target="tabRHSize"> </xref> reports Routing header size as
        a function of Routing header type and number of SIDs contained by the
        Routing header. Due to their relative immaturity, <xref
        target="I-D.filsfils-spring-net-pgm-extension-srv6-usid"/>, <xref
        target="I-D.li-spring-compressed-srv6-np"/> and <xref
        target="I-D.mirsky-6man-unified-id-sr"/> are omitted from this
        analysis.</t>

        <t>Large Routing headers are undesirable for the following
        reasons:</t>

        <t><list style="symbols">
            <t>Many ASIC-based forwarders copy all headers from buffer memory
            to on-chip memory. As header sizes increase, so does the cost of
            this copy.</t>

            <t>Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely
            reliable, many IPv6 hosts refrain from sending packets larger than
            the IPv6 minimum link MTU (i.e., 1280 bytes). When packets are
            small, the overhead imposed by large Routing Headers is
            excessive.</t>
          </list></t>
      </section>

      <section title="Authentication">
        <t>An SRm6 packet can include any valid combination of IPv6 extension
        headers. However, the <xref target="RFC4302">IPv6 Authentication
        Header (AH) </xref> is not defined in SRv6.</t>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document does not request any actions by IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>SRm6 inherits the security consideration of <xref
      target="RFC2473">IPv6 tunneling</xref>, the <xref
      target="I-D.bonica-6man-comp-rtg-hdr">Compressed Routing Header
      (CRH)</xref>, and the <xref target="I-D.bonica-6man-vpn-dest-opt">IPv6
      Tunnel Payload Forwarding (TPF) Option</xref>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors wish to acknowledge Dr. Vanessa Ameen, Reji Thomas, Parag
      Kaneriya, Rejesh Shetty, Nancy Shaw, and John Scudder.</t>
    </section>
  </middle>

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

      <?rfc ?>

      <?rfc include='reference.I-D.bonica-6man-comp-rtg-hdr'?>

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

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

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

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

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

      <?rfc include='reference.I-D.ssangli-idr-bgp-vpn-srv6-plus'?>

      <?rfc include='reference.I-D.bonica-6man-vpn-dest-opt'?>

      <?rfc include='reference.I-D.bonica-lsr-crh-isis-extensions'?>

      <?rfc include='reference.I-D.alston-spring-crh-bgp-signalling'?>
    </references>

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

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

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

      <?rfc ?>

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

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

      <?rfc ?>

      <?rfc include='reference.I-D.filsfils-spring-net-pgm-extension-srv6-usid'?>

      <?rfc include='reference.I-D.ietf-6man-spring-srv6-oam"?>

      <?rfc include='reference.I-D.li-spring-compressed-srv6-np'?>

      <?rfc ?>

      <?rfc include='reference.I-D.mirsky-6man-unified-id-sr'?>

      <?rfc ?>
    </references>
  </back>
</rfc>
