Compressed Routing Header (CRH) Helper Option

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 6 February 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

IPv6 [RFC8200] source nodes use Routing Headers to steer packets through a specified delivery path. Figure 1 depicts a generic IPv6 Routing Header.¶

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.¶

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.¶

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 - (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.¶

Figure 5 depicts 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

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.¶

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?¶

  • 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

Authors' Addresses