ICMPv6 Extensions for Reflecting IPv6 Extension Header

As specified in [RFC4443], the Internet Control Message Protocol for IPv6 (ICMPv6) is an integral part of IPv6, and the base protocol MUST be fully implemented by every IPv6 node. ICMPv6 messages include error messages and informational messages, and the latter are referred to as ICMPv6 Echo Request/Reply messages. ICMPv6 Echo request/reply message is very commonly used for diagnostic purposes, such as PING [RFC2151], to test bidirectional connectivity between two nodes: the source node sends an Echo Request to the destination node, and the destination node responds with an Echo Reply to the source node. The data (payload) received in the ICMPv6 Echo Request message MUST be returned entirely and unmodified in the ICMPv6 Echo Reply message. [RFC4884] defines ICMPv6 Extension Structure by which multi-part ICMPv6 error messages are supported. [RFC8335] defines ICMPv6 Extended Echo Request/Reply messages, containing an ICMPv6 Extension Structure customized for this message. Both [RFC4884] and [RFC8335] provide sound principles and examples on how to extend ICMPv6 messages. IPv6 encapsulation for In-situ OAM (IOAM) data is defined in RFC9486], which uses the IPv6 Hop-by-Hop and Destination options header to carry IOAM data fields ([RFC9197], [RFC9326]). [I-D. shi-ippm-congestion-measurement-data] also adopts Hop-by-hop Option Header and Destination option header to collect the congestion information data along the path. [draft-filsfils-ippm-path-tracing] provides a record of the packet path as a sequence of interface ids by adopting Hop-by-hop Option Header and Destination option header. These two extension option headers are used for collecting information along the path a packet traverses. It is expected that there are more requirements that need to use IPv6 options header for carrying path information in the future. The collected information is then exported to a central collector or controller for further process. However, clearly in some cases, the sender is more concerned about these trace information. Currently there are some RFCs and ongoing drafts in IETF that describe methods for sending this tracking information back to the sender. [RFC9322] defines two new flags in the IOAM Trace Option headers: the Loopback and Active flags. The Loopback flag is used to request that each transit device along the path loops back a truncated copy of the data packet to the sender. The Active flag indicates that a packet is used for active measurement. [I-D. ippm-stamp-ext-hdr-00] extends Simple Two-Way Active Measurement Protocol (STAMP) to carry and reflect any type of IPv6 option that carries IOAM data fields. This document defines a generic ICMPv6 extensions for carrying and reflecting IPv6 extension headers, using two extended ICMPv6 message types: Echo Request and Echo Reply. Also, an example of leveraging the ICMPv6 extensions for carrying and reflecting IPv6 option header, which contains the IOAM Trace Option, is presented.

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 when, and only when, they appear in all capitals, as shown here.

Abbreviations used in this document: ICMPv6: Internet Control Message Protocol for IPv6 IOAM: In situ Operation, Administration, and Maintenance ECMP: Equal-Cost Multipath

This document defines two extended ICMPv6 types: the extended Echo Request and the extended Echo Reply.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP Extension Structure | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ICMPv6 Fields: Type: TDB, defined in this document. Code: MUST be set to 0. Identifier: As defined in [RFC4443], the identifier to aid in matching Echo Replies to this Echo Request. May be zero. Sequence Number: As defined in [RFC4443], the sequence number to aid in matching Echo Replies to this Echo Request. May be zero. ICMP Extension Structure: As defined in [RFC4884], it contains exactly one Extension Header followed by one or more extension objects. Description Every node MUST implement an ICMPv6 Echo responder function that receives ICMPv6 Echo Requests and originates corresponding Echo Replies. A node SHOULD also implement an application-layer interface for originating ICMPv6 Echo Requests and receiving ICMPv6 Echo Replies, for diagnostic purposes. Upper Layer Notification Echo Request messages MAY be passed to processes receiving ICMP messages.

Each extension object contains one 32-bit word, representing an object header without any payload. All object headers share a common format. Figure 2 depicts the object header.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AS defined in [RFC4884], an object header has the following fields: Length: 16 bits, length of the object, measured in octets, including the object header. Class-Num: 8 bits, identifies object class. C-Type: 8 bits, identifies object sub-type. This document defines the values of Class-Num and C-Type as follows: Class-Num: IPv6 extension header Object. The values are listed as the following: Value Object Name ----- ----------- TBD1 the Hop-by-Hop Options header TBD2 the Destination Options header TBD3 the Routing header C-Type: Values are listed as the following: Class-Num C-Type C-Type Name --------- ------ ----------- TBD1 0 Reserved TBD2 0 Reserved TBD3 0 Reserved

In some use cases where only one object is used, which instructs the destination node (Echo responder) to copy the corresponding IPv6 extension header into the Object payload in the extended Echo Reply packet,, the Echo Request is depicted as follows:

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP Extension Structure | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ICMPv6 Fields: Type: TDB, defined in this document. Code: MUST be set to 0. Identifier: As defined in [RFC4443], the identifier from the invoking Echo Request message. Sequence Number: As defined in [RFC4443], the sequence number from the invoking Echo Request message. ICMP Extension Structure: As defined in [RFC4884], it contains exactly one Extension Header followed by one or more extension objects. Description Every node MUST implement an ICMPv6 Echo responder function that receives ICMPv6 Echo Requests and originates corresponding Echo Replies. A node SHOULD also implement an application-layer interface for originating ICMPv6 Echo Requests and receiving ICMPv6 Echo Replies, for diagnostic purposes. Upper Layer Notification Echo Reply messages MUST be passed to the process that originated an Echo Request message.

Each extension object contains one or more 32-bit words, including an object header and payload. All object headers share a common format. Figure 6 depicts the object header and payload.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | // (Object payload) // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AS defined in [RFC4884], an object header has the following fields: Length: 16 bits, length of the object, measured in octets, including the object header. Class-Num: 8 bits, and its values are defined in Section 3.1.1. C-Type: 8 bits, and its values are defined in Section 3.1.1. Object payload: n*32 bits, MUST contain the integral IPv6 extension header, including Next Header field, Hdr Ext Len field and Options field, defined in RFC8200. Echo Reply packet MUST copy the entire IPv6 extension header into the Object payload.

In some use cases where only one object is used, the Echo Reply, with an Object payload containing the corresponding IPv6 extension header, is depicted as follows:

When the source node adds an IPv6 extension header to be reflected, it also MUST add one object contained in ICMP extension structure in the extended ICMPv6 Echo Request packet, which instructs the destination node to copy the corresponding IPv6 extension header into the Object payload in the extended Echo Reply packet. When adding multiple IPv6 extension headers, one or multiple objects MUST be added, each one with matching IPv6 extension header object class. When the extended Echo Request packet carries an IPv6 extension header that it does not require Echo responder to reflect in the Echo Reply packet, it SHOULD not add the matching object class in ICMP extension structure in the extended Echo Request packet. When the Echo responder receives the extended Echo Request packet with IPv6 extension header and ICMP extension structure, the responder that supports this extended Echo, MUST copy the entire IPv6 extension header into the Object payload in the extended Echo Reply packet. When the Echo responder receives the extended Echo Request packet with IPv6 extension header but it does not carry any object in ICMP extension structure, the responder SHOULD not copy the entire IPv6 extension header into the Object payload. When the Echo responder receives the extended Echo Request packet with IPv6 extension header and ICMP extension structure carrying any unrecognized object class, the responder SHOULD skip this object and only copy the entire IPv6 extension header with recognized object class into the Object payload.

In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network. The IOAM data fields are defined in [RFC9197]. This document presents an example of leveraging the ICMPv6 extensions for carrying and reflecting IPv6 options header, which contains the IOAM Trace Option. IPv6 encapsulation for IOAM data is defined in RFC9486], which uses the IPv6 Hop-by-Hop option header to collect information along the path a packet traverses. Clearly in some cases, the sender is more concerned about these trace information. Some possible needs are listed as follows: Which nodes and links does the specified traffic flow traverse? In an Equal-Cost Multipath (ECMP) scenario, which ECMP path does a specified N-tuple of flow pass through? Is the specified traffic flow forwarding path consistent on both forward and reverse path? An integral extended Echo Request packet includes IPv6 header, Hop-by-Hop option header, ICMPv6 header and ICMP extension structure that contains one object, instructing the Echo responder to reflect IOAM trace information. This extended Echo Request packet is depicted as follows:

+----------------------------+ | IPv6 Header | +----------------------------+ | Hop-by-Hop Option Header | +----------------------------+ | ICMPv6 Header | +----------------------------+--+ | ICMP Extension Header | | +----------------------------+ ICMP Extension Structure | Object Header | | +----------------------------+--+ Similarly, an integral extended Echo Reply packet also includes IPv6 header, Hop-by-Hop option header, ICMPv6 header and ICMP extension structure that contains one object with object payload field filled with Hop-by-Hop option header. This extended Echo Reply packet is depicted as follows:

+----------------------------------+ | IPv6 Header | +----------------------------------+ | Hop-by-Hop Options Header | +----------------------------------+ | ICMPv6 Header | +----------------------------------+--+ | ICMP Extension Header | | +----------------------------------+ | | Object Header |ICMP Extension Structure +----------------------------------+ | | Object payload | | | (IPv6 Hop-by-Hop Options Header) | | +----------------------------------+--+

An IOAM network can be depicted as follows.

+--------+ +-----------+ +-----------+ +-----------+ +--------+ | Host |=====| IOAM node |=====| IOAM node |=====| IOAM node |=====| Host | +--------+ +-----------+ +-----------+ +-----------+ +--------+ Encapsulating Transit Decapsulating Node Node Node |------------------ IOAM-Domain ---------------| The sender (source) of the Echo request messages can be a host or network device. When a host or a network device sends an Echo request message, if it acts as an IOAM encapsulating node, it MUST perform the operation of IOAM Data-Fields encapsulation, i.e., it MUST place the IOAM Data-Fields directly in the IPv6 Hop-by-Hop Option Header. To accurately retrieve the trace information the Echo request packet traverses, including all nodes and links it passes through, the IOAM encapsulating node MUST set both the Most significant bit (Bit 0) and Bit 1 of the IOAM Trace-Type value to "1". Therefore, when processing this trace option, every transit node (including encapsulating node) in IOAM-Domain MUST populates its IOAM data with two data fields, namely, the Hop_Lim and node_id data field and ingress_if_id and egress_if_id data field. The rest of the bits of IOAM-Trace-Type MAY be set "1" or "0" depending on implementation. Similarly, the responder (destination) of the Echo request messages can also be a host or network device. When a host or a network device receives an Echo request message, if it acts as an IOAM node, no matter what node (encapsulating node, transit node or decapsulating node) it is, it MUST originate an Echo reply message, copying the entire IPv6 Hop-by-Hop Option Header with IOAM Data into the Object payload of ICMP Extension Structure. In reverse path, to accurately retrieve the trace information the Echo reply packet traverses, similarly, when processing this trace option, every transit node in IOAM-Domain MUST populates IOAM Data with two data fields, namely, the Hop_Lim and node_id data field and ingress_if_id and egress_if_id data field. The sender can determine the consistence of the forward and reverse path by comparing the Object payload of ICMP Extension Structure with the IPv6 Hop-by-Hop Options Header carrying IOAM data in the received Echo reply packet. Notably, to simulate the real path the specified traffic flow traverses, especially in ECMP scenario, the same value or values in any ECMP affecting fields (e.g., the 3-tuple of the Flow Label, Source Address, and Destination Address fields [RFC6437]) MUST be populated in Echo request packets, ensuring the fate sharing between the Echo request/reply packets and the specified traffic flow packets.

Section 4.6 of [RFC4884] provides a list of extensible ICMP messages (i.e., messages that can carry the ICMP Extension Structure). This document adds the ICMPv6 Extended Echo Request message and the ICMPv6 Extended Echo Reply message to that list.

IANA is requested to allocate the following values in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry. Two values are to be allocated from the "ICMPv6 type Numbers" range:

IANA is requested to allocate the following values in the "ICMP Extension Object Classes and Class Sub-types" registry.

+--------------+----------------------------+----------+---------------+-----------------+ | Class-Num | Object Name | C-Type | C-Type Name | Reference | +--------------+------------------+---------+---------------+----------------------------+ | TBD1 | Hop-by-Hop Options Header | 0 | Reserved | [This document] | +--------------+----------------------------+----------+---------------+-----------------+ | TBD2 | Destination Options Header | 0 | Reserved | [This document] | +--------------+----------------------------+----------+---------------+-----------------+ | TBD3 | Routing Header | 0 | Reserved | [This document] | +--------------+----------------------------+----------+---------------+-----------------+

From a security perspective this document does not introduce new security threats beyond the threats that are already applicable for existing ICMPv6 messages, and are described in [RFC4443]. The extended ICMPv6 Echo Reply message can be longer than the extended Echo Request message, since the Extension Structure of the extended Echo Reply includes one or more objects containing the respective IPv6 options header. Thus, an Echo Reply message is slightly amplified compared to an Echo Request message. However, the amplification effect is minor, as an IPv6 options can have a maximum length of 255 octets.