Internet-Draft | CRH Helper Option | October 2021 |
Li, et al. | Expires 14 April 2022 | [Page] |
This document defines the IPv6 Compressed Routing Header (CRH) Helper option. When a source node sends a packet with a CRH, it can use the CRH Helper option to provide additional information to downstream nodes.¶
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 14 April 2022.¶
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
IPv6 [RFC8200] source nodes use the Compressed Routing Header (CRH) [I-D.bonica-6man-comp-rtg-hdr] to steer packets along a delivery path to their destination. Two CRH versions have been defined. The CRH-16 encodes segment endpoints in 16 bits, while CRH-32, encodes segment endpoints in 32 bits.¶
Both CRH versions contain the following fields:¶
As per [RFC8200], when an IPv6 node receives a packet, it examines the packet's destination address. If the destination address represents an interface belonging to the node, the node processes the next header. If the next header is a CRH, it is processed as follows:¶
In a typical CRH deployment, every segment ingress node maintains a complete CRH-FIB and the above-mentioned query returns a CRH-FIB entry. However, in some CRH deployments, some segment ingress nodes maintain a complete CRH-FIB while others do not. For example, a node that does not participate in a control plane or communicate with a controller may not maintain a CRH-FIB.¶
This document defines the IPv6 CRH Helper option. When a source node sends a packet with a CRH, it can use the IPv6 CRH Helper option to provide CRH-FIB information to downstream nodes that do not maintain a complete CRH-FIB.¶
If a segment ingress node queries its CRH-FIB, searching for an entry that is indexed by the current SID, and that query returns nothing, the segment ingress node can obtain the required CRH-FIB information from the IPv6 CRH Helper option. If the segment ingress node cannot obtain the required CRH-FIB information from either source, it discards the packet and sends an ICMPv6 [RFC4443] Parameter Problem message to the source node.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The CRH Helper option contains the following fields:¶
Each Helper contains the following fields:¶
NOTE : The highest-order two bits of the Option Type (i.e., the "act" bits) are 00. These bits specify the action taken by a destination node that does not recognize the option. The required action is to skip over this option and continue processing the header.¶
The third highest-order bit of the Option Type (i.e., the "chg" bit) is 0. This indicates that Option Data cannot be modified along the path between the packet's source and its destination.¶
When a segment endpoint node processes a CRH, it attempts to resolve the SID using information contained by its CRH-FIB. If it cannot resolve the SID using CRH-FIB, it attempts to resolve the SID using information received in an applicable Helper. If no Helper applies to the current SID, the processing node discards the packet and sends an ICMPv6 Parameter Problem message to the source node.¶
When the processing node uses a Helper to resolve a SID, it executes the following procedure:¶
If the prefix found in the applicable Helper is 16 bytes long, it overwrites the entire IPv6 Destination Address.¶
The CRH Helper option MAY occur in a Destination Options header that precedes a CRH. It SHOULD NOT occur in a Hop-by-hop options header or in a Destination Options header that precedes an upper-layer header.¶
When a segment ingress node resolves a SID using information obtained from the CRH helper option, it forwards the packet through the least-cost path to its new destination.¶
Information obtained from the CRH Helper option is transient. It is discarded as soon as the packet that carried it has been processed.¶
When a segment endpoint node processes a CRH, it attempts to resolve the SID using information contained by its CRH-FIB. If it can resolve the SID using CRH-FIB, it MUST ignore the CRH Helper option, even if it contains an applicable Helper.¶
IANA is requested to allocate a code point from the Destination Options and Hop-by-hop Options registry (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2). This option is called "CRH Helper Option". The "act" bits are 00 and the "chg" bit is 0. (Suggested value: 0x11).¶
Thanks to TBD for their careful review of this document.¶