Network T. Mizrahi Internet-Draft T. Zhou Intended status: Standards Track S. Belkar Expires: 5 December 2024 R. Cohen Huawei J. Iurman ULiege 3 June 2024 Internet Control Message Protocol (ICMPv6) Loopback draft-mcb-6man-icmpv6-loopback-01 Abstract This document defines ICMPv6 Loopback, which enables a two-way packet exchange that can be used for probing and for diagnostic purposes. ICMPv6 Loopback is similar to ICMPv6 Echo, except that after a Loopback Request is sent, its corresponding Reply includes as much of the IPv6 Loopback Request packet as possible, including the IPv6 header and IPv6 extension headers and options if they are present. Status of This Memo 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 5 December 2024. Copyright Notice Copyright (c) 2024 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 Mizrahi, et al. Expires 5 December 2024 [Page 1] Internet-Draft ICMPv6 Loopback June 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. ICMPv6 Loopback Messages . . . . . . . . . . . . . . . . . . 5 3.1. Loopback Request Message . . . . . . . . . . . . . . . . 5 3.2. Loopback Reply Message . . . . . . . . . . . . . . . . . 6 3.3. Loopback Message Code . . . . . . . . . . . . . . . . . . 7 3.4. Symmetric Loopback . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. New ICMPv6 Type vs. New Code . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction ICMPv6 Echo [RFC4443] is very commonly used for diagnostic purposes ("Ping"), and is based on a two-way exchange: Node A sends an Echo Request to Node B, and Node B responds with an Echo Reply to Node A. The data (payload) of the Echo Reply message is identical to the data of the invoking Echo Request message. This document defines ICMPv6 Loopback, using two ICMPv6 message types: Loopback Request and Loopback Reply. The Loopback procedure uses a two-way exchange that is similar to the Echo exchange, with the exception that the payload of the Loopback Reply includes as much of the invoking IPv6 Loopback Request as possible without exceeding the MTU, including IPv6 extension headers if they are present. Mizrahi, et al. Expires 5 December 2024 [Page 2] Internet-Draft ICMPv6 Loopback June 2024 +----------------------------+ | IPv6 Header | |+ optional extension headers| +----------------------------+ | ICMPv6 Header | | Loopback Request | +----------------------------+ | ICMPv6 Data | +----------------------------+ ^ ^ | | +-----+ +----- Loopback Request -----+ +-----+ | |-------------------------------------------------->| | | A | | B | | |<--------------------------------------------------| | +-----+ +----- Loopback Reply -----+ +-----+ | | v v +----------------------------+ | IPv6 Header | |+ optional extension headers| +----------------------------+ | ICMPv6 Header | | Loopback Reply | +- +----------------------------+ | | IPv6 Header | | |+ optional extension headers| Invoking | +----------------------------+ Loopback -+ | ICMPv6 Header | Request | | Loopback Request | | +----------------------------+ | | ICMPv6 Data | +- +----------------------------+ Figure 1: The ICMPv6 Loopback Procedure It should be noted that ICMPv6 error messages [RFC4443] already include as much of the IPv6 offending packet as possible. For example, a node that runs Traceroute receives the inoking packets back in the returned Time Exceeded messages. The Loopback messages that are defined in this document enable this information to be returned to the sender without invoking ICMP error messages. Mizrahi, et al. Expires 5 December 2024 [Page 3] Internet-Draft ICMPv6 Loopback June 2024 ICMPv6 Loopback provides detailed information about the invoking IPv6 packet that is not available in ICMPv6 Echo, including the IPv6 header and extension headers. A related capability was proposed in the context of the Simple Two- way Active Measurement Protocol (STAMP): the STAMP extension that was proposed in [I-D.wang-ippm-stamp-hbh-extensions] allows a STAMP session-reflector to reflect IPv6 options that were received in test packets from the session-sender. This functionality is performed over STAMP, while the ICMPv6 Loopback functionality is performed in Layer 3, and does not require any parsing or processing beyond Layer 3, namely IPv6 and ICMPv6. There is a number of in-progress drafts in the IETF that define IPv6 extension headers that can be used for tracing the path and its performance, including for example, [I-D.ietf-ippm-ioam-ipv6-options], [I-D.filsfils-spring-path-tracing], [I-D.ali-spring-ioam-srv6], [I-D.kumar-ippm-ifa]. These extensions are used for collecting information along the path of a packet. The collected information is then exported to a central collector or controller for further processing. However, there is currently no straightforward way of sending such trace information back to the sender, while clearly in some cases this trace information is most relevant to the sender. ICMPv6 Loopback enables collected trace information along with other extension headers to be echoed back to the sender in a strightforward and generic way. 2. Conventions 2.1. Requirement Language 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. 2.2. Terminology Abbreviations used in this document: ICMP: Internet Control Message Protocol MTU: Maximum Transmission Unit Mizrahi, et al. Expires 5 December 2024 [Page 4] Internet-Draft ICMPv6 Loopback June 2024 3. ICMPv6 Loopback Messages This document defines two new ICMPv6 types: Loopback Request and Loopback Reply. 3.1. Loopback Request Message 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+- Figure 2: Loopback Request IPv6 Fields: Destination Address Any legal IPv6 address. ICMPv6 Fields: Type TBD-LB-Req Code 0 Identifier An identifier to aid in matching Loopback Replies to this Loopback Request. May be zero. Sequence Number A sequence number to aid in matching Loopback Replies to this Loopback Request. May be zero. Data Zero or more octets of arbitrary data. Description A node that implements the ICMPv6 Echo Request and Reply MAY implement an ICMPv6 Loopback responder function that receives Loopback Requests and originates corresponding Loopback Replies. A node MAY also implement an application-layer interface for originating Loopback Requests and receiving Loopback Replies, for diagnostic purposes. Upper Layer Notification Mizrahi, et al. Expires 5 December 2024 [Page 5] Internet-Draft ICMPv6 Loopback June 2024 Loopback Request messages MAY be passed to processes receiving ICMPv6 messages. 3.2. Loopback Reply Message 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As much of the invoking IPv6 Loopback Request packet | + as possible without the ICMPv6 packet + | exceeding the minimum IPv6 MTU [RFC8200] | Figure 3: Loopback Reply IPv6 Fields: Destination Address Copied from the Source Address field of the invoking Loopback Request packet. ICMPv6 Fields: Type TBD-LB-Rep Code 0 Identifier The identifier from the invoking Loopback Request message. Sequence Number The sequence number from the invoking Loopback Request message. Description A node that implements the ICMPv6 Echo Request and Reply MAY implement an ICMPv6 Loopback responder function that receives Loopback Requests and originates corresponding Loopback Replies. A node MAY also implement an application-layer interface for originating Loopback Requests and receiving Loopback Replies, for diagnostic purposes. The source address of a Loopback Reply sent in response to a unicast Loopback Request message MUST be the same as the destination address of that Loopback Request message. Mizrahi, et al. Expires 5 December 2024 [Page 6] Internet-Draft ICMPv6 Loopback June 2024 A Loopback Reply SHOULD be sent in response to a Loopback Request message sent to an IPv6 multicast or anycast address. In this case, the source address of the reply MUST be a unicast address belonging to the interface on which the Loopback Request message was received. The payload of the ICMPv6 Loopback Reply message, which resides after the Sequence Number field, MUST include as much of the invoking IPv6 Loopback Request packet without exceeding the IPv6 MTU. Note that if the invoking packet includes IPv6 extension headers, they are included in the payload of the Loopback Reply message. Upper Layer Notification Loopback Reply messages MUST be passed to the process that originated a Loopback Request message. A Loopback Reply message MAY be passed to processes that did not originate the Loopback Request message. 3.3. Loopback Message Code The Loopback Request and Reply messages include a Code field. Two Code values are defined in this document, 0 and 1. Code 0 indicates the Loopback Request and Reply as defined above, while Code 1 indicates the Symmetric Loopback Request and Reply, as described in Section 3.4. An ICMPv6 Loopback message that is received with an unknown Code value MUST be discarded. A Loopback Reply message MUST incorporate the same Code value that was received in the corresponding Loopback Request message. An ICMPv6 Loopback responder MAY be configured to respond to a subset of the supported Code values. 3.4. Symmetric Loopback The Symmetric Loopback Request and Reply are identical to the conventional Loopback Request and Reply, except that the length of the ICMPv6 payload in the Symmetric Loopabck Reply is equal to the length of the payload of the corresponding Symmetric Loopback Request. The payload of the ICMPv6 Symmetric Loopback Reply message, which resides after the Sequence Number field, MUST include the invoking IPv6 Loopback Request packet, truncated to match the length of the payload of the corresponding ICMPv6 Symmetric Loopback Request, and if necessary truncated further to avoid exceeding the IPv6 MTU. The payload of the ICMPv6 Symmetric Loopback Request message SHOULD be sufficiently long to allow the Reply to include the IPv6 and ICMPv6 headers. Mizrahi, et al. Expires 5 December 2024 [Page 7] Internet-Draft ICMPv6 Loopback June 2024 4. IANA Considerations 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: +-------------+---------------------+---------------------------+ | Type | Name | Reference | +-------------+---------------------+---------------------------+ | TBD-LB-Req | Loopback Request | [This document] | +-------------+---------------------+---------------------------+ | TBD-LB-Rep | Loopback Reply | [This document] | +-------------+---------------------+---------------------------+ Figure 4: ICMPv6 Loopback Type Numbers The two type values should be allocated from one of the unassigned values greater than 127. IANA is requested to define a code registry for each of the two new types. The registration procedure for these registries are "Specification Required". In each of these new registries, the following code values are assigned by this document: +-------------+---------------------+---------------------------+ | Code | Name | Reference | +-------------+---------------------+---------------------------+ | 0 | Loopback | [This document] | +-------------+---------------------+---------------------------+ | 1 | Symmetric Loopback | [This document] | +-------------+---------------------+---------------------------+ Figure 5: ICMPv6 Loopback Code Numbers 5. Security Considerations 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]. An ICMPv6 Loopback Reply message may be longer than the invoking Loopback Request message, since the Loopback Reply includes the invoking IPv6 packet, encapsulated in an ICMPv6 over IPv6 packet. Thus, replies are slightly amplified compared to requests. Notably, the amplification effect in this case is similar to ICMPv6 error Mizrahi, et al. Expires 5 December 2024 [Page 8] Internet-Draft ICMPv6 Loopback June 2024 message, and specifically similar to Traceroute. The amplification effect can be avoided by configuring responders to respond only to Symmetric Loopback (with Code 1), as defined in Section 3.4. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 6.2. Informative References [I-D.ali-spring-ioam-srv6] Ali, Z., Gandhi, R., Filsfils, C., Brockners, F., Nainar, N. K., Pignataro, C., Li, C., Chen, M., and G. Dawra, "Segment Routing Header encapsulation for In-situ OAM Data", Work in Progress, Internet-Draft, draft-ali-spring- ioam-srv6-06, 10 July 2022, . [I-D.filsfils-spring-path-tracing] Filsfils, C., Abdelsalam, A., Camarillo, P., Yufit, M., Graf, T., Su, Y., Matsushima, S., Valentine, M., and Dhamija, "Path Tracing in SRv6 networks", Work in Progress, Internet-Draft, draft-filsfils-spring-path- tracing-05, 23 October 2023, . Mizrahi, et al. Expires 5 December 2024 [Page 9] Internet-Draft ICMPv6 Loopback June 2024 [I-D.ietf-ippm-ioam-ipv6-options] Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam- ipv6-options-12, 7 May 2023, . [I-D.kumar-ippm-ifa] Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook, H., Ghanwani, A., Cai, D., Ou, H., Li, Y., and X. Wang, "Inband Flow Analyzer", Work in Progress, Internet-Draft, draft-kumar-ippm-ifa-08, 26 April 2024, . [I-D.spiegel-ippm-ioam-rawexport] Spiegel, M., Brockners, F., Bhandari, S., and R. Sivakolundu, "In-situ OAM raw data export with IPFIX", Work in Progress, Internet-Draft, draft-spiegel-ippm-ioam- rawexport-07, 12 February 2024, . [I-D.wang-ippm-stamp-hbh-extensions] Zhou, T., Fioccola, G., Mishra, G. S., Yang, H., and C. Liu, "Simple Two-way Active Measurement Protocol (STAMP) Extensions for Hop- by-Hop Data Collection", Work in Progress, Internet-Draft, draft-wang-ippm-stamp-hbh- extensions-07, 24 April 2024, . Appendix A. New ICMPv6 Type vs. New Code One of the issues that was discussed in the development of this document is whether ICMPv6 Loopback Request and Reply should be identified based on the ICMPv6 type, or based on the code value. The first approach, which is used throughout this document, is to define new type values for Loopback Request and Loopback Reply. The second approach is to reuse the Echo Request and Reply type values, but to define new code values that identify the Loopback messages. Notably, the behavior of ICMPv6 as defined in [RFC4443] is well defined when receiving an unknown type, but the behavior when receiving an unknown code in an Echo message has not been defined. Therefore, this behavior varies between different implementations. For example, in Debian distributions an Echo Reply is sent with the same code that was received in the Echo Request, regardless of Mizrahi, et al. Expires 5 December 2024 [Page 10] Internet-Draft ICMPv6 Loopback June 2024 whether the code value is known. In FreeBSD, on the other hand, if an Echo Request is received with an unknown code it is ignored. Due to this ambiguity in [RFC4443] it is not possible to use Echo messages with a new code value, since existing implementations may behave in an unpredictable manner. The current document therefore defines new type values for ICMPv6 Loopback messages. Authors' Addresses Tal Mizrahi Huawei 8-2 Matam Haifa 3190501 Israel Email: tal.mizrahi.phd@gmail.com Tianran Zhou Huawei 156 Beiqing Rd. Beijing 100095 China Email: zhoutianran@huawei.com Shahar Belkar Huawei 8-2 Matam Haifa 3190501 Israel Email: shahar.belkar@huawei.com Reuven Cohen Huawei 8-2 Matam Haifa 3190501 Israel Email: reuven.cohen@huawei.com Mizrahi, et al. Expires 5 December 2024 [Page 11] Internet-Draft ICMPv6 Loopback June 2024 Justin Iurman Universite de Liege 10, Allee de la decouverte (B28) 4000 Sart-Tilman Belgium Email: justin.iurman@uliege.be Mizrahi, et al. Expires 5 December 2024 [Page 12]