]> Compressed Routing Header (CRH) Helper Option CERNET Center/Tsinghua University
Beijing China xing@cernet.edu.cn
CERNET Center/Tsinghua University
Beijing China congxiao@cernet.edu.cn
HPE
Herndon Virginia USA rbonica@juniper.net
Internet 6man IPv6, CRH This document introduces a new IPv6 Destination Option called the CRH Helper. The CRH Helper is used with the Compact Routing Header (CRH) [RFC 9631]. It contains information required to convert a CRH SID to the IPv6 address of a interface on a packet's delivery path. Because the CRH Helper contains this information, it eliminates the need for a CRH-FIB. It also eliminates the need for CRH-FIB support in the control plane. The CRH helper is useful in underlay networks, where all interfaces are numbered from a few /112 or /96 prefixes.
Introduction IPv6 source nodes use Routing Headers to steer packets through a specified delivery path. depicts a generic IPv6 Routing Header.
Generic IPv6 Routing Header Next Header Hdr Ext Len Routing Type Segments Left . . . type-specific data .
In , type-specific data represents a list of interfaces. Depending upon the Routing Type, a packet traverses these interfaces in forward or reverse order. If the packet traverses the interfaces in forward order, the last interface in the list is the packet's ultimate destination. If the packet traverses the interfaces in reverse order, the first packet in the list is the packet's ultimate destination. The packet may also traverse other interfaces that are not in the list. The IETF has defined several Routing Types . defines two of these. Collectively, they are called the Compact Routing Headers (CRH). Individually, they are called the CRH-16 and CRH-32. depicts the CRH-16 while depicts the CRH-32.
The CRH-16 Routing Type 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 Next Header Hdr Ext Len Routing Type Segments Left SID[0] SID[1] . . . . .
The CRH-32 Routing Type 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 Next Header Hdr Ext Len Routing Type Segments Left SID[0] SID[1] . . . . .
In the CRH-16 and in the CRH-32, each CRH SID identifies an entry in the CRH Forwarding Information Base (CRH-FIB). Each CRH-FIB entry identifies an interface on the packet's delivery path. This document introduces a new IPv6 Destination Option called the CRH Helper. The CRH Helper contains the information required to convert a CRH SID to the IPv6 address of a interface on a packet's delivery path. Therefore, the CRH Helper eliminates the need for a CRH-FIB. It also eliminates the need for CRH-FIB support in the control plane. The CRH helper is useful in underlay networks, where all interfaces are numbered from a few /112 or /96 prefixes.
Conventions and Definitions 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 BCP14 when, and only when, they appear in all capitals, as shown here.
The CRH Helper The CRH Helper is IPv6 Destination Option. It MAY occur in packets that contain a CRH. It SHOULD NOT occur in packets that do not contain a CRH. If it occurs in a packet that does not include a CRH, it MUST be ignored by the receiver. The CRH Helper MAY occur in a Destination Option Header that precedes a Routing Header. If it occurs in any other IPv6 extension header, it MUST be ignored by the receiver. depicts the CRH Helper option.
The CRH Helper Option - - - - - - - - Option Type Opt Data Len Helpers - - - - - - - -
  • Option Type - (8 bits) RFC3692-style Experiment. Value Ox9E. See NOTE below.
  • Opt Data Len - (8 bits) Length of the option, in octets, excluding the Option Type and Option Length fields.
  • Helpers - (variable length). One or more single helper fields, as depicted in . Helper fields MUST be sorted in by their High SID value, in ascending order. See below. If they are not sorted correctly, the receiver MUST discard the packet and send an ICMPv6 Parameter Problem message, Code 0, to the source, pointing to the first incorrectly sorted Helper field.
depicts a single helper field.
A Single Helper Field - - - - - - - - Helper Len High SID Prefix - - - - - - - -
  • Helper Len - (8 bits) Length of the Helper, in octets, excluding the Helper Length field. MUST be greater than 2 and less than 16.
  • High SID - (8 bits) The index of the highest CRH SID to which this helper applies.
  • Prefix - (Variable length) The high-order bits of an IPv6 address.
NOTE: For this experiment, the Option Type is set to '10011110', i.e., 0x9E. The highest-order two bits are set to 10 indicating that the required action by a destination node that does not recognize the option is to discard the packet and send an ICMP message. The third highest-order bit is set to 0 indicating that Option Data cannot be modified along the path between the packet's source and its destination. The remaining low-order bits are set to '11110' to indicate the single IPv6 Destination Option Type code point available in the registry for experimentation.
CRH Processing
In The Absence Of The CRH Helper Option In the absence of the CRH helper option, CRH processing is as described in .
In The Presence Of the CRH Helper Option In the presence of the CRH helper option is as follows:
  • 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 as described in section 5.1 of .
  • If L is greater than Hdr Ext Len, discard the packet and send an ICMPv6 Parameter Problem, Code 6, message to the Source Address, pointing to the Segments Left field.
  • Decrement Segments Left.
  • Search the CRH Helper Option for a CRH Helper that applies to the current CRH SID" In this document, the "current CRH SID" is the CRH SID list entry referenced by the Segments Left field.
  • If the search does not return a CRH Helper, discard the packet and send an ICMPv6 Parameter Problem, Code 0, message to the Source Address, pointing to the current SID.
  • Set the Destination Address field in the IPv6 header to ::0.
  • Overwrite the high-order bits of the Destination Address field in the IPv6 header with the prefix from the CRH Helper.
  • Overwrite the low-order bits of the Destination Address field in the IPv6 header with the current CRH.
  • If Segments Left is greater than 0 and the Destination Address is a multicast address, discard the packet and send an ICMPv6 Parameter Problem, Code 0, message to the Source Address, pointing to the current SID. (This prevents packet storms.)
  • Forward the packet
Relationship To RHO When used with the CRH Helper, the CRH is functionally identical to the deprecated Type 0 Routing Header (RH0) . It differs only in that its encoding is more compact when used in common underlay numbering schemes. For example, assume the following:
  • An underlay network numbers all of its interfaces from a /112.
  • An IPv6 delivery path traverses 5 of those interfaces.
RH0 required 88 bytes to encode that delivery path. The same delivery path can be encoded with a 16 byte CRH-16 and a 20 byte CRH Helper (total: 36 bytes). When used with the CRH Helper option, the CRH inherits security considerations from RH0. See for details.
Deployment Considerations Some networks discard packets that include IPv6 Destination Options. This is an impediment to deployment. Because the CRH Helper Option uses an experimental code point, there is a risk of collisions with other experiments. Specifically, the egress PE may process packets from another experiment that uses the same code point. It is expected that, as with all experiments with IETF protocols, care is taken by the operator to ensure that all nodes participating in an experiment are carefully configured. Because the CRH Helper Destination Option uses an experimental code point, processing of this option MUST be disabled by default. Explicit configuration is required to enable processing of the option.
IANA Considerations This document does not make any IANA requests.
Security Considerations inherits security considerations from and this document inherits security considerations from . addresses the security considerations inheritted from by restricting CRH deployment to a community of trusted nodes. It also describes several methods by which trust can be verified. Because the CRH Helper is processed only in the presence of the CRH, it introduces no security considerations beyond those described in .
Experimental Results Parties participating in this experiment should publish experimental results within one year of the publication of this document. Experimental results should address the following:
  • Effort required to deploy
    • Was deployment incremental or network-wide?
    • Was there a need to synchronize configurations at each node or could nodes be configured independently?
    • Did the deployment require hardware upgrade?
  • Effort required to secure
    • Performance impact
    • Effectiveness of risk mitigation with ACLs
    • Cost of risk mitigation with ACLs
  • Mechanism used to populate the FIB
  • Scale of deployment
  • Interoperability
    • Did you deploy two interoperable implementations?
    • Did you experience interoperability problems?
  • Effectiveness and sufficiency of OAM mechanisms
    • Did PING work?
    • Did TRACEROUTE work?
    • Did Wireshark work?
    • Did TCPDUMP work?
Acknowledgements TBD
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Internet Protocol, Version 6 (IPv6) Specification This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. The IPv6 Compact Routing Header (CRH) This document describes an experiment in which two new IPv6 Routing headers are implemented and deployed. Collectively, they are called the Compact Routing Header (CRH). Individually, they are called CRH-16 and CRH-32. One purpose of this experiment is to demonstrate that the CRH can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations described in this document can be addressed with Access Control Lists (ACLs). Finally, this document encourages replication of the experiment. Informative References Deprecation of Type 0 Routing Headers in IPv6 The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6 Type 0 Routing Headers, in light of this security concern. [STANDARDS-TRACK] Routing Types Internet Assigned Numbers Authority (IANA)