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 Unicast IPv6 address of a probed node. This ICMP message requests that it be reflected back to the probing node. The probed node receives the above-mentioned message, encodes it 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". The reply message includes a copy of the request message, starting from its IPv6 header, as it was when it arrived at the probed node. The ICMPv6 Reflection utility uses the ICMPv6 Extended Echo Request and Extended Echo Reply message types . The destination address of both the request and reply is always a unicast address. Each of these message types includes an ICMP Extension Structure . The ICMP Extension Structure includes one or more extension objects. This document defines the 'Reflect All' object, which is used for reflecting the request message, as it arrived at the probed node. The document acknowledges an alternative approach that involves the probing node sending a UDP packet with an unused destination port to the probed node. This causes 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" . Similarly, sending an ICMPv6 echo request to an address beyond the probed node with a Hop Limit that expires on the probed node would result in an ICMPv6 Time Exceeded message along with the invoking packet. However, these approaches use ICMPv6 error processing which may be subject to implementation and policy controls on the probed nodes as well as nodes along the path that may cause the monitoring to fail. The solution specified in this document is purpose-built for providing operators with visibility into whether and how packets are affected along a network path.

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 ICMPv6 Reflection utility can 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 the value of the Hop Limit, DSCP and ECN fields as received by the probed node. The utility can also be used for determining whether and how on-path nodes have changed the Source Address, Destination Address, Flow Label, and any extension headers if they are present. The ICMPv6 Reflection utility also provides a mechanism by which IPv6 extension headers in the request message are reflected back to the probing node. For example, this information can be useful to the probing node when one of the following mutable IPv6 extension headers is used: IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM) Inband Flow Analyzer Path Tracing in SRv6 networks These extensions are used to collect information along a packet's delivery path, allowing the collected information to be sent to a controller for processing. However, the Reflection utility allows this information to be sent back to the probing node.

The probing node sends an ICMPv6 Extended Echo Request message to a Unicast IPv6 address of the probed node. This request message contains an ICMP Extension Structure . The ICMP Extension Structure includes an Extension Header and a 'Reflect All' object, which is defined in this document. The 'Reflect All' object in the request message contains an object payload field with arbitrary data. This field serves as a placeholder that is used in the reply message for containing the reflected request. The length of the object payload field specifies how many octets, starting from the beginning of the request's IPv6 header, the probed node includes in the reply. The length of the object payload in the request SHOULD be sufficient to cover at least the IPv6 and ICMP headers of the reflected request. The object payload can be longer, allowing inclusion of additional portions of the request message, up to and including the 'Reflect All' object header and the initial octets of the object payload. The length of both the request and reply packets SHOULD NOT exceed the IPv6 minimum MTU defined in , to avoid triggering fragmentation. If the probed node receives the ICMPv6 Extended Echo Request, the probed node formats an ICMPv6 Extended Echo Reply message, provided that this action aligns with its local policies, such as security policies and rate limiting. The length of the ICMPv6 Extended Echo Reply message is equal to the length of the corresponding request message, unless the probed node's policy restricts the reply length or the reply size would exceed the MTU, in which cases the reply might be shorter. The main body of the ICMPv6 Extended Echo Reply message, as in , reflects the status of an interface on the probed node. The ICMPv6 Extended Echo Reply message also contains an ICMP Extension Structure. The ICMP Extension Structure MUST contain the 'Reflect All' object from the request. The length of the 'Reflect All' object in the reply message MUST be less than or equal to the length of the 'Reflect All' object in the request message. By default, the lengths of the 'Reflect All' object in the request and reply are equal. The reply object can be shorter if the probed node's policy restricts the reply length or the reply size would exceed the MTU. In reply messages, the object payload field MUST contain the received request message starting from the beginning of the IPv6 header and according to the length of the object payload, provided that the probed node supports the 'Reflect All' object and that responding does not conflict with its security policy. If a node that does not support the 'Reflect All' object receives an ICMP Extended Echo Request containing this object, the expected behavior according to is to respond with an ICMP Echo Reply message that includes the "Malformed Query" code in the Code field. From an operational perspective, the reflection utility may have various deployment scenarios, depending on where it is deployed and which nodes it intends to probe. For example, an operator may use the reflection utility for probing specific nodes, or might disable or filter reflection in some parts of the network. Regardless of these considerations, the Reflect All extension object is not modified by network elements. This ensures that the reflected information reaches the probing node exactly as sent by the probed node. Two examples of a request and a reply are illustrated in and below. As illustrated in , both the request and reply messages include the 'Reflect All' object. The 'Reflect All' object in the reply contains the request's IPv6 header, followed by the request's ICMPv6 header and ICMP Extension Header. The request and reply messages have the same length. The request's IPv6 header is 40 octets long, followed by an 8-octet ICMPv6 header, a 4-octet ICMP Extension Header, a 4-octet Object Header, and the object payload. These lengths in octets are shown in the figure. The length of the object payload in this example is 52 octets, allowing the reply's object payload to include the reflected request message starting from the IPv6 header and up to and including the ICMP Extension Header. This reflected message includes the IPv6 header as received by the probed node, including, for example, the received value of the Hop Limit, DSCP and ECN fields.

illustrates an example in which the request's IPv6 header is followed by a 16-octet extension header, while the IPv6 header of the reply is followed by a (different) 8-octet extension header. In this example the length of the object payload is 100 octets, both in the request and in the reply. Thus, the object payload in the reply contains 100 octets copied from the request message, as received by the probed node, starting from the IPv6 header, including the request's IPv6 header and extension header, followed by the request's ICMPv6 header, ICMP Extension Header, the 'Reflect All' Object Header, and finally the first 28 octets of the request's object payload. Note that the request message and reply message have the same length, while the IPv6 payload length of the reply packet is shorter by 8 octets since the extension header in the reply packet is shorter.

This document defines the 'Reflect All' object. An implementation that supports ICMPv6 Reflection MUST support the 'Reflect All' object. In the ICMPv6 Reflection utility, the 'Reflect All' object MUST be the only object in the Extension Structure. An ICMPv6 message MUST NOT include more than one 'Reflect All' object. The structure of the 'Reflect All' object follows the specification of ICMP Extension Objects as defined in and MUST include the following fields: The Length of the 'Reflect All' object. An object class (as specified in ). C-Type as described below. An object payload field. The Length field specifies the number of octets in the object. 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: (0) Request (1) Reply - No Error (2) Reply - Unsupported Object 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 'Reflect All' object, it MUST update the C-Type field to the 'Reply - No Error' value. If the probed node is not able to process the object, it MUST update the C-Type value of the object in the Extended Echo Reply to 'Reply - Unsupported Object'. If the 'Reflect All' object is received with an unsupported or an unexpected C-Type value, the message MUST be discarded. For example, if a 'Reflect All' object with a 'Reply - No Error' is received in an ICMP Extended Echo Request message, the message is discarded. The object payload field in the ICMPv6 Extended Echo Request message contains arbitrary data and serves as a placeholder for the corresponding reply message. In reply messages the object payload field contain the received request message starting from the beginning of the IPv6 header and according to the length of the object payload.

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

IANA is requested to create a sub-type registry, "Sub-types - Class TBD1 - Reflect All". The following C-Type values are defined for the Reflect All object class. Unassigned C-Type values will be assigned on a First Come First Served (FCFS) basis.

Since this document uses technologies from , , and , it inherits security considerations from those documents. Specifically, security considerations relevant to ICMPv6 also apply to the current document. For example, ICMPv6 can be misused to create a covert channel between the probing and probed nodes, a technique commonly known as ICMP tunneling. Another relevant risk is an ICMP Echo Spoofing attack, where an attacker sends ICMP Echo Request messages to a target, forging the source IP address to make the packets appear to originate from a victim host, who subsequently receives the unsolicited ICMP Echo Reply packets. Importantly, this document does not introduce any new security risks in this context compared to other existing ICMP message types. It is common practice for network operators to filter (block) or disable support for various ICMPv6 informational and error messages. This practice is contingent upon the network's security policy and the location of the nodes. 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. The Reflection procedure that is defined in this document guarantees that the length of the reply message does not exceed the length of the request, mitigating the potential for amplification attacks, which would be possible if the reply was longer than the request. Furthermore, as defined in , the destination address of the Extended Echo Request is always a unicast address, thus mitigating the potential for various DDoS attacks. As in other monitoring and measurement mechanisms , a successful attack on the Reflection utility can create a false illusion of nonexistent issues or prevent the detection of actual ones. For instance, a probed node can intentionally misrepresents what it received when sending the Reflect All object. A similar effect can be performed by modification of the Reflect All object along the path between the probed node and the probing node. Rate-limiting mechanisms SHOULD be employed to limit the bandwidth and forwarding costs incurred by processing ICMP Extended Echo Request messages and/or originating ICMP Extended Echo Reply messages. Guidance on ICMP rate-limiting is provided in . Moreover, as per , by default, ICMP Extended Echo functionality is disabled.

The authors gratefully acknowledge Sebastian Moeller, Zafar Ali, Bob Hinden, Jen Linkova, Jeremy Duncan, Greg Mirsky, Nick Buraglio, Maciej Zenczykowski, Robert Sparks, Thomas Fossati, Kyle Rose, Suresh Krishnan, Niclas Comstedt, Mohamed Boucadair, Ketan Talaulikar, Deb Cooley, Eric Vyncke, Gorry Fairhurst, Mike Bishop and Roman Danyliw for their insightful comments.