rfc9631xml2.original.xml   rfc9631.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie
<?rfc compact="yes"?> tf-6man-comp-rtg-hdr-10" number="9631" consensus="true" ipr="trust200902" obsole
<?rfc subcompact="no"?> tes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth
<rfc category="exp" docName="draft-ietf-6man-comp-rtg-hdr-10" ="3" symRefs="true" sortRefs="true" version="3">
ipr="trust200902">
<front> <front>
<title abbrev="IPv6 Compact Routing Header">The IPv6 Compact Routing <title abbrev="IPv6 Compact Routing Header">The IPv6 Compact Routing
Header (CRH)</title> Header (CRH)</title>
<seriesInfo name="RFC" value="9631"/>
<author fullname="Ron Bonica" initials="R." surname="Bonica"> <author fullname="Ron Bonica" initials="R." surname="Bonica">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>2251 Corporate Park Drive</street> <street>2251 Corporate Park Drive</street>
<city>Herndon</city> <city>Herndon</city>
<code>20171</code> <code>20171</code>
<region>VA</region>
<region>Virginia</region> <country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>rbonica@juniper.net</email> <email>rbonica@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Yuji Kamite" initials="Y. " surname="Kamite"> <author fullname="Yuji Kamite" initials="Y. " surname="Kamite">
<organization>NTT Communications Corporation</organization> <organization>NTT Communications Corporation</organization>
<address> <address>
<postal> <postal>
<street>3-4-1 Shibaura, Minato-ku</street> <street>3-4-1 Shibaura, Minato-ku</street>
<region>Tokyo</region>
<city>Tokyo</city>
<code>108-8118</code> <code>108-8118</code>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<email>y.kamite@ntt.com</email> <email>y.kamite@ntt.com</email>
</address> </address>
</author> </author>
<author fullname="Andrew Alston" initials="A." surname="Alston"> <author fullname="Andrew Alston" initials="A." surname="Alston">
<organization>Liquid Telecom</organization> <organization>Alston Networks</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Nairobi</city> <city>Nairobi</city>
<country>Kenya</country> <country>Kenya</country>
</postal> </postal>
<email>aa@alstonnetworks.net</email>
<email>Andrew.Alston@liquidtelecom.com</email>
</address> </address>
</author> </author>
<author fullname="Daniam Henriques" initials="D." surname="Henriques"> <author fullname="Daniam Henriques" initials="D." surname="Henriques">
<organization>Liquid Telecom</organization> <organization>Liquid Telecom</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Johannesburg</city> <city>Johannesburg</city>
<country>South Africa</country> <country>South Africa</country>
</postal> </postal>
<email>daniam.henriques@liquidtelecom.com</email> <email>daniam.henriques@liquidtelecom.com</email>
</address> </address>
</author> </author>
<author fullname="Luay Jalil" initials="L." surname="Jalil"> <author fullname="Luay Jalil" initials="L." surname="Jalil">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Richardson</city> <city>Richardson</city>
<region>TX</region>
<region>Texas</region> <country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>luay.jalil@one.verizon.com</email> <email>luay.jalil@one.verizon.com</email>
</address> </address>
</author> </author>
<date month="August" year="2024"/>
<date day="30" month="May" year="2024"/> <area>INT</area>
<area>INT Area</area>
<workgroup>6man</workgroup> <workgroup>6man</workgroup>
<keyword>IPv6</keyword> <keyword>IPv6</keyword>
<keyword>Routing header</keyword> <keyword>Routing header</keyword>
<abstract> <abstract>
<t>This document describes an experiment in which two new IPv6 Routing <t>This document describes an experiment in which two new IPv6 Routing
headers are implemented and deployed. Collectively, they are called the headers are implemented and deployed. Collectively, they are called the
Compact Routing Headers (CRH). Individually, they are called CRH-16 and Compact Routing Header (CRH). Individually, they are called CRH-16 and
CRH-32.</t> CRH-32.</t>
<t>One purpose of this experiment is to demonstrate that the CRH can be <t>One purpose of this experiment is to demonstrate that the CRH can be
implemented and deployed in a production network. Another purpose is to implemented and deployed in a production network. Another purpose is to
demonstrate that the security considerations, described in this demonstrate that the security considerations described in this
document, can be addressed with access control lists. Finally, this document can be addressed with Access Control Lists (ACLs). Finally, this
document encourages replication of the experiment.</t> document encourages replication of the experiment.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Intro" title="Introduction"> <section anchor="Intro" numbered="true" toc="default">
<t><xref target="RFC8200">IPv6 </xref> source nodes use Routing headers <name>Introduction</name>
<t>IPv6 <xref target="RFC8200" format="default"></xref> source nodes use R
outing headers
to specify the path that a packet takes to its destination(s). The IETF ha s to specify the path that a packet takes to its destination(s). The IETF ha s
defined several <xref target="IANA-RH">Routing types</xref>. This defined several Routing Types; see <xref target="IANA-RT" format="default"
document defines two new Routing types. Collectively, they are ></xref>. This
called the Compact Routing Headers (CRH). Individually, they are called document defines two new Routing Types. Collectively, they are
called the Compact Routing Header (CRH). Individually, they are called
CRH-16 and CRH-32.</t> CRH-16 and CRH-32.</t>
<t>The CRH allows IPv6 source nodes to specify the path that a packet <t>The CRH allows IPv6 source nodes to specify the path that a packet
takes to its destination. The CRH can be encoded in relatively few takes to its destination. The CRH can be encoded in relatively few
bytes. The following are reasons for encoding the CRH in as few bytes as bytes. The following are reasons for encoding the CRH in as few bytes as
possible:</t> possible:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Many ASIC-based forwarders copy headers from buffer memory to <t> Many forwarders based on Application-Specific Integrated
on-chip memory. As header sizes increase, so does the cost of this Circuits (ASICs) copy headers from buffer memory to on-chip
copy.</t> memory. As header sizes increase, so does the cost of this copy.</t>
</li>
<t>Because <xref target="RFC8201">Path MTU Discovery (PMTUD)</xref> <li>
is not entirely reliable, many IPv6 hosts refrain from sending <t>Because Path MTU Discovery (PMTUD) <xref target="RFC8201"
packets larger than the IPv6 minimum link MTU (i.e., 1280 bytes). format="default"></xref> is not entirely reliable, many IPv6 hosts
When packets are small, the overhead imposed by large Routing refrain from sending packets larger than the IPv6 minimum link MTU
Headers is excessive.</t> (i.e., 1280 bytes). When packets are small, the overhead imposed by
</list>This document describes an experiment whose purposes are:</t> large Routing headers is excessive.</t>
</li>
<t><list style="symbols"> </ul>
<t>To demonstrate that the CRH can be implemented and deployed.</t> <t>This document describes an experiment with the following purposes:</t>
<ul spacing="normal">
<t>To demonstrate that the security considerations, described in <li>
this document, can be addressed with access control lists.</t> <t>To demonstrate that the CRH can be implemented and deployed</t>
</li>
<t>To encourage replication of the experiment.</t> <li>
</list></t> <t>To demonstrate that the security considerations described in
this document can be addressed with ACLs</t>
</li>
<li>
<t>To encourage replication of the experiment</t>
</li>
</ul>
</section> </section>
<section anchor="ReqLang" numbered="true" toc="default">
<section anchor="ReqLang" title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in <xref IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
target="RFC2119">BCP 14</xref> <xref target="RFC8174"/> when, and only NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="The Compact Routing Headers (CRH)"> <name>The Compact Routing Header (CRH)</name>
<t>Both CRH versions (i.e., CRH-16 and CRH-32) contain the following <t>Both CRH versions (i.e., CRH-16 and CRH-32) contain the following
fields:</t> fields:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Next Header, as defined in <xref target="RFC8200"
<t>Next Header - Defined in <xref target="RFC8200"/>.</t> format="default"/></li>
<li>Hdr Ext Len, as defined in <xref target="RFC8200"
<t>Hdr Ext Len - Defined in <xref target="RFC8200"/>.</t> format="default"/></li>
<li>Routing Type, as defined in <xref target="RFC8200"
<t>Routing Type - Defined in <xref target="RFC8200"/>. (CRH-16 value format="default"/> (CRH-16 value is 5, and CRH-32 value is 6.)</li>
is 5. CRH-32 value is 6).</t> <li>Segments Left, as defined in <xref target="RFC8200"
format="default"/></li>
<t>Segments Left - Defined in <xref target="RFC8200"/>.</t> <li>type-specific data, as described in <xref target="RFC8200" format=
"default"/></li>
<t>Type-specific Data - Described in <xref target="RFC8200"/>.</t> </ul>
</list></t> <t>In the CRH, the type-specific data field contains a list of CRH Segment
Identifiers (CRH SIDs). Each CRH SID identifies an entry in the CRH Forwar
<t>In the CRH, the Type-specific data field contains a list of CRH Segment ding Information Base (CRH-FIB) (<xref target="crh-fib" format="default"></xref>
Identifiers (CRH SIDs). Each CRH SID identifies an entry in the <xref ). Each
target="crh-fib">CRH Forwarding Information Base (CRH-FIB) </xref>. Each
CRH-FIB entry identifies an interface on the path that the packet takes CRH-FIB entry identifies an interface on the path that the packet takes
to its destination.</t> to its destination.</t>
<t>CRH SIDs are listed in reverse order. So, the first CRH SID in the list <t>CRH SIDs are listed in reverse order. So, the first CRH SID in the list
represents the final interface in the path. Because CRH SIDs are listed represents the final interface in the path. Because CRH SIDs are listed
in reverse order, the Segments Left field can be used as an index into in reverse order, the Segments Left field can be used as an index into
the CRH SID list. In this document, the "current CRH SID" is the CRH SID l ist entry the CRH SID list. In this document, the "current CRH SID" is the CRH SID l ist entry
referenced by the Segments Left field.</t> referenced by the Segments Left field.</t>
<t>The first CRH SID in the path is omitted from the list unless there
<t>The first CRH SID in the path is omitted from the list unless there is is some reason to preserve it. See <xref target="Examples"
some format="default"> </xref> for an example.</t>
reason to preserve it. See <xref <t>In the CRH-16 (<xref target="CRHFig16" format="default"></xref>),
target="Examples"> </xref> for an example.</t> each CRH SID is encoded in 16 bits. In the CRH-32 (<xref
target="CRHFig32" format="default"></xref>), each CRH SID is encoded in
<t>In the <xref target="CRHFig16">CRH-16</xref>, each CRH SID is encoded i 32 bits.</t>
n <t>In all cases, the CRH <bcp14>MUST</bcp14> end on a 64-bit boundary. So,
16-bits. In the <xref target="CRHFig32">CRH-32</xref>, each CRH SID is the type-specific data field <bcp14>MUST</bcp14> be padded with zeros if the CR
encoded in 32-bits.</t> H would otherwise
<t>In all cases, the CRH MUST end on a 64-bit boundary. So, the Type-
specific data field MUST be padded with zeros if the CRH would otherwise
not end on a 64-bit boundary.</t> not end on a 64-bit boundary.</t>
<figure anchor="CRHFig16">
<figure align="left" anchor="CRHFig16" title="CRH-16"> <name>CRH-16</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left | | Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID[0] | SID[1] | | SID[0] | SID[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| ......... | .........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork> ]]></artwork>
</figure> </figure>
<figure anchor="CRHFig32">
<figure align="left" anchor="CRHFig32" title="CRH-32"> <name>CRH-32</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="left" alt=""><![CDATA[
3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left | | Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ SID[0] + + SID[0] +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ SID[1] + + SID[1] +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ......... | .........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
skipping to change at line 242 skipping to change at line 201
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left | | Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ SID[0] + + SID[0] +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ SID[1] + + SID[1] +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ......... | .........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="crh-fib" numbered="true" toc="default">
<section anchor="crh-fib" <name>The CRH Forwarding Information Base (CRH-FIB)</name>
title="The CRH Forwarding Information Base (CRH-FIB)">
<t>Each CRH SID identifies a CRH-FIB entry.</t> <t>Each CRH SID identifies a CRH-FIB entry.</t>
<t>Each CRH-FIB entry contains:</t> <t>Each CRH-FIB entry contains:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>An IPv6 address.</t> <t>An IPv6 address</t>
</li>
<t>A topological function.</t> <li>
<t>A topological function</t>
<t>Arguments for the topological function. (Optional).</t> </li>
</list></t> <li>
<t>Arguments for the topological function (optional)</t>
<t>The IPv6 address can be a Global Unicast Address (GUA), a Link Local Un </li>
icast address (LLU), or </ul>
<t>The IPv6 address can be a Global Unicast Address (GUA), a Link-Local Un
icast (LLU) address, or
a Unique Local Address (ULA). When the IPv6 address is the final address i n a path, it a Unique Local Address (ULA). When the IPv6 address is the final address i n a path, it
can also be a multicast address.</t> can also be a multicast address.</t>
<t>The topological function specifies how the processing node forwards <t>The topological function specifies how the processing node forwards
the packet to the interface identified by the IPv6 address. The the packet to the interface identified by the IPv6 address. The
following are examples:</t> following are examples:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Forward the packet through the least-cost path to the interface <t>Forward the packet through the least-cost path to the interface
identified by the IPv6 address (i.e., loose source routing).</t> identified by the IPv6 address (i.e., loose source routing).</t>
</li>
<li>
<t>Forward the packet through a specified interface to the interface <t>Forward the packet through a specified interface to the interface
identified by the IPv6 address (i.e.,strict source routing)</t> identified by the IPv6 address (i.e., strict source routing).</t>
</list></t> </li>
</ul>
<t>Some topological functions require parameters. For example, a <t>Some topological functions require parameters. For example, a
topological function might require a parameter that identifies the topological function might require a parameter that identifies the
interface through which the packet is forwarded.</t> interface through which the packet is forwarded.</t>
<t>The CRH-FIB can be populated by:</t>
<t>The CRH-FIB can be populated:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>An operator, using a Command Line Interface (CLI)</t>
<t>By an operator, using a Command Line Interface (CLI).</t> </li>
<li>
<t>By a controller, using the <xref target="RFC5440">Path <t>A controller, using the Path
Computation Element (PCE) Communication Protocol (PCEP) </xref> or Computation Element Communication Protocol (PCEP) <xref target="RFC544
the <xref target="RFC6241">Network Configuration Protocol 0" format="default"></xref> or
(NETCONF)</xref>.</t> the Network Configuration Protocol
(NETCONF) <xref target="RFC6241" format="default"></xref></t>
<t>By a distributed routing protocol <xref </li>
target="ISO10589-Second-Edition"/>, <xref target="RFC5340"/>, <xref <li>
target="RFC4271"/>.</t> <t>A distributed routing protocol, such as those defined in <xref targ
</list></t> et="ISO10589-Second-Edition" format="default"/>, <xref target="RFC5340" format="
default"/>, and <xref target="RFC4271" format="default"/></t>
<t>The above-mentioned mechanisms are not defined here and are beyond the </li>
scope of this document</t> </ul>
<t>The above-mentioned mechanisms are not defined here and are beyond the
scope of this document.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Processing Rules"> <name>Processing Rules</name>
<t>The following rules describe CRH processing:<list style="symbols"> <t>The following rules describe CRH processing:</t>
<ul spacing="normal">
<li>
<t>If Hdr Ext Len indicates that the CRH is larger than the <t>If Hdr Ext Len indicates that the CRH is larger than the
implementation can process, discard the packet and send an <xref implementation can process, discard the packet and send an ICMPv6
target="RFC4443">ICMPv6 </xref> Parameter Problem, Code 0, message <xref target="RFC4443" format="default"></xref> Parameter Problem,
to the Source Address, pointing to the Hdr Ext Len field.</t> Code 0, message to the Source Address, pointing to the Hdr Ext Len
field.</t>
<t>Compute L, the minimum CRH length ( <xref target="SLLeng"> </li>
</xref>).</t> <li>
<t>Compute L, the minimum CRH length (<xref target="SLLeng" format="de
fault">
</xref>).</t>
</li>
<li>
<t>If L is greater than Hdr Ext Len, discard the packet and send an <t>If L is greater than Hdr Ext Len, discard the packet and send an
ICMPv6 Parameter Problem, Code 6, message to the Source Address, ICMPv6 Parameter Problem, Code 6, message to the Source Address,
pointing to the Segments Left field.</t> pointing to the Segments Left field.</t>
</li>
<li>
<t>Decrement Segments Left.</t> <t>Decrement Segments Left.</t>
</li>
<li>
<t>Search for the current CRH SID in the CRH-FIB. In this document, th e <t>Search for the current CRH SID in the CRH-FIB. In this document, th e
"current CRH SID" is the CRH SID list entry referenced by the Segments Left "current CRH SID" is the CRH SID list entry referenced by the Segments Left
field.</t> field.</t>
</li>
<li>
<t>If the search does not return a CRH-FIB entry, discard the packet <t>If the search does not return a CRH-FIB entry, discard the packet
and send an ICMPv6 Parameter Problem, Code 0, message to the Source and send an ICMPv6 Parameter Problem, Code 0, message to the Source
Address, pointing to the current SID.</t> Address, pointing to the current SID.</t>
</li>
<li>
<t>If Segments Left is greater than 0 and the CRH-FIB entry contains <t>If Segments Left is greater than 0 and the CRH-FIB entry contains
a multicast address, discard the packet and send an ICMPv6 Parameter a multicast address, discard the packet and send an ICMPv6 Parameter
Problem, Code 0, message to the Source Address, pointing to the Problem, Code 0, message to the Source Address, pointing to the
current SID. (This prevents packet storms.)</t> current SID. (This prevents packet storms.)</t>
</li>
<li>
<t>Copy the IPv6 address from the CRH-FIB entry to the Destination <t>Copy the IPv6 address from the CRH-FIB entry to the Destination
Address field in the IPv6 header.</t> Address field in the IPv6 header.</t>
</li>
<li>
<t>Submit the packet, its topological function, and its parameters to
the IPv6 module.</t>
</li>
</ul>
<t>Submit the packet, its topological function and its parameters to <aside><t>NOTE: By default, the IPv6 module determines the next hop and
the IPv6 module. See NOTE.</t>
</list>NOTE: By default, the IPv6 module determines the next-hop and
forwards the packet. However, the topological function may elicit forwards the packet. However, the topological function may elicit
another behavior. For example, the IPv6 module may forward the packet another behavior. For example, the IPv6 module may forward the packet
through a specified interface.</t> through a specified interface.</t>
</aside>
<section anchor="SLLeng" title="Computing Minimum CRH Length"> <section anchor="SLLeng" numbered="true" toc="default">
<name>Computing Minimum CRH Length</name>
<t>The algorithm described in this section accepts the following CRH <t>The algorithm described in this section accepts the following CRH
fields as its input parameters:</t> fields as its input parameters:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Routing Type (i.e., CRH-16 or CRH-32).</t> <t>Routing Type (i.e., CRH-16 or CRH-32)</t>
</li>
<t>Segments Left.</t> <li>
</list></t> <t>Segments Left</t>
</li>
</ul>
<t>It yields L, the minimum CRH length. The minimum CRH length is <t>It yields L, the minimum CRH length. The minimum CRH length is
measured in 8-octet units, not including the first 8 octets.</t> measured in 8-octet units, not including the first 8 octets.</t>
<figure> <sourcecode name="" type="pseudocode" markers="true"><![CDATA[
<artwork align="center"><![CDATA[<CODE BEGINS>
switch(Routing Type) { switch(Routing Type) {
case CRH-16: case CRH-16:
if (Segments Left <= 2) if (Segments Left <= 2)
return(0) return(0)
sidsBeyondFirstWord = Segments Left - 2; sidsBeyondFirstWord = Segments Left - 2;
sidPerWord = 4; sidPerWord = 4;
case CRH-32: case CRH-32:
if (Segments Left <= 1) if (Segments Left <= 1)
return(0) return(0)
sidsBeyondFirstWord = Segments Left - 1; sidsBeyondFirstWord = Segments Left - 1;
sidsPerWord = 2; sidsPerWord = 2;
case default: case default:
return(0xFF); return(0xFF);
} }
words = sidsBeyondFirstWord div sidsPerWord; words = sidsBeyondFirstWord div sidsPerWord;
if (sidsBeyondFirstWord mod sidsPerWord) if (sidsBeyondFirstWord mod sidsPerWord)
words++; words++;
return(words) return(words)
]]></sourcecode>
<CODE ENDS>
]]></artwork>
</figure>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Mutability"> <name>Mutability</name>
<t>In the CRH, the Segments Left field is mutable. All remaining fields <t>In the CRH, the Segments Left field is mutable. All remaining fields
are immutable.</t> are immutable.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Applications And SIDs"> <name>Applications and CRH SIDs</name>
<t>A CRH contains one or more CRH SIDs. Each CRH SID is processed by exact ly one CRH-configured <t>A CRH contains one or more CRH SIDs. Each CRH SID is processed by exact ly one CRH-configured
router whose one address matches the packet destination address.</t> router whose one address matches the packet Destination Address.</t>
<t>Therefore, a CRH SID is not required to have domain-wide significance. <t>Therefore, a CRH SID is not required to have domain-wide
Applications can:<list style="symbols"> significance. Applications can allocate CRH SIDs so that they have
<t>Allocate CRH SIDs so that they have domain-wide significance.</t> either domain-wide or node-local significance.</t>
<t>Allocate CRH SIDs so that they have node-local significance.</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Operational Considerations"> <name>Operational Considerations</name>
<t><xref target="RFC2151">PING and TRACEROUTE </xref> both operate <t>PING and Traceroute <xref target="RFC2151" format="default"></xref> bot
h operate
correctly in the presence of the CRH. TCPDUMP and Wireshark have been correctly in the presence of the CRH. TCPDUMP and Wireshark have been
extended to support the CRH.</t> extended to support the CRH.</t>
<t>PING and Traceroute report 16-bit CRH SIDs for CRH-16 and
<t>PING and TRACEROUTE report 16-bit CRH SIDs for CRH-16, and
32-bit CRH SIDs for CRH-32. It is recommended that the 32-bit CRH SIDs for CRH-32. It is recommended that the
experimental versions of PING use the text representations experimental versions of PING use the textual representations
described in <xref target="TR"> </xref>.</t> described in <xref target="TR" format="default"> </xref>.</t>
</section> </section>
<section anchor="TR" numbered="true" toc="default">
<section anchor="TR" title="Textual Representation"> <name>Textual Representations</name>
<t>A 16-bit CRH SID can be represented by four lower-case hexadecimal digi <t>A 16-bit CRH SID can be represented by four lowercase hexadecimal digit
ts. Leading s. Leading
zeros SHOULD be omitted. However, the all-zeros CRH SID MUST be represente zeros <bcp14>SHOULD</bcp14> be omitted. However, the all-zeros CRH SID <bc
d p14>MUST</bcp14> be represented
by a single 0. The following are examples:</t> by a single 0. The following are examples:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>beef</t> <t>beef</t>
</li>
<li>
<t>eef</t> <t>eef</t>
</li>
<li>
<t>0</t> <t>0</t>
</list></t> </li>
</ul>
<t>A 16-bit CRH SID also can be represented in dotted-decimal notation. Th e <t>A 16-bit CRH SID also can be represented in dotted-decimal notation. Th e
following are examples:<list style="symbols"> following are examples:</t>
<ul spacing="normal">
<li>
<t>192.0</t> <t>192.0</t>
</li>
<li>
<t>192.51</t> <t>192.51</t>
</list></t> </li>
</ul>
<t>A 32-bit CRH SID can be represented by four lower-case hexadecimal digi <t>A 32-bit CRH SID can be represented by four lowercase hexadecimal digit
ts, a colon s, a colon
(:), and another four lower-case hexadecimal digits. Leading zeros MUST be (:), and another four lowercase hexadecimal digits. Leading zeros <bcp14>M
omitted. UST</bcp14> be omitted.
The following are examples:</t> The following are examples:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>dead:beef</t> <t>dead:beef</t>
</li>
<li>
<t>ead:eef</t> <t>ead:eef</t>
</li>
<li>
<t>:beef</t> <t>:beef</t>
</li>
<li>
<t>beef:</t> <t>beef:</t>
</li>
<li>
<t>:</t> <t>:</t>
</list>A 32-bit CRH SID can also be represent in dotted-decimal notation </li>
. </ul>
The following are examples:<list style="symbols"> <t>A 32-bit CRH SID can also be represented in dotted-decimal notation.
The following are examples:</t>
<ul spacing="normal">
<li>
<t>192.0.2.1</t> <t>192.0.2.1</t>
</li>
<li>
<t>192.0.2.2</t> <t>192.0.2.2</t>
</li>
<li>
<t>192.0.2.3</t> <t>192.0.2.3</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>In this document, one node trusts another only if both nodes are <t>In this document, one node trusts another only if both nodes are
operated by the same party. A node determines whether it trusts another operated by the same party. A node determines whether it trusts another
node by examining its IP address. In many networks, operators number their nodes node by examining its IP address. In many networks, operators number their nodes
from a small number of prefixes. This facilitates identification of truste using a small number of prefixes. This facilitates identification of trust
d nodes.</t> ed nodes.</t>
<t>A node can encounter security vulnerabilities when it processes a Routi
<t>A node can encounter security vulnerabilities when it processes a Routi ng header that
ng Header that originated on an untrusted node <xref target="RFC5095" format="default"/>.
originated on an untrusted node <xref Therefore, nodes <bcp14>MUST</bcp14> deploy ACLs that discard packets containin
target="RFC5095"/>. Therefore, nodes MUST deploy ACLs that discard packets g the
containing the
CRH when both of the following conditions are true:</t> CRH when both of the following conditions are true:</t>
<ul spacing="normal">
<list style="symbols"> <li>
<t>The Source Address does not identify an interface on a trusted <t>The Source Address does not identify an interface on a trusted
node.</t> node.</t>
</li>
<li>
<t>The Destination Address identifies an interface on the local <t>The Destination Address identifies an interface on the local
node.</t> node.</t>
</list> </li>
</ul>
<t>The above-mentioned ACLs do not protect the node from attack packets <t>The above-mentioned ACLs do not protect the node from attack packets
that contain a forged (i.e., spoofed) Source Address. In order to that contain a forged (i.e., spoofed) Source Address. In order to
mitigate this risk, nodes MAY also discard packets containing the CRH mitigate this risk, nodes <bcp14>MAY</bcp14> also discard packets containi ng the CRH
when all of the following conditions are true:</t> when all of the following conditions are true:</t>
<ul spacing="normal">
<list style="symbols"> <li>
<t>The Source Address identifies an interface on a trusted node.</t> <t>The Source Address identifies an interface on a trusted node.</t>
</li>
<li>
<t>The Destination Address identifies an interface on the local <t>The Destination Address identifies an interface on the local
node.</t> node.</t>
</li>
<li>
<t>The packet does not pass an <xref target="RFC8704">Enhanced <t>The packet does not pass an Enhanced
Feasible-Path Unicast Reverse Path Forwarding (RPF) </xref>,</t> Feasible-Path Unicast Reverse Path Forwarding (EFP-uRPF) <xref target=
</list> "RFC8704" format="default"></xref> check.</t>
</li>
<t>The RPF check eliminates some, but not all packets with forged </ul>
source addresses. Therefore, a network operator that deploys CRH MUST <t>The EFP-uRPF check eliminates some, but not all, packets with forged
implement Access Control Lists (ACL) on each of its edge nodes. The ACL Source Addresses. Therefore, a network operator that deploys CRH <bcp14>MU
discards packets whose source address identifies an interface on a ST</bcp14>
implement ACLs on each of its edge nodes. The ACL
discards packets whose Source Address identifies an interface on a
trusted node.</t> trusted node.</t>
<t>The CRH is compatible with end-to-end IPv6 Authentication Header (AH)
<t>The CRH is compatible with end-to-end IPv6 Authentication Header (AH) <xref target="RFC4302" format="default"/> processing. This is because the s
<xref target="RFC4302"></xref> processing. This is becasue the source node ource node calculates
calculates
the Integrity Check Value (ICV) over the packet as it arrives at the the Integrity Check Value (ICV) over the packet as it arrives at the
destination node.</t> destination node.</t>
</section>
<section title="Implementation and Deployment Status">
<t>Juniper Networks has produced experimental implementations of the CRH
on the MX-series (ASIC-based) router</t>
<t>Liquid Telecom has produced experimental implementations of the CRH
on software based routers.</t>
<t>The CRH has carried non-production traffic in CERNET and Liquid
Telecom.</t>
<t>Interoperability among these implementations has not yet been demonstra
ted.</t>
</section> </section>
<section title="Experimental Results"> <section numbered="true" toc="default">
<name>Experimental Results</name>
<t>Parties participating in this experiment should publish experimental <t>Parties participating in this experiment should publish experimental
results within one year of the publication of this document. results within one year of the publication of this document.
Experimental results should address the following:</t> Experimental results should address the following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Effort required to deploy<list style="symbols"> <t>Effort required to deploy</t>
<ul spacing="normal">
<li>
<t>Was deployment incremental or network-wide?</t> <t>Was deployment incremental or network-wide?</t>
</li>
<t>Was there a need to synchronize configurations at each node <li>
or could nodes be configured independently</t> <t>Was there a need to synchronize configurations at each node,
or could nodes be configured independently?</t>
<t>Did the deployment require hardware upgrade?</t> </li>
<li>
<t>Did the deployment require a hardware upgrade?</t>
</li>
<li>
<t>Did the CRH SIDs have domain-wide or node-local significance?</ t> <t>Did the CRH SIDs have domain-wide or node-local significance?</ t>
</list></t> </li>
</ul>
</li>
<li>
<t>Effort required to secure</t> <t>Effort required to secure</t>
</li>
<li>
<t>Performance impact</t> <t>Performance impact</t>
</li>
<li>
<t>Effectiveness of risk mitigation with ACLs</t> <t>Effectiveness of risk mitigation with ACLs</t>
</li>
<li>
<t>Cost of risk mitigation with ACLs</t> <t>Cost of risk mitigation with ACLs</t>
</li>
<t>Mechanism used to populate the FIB</t> <li>
<t>Mechanism used to populate the CRH-FIB</t>
</li>
<li>
<t>Scale of deployment</t> <t>Scale of deployment</t>
</li>
<t>Interoperability<list style="symbols"> <li>
<t>Did you deploy two inter-operable implementations?</t> <t>Interoperability</t>
<ul spacing="normal">
<li>
<t>Did you deploy two interoperable implementations?</t>
</li>
<li>
<t>Did you experience interoperability problems?</t> <t>Did you experience interoperability problems?</t>
</li>
<li>
<t>Did implementations generally implement the same topological <t>Did implementations generally implement the same topological
functions with identical arguments?</t> functions with identical arguments?</t>
</li>
<li>
<t>Were topological function semantics identical on each <t>Were topological function semantics identical on each
implementation?</t> implementation?</t>
</list></t> </li>
</ul>
<t>Effectiveness and sufficiency of OAM mechanism<list </li>
style="symbols"> <li>
<t>Effectiveness and sufficiency of Operations, Administration, and
Maintenance (OAM) mechanisms</t>
<ul spacing="normal">
<li>
<t>Did PING work?</t> <t>Did PING work?</t>
</li>
<t>Did TRACEROUTE work?</t> <li>
<t>Did Traceroute work?</t>
</li>
<li>
<t>Did Wireshark work?</t> <t>Did Wireshark work?</t>
</li>
<li>
<t>Did TCPDUMP work?</t> <t>Did TCPDUMP work?</t>
</list></t> </li>
</list></t> </ul>
</li>
</ul>
</section> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations"> <t>IANA has registered the following in the "Routing Types"
<t>This document makes the following registrations in the "Internet subregistry within the "Internet Protocol Version 6 (IPv6) Parameters"
Protocol Version 6 (IPv6) Parameters" "Routing Types" subregistry registry:</t>
maintained by IANA:</t> <table anchor="iana-table">
<name></name>
<figure> <thead>
<artwork><![CDATA[ +-------+------------------------------+----- <tr>
----------+ <th>Value</th>
| Value | Description | Reference | <th>Description</th>
+=======+==============================+===============+ <th>Reference</th>
| 5 | CRH-16 | This document | </tr>
+-------+------------------------------+---------------+ </thead>
| 6 | CRH-32 | This document | <tbody>
+-------+------------------------------+---------------+ <tr>
]]></artwork> <td>5</td>
</figure> <td>CRH-16</td>
<td>RFC 9631</td>
<t/> </tr>
</section> <tr>
<td>6</td>
<td>CRH-32 </td>
<td>RFC 9631</td>
</tr>
</tbody>
</table>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Dr. Vanessa Ameen, Dale Carder, Brian Carpenter, Adrian
Farrel, Fernando Gont, Naveen Kottapalli, Joel Halpern, Mark Smith, Reji
Thomas, Tony Li, Xing Li, Gerald Schmidt, Nancy Shaw, Ketan Talaulikar,
and Chandra Venkatraman for their contributions to this document.</t>
</section> </section>
<section title="Contributors">
<t><list style="empty">
<t>Gang Chen</t>
<t>Baidu</t>
<t>No.10 Xibeiwang East Road Haidian District</t>
<t>Beijing 100193 P.R. China</t>
<t>Email: phdgang@gmail.com</t>
</list><list style="empty">
<t/>
</list><list style="empty">
<t>Yifeng Zhou</t>
<t>ByteDance</t>
<t>Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian District</t>
<t>Beijing 100000 P.R. China</t>
<t>Email: yifeng.zhou@bytedance.com</t>
</list><list style="empty">
<t/>
</list><list style="empty">
<t>Gyan Mishra</t>
<t>Verizon</t>
<t>Silver Spring, Maryland, USA</t>
<t>Email: hayabusagsm@gmail.com</t>
</list></t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>References</name>
<references>
<?rfc include='reference.RFC.8174'?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.8200'?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.4443'?> 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.5095'?> 200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include='reference.RFC.4302'?> 443.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc ?> 095.xml"/>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
302.xml"/>
<references title="Informative References"> </references>
<?rfc include='reference.RFC.2151'?> <references>
<name>Informative References</name>
<?rfc include='reference.RFC.5440'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
151.xml"/>
<?rfc include='reference.RFC.6241'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
440.xml"/>
<?rfc include='reference.RFC.5340'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
241.xml"/>
<?rfc include='reference.RFC.4271'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
340.xml"/>
<?rfc include='reference.RFC.8201'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<?rfc include='reference.RFC.8704'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
201.xml"/>
<?rfc ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
704.xml"/>
<reference anchor="IANA-RH"
target="https://www.iana.org/assignments/ipv6-parameters/ipv6-p
arameters.xhtml#ipv6-parameters-3">
<front>
<title>Routing Headers</title>
<author fullname="" initials="" surname="">
<organization>IANA</organization>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="ISO10589-Second-Edition" target=""> <reference anchor="IANA-RT" target="https://www.iana.org/assignments/ipv
<front> 6-parameters">
<title>"Intermediate system to Intermediate system intra-domain <front>
routeing information exchange protocol for use in conjunction with <title>Routing Types</title>
the protocol for providing the connectionless-mode Network Service <author>
(ISO 8473)", ISO/IEC 10589:2002, Second Edition,</title> <organization>IANA</organization>
</author>
</front>
</reference>
<author fullname="" initials="" surname=""> <reference anchor="ISO10589-Second-Edition" target="https://www.iso.org/
<organization>International Organization for standard/30932.html">
Standardization</organization> <front>
</author> <title>Information technology - Telecommunications and information e
xchange between systems - Intermediate System to Intermediate System intra-domai
n routeing information exchange protocol for use in conjunction with the protoco
l for providing the connectionless-mode network service (ISO 8473)</title>
<author>
<organization>ISO/IEC</organization>
</author>
<date month="November" year="2002"/>
</front>
<refcontent>Second Edition</refcontent>
<seriesInfo name="ISO/IEC" value="10589:2002"/>
</reference>
<date month="November" year="2001"/> </references>
</front>
</reference>
</references> </references>
<section anchor="Examples" numbered="true" toc="default">
<name>CRH Processing Examples</name>
<section anchor="Examples" title="CRH Processing Examples">
<t>This appendix demonstrates CRH processing in the following <t>This appendix demonstrates CRH processing in the following
scenarios:</t> scenarios:</t>
<ul spacing="normal">
<li>
<t>The CRH SID list contains one entry for each segment in the path
(<xref target="LSRP" format="default"></xref>).</t>
</li>
<li>
<t>The CRH SID list omits the first entry in the path (<xref
target="LSR" format="default"></xref>).</t>
</li>
</ul>
<t><xref target="RefTopo" format="default"/> provides a reference
topology that is used in all examples, and <xref target="lsid"
format="default"/> describes two entries that appear in each
node's CRH-FIB.</t>
<t><list style="symbols"> <figure anchor="RefTopo">
<t><xref target="LSRP">The CRH SID list contains one entry for each <name>Reference Topology</name>
segment in the path </xref>.</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<t><xref target="LSR">The CRH SID list omits the first entry in the pa
th
</xref>.</t>
</list></t>
<figure align="center" anchor="RefTopo" title="Reference Topology">
<artwork><![CDATA[
----------- ----------- ----------- ----------- ----------- -----------
|Node: S | |Node: I1 | |Node: I2 | |Node: S | |Node: I1 | |Node: I2 |
|Loopback: |---------------|Loopback: |---------------|Loopback: | |Loopback: |---------------|Loopback: |---------------|Loopback: |
|2001:db8::a| |2001:db8::1| |2001:db8::2| |2001:db8::a| |2001:db8::1| |2001:db8::2|
----------- ----------- ----------- ----------- ----------- -----------
| | | |
| ----------- | | ----------- |
| |Node: D | | | |Node: D | |
---------------------|Loopback: |--------------------- ---------------------|Loopback: |---------------------
|2001:db8::b| |2001:db8::b|
----------- -----------
]]></artwork> ]]></artwork>
</figure> </figure>
<table anchor="lsid" align="center">
<name>Node SIDs</name>
<thead>
<tr>
<th align="left">SID</th>
<th align="left">IPv6 Address</th>
<th align="left">Forwarding Method</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">2</td>
<td align="left">2001:db8::2</td>
<td align="left">Least-cost path</td>
</tr>
<tr>
<td align="left">11</td>
<td align="left">2001:db8::b</td>
<td align="left">Least-cost path</td>
</tr>
</tbody>
</table>
<section anchor="LSRP" numbered="true" toc="default">
<name>The CRH SID list contains one entry for each segment in the path.<
/name>
<t/> <t>In this example, Node S sends a packet to Node D via I2, and
I2 appears in the CRH segment list.</t>
<t><xref target="RefTopo"/> provides a reference topology that is used <table align="center">
in all examples.</t> <name>Packet Travels from S to I2</name>
<tbody>
<texttable anchor="lsid" title="Node SIDs"> <tr>
<ttcol>SID</ttcol> <td align="left">Source Address = 2001:db8::a</td>
<td align="left">Segments Left = 1</td>
<ttcol>IPv6 Address</ttcol> </tr>
<tr>
<ttcol>Forwarding Method</ttcol> <td align="left">Destination Address = 2001:db8::2</td>
<td align="left">SID[0] = 11</td>
<c>2</c> </tr>
<tr>
<c>2001:db8::2</c> <td align="left"/>
<td align="left">SID[1] = 2</td>
<c>Least-cost path</c> </tr>
</tbody>
<c>11</c> </table>
<table align="center">
<c>2001:db8::b</c> <name>Packet Travels from I2 to D</name>
<tbody>
<c>Least-cost path</c> <tr>
</texttable> <td align="left">Source Address = 2001:db8::a</td>
<td align="left">Segments Left = 0</td>
<t><xref target="lsid"/> describes two entries that appear in each </tr>
node's CRH-FIB.</t> <tr>
<td align="left">Destination Address = 2001:db8::b</td>
<t/> <td align="left">SID[0] = 11</td>
</tr>
<section anchor="LSRP" <tr>
title="The CRH SID List Contains One Entry For Each Segment In Th <td align="left"/>
e Path"> <td align="left">SID[1] = 2</td>
<t>In this example, Node S sends a packet to Node D, via I2. In this </tr>
example, I2 appears in the CRH segment list.</t> </tbody>
</table>
<texttable>
<ttcol>As the packet travels from S to I2:</ttcol>
<ttcol/>
<c>Source Address = 2001:db8::a</c>
<c>Segments Left = 1</c>
<c>Destination Address = 2001:db8::2</c>
<c>SID[0] = 11</c>
<c/>
<c>SID[1] = 2</c>
</texttable>
<texttable>
<ttcol>As the packet travels from I2 to D:</ttcol>
<ttcol/>
<c>Source Address = 2001:db8::a</c>
<c>Segments Left = 0</c>
<c>Destination Address = 2001:db8::b</c>
<c>SID[0] = 11</c>
<c/>
<c>SID[1] = 2</c>
</texttable>
</section> </section>
<section anchor="LSR" numbered="true" toc="default">
<name>The CRH SID list omits the first entry in the path.</name>
<t>In this example, Node S sends a packet to Node D via I2, and
I2 does not appear in the CRH segment list.</t>
<table align="center">
<name>Packet Travels from S to I2</name>
<tbody>
<tr>
<td align="left">Source Address = 2001:db8::a</td>
<td align="left">Segments Left = 1</td>
</tr>
<tr>
<td align="left">Destination Address = 2001:db8::2</td>
<td align="left">SID[0] = 11</td>
</tr>
</tbody>
</table>
<section anchor="LSR" <table align="center">
title="The CRH SID List Omits The First Entry In The Path "> <name>Packet Travels from I2 to D</name>
<t>In this example, Node S sends a packet to Node D, via I2. In this <tbody>
example, I2 does not appear in the CRH segment list.</t> <tr>
<td align="left">Source Address = 2001:db8::a</td>
<texttable> <td align="left">Segments Left = 0</td>
<ttcol>As the packet travels from S to I2:</ttcol> </tr>
<tr>
<ttcol/> <td align="left">Destination Address = 2001:db8::b</td>
<td align="left">SID[0] = 11</td>
<c>Source Address = 2001:db8::a</c> </tr>
</tbody>
<c>Segments Left = 1</c> </table>
<c>Destination Address = 2001:db8::2</c>
<c>SID[0] = 11</c>
</texttable>
<t/>
<texttable>
<ttcol>As the packet travels from I2 to D:</ttcol>
<ttcol/>
<c>Source Address = 2001:db8::a</c>
<c>Segments Left = 0</c>
<c>Destination Address = 2001:db8::b</c> </section>
</section>
<c>SID[0] = 11</c> <section anchor="Acknowledgements" numbered="false" toc="default">
</texttable> <name>Acknowledgements</name>
<t>Thanks to <contact fullname="Dr. Vanessa Ameen"/>, <contact
fullname="Dale Carder"/>, <contact fullname="Brian Carpenter"/>,
<contact fullname="Adrian Farrel"/>, <contact fullname="Fernando
Gont"/>, <contact fullname="Joel Halpern"/>, <contact fullname="Naveen
Kottapalli"/>, <contact fullname="Tony Li"/>, <contact fullname="Xing
Li"/>, <contact fullname="Gerald Schmidt"/>, <contact fullname="Nancy
Shaw"/>, <contact fullname="Mark Smith"/>, <contact fullname="Ketan
Talaulikar"/>, <contact fullname="Reji Thomas"/>, and <contact
fullname="Chandra Venkatraman"/> for their contributions to this
document.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Gang Chen" >
<organization>Baidu</organization>
<address>
<postal>
<street>No.10 Xibeiwang East Road</street>
<city>Beijing</city>
<cityarea>Haidian District</cityarea>
<region></region><code>100193</code>
<country>China</country>
</postal>
<email>phdgang@gmail.com</email>
</address>
</contact>
<contact fullname="Yifeng Zhou" >
<organization>ByteDance</organization>
<address>
<postal>
<street>43 N 3rd Ring W Rd</street>
<extaddr>Building 1, AVIC Plaza</extaddr>
<cityarea>Haidian District</cityarea>
<city>Beijing</city>
<region></region><code>100000</code>
<country>China</country>
</postal>
<email>yifeng.zhou@bytedance.com</email>
</address>
</contact>
<contact fullname="Gyan Mishra" >
<organization>Verizon</organization>
<address>
<postal>
<street></street>
<city>Silver Spring</city>
<region>MD</region><code></code>
<country>United States of America</country>
</postal>
<email>hayabusagsm@gmail.com</email>
</address>
</contact>
<t/>
</section>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 143 change blocks. 
584 lines changed or deleted 607 lines changed or added

This html diff was produced by rfcdiff 1.48.