Internet Control Message Protocol (ICMPv6) Reflection

The ICMPv6 Reflection utility is an IPv6 diagnostic tool. It is similar to Ping and the ICMPv6 Probe , utility in the following respects: A probing node sends an ICMPv6 message to a probed node. This ICMP message requests specific information. The probed node receives the above-mentioned message, encodes the requested information into another ICMPv6 message, and sends that ICMPv6 message back to the probing node. For the purposes of this document, the ICMPv6 message that the probing node sends is called the "request message" and the ICMPv6 message that the probed node sends is called the "reply message". Using the IPv6 Reflection utility, the following information can be requested: The status of an interface on the probed node. A copy of the request message, including its IPv6 header and extension headers, as it arrived at the probed node. The probing node can also request specific pieces of the request message, as they arrived at the probed node. For example, the probing node can request only the IPv6 header and extension headers that encapsulated the request message. The ICMPv6 Reflection utility uses the ICMPv6 Extended Echo Request and Extended Echo Reply message types . Each of these message types can include an ICMP Extension Structure . The ICMP Extension Structure includes one or more extension objects. This document defines several new extension objects that are used to reflect portions of the request message, as it arrived at the probed node. An alternative approach that could be considered involves the probing node sending a UDP packet with an unused destination port to the probed node, causing the probed node to send an ICMPv6 Destination Unreachable message, which includes "As much of invoking packet as possible without the ICMPv6 packet exceeding the minimum IPv6 MTU" . The benefit of ICMPv6 Reflection is that it enables the probing node to selectively request specific parts of the request message to be included in the reply. Additionally, the payload of ICMP error messages such as Destination Unreachable might be modified by middleboxes (e.g. ), whereas ICMPv6 Reflection is intended to reflect parts of the request message as received by the probed 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 when, and only when, they appear in all capitals, as shown here.

The following protocols define mutable IPv6 extension headers that can be used to trace a path and its performance: IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM) Inband Flow Analyzer Path Tracing in SRv6 networks Segment Routing Header encapsulation for In-situ OAM Data These extensions are used to collect information along a packet's delivery path. Currently, the collected information is sent to a controller for processing. However, in some cases this information is relevant to the sender. The ICMPv6 Reflection utility provides a mechanism by which this information can be returned to the probing node. The ICMPv6 Reflection utility can also be used to determine how the probe message's IPv6 header has changed along its delivery path. For example, it can be used to determine how middleboxes have changed the Source Address, Destination Address, and Flow Label.

The probing node sends an ICMPv6 Extended Echo Request message to the probed node. The ICMPv6 Extended Echo Request message contains an ICMP Extension Structure and the ICMP Extension Structure contains an Extension Header followed by any combination of the extension objects defined in of this document. These objects are called Reflection objects. Each Reflection object requests that the probed node reflect a portion of the request message back to the probing node. Each Reflection object contains an object payload field whose length SHOULD be sufficient to carry the requested information. The total length of the ICMPv6 Extended Echo Request message MUST NOT exceed the IPv6 minimum MTU (1280 bytes.) The probed node receives the ICMPv6 Extended Echo Request and formats an ICMPv6 Extended Echo Reply message. The main body of the ICMPv6 Extended Echo Reply message reflects the status of an interface on the probed node. That interface is identified by the Destination Address in the request message. Alternatively, the interface can be identified by including an Interface Identification Object in the request message, as defined in . The ICMPv6 Extended Echo Reply message also contains an ICMP Extension Structure. The ICMP Extension Structure MUST contain all the Reflection objects that the ICMPv6 Extended Echo Request message contained. These objects MUST be listed in the order that they appeared in the ICMPv6 Extended Echo Request message. If the following requirements are satisfied, the probed node populates the payload field of a Reflection object: The probed node supports the object. Divulging the requested information does not violate the probed node's security policy. The payload field is sufficiently large to accommodate the requested data without truncation. Otherwise, the probed node sets the object payload field to all zeros. An example of a request and a reply is provided in . In this example the request message includes the following Reflection objects: A 'Reflect All' object. This object requests that the entire request message, including all headers, be reflected to the probing node. 'Reflect Arbitrary Data' object. This object requests that the contents of the incoming 'Arbitrary Data' object be reflected to the probing node. The request and reply messages have the same length. This is because they include the same set of objects, and each object has the same length in the request and reply. It should be noted that while some middleboxes might alter the payload of ICMP error messages, such modifications do not apply to ICMP informational messages, such as Extended Echo Request and Reply. This ensures that the reflected information reaches the probing node exactly as sent by the probed node. Therefore, the payload of Extended Echo Reply messages is expected to be unmodified by middleboxes.

Existing implementations of do not support Reflection objects as defined in the current document. If a node that does not support Reflection objects receives an ICMP Extended Echo Request containing Reflection objects, the expected behavior according to is to respond with an ICMP Echo Reply message that includes the "Malformed Query" code in the Code field.

This document defines the following extension object classes. Reflect All Reflect IPv6 Header Reflect HBH Header Reflect Routing Header Reflect Destination Header Reflect Request Reflect Arbitrary Data Collectively, these objects are referred to as Reflection objects. An implementation that supports ICMPv6 Reflection MUST support the Reflect All object and MAY support other Reflection objects. In the IPv6 Reflection utility, an Extended Echo Request includes one or more Reflection objects. If the Reflect All object is present, it MUST be the first object.

Each Reflection object MUST include the following: An object class (as specified in ). C-Type as described below. An object payload field, whose length SHOULD be sufficient to contain the requested information without truncation. The C-Type value is used for indicating whether the probed node was able to process the object. The following C-Type values are supported in each of the Reflection objects: (0) Request (1) Reply - No Error (2) Reply - Unsupported Object (3) Reply - Object Length Exceeded The C-Type field of a Reflection object in a request message MUST be set to the 'Request' value. If the probed node is able to process the Reflection object, it MUST copy the requested information into the object payload and update the C-Type field to the 'Reply - No Error' value. If the probed node is not able to process the object for any of the reasons listed in , it MUST update the C-Type value of the object in the Extended Echo Reply, indicating the reason for not processing it.

The requested information in this object is the IPv6 header, all of its extensions, and the ICMPv6 Extended Echo Request up to and including the ICMP extension header, as they arrived at the probed node. In the ICMPv6 Extended Echo Request message, the object payload field MUST contain all zeros.

The requested information in this object is the IPv6 header, not including the IPv6 extension headers, as it arrived at the probed node. In the ICMPv6 Extended Echo Request message, the object payload field MUST contain all zeros

The requested information in this object is the Hop-by-hop Options extension header, as it arrived at the probed node. In the ICMPv6 Extended Echo Request message, the payload field MUST contain all zeros

The requested information in this object is the Routing header, as it arrived at the probed node. In the ICMPv6 Extended Echo Request message, the payload field MUST contain all zeros

The requested information in this object is the Destination Options header, as it arrived at the probed node. In the ICMPv6 Extended Echo Request message, the payload field MUST contain all zeros

The requested information in this object is the ICMPv6 Extended Echo Request message up to and including the ICMP extension header, as it arrived at the probed node. In the ICMPv6 Extended Echo Request message, the payload field MUST contain all zeros

The requested information in this object is the arbitrary data in the object payload field of the current object, as it arrived at the probed node. Reflection of arbitrary data is slightly similar to the way the data of ICMP Echo messages is reflected back to the probing node. In the ICMPv6 Extended Echo Request message, the object payload field contains arbitrary data.

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

For each of the object classes above the following C-Type values are defined: (0) Request (1) Reply - No Error (2) Reply - Unsupported Object (3) Reply - Object Length Exceeded

Since this document uses technologies from , , and , it inherits security considerations from those documents. The Reflection procedure that is defined in this document is symmetric in terms of the length of the request and reply messages. This symmetry mitigates the potential for amplification attacks, which would be possible if the reply message was longer than the request message. Depending on the network policy and the location of nodes in the network, ICMPv6 informational and/or error messages are sometimes filtered or not supported. For example, some nodes do not reply to ICMPv6 Echo or do not send ICMPv6 Time Exceeded messages (used in Traceroute), due to policy considerations that may be related to DoS mitigation or to privacy. Network operators SHOULD apply similar considerations to ICMPv6 Extended Echo messages when they are used for Reflection. For example, an operator can choose to disable support for ICMPv6 Reflection in networks or in nodes that do not respond to ICMPv6 Echo and/or do not generate ICMPv6 Time Exceeded messages. As specified in , in order to protect local resources, implementations SHOULD rate-limit incoming ICMP Extended Echo Request messages. Moreover, as per , by default, ICMP Extend Echo functionality is disabled.

The authors gratefully acknowledge Sebastian Moeller for his insightful comments.