6MAN Working Group X. He Internet-Draft China Telecom Intended status: Standards Track R. Bonica Expires: 6 January 2025 Juniper Networks X. Min ZTE Corp. C. Xie China Telecom T. Mizrahi Huawei Z. Li China Mobile 5 July 2024 LOOPBACK6: A Utility For Detecting IPv6 Extension Header Changes draft-he-6man-icmpv6-extensions-ipv6-ext-header-02 Abstract This document describes LOOPBACK6. LOOPBACK6 is a utility that network operators can use to determine how IPv6 extension headers have been altered by transit nodes. Its operation is similar to that of PING and PROBE. 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 6 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. He, et al. Expires 6 January 2025 [Page 1] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 4. The Extended ICMPv6 Messages . . . . . . . . . . . . . . . . 4 4.1. ICMPv6 Extended Echo Request Message . . . . . . . . . . 4 4.1.1. ICMP Extension Objects . . . . . . . . . . . . . . . 5 4.2. ICMPv6 Extended Echo Reply Message . . . . . . . . . . . 6 4.2.1. ICMP Extension Objects . . . . . . . . . . . . . . . 7 5. Example of Reflecting IOAM Trace Information . . . . . . . . 7 5.1. Operation of the Extended ICMPv6 Messages . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction IPv6 [RFC8200] is an extensible protocol. Source nodes use IPv6 extension headers to elicit extended IPv6 behaviors. The following are a subset of IPv6 extension header types: * Hop-by-Hop Options * Routing * Destination Options The Hop-by-hop Options extension header can be processed by each node along a packet's delivery path. However, the Routing extension header is processed by only a selected set of nodes along a packet's delivery path. And finally, the Destination Options extension header is processed by a packet's destination node only. He, et al. Expires 6 January 2025 [Page 2] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 Depending on their contents, IPv6 extensions headers can be mutable or immutable. Transit nodes can alter the contents of a mutable extension header. In at least one example [RFC9197] [RFC9486], transit routers accumulate OAM information in mutable extension headers. However, transit nodes cannot alter the contents of an immutable extension header. LOOPBACK6 is a utility that network operators can use to determine how IPv6 extension headers have been altered by transit nodes. Its operation is similar to that of PING [RFC2151] and PROBE [RFC8335]. This document describes LOOPBACK6 operation. 2. Conventions 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. 3. Theory of Operation LOOPBACK6 executes on a probing node. It originates and sends an ICMPv6 Extended Echo Request message [RFC4443] [RFC8335] from the probing node to a probed interface that resides on a probed node. The L-bit of the ICMPv6 Extended Echo Request message MUST be set to 1. This indicates that the probed interface resides on the probed node. The ICMP Extended Echo Request contains an ICMP Extension Structure [RFC4884] and the ICMP Extension Structure contains one or more of the following ICMP Extension Objects: * Hop-by-Hop Options Header * Routing Header * Destination Options Header The above-mentioned ICMP Extension Objects are defined in Section 4 of this document. When they are used in the ICMPv6 Extended Echo Request message, they carry no payload. Therefore, their length MUST be equal to 4 octets. The ICMP Extended Echo Request is encapsulated in an IPv6 header and the IPv6 header can carry IPv6 extension headers. He, et al. Expires 6 January 2025 [Page 3] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 When the probed node receives the ICMPv6 Extended Echo Request message, it formats and sends an ICMPv6 Extended Reply message. The ICMP Extended Echo Reply contains an ICMP Extension Structure and the ICMP Extension Structure contains the same set of ICMP Extension Objects that the ICMP Extended Request message contained. However, the ICMP Extension objects MUST include payloads. Specifically: * The payload field for the Hop-by-Hop Options Header option MUST reflect the Hop-by-Hop Option extension header from the packet that carried the ICMPv6 Extended Echo Request message to the probed node. * The payload field for the Routing Header option MUST reflect the Routing extension header from the packet that carried the ICMPv6 Extended Echo Request message to the probed node. * The payload field for the Destination Options Header option MUST reflect the Destination Option extension header from the packet that carried the ICMPv6 Extended Echo Request message to the probed node. 4. The Extended ICMPv6 Messages LOOPBACK6 leverages two extended ICMPv6 messages: the Extended Echo Request Message and the Extended Echo Reply Message defined in [RFC8335]. 4.1. ICMPv6 Extended Echo Request Message the ICMPv6 Extended Echo Request message is encapsulated in an IPv6 header. Figure 1 depicts the ICMPv6 Extended Echo 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| Reserved |L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP Extension Structure | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ICMPv6 Extended Echo Request Message ICMPv6 Fields: Type: Extended Echo Request. As defined in [RFC8335], The value is 160. He, et al. Expires 6 January 2025 [Page 4] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 Code: MUST be set to 0. Checksum: As defined in [RFC4443]. 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. Reserved: This field MUST be set to 0 and ignored upon receipt. L (local): As defined in [RFC8335]. MUST be set to 0 in this document. ICMP Extension Structure: As defined in [RFC4884], it contains exactly one Extension Header followed by one or more extension objects. 4.1.1. ICMP Extension Objects 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Object header without any 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, 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, which instructs the Echo responder to copy the corresponding IPv6 extension header into the Object payload field in the extended Echo Reply packet. The values are listed as the following: He, et al. Expires 6 January 2025 [Page 5] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 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 4.2. ICMPv6 Extended Echo Reply Message The ICMPv6 Extended Echo Reply message is encapsulated in an IPv6 header. Figure 3 depicts the ICMPv6 Extended Echo 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|State|Res|A|4|6| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ICMP Extension Structure | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ICMPv6 Extended Echo Reply Message ICMPv6 Fields: Type: Extended Echo Reply. As defined in [RFC8335], The value is 161. 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. State: As defined in [RFC8335].This field MUST be set to 0 in this document. Res: This field MUST be set to 0 and ignored upon receipt. He, et al. Expires 6 January 2025 [Page 6] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 A (Active): As defined in [RFC8335]. 4 (IPv4): As defined in [RFC8335]. 6 (IPv6): As defined in [RFC8335]. ICMP Extension Structure: As defined in [RFC4884], it contains exactly one Extension Header followed by one or more extension objects. 4.2.1. ICMP Extension Objects Each extension object contains one or more 32-bit words, including an object header and payload. All object headers share a common format. Figure 4 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) // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Object header and 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 4.1.1. C-Type: 8 bits, and its values are defined in Section 4.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]. 5. Example of Reflecting IOAM Trace Information 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 He, et al. Expires 6 January 2025 [Page 7] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 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 | | +----------------------------+--+ Figure 5: An integral extended Echo Request packet 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: He, et al. Expires 6 January 2025 [Page 8] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 +----------------------------------+ | 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) | | +----------------------------------+--+ Figure 6: An integral extended Echo Reply packet 5.1. Operation of the Extended ICMPv6 Messages 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 field of ICMP Extension Structure. He, et al. Expires 6 January 2025 [Page 9] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 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. 6. IANA Considerations 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 | 0 | Reserved | [This document] | | | Options Header | | | | +--------------+------------------+----------+---------------+-----------------+ | TBD2 | Destination | 0 | Reserved | [This document] | | | Options Header | | | | +--------------+------------------+----------+---------------+-----------------+ | TBD3 | Routing Header | 0 | Reserved | [This document] | +--------------+------------------+----------+---------------+-----------------+ Figure 7: ICMP Extension Object Classes and Class Sub-types values 7. Security Considerations The technology described in this document inherits all of the vulnerabilities described in [RFC4443]. He, et al. Expires 6 January 2025 [Page 10] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 Because the ICMPv6 Extended Echo Reply message can be longer than the ICMPv6 Extended Echo Request message, there is a slight risk that this technology could be used as a vector for denial of service attacks. However, this risk is minimal, because the ICMPv6 Extended Echo Reply message, along with its IPv6 header, cannot exceed 1280 octets. 8. References 8.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, . [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ IP Tools and Utilities", FYI 30, RFC 2151, DOI 10.17487/RFC2151, June 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, . [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8335] Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M. Boucadair, "PROBE: A Utility for Probing Interfaces", RFC 8335, DOI 10.17487/RFC8335, February 2018, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . He, et al. Expires 6 January 2025 [Page 11] Internet-Draft LOOPBACK6: A Utility For Detecting IPv6 July 2024 [RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023, . 8.2. Informative References [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate-Marking Method", RFC 9343, DOI 10.17487/RFC9343, December 2022, . Authors' Addresses Xiaoming He China Telecom Email: hexm4@chinatelecom.cn Ron Bonica Juniper Networks United States of America Email: rbonica@juniper.net Xiao Min ZTE Corp. Email: xiao.min2@zte.com.cn Chongfeng Xie China Telecom Email: xiechf@chinatelecom.cn Tal Mizrahi Huawei Email: tal.mizrahi.phd@gmail.com Zhenqiang Li China Mobile Email: li_zhenqiang@hotmail.com He, et al. Expires 6 January 2025 [Page 12]