| Internet-Draft | ICMPv6 Reflection | July 2025 |
| Mizrahi, et al. | Expires 30 January 2026 | [Page] |
This document describes the ICMPv6 Reflection utility. The ICMPv6 Reflection utility is a diagnostic tool, similar to Ping and the ICMPv6 Probe utility. It is similar to Ping and Probe in that it relies on a stateless message exchange between a probing node and a probed node. The probing node sends a request to the probed node and the probed node responds to the request.¶
The ICMPv6 Reflection utility differs from Ping and Probe because, in the ICMPv6 Reflection utility, the probing node requests a snapshot of the message that it sent, as it was when arrived at the probed node. The probed node returns the requested snapshot.¶
The ICMPv6 Reflection utility is useful because it allows the user to see how the network modified the request as it traveled from the probing node to the probed node.¶
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 30 January 2026.¶
Copyright (c) 2025 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 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.¶
The ICMPv6 Reflection utility is an IPv6 [RFC8200] diagnostic tool. It is similar to Ping [RFC2151] and the ICMPv6 Probe [I-D.ietf-intarea-rfc8335bis] utility in the following respects:¶
A probing node sends an ICMPv6 [RFC4443] message to 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 was when it arrived at the probed node.¶
The ICMPv6 Reflection utility uses the ICMPv6 Extended Echo Request and Extended Echo Reply message types [I-D.ietf-intarea-rfc8335bis]. Each of these message types includes an ICMP Extension Structure [RFC4884]. 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.¶
An alternative approach 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" [RFC4443]. However, middle boxes modify the invoking packet in ICMPv6 Destination Unreachable messages (e.g. [RFC3022]). By contrast, middle boxes do not modify the Reflect All object.¶
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 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) [RFC9486]¶
Inband Flow Analyzer [I-D.kumar-ippm-ifa]¶
Path Tracing in SRv6 networks [I-D.filsfils-ippm-path-tracing]¶
Segment Routing Header encapsulation for In-situ OAM Data [I-D.ali-spring-ioam-srv6]¶
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 [I-D.ietf-intarea-rfc8335bis] to the probed node. The ICMPv6 Extended Echo Request message contains an ICMP Extension Structure [RFC4884] and the ICMP Extension Structure contains an Extension Header. The ICMP Extension Header MUST include the Length field, as defined in [I-D.ietf-intarea-icmp-exten-hdr-len]. The ICMP Extension structure includes a 'Reflect All' object, which is defined in this document.¶
The 'Reflect All' object contains an object payload field whose length SHOULD be sufficient to carry the IPv6 and ICMP header of the reflected request message. 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.¶
The ICMPv6 Extended Echo Reply message also contains an ICMP Extension Structure. The ICMP Extension Header MUST include the Length field, as defined in [I-D.ietf-intarea-icmp-exten-hdr-len]. The ICMP Extension Structure also MUST contain the 'Reflect All' object that the ICMPv6 Extended Echo Request message contained. If the following requirements are satisfied, the probed node populates the payload field of the 'Reflect All' object:¶
The probed node supports the 'Reflect All' object.¶
Divulging the requested information does not violate the probed node's security policy.¶
Otherwise, the probed node sets the object payload field to all zeros.¶
An example of a request and a reply is provided in Figure 1. In this example the request message includes the 'Reflect All' object. The reply also includes the 'Reflect All' object, containing the IPv6 header, ICMPv6 header and ICMP Extension Header of the request message. The request and reply messages have the same length.¶
Middle boxes MUST NOT modify the Reflect All extension object.¶
+----------------------------+ +----------------------------+
| IPv6 Header | | IPv6 Header |
| and extension headers | | and extension headers |
+----------------------------+ +----------------------------+
| ICMPv6 Header | | ICMPv6 Header |
| Extended Echo Request | | Extended Echo Reply |
+----------------------------+ +----------------------------+
| ICMP Extension Header | | ICMP Extension Header |
+----------------------------+ +----------------------------+
|'Reflect All' Object Header | |'Reflect All' Object Header |
+----------------------------+ +----------------------------+
| Object payload | | Request's IPv6 Header |
| (placeholder) | | and extension headers |
| | | ------------------------ |
| | | Request's ICMPv6 Header |
| | | Extended Echo Request |
| | | ------------------------ |
| | | Request's ICMP Ext. Header |
+----------------------------+ +----------------------------+
^ ^ ^ ^
| | | |
+-- Extended Echo Request ---+ +--- Extended Echo Reply ----+
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 [I-D.ietf-intarea-rfc8335bis] and [RFC8335] is to respond with an ICMP Echo Reply message that includes the "Malformed Query" code in the Code field.¶
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 included in the Extension Structure. If there is more than one object, the 'Reflect All' object MUST be the first object.¶
The structure of the 'Reflect All' object follows the specification of ICMP Extension Objects as defined in [RFC4884] and MUST include the following fields:¶
The Length field specifies the number of octets in the object. The Length in the 'Reflect All' object of a reply message MUST be equal to the Length in the 'Reflect All' object of the respective request message.¶
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:¶
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 copy the request message 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, it MUST update the C-Type value of the object in the Extended Echo Reply to 'Reply - Unsupported Object'.¶
The object payload field in the ICMPv6 Extended Echo Request message is a placeholder for the corresponding reply message. Its length determines the number of bytes, starting from the beginning of the IPv6 header, that the probed node includes in the object payload of the reply. The object payload field in a request message MAY contain all zeros. Alternatively, this field MAY contain arbitrary data. 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 payload object.¶
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 | Reflect All | 0-2 | See below | [This document] | | | | | | | +-----------+------------------+--------+---------------+-----------------+
For each of the object classes above the following C-Type values are defined:¶
Since this document uses technologies from [RFC4443], [RFC4884], and [I-D.ietf-intarea-rfc8335bis], 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 [I-D.ietf-intarea-rfc8335bis], in order to protect local resources, implementations SHOULD rate-limit incoming ICMP Extended Echo Request messages. Moreover, as per [I-D.ietf-intarea-rfc8335bis], by default, ICMP Extend Echo functionality is disabled.¶
The authors gratefully acknowledge Sebastian Moeller for his insightful comments.¶
Shahar Belkar Huawei 8-2 Matam Haifa 3190501 Israel Email: shahar.belkar@huawei.com Chongfeng Xie China Telecom Email: xiechf@chinatelecom.cn Zhenqiang Li China Mobile Email: li_zhenqiang@hotmail.com Justin Iurman Universite de Liege 10, Allee de la decouverte (B28) 4000 Sart-Tilman Belgium Email: justin.iurman@uliege.be¶