Compact Routing Header (CRH) Helper Option
draft-bonica-6man-crh-helper-opt-06
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Xing Li , Congxiao Bao , Ron Bonica | ||
| Last updated | 2025-10-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bonica-6man-crh-helper-opt-06
6man X. Li
Internet-Draft C. Bao
Intended status: Experimental CERNET Center/Tsinghua University
Expires: 4 April 2026 R. Bonica
HPE
1 October 2025
Compact Routing Header (CRH) Helper Option
draft-bonica-6man-crh-helper-opt-06
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 April 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires 4 April 2026 [Page 1]
Internet-Draft CRH Helper Option October 2025
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. The CRH Helper . . . . . . . . . . . . . . . . . . . . . . . 4
4. CRH Processing . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. In The Absence Of The CRH Helper Option . . . . . . . . . 5
4.2. In The Presence Of the CRH Helper Option . . . . . . . . 5
5. Relationship To RHO . . . . . . . . . . . . . . . . . . . . . 6
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Experimental Results . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
IPv6 [RFC8200] source nodes use Routing Headers to steer packets
through a specified delivery path. Figure 1 depicts a generic IPv6
Routing Header.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Generic IPv6 Routing Header
Li, et al. Expires 4 April 2026 [Page 2]
Internet-Draft CRH Helper Option October 2025
In Figure 1, 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 [V6RTG]. [RFC9631]
defines two of these. Collectively, they are called the Compact
Routing Headers (CRH). Individually, they are called the CRH-16 and
CRH-32. Figure 2 depicts the CRH-16 while Figure 3 depicts the CRH-
32.
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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| .........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: 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] +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: The CRH-32 Routing Type
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.
Li, et al. Expires 4 April 2026 [Page 3]
Internet-Draft CRH Helper Option October 2025
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.
2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. 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.
Figure 4 depicts the CRH Helper option.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Helpers
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Figure 4: The CRH Helper Option
* 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 Figure 5. 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 [RFC4443] Parameter Problem message, Code 0, to the source,
pointing to the first incorrectly sorted Helper field.
Li, et al. Expires 4 April 2026 [Page 4]
Internet-Draft CRH Helper Option October 2025
Figure 5 depicts a single helper field.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Helper Len | High SID | Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Figure 5: A Single Helper Field
* 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.
4. CRH Processing
4.1. In The Absence Of The CRH Helper Option
In the absence of the CRH helper option, CRH processing is as
described in [RFC9631].
4.2. 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
[RFC9631].
* 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.
Li, et al. Expires 4 April 2026 [Page 5]
Internet-Draft CRH Helper Option October 2025
* 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
5. Relationship To RHO
When used with the CRH Helper, the CRH is functionally identical to
the deprecated Type 0 Routing Header (RH0) [RFC5095]. 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 Section 8 for details.
Li, et al. Expires 4 April 2026 [Page 6]
Internet-Draft CRH Helper Option October 2025
6. 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.
7. IANA Considerations
This document does not make any IANA requests.
8. Security Considerations
[RFC9631] inherits security considerations from [RFC5095] and this
document inherits security considerations from [RFC9631]. [RFC9631]
addresses the security considerations inheritted from [RFC5095] 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
[RFC9631].
9. 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?
Li, et al. Expires 4 April 2026 [Page 7]
Internet-Draft CRH Helper Option October 2025
- 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?
10. Acknowledgements
TBD
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/rfc/rfc4443>.
Li, et al. Expires 4 April 2026 [Page 8]
Internet-Draft CRH Helper Option October 2025
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/rfc/rfc8200>.
[RFC9631] Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L.
Jalil, "The IPv6 Compact Routing Header (CRH)", RFC 9631,
DOI 10.17487/RFC9631, August 2024,
<https://www.rfc-editor.org/rfc/rfc9631>.
11.2. Informative References
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/rfc/rfc5095>.
[V6RTG] Internet Assigned Numbers Authority (IANA), "Routing
Types", Web <https://www.iana.org/assignments/ipv6-
parameters/ipv6-parameters.xhtml#ipv6-parameters-3>.
Authors' Addresses
Xing Li
CERNET Center/Tsinghua University
Beijing
China
Email: xing@cernet.edu.cn
Congxiao Bao
CERNET Center/Tsinghua University
Beijing
China
Email: congxiao@cernet.edu.cn
Ron Bonica
HPE
Herndon, Virginia
United States of America
Email: rbonica@juniper.net
Li, et al. Expires 4 April 2026 [Page 9]