6man                                                               X. LiInternet-Draft                                                    C. BaoIntended status: Experimental          CERNET Center/Tsinghua UniversityExpires: 4 April 2026                                          R. Bonica                                                                     HPE                                                          1 October 2025               Compact Routing Header (CRH) Helper Option                  draft-bonica-6man-crh-helper-opt-06Abstract   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  . . . . . . . . . . . . . . . . . . . . . . .   91.  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 HeaderLi, 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 Processing4.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 packet5.  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 20256.  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   TBD11.  References11.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.netLi, et al.                Expires 4 April 2026                  [Page 9]