The IPv6 Compressed Routing
Header (CRH)Juniper Networks2251 Corporate Park DriveHerndon20171VirginiaUSArbonica@juniper.netNTT Communications Corporation3-4-1 Shibaura, Minato-kuTokyo108-8118Japany.kamite@ntt.comKDDI3-22-7, Yoyogi, Shibuya-kuTokyo151-0053Japanto-niwa@kddi.comLiquid TelecomNairobiKenyaAndrew.Alston@liquidtelecom.comLiquid TelecomJohannesburgSouth Africadaniam.henriques@liquidtelecom.comVerizonRichardsonTexasUSAluay.jalil@one.verizon.comReliance Jio3010 Gaylord PKWY, Suite 150FriscoTexas75034USANing.So@ril.comReliance Jio3010 Gaylord PKWY, Suite 150FriscoTexas75034USAFengman.Xu@ril.comBaiduNo.10 Xibeiwang East Road Haidian DistrictBeijing100193P.R. Chinaphdgang@gmail.comChina Telecom109 West Zhongshan Ave, Tianhe DistrictGuangzhouP.R. Chinazhuyq.gd@chinatelecom.cnByteDanceBuilding 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian
DistrictBeijing100000P.R. Chinayifeng.zhou@bytedance.com
INT Area
6manIPv6Routing headerThis document defines two new IPv6 Routing header types. Generically,
they are called the Compressed Routing Header (CRH). More specifically,
the 16-bit version of the CRH is called the CRH-16, while the 32-bit
version of the CRH is called the CRH-32. SRm6 nodes use the CRH to steer
packets from segment to segment along SRm6 paths.This document defines two new IPv6
Routing header types. Generically, they are called the Compressed
Routing Header (CRH). More specifically, the 16-bit version of the CRH
is called the CRH-16, while the 32-bit version of the CRH is called the
CRH-32. SRm6 nodes use
the CRH to steer packets from segment to segment along SRm6 paths.For details regarding SRm6 paths, segments, Segment Identifiers
(SIDs) and instructions, see .The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only
when, they appear in all capitals, as shown here.Both CRH versions (i.e., CRH-16 and CRH-32) contain the following
fields:Next Header - Defined in . Identifies the
type of header immediately following the CRH.Hdr Ext Len - Defined in . Length of the
CRH in 8-octet units, not including the first 8 octets.Routing Type - Defined in . Value TBD by
IANA. (For CRH-16, the suggested value is 5. For CRH-32, the
suggested value is 6.)Segments Left - Defined in . Number of
route segments remaining, i.e., number of explicitly listed
intermediate nodes still to be visited before reaching the final
destination.SID List - Represents the SRm6 path as an ordered list of SIDs.
SIDs are listed in reverse order, with SID[0] representing the final
segment, SID[1] representing the penultimate segment, and so forth.
SIDs are listed in reverse order so that Segments Left can be used
as an index to the SID List. The SID indexed by Segments Left is
called the current SID.In the CRH-16, each SID list entry is
encoded in 16-bits. In the CRH-32, each
SID list entry is encoded in 32-bits. In networks where the smallest feasible Maximum SID Value
(MSV) is greater than 65,535, CRH-32 is required. Otherwise,
CRH-16 is preferred.When choosing between the CRH-16 and CRH-32, network operators should
consider average size of packets on their network. If short (e.g.,
voice) packets constitute a significant portion of network traffic, the
overhead associated with the CRH-32 may be significant. Therefore, the
network operator should consider the CRH-16.In all cases, the CRH MUST end on a 64-bit boundary. Therefore, the
CRH MAY be padded with zeros.A segment ingress node maintains one Segment Forwarding Information
Base (SFIB) entry for each segment that it originates. Each SFIB entry
contains the following information:A SID.A segment type.Topological instruction parameters.The following are valid segment types:Adjacency.Node.Binding.The following parameters are associated with topological
instructions that control adjacency segments:An IPv6 address that identifies an interface on the segment
egress node.An interface identifier.Node segments are associated with a single topological instruction
parameter. This parameter is an IPv6 address that identifies an
interface on the segment egress node.The following parameters are associated with topological instructions
that control binding segments:An IPv6 address that identifies an interface on the first segment
egress node in the binding segment.A SID list length.A SID list. defines rules that apply to IPv6 extension
headers, in general, and IPv6 Routing headers, in particular. All of
these rules apply to the CRH.For example:Extension headers (except for the Hop-by-Hop Options header)
are not processed, inserted, or deleted by any node along a
packet's delivery path, until the packet reaches the node (or each
of the set of nodes, in the case of multicast) identified in the
Destination Address field of the IPv6 header.If, while processing a received packet, a node encounters a
Routing header with an unrecognized Routing Type value, the
required behavior of the node depends on the value of the Segments
Left field. If Segments Left is zero, the node must ignore the
Routing header and proceed to process the next header in the
packet, whose type is identified by the Next Header field in the
Routing header. If Segments Left is non-zero, the node must
discard the packet and send an ICMPv6
Parameter Problem, Code 0, message to the packet's Source
Address, pointing to the unrecognized Routing Type.If, after processing a Routing header of a received packet, an
intermediate node determines that the packet is to be forwarded
onto a link whose link MTU is less than the size of the packet,
the node must discard the packet and send an ICMPv6 Packet Too Big
message to the packet's Source Address.When a node recognizes and processes a CRH, it executes the
following procedure:If the IPv6 Source Address is a link-local address, discard the
packet.If the IPv6 Source Address is a multicast address, discard the
packet.If Segments Left equals 0, skip over the CRH and process the
next header in the packet.If Hdr Ext Len indicates that the CRH is larger than the
implementation can process, discard the packet and send an ICMPv6
Parameter Problem, Code 0, message to the Source Address, pointing
to the Hdr Ext Len field.Compute L, the minimum CRH length (See ).If L is greater than Hdr Ext Len, discard the packet and send
an ICMPv6 Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field.Decrement the packet's Hop Count.If the Hop Count has expired, discard the packet and send an
ICMPv6 Time Expired message to the packet's source node.Decrement Segments LeftSearch for the current SID in the SFIB.If the above-mentioned search does not return an SFIB entry,
discard the packet and send an ICMPv6 Parameter Problem, Code 0,
message to the Source Address, pointing to the current SID.If the above-mentioned search returns an SFIB entry, and that
SFIB entry contains a link-local address, discard the packet and
send an ICMPv6 Parameter Problem, Code 0, message to the Source
Address, pointing to the current SID. (See NOTE.)If the above-mentioned search returns an SFIB entry that
represents an adjacency segment, execute the topological
instruction described in .If the above-mentioned search returns an SFIB entry that
represents a node segment, execute the topological instruction
described in .If the above-mentioned search returns an SFIB entry that
represents a binding segment, execute the topological instruction
described in .The above stated rules are demonstrated in .The algorithm described in this section accepts the following CRH
fields as its input parameters:Routing Type (i.e., CRH-16 or CRH-32).Segments Left.It yields L, the minimum CRH length. The minimum CRH length is
measured in 8-octet units, not including the first 8 octets.A topological instruction that controls an adjacency segment
accepts the following parameters:An IPv6 address that identifies an interface on the segment
egress node.An interface identifier.The instruction behaves as follows:If the interface that was received as a parameter is not
operational, discard the packet and send an ICMPv6 Destination
Unreachable message (Code: 5, Source Route Failed) to the
packet's source node.Overwrite the packet's Destination Address with the IPv6
address that was received as a parameter.Forward the packet through the above-mentioned interface.A topological instruction that controls a node segment accepts a
single parameter. This parameter is an IPv6 address that identifies
an interface on the segment egress node.The instruction behaves as follows:If the segment ingress node does not have a viable route to
the IPv6 address included as a parameter, discard the packet and
send an ICMPv6 Destination Unreachable message (Code:1 Net
Unreachable) to the packet's source node.Overwrite the packet's Destination Address with the
destination address that was included as a parameter.Forward the packet to the next hop along the least cost path
to the segment egress node. If there are multiple least cost
paths to the segment egress node (i.e., Equal Cost Multipath),
execute procedures so that all packets belonging to a flow are
forwarded through the same next hop.A topological instruction that controls an binding segment
accepts the following parameters:An IPv6 address that identifies an interface on the first
segment egress node in the binding segment.A SID list length.A SID list.The instruction behaves as follows:If the segment ingress node does not have a viable route to
the IPv6 address received as a parameter, discard the packet and
send an ICMPv6 Destination Unreachable message (Code:1 Net
Unreachable) to the packet's source node.Prepend a CRH to the packet. Copy the SID list length,
received as a parameter, to the CRH Segments Left field. Also
copy the SID list, received as a parameter, to the CRH SID
list.Prepend an IPv6 header to the packet. Copy the IPv6 address,
received as a parameter, to the IPv6 Destination Address.Forward the packet to the next hop along the least cost path
to the IPv6 address received as a parameter. If there are
multiple least cost paths to the IPv6 address received as a
parameter (i.e., Equal Cost Multipath), execute procedures so
that all packets belonging to a flow are forwarded through the
same next hop.In the CRH, the Segments Left field is mutable. All remaining fields
are immutable.In order to be compliant with this specification, an SRm6
implementation MUST:Be able to process IPv6 options as described in Section 4.2 of
.Be able to process the Routing header as described in Section 4.4
of .Support the CRH-16 and the CRH-32.PING and TRACEROUTE both operate
correctly in the presence of the CRH.SRm6 implementations MUST comply with the ICMPv6 processing rules
specified in Section 2.4 of . For example:An SRm6 implementation MUST NOT originate an ICMPv6 error message
in response to another ICMPv6 error message.An SRm6 implementation MUST rate limit the ICMPv6 messages that
it originates.SRm6 domains MUST NOT span security domains. In order to enforce this
requirement, security domain edge routers MUST do one of the
following:Discard all inbound SRm6 packets whose IPv6 destination address
represents domain infrastructure.Authenticate all inbound SRm6 packets whose IPv6 destination
address represents domain infrastructure.IANA is requested to make the following entries in the Internet
Protocol Version 6 (IPv6) Parameters "Routing Type" registry:Thanks to Naveen Kottapalli, Joel Halpern, Tony Li, Gerald Schmidt,
Nancy Shaw, and Chandra Venkatraman for their comments.This appendix demonstrates CRH processing in the following
scenarios:SR path contains node segments only
.SR path contains node segments only and
preserves the first SID .SR path contains adjacency segments only
. provides a reference topology that is used
in all examples.Instantiating NodeSIDSegment TypeIPv6 AddressAll1Node2001:db8::1All2Node2001:db8::2All3Node2001:db8::3All10Node2001:db8::aAll11Node2001:db8::b describes SFIB entries that are instantiated on
all nodes. All of these SFIB entries represent node segments.Instantiating NodeSIDIPv6 AddressInterfaceS1292001:db8:0:1::2S -> I1S1302001:db8:0:2::2S -> I2I11292001:db8:0:3::2I1 -> I3I21292001:db8:0:4::2I2 -> I3I31292001:db8:0:b::2I3 -> D describes SFIB entries that are instantiated on
specific nodes. All of these SFIB entries represent adjacency
segments.In this example, Node S sends a packet to Node D, though a node
segment that terminates on I3. In this example, I3 does not appear in
the CRH segment list. Therefore, the destination node may not be able
to send return traffic through the same path.As the packet travels from S to I3:Source Address = 2001:db8::aSegments Left = 1Destination Address = 2001:db8::3SID[0] = 11As the packet travels from I3 to D:Source Address = 2001:db8::aSegments Left = 0Destination Address = 2001:db8::bSID[0] = 11In this example, Node S sends a packet to Node D, through a node
segment that terminates on I3. In this example, I3 appears in the CRH
segment list. Therefore, the destination node can send return traffic
through the same path.As the packet travels from S to I3:Source Address = 2001:db8::aSegments Left = 1Destination Address = 2001:db8::3SID[0] = 11SID[1] = 3As the packet travels from I3 to D:Source Address = 2001:db8::aSegments Left = 0Destination Address = 2001:db8::bSID[0] = 11SID[1] = 3In this example, Node S sends a packet to Node D, via two adjacency
segments..As the packet travels from S to I1:Source Address = 2001:db8::aSegments Left = 2Destination Address = 2001:db8:0:1::2SID[0] = 129SID[1] = 129As the packet travels from I1 to I3:Source Address = 2001:db8::aSegments Left = 1Destination Address = 2001:db8:0:3::2SID[0] = 129SID[1] = 129As the packet travels from I3 to D:Source Address = 2001:db8::aSegments Left = 0Destination Address = 2001:db8:0:b::2SID[0] = 129SID[1] = 129