Skip to main content

ICMPv6 Extensions for Reflecting IPv6 Extension Header
draft-he-6man-icmpv6-extensions-ipv6-ext-header-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors hexiaoming , Xiao Min , Chongfeng Xie , Tal Mizrahi , Zhenqiang Li
Last updated 2024-06-20
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-he-6man-icmpv6-extensions-ipv6-ext-header-00
6MAN Working Group                                                 X. He
Internet-Draft                                             China Telecom
Intended status: Standards Track                                  X. Min
Expires: 22 December 2024                                      ZTE Corp.
                                                                  C. Xie
                                                           China Telecom
                                                              T. Mizrahi
                                                                  Huawei
                                                                   Z. Li
                                                            China Mobile
                                                            20 June 2024

         ICMPv6 Extensions for Reflecting IPv6 Extension Header
           draft-he-6man-icmpv6-extensions-ipv6-ext-header-00

Abstract

   This document defines a generic ICMPv6 extensions for carrying and
   reflecting IPv6 extension header, using two extended ICMPv6 message
   types: Echo Request and Echo Reply, for diagnostic purposes.  Also,
   an example of leveraging the ICMPv6 extensions for carrying and
   reflecting IPv6 option header, which contains the IOAM Trace Option,
   is presented.

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 22 December 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

He, et al.              Expires 22 December 2024                [Page 1]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 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
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  The extended ICMPv6 Messages  . . . . . . . . . . . . . . . .   4
     3.1.  The extended Echo Request Message . . . . . . . . . . . .   4
       3.1.1.  ICMP Extension Objects  . . . . . . . . . . . . . . .   5
       3.1.2.  Examples of Echo Request  . . . . . . . . . . . . . .   6
     3.2.  The extended Echo Reply Message . . . . . . . . . . . . .   7
       3.2.1.  ICMP Extension Objects  . . . . . . . . . . . . . . .   8
       3.2.2.  Examples of Echo Reply  . . . . . . . . . . . . . . .   8
   4.  The Extended Echo Request/Reply Operation . . . . . . . . . .  10
   5.  Example of Reflecting IOAM Trace Information  . . . . . . . .  10
     5.1.  Operation of the Extended ICMPv6 Messages . . . . . . . .  12
   6.  Updates to RFC 4884 . . . . . . . . . . . . . . . . . . . . .  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  ICMPv6 Type . . . . . . . . . . . . . . . . . . . . . . .  13
     7.2.  ICMP Extension Object Class . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   As specified in [RFC4443], the Internet Control Message Protocol for
   IPv6 (ICMPv6) is an integral part of IPv6, and the base protocol MUST
   be fully implemented by every IPv6 node.  ICMPv6 messages include
   error messages and informational messages, and the latter are
   referred to as ICMPv6 Echo Request/Reply messages.  ICMPv6 Echo
   request/reply message is very commonly used for diagnostic purposes,
   such as PING [RFC2151], to test bidirectional connectivity between
   two nodes: the source node sends an Echo Request to the destination
   node, and the destination node responds with an Echo Reply to the
   source node.  The data (payload) received in the ICMPv6 Echo Request
   message MUST be returned entirely and unmodified in the ICMPv6 Echo

He, et al.              Expires 22 December 2024                [Page 2]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

   Reply message.

   [RFC4884] defines ICMPv6 Extension Structure by which multi-part
   ICMPv6 error messages are supported.  [RFC8335] defines ICMPv6
   Extended Echo Request/Reply messages, containing an ICMPv6 Extension
   Structure customized for this message.  Both [RFC4884] and [RFC8335]
   provide sound principles and examples on how to extend ICMPv6
   messages.

   IPv6 encapsulation for In-situ OAM (IOAM) data is defined in
   RFC9486], which uses the IPv6 Hop-by-Hop and Destination options
   header to carry IOAM data fields ([RFC9197], [RFC9326]).  [I-D. shi-
   ippm-congestion-measurement-data] also adopts Hop-by-hop Option
   Header and Destination option header to collect the congestion
   information data along the path. [draft-filsfils-ippm-path-tracing]
   provides a record of the packet path as a sequence of interface ids
   by adopting Hop-by-hop Option Header and Destination option header.
   These two extension option headers are used for collecting
   information along the path a packet traverses.  It is expected that
   there are more requirements that need to use IPv6 options header for
   carrying path information in the future.

   The collected information is then exported to a central collector or
   controller for further process.  However, clearly in some cases, the
   sender is more concerned about these trace information.  Currently
   there are some RFCs and ongoing drafts in IETF that describe methods
   for sending this tracking information back to the sender.  [RFC9322]
   defines two new flags in the IOAM Trace Option headers: the Loopback
   and Active flags.  The Loopback flag is used to request that each
   transit device along the path loops back a truncated copy of the data
   packet to the sender.  The Active flag indicates that a packet is
   used for active measurement.  [I-D. ippm-stamp-ext-hdr-00] extends
   Simple Two-Way Active Measurement Protocol (STAMP) to carry and
   reflect any type of IPv6 option that carries IOAM data fields.

   This document defines a generic ICMPv6 extensions for carrying and
   reflecting IPv6 extension headers, using two extended ICMPv6 message
   types: Echo Request and Echo Reply.  Also, an example of leveraging
   the ICMPv6 extensions for carrying and reflecting IPv6 option header,
   which contains the IOAM Trace Option, is presented.

2.  Conventions

He, et al.              Expires 22 December 2024                [Page 3]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

2.1.  Requirements 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:

   ICMPv6: Internet Control Message Protocol for IPv6

   IOAM: In situ Operation, Administration, and Maintenance

   ECMP: Equal-Cost Multipath

3.  The extended ICMPv6 Messages

   This document defines two extended ICMPv6 types: the extended Echo
   Request and the extended Echo Reply.

3.1.  The 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        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 ICMP Extension Structure                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1: The Extended Echo Request

   ICMPv6 Fields:

   Type: TDB, defined in this document.

   Code: MUST be set to 0.

   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.

He, et al.              Expires 22 December 2024                [Page 4]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

   ICMP Extension Structure: As defined in [RFC4884], it contains
   exactly one Extension Header followed by one or more extension
   objects.

   Description

   Every node MUST implement an ICMPv6 Echo responder function that
   receives ICMPv6 Echo Requests and originates corresponding Echo
   Replies.  A node SHOULD also implement an application-layer interface
   for originating ICMPv6 Echo Requests and receiving ICMPv6 Echo
   Replies, for diagnostic purposes.

   Upper Layer Notification

   Echo Request messages MAY be passed to processes receiving ICMP
   messages.

3.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.  The values are listed as
      the following:

He, et al.              Expires 22 December 2024                [Page 5]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 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

3.1.2.  Examples of Echo Request

   In some use cases where only one object is used, which instructs the
   destination node (Echo responder) to copy the corresponding IPv6
   extension header into the Object payload in the extended Echo Reply
   packet,, the Echo Request is depicted as follows:

      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        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    ICMP Extension Header                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Length            |  Class-Num1   |   C-Type(0)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 3: Echo Request of ICMP extension structure including one
                                   object

   In another use cases where multiple objects may be used, which
   instruct the destination node to copy the multiple corresponding IPv6
   extension headers into the Object payload respectively, the Echo
   Request with two objects is depicted as follows:

He, et al.              Expires 22 December 2024                [Page 6]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

     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        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    ICMP Extension Header                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Length            |   Class-Num1    |   C-Type(0) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Length            |   Class-Num2    |   C-Type(0) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 4: Echo Request of ICMP extension header including two object

3.2.  The 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        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 ICMP Extension Structure                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5: The Extended Echo Reqply

   ICMPv6 Fields:

   Type: TDB, defined in this document.

   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.

   ICMP Extension Structure: As defined in [RFC4884], it contains
   exactly one Extension Header followed by one or more extension
   objects.

   Description

He, et al.              Expires 22 December 2024                [Page 7]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

   Every node MUST implement an ICMPv6 Echo responder function that
   receives ICMPv6 Echo Requests and originates corresponding Echo
   Replies.  A node SHOULD also implement an application-layer interface
   for originating ICMPv6 Echo Requests and receiving ICMPv6 Echo
   Replies, for diagnostic purposes.

   Upper Layer Notification

   Echo Reply messages MUST be passed to the process that originated an
   Echo Request message.

3.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 6 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 6: 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 3.1.1.

   C-Type: 8 bits, and its values are defined in Section 3.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.  Echo Reply packet MUST copy the entire
   IPv6 extension header into the Object payload.

3.2.2.  Examples of Echo Reply

   In some use cases where only one object is used, the Echo Reply, with
   an Object payload containing the corresponding IPv6 extension header,
   is depicted as follows:

He, et al.              Expires 22 December 2024                [Page 8]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

      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        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    ICMP Extension Header                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Length            |   Class-Num1    | C-Type (0)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |   Object payload containing IPv6 Hop-by-Hop Options Header    |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7: The extended Echo Reply including an object carrying the
                    corresponding IPv6 extension header

   In another use cases where two objects may be used, the Echo Reply,
   with two Object payloads containing the IPv6 extension header
   respectively, is depicted as follows:

        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        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    ICMP Extension Header                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Length            |  Class-Num1   |   C-Type (0)  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |   Object payload containing IPv6 Hop-by-Hop Options Header    |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Length            |  Class-Num2   |  C-Type (0)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |  Object payload containing IPv6 Destination Options Header    |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 8: The extended Echo Reply including two objects

He, et al.              Expires 22 December 2024                [Page 9]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

4.  The Extended Echo Request/Reply Operation

   When the source node adds an IPv6 extension header to be reflected,
   it also MUST add one object contained in ICMP extension structure in
   the extended ICMPv6 Echo Request packet, which instructs the
   destination node to copy the corresponding IPv6 extension header into
   the Object payload in the extended Echo Reply packet.  When adding
   multiple IPv6 extension headers, one or multiple objects MUST be
   added, each one with matching IPv6 extension header object class.

   When the extended Echo Request packet carries an IPv6 extension
   header that it does not require Echo responder to reflect in the Echo
   Reply packet, it SHOULD not add the matching object class in ICMP
   extension structure in the extended Echo Request packet.

   When the Echo responder receives the extended Echo Request packet
   with IPv6 extension header and ICMP extension structure, the
   responder that supports this extended Echo, MUST copy the entire IPv6
   extension header into the Object payload in the extended Echo Reply
   packet.

   When the Echo responder receives the extended Echo Request packet
   with IPv6 extension header but it does not carry any object in ICMP
   extension structure, the responder SHOULD not copy the entire IPv6
   extension header into the Object payload.

   When the Echo responder receives the extended Echo Request packet
   with IPv6 extension header and ICMP extension structure carrying any
   unrecognized object class, the responder SHOULD skip this object and
   only copy the entire IPv6 extension header with recognized object
   class into the Object payload.

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
   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?

He, et al.              Expires 22 December 2024               [Page 10]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

   *  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 9: 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:

            +----------------------------------+
            |          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) |  |
            +----------------------------------+--+

He, et al.              Expires 22 December 2024               [Page 11]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

             Figure 10: An integral extended Echo Reply packet

5.1.  Operation of the Extended ICMPv6 Messages

   An IOAM network can be depicted as follows.

   +--------+     +-----------+     +-----------+     +-----------+     +--------+
   |  Host  |=====| IOAM node |=====| IOAM node |=====| IOAM node |=====|  Host  |
   +--------+     +-----------+     +-----------+     +-----------+     +--------+
                  Encapsulating        Transit        Decapsulating
                     Node                Node              Node

                  |------------------  IOAM-Domain  ---------------|

                       Figure 11: IOAM network

   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 of ICMP Extension Structure.

He, et al.              Expires 22 December 2024               [Page 12]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 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.  Updates to RFC 4884

   Section 4.6 of [RFC4884] provides a list of extensible ICMP messages
   (i.e., messages that can carry the ICMP Extension Structure).  This
   document adds the ICMPv6 Extended Echo Request message and the ICMPv6
   Extended Echo Reply message to that list.

7.  IANA Considerations

7.1.  ICMPv6 Type

   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        |  Code  |    Name     |     Reference    |
   +---------+------------------+--------+-------------+------------------+
   | TBD     |  Echo Request    |   0    |  Reserved   | [This document]  |
   +---------+---------------------------+-------------+------------------+
   | TBD     |  Echo Reply      |   0    |  Reserved   |  [This document] |
   +---------+------------------+--------+-------------+------------------+

             Figure 12: The extended ICMPv6 Type Numbers

   The two type values should be allocated from one of the unassigned
   values greater than 127.

He, et al.              Expires 22 December 2024               [Page 13]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

   IANA is requested to define a code registry for each of the two new
   types.  The registration procedure for these registries is First Come
   First Served.  In each of these new registries, a single code value
   is assigned by this document: Code 0.

7.2.  ICMP Extension Object Class

   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 Options Header  |    0     |  Reserved     | [This document] |
  +--------------+----------------------------+----------+---------------+-----------------+
  |     TBD2     | Destination Options Header |    0     |  Reserved     | [This document] |
  +--------------+----------------------------+----------+---------------+-----------------+
  |     TBD3     | Routing Header             |    0     |  Reserved     | [This document] |
  +--------------+----------------------------+----------+---------------+-----------------+

 Figure 13: ICMP Extension Object Classes and Class Sub-types values

8.  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].

   The extended ICMPv6 Echo Reply message can be longer than the
   extended Echo Request message, since the Extension Structure of the
   extended Echo Reply includes one or more objects containing the
   respective IPv6 options header.  Thus, an Echo Reply message is
   slightly amplified compared to an Echo Request message.  However, the
   amplification effect is minor, as an IPv6 options can have a maximum
   length of 255 octets.

9.  References

9.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,
              <https://www.rfc-editor.org/info/rfc2119>.

He, et al.              Expires 22 December 2024               [Page 14]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

   [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,
              <https://www.rfc-editor.org/info/rfc2151>.

   [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,
              <https://www.rfc-editor.org/info/rfc4443>.

   [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,
              <https://www.rfc-editor.org/info/rfc4884>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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,
              <https://www.rfc-editor.org/info/rfc8335>.

   [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, <https://www.rfc-editor.org/info/rfc9197>.

   [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,
              <https://www.rfc-editor.org/info/rfc9486>.

9.2.  Informative References

   [I-D.filsfils-ippm-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-ippm-path-
              tracing-01, 2 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-filsfils-
              ippm-path-tracing-01>.

He, et al.              Expires 22 December 2024               [Page 15]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

   [I-D.ietf-ippm-stamp-ext-hdr]
              Gandhi, R. and T. Zhou, "Simple Two-Way Active Measurement
              Protocol (STAMP) Extensions for Reflecting STAMP Packet
              Extension Headers", Work in Progress, Internet-Draft,
              draft-ietf-ippm-stamp-ext-hdr-00, 30 May 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
              stamp-ext-hdr-00>.

   [I-D.shi-ippm-congestion-measurement-data]
              Shi, H., Zhou, T., and Z. Li, "Data Fields for Congestion
              Measurement", Work in Progress, Internet-Draft, draft-shi-
              ippm-congestion-measurement-data-00, 3 March 2024,
              <https://datatracker.ietf.org/doc/html/draft-shi-ippm-
              congestion-measurement-data-00>.

   [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,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC9322]  Mizrahi, T., Brockners, F., Bhandari, S., Gafni, B., and
              M. Spiegel, "In Situ Operations, Administration, and
              Maintenance (IOAM) Loopback and Active Flags", RFC 9322,
              DOI 10.17487/RFC9322, November 2022,
              <https://www.rfc-editor.org/info/rfc9322>.

   [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,
              <https://www.rfc-editor.org/info/rfc9343>.

Authors' Addresses

   Xiaoming He
   China Telecom
   Email: hexm4@chinatelecom.cn

   Xiao Min
   ZTE Corp.
   Email: xiao.min2@zte.com.cn

   Chongfeng Xie
   China Telecom
   Email: xiechf@chinatelecom.cn

He, et al.              Expires 22 December 2024               [Page 16]
Internet-Draft  ICMPv6 Extensions for Reflecting IPv6 Ex       June 2024

   Tal Mizrahi
   Huawei
   Email: tal.mizrahi.phd@gmail.com

   Zhenqiang Li
   China Mobile
   Email: li_zhenqiang@hotmail.com

He, et al.              Expires 22 December 2024               [Page 17]