



Internet Area Working Group                         J. Rajamanickam, Ed.
Internet-Draft                                                  D. Dukes
Intended status: Standards Track                M. Sankaranarayanan, Ed.
Expires: 28 August 2026                              Cisco Systems, Inc.
                                                               R. Bonica
                                                                     HPE
                                                        24 February 2026


             ICMP extension to include underlay information
              draft-jags-intarea-icmp-ext-underlay-info-04

Abstract

   Network operators managing overlay networks require visibility into
   underlay network hops during traceroute operations from overlay
   endpoints.  This document defines an ICMP extension object, the
   Underlay Information Object (UIO), which allows underlay head-end
   nodes to encapsulate underlay error information within ICMP error
   messages.  This mechanism provides overlay operators with crucial
   visibility into underlay network paths for troubleshooting.

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 28 August 2026.

Copyright Notice

   Copyright (c) 2026 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



Rajamanickam, et al.     Expires 28 August 2026                 [Page 1]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  ICMP Error Message Origination and UIO  . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Underlay Information Object . . . . . . . . . . . . . . . . .   5
     3.1.  UIO Object Format . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Underlay Information Object Encoding Process  . . . . . .   6
     3.3.  Content Restrictions and Filtering  . . . . . . . . . . .   7
       3.3.1.  Permitted ICMP Message Types  . . . . . . . . . . . .   7
       3.3.2.  Permitted Extension Objects . . . . . . . . . . . . .   8
       3.3.3.  Size Constraints  . . . . . . . . . . . . . . . . . .   8
       3.3.4.  Loop and Recursion Prevention . . . . . . . . . . . .   9
       3.3.5.  Single Source Principle . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     4.1.  Information Disclosure  . . . . . . . . . . . . . . . . .   9
     4.2.  Privacy Considerations  . . . . . . . . . . . . . . . . .  10
     4.3.  Message Size and Amplification  . . . . . . . . . . . . .  10
     4.4.  Spoofing and Forgery  . . . . . . . . . . . . . . . . . .  10
     4.5.  Intended Use  . . . . . . . . . . . . . . . . . . . . . .  10
     4.6.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . .  10
     4.7.  Content Filtering and Sanitization  . . . . . . . . . . .  11
       4.7.1.  Information Disclosure Risks  . . . . . . . . . . . .  11
       4.7.2.  Amplification and Abuse Risks . . . . . . . . . . . .  11
     4.8.  Operational Security  . . . . . . . . . . . . . . . . . .  12
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  ICMP Extension Object Class . . . . . . . . . . . . . . .  12
     5.2.  C-Type Values . . . . . . . . . . . . . . . . . . . . . .  13
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .  13
     6.1.  Configuration . . . . . . . . . . . . . . . . . . . . . .  13
     6.2.  Troubleshooting Workflow  . . . . . . . . . . . . . . . .  13
     6.3.  Multi-Vendor Interoperability . . . . . . . . . . . . . .  14
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Appendix . . . . . . . . . . . . . . . . . . . . . .  15
     A.1.  UIO ICMP Extension Message Examples . . . . . . . . . . .  15
       A.1.1.  UIO carrying IPv6 information to the IPv4 source  . .  15
       A.1.2.  UIO carrying IPv4 information to the IPv6 source  . .  16
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18




Rajamanickam, et al.     Expires 28 August 2026                 [Page 2]

Internet-Draft        ICMP Underlay Info Extension         February 2026


1.  Introduction

   The mechanism for ICMP messages to carry additional information is
   defined in [RFC4884].  ICMP message extensions that enable ICMP
   messages to carry additional information about the system where an
   error occurred are defined in [RFC5837], [RFC8335], and [RFC8883].
   These extensions transmit enhanced diagnostic information to the
   source node.

   Network operators who manage both overlay and underlay networks, such
   as those operating VPN segments connected through an SRv6 core
   network, require the ability to trace paths through the underlay
   infrastructure.  Currently, when performing traceroute operations
   from an overlay endpoint, operators lack visibility into the underlay
   path and cannot identify the specific underlay node where a failure
   occurred.  For instance, imagine a VPN service (overlay) running over
   an SRv6 network (underlay).  If a packet gets dropped within the SRv6
   network, the VPN operator currently has no direct way to pinpoint the
   exact underlay node causing the issue.

   The Underlay Information Object (UIO) defined in this document
   addresses this operational requirement by enabling underlay head-end
   nodes to include underlay-specific diagnostic information in ICMP
   error messages sent to overlay endpoints, thereby providing crucial
   visibility for troubleshooting.

1.1.  ICMP Error Message Origination and UIO

   The mechanism described in this document, where an underlay head-end
   node encapsulates underlay error information into a new ICMP error
   message destined for an overlay endpoint, deviates from existing ICMP
   error message origination rules.  Specifically, [RFC4443],
   Section 2.4, Rule (e.1) states that "An ICMPv6 error message MUST NOT
   be originated as a result of receiving the following: (e.1) An ICMPv6
   error message."  A similar restriction exists for ICMPv4 in [RFC792].

   This document defines a specific exception to this rule for the
   purpose of the Underlay Information Object (UIO).  The UIO mechanism
   is designed to provide critical diagnostic visibility into underlay
   network failures for overlay operators, a function not adequately
   served by existing ICMP mechanisms.  The underlay head-end node acts
   as an intermediary, translating an underlay error into a new error
   message containing encapsulated UIO information for the overlay,
   rather than simply forwarding the original error message.  This
   controlled origination of a new ICMP error message, triggered by an
   underlay ICMP error message, is essential for the UIO's intended
   troubleshooting workflow.  Therefore, this document updates [RFC4443]
   to accommodate this specific behavior.



Rajamanickam, et al.     Expires 28 August 2026                 [Page 3]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   However, permitting this exception introduces new challenges that
   must be carefully addressed.  Because UIO creates an intentional
   pathway for underlay diagnostic information to cross into the overlay
   domain, it raises the following concerns:

   *  Information Leakage: Unrestricted encapsulation could expose
      underlay topology, routing state, or configuration details beyond
      what is necessary for troubleshooting.

   *  Amplification and Abuse: Without constraints, a small probe could
      trigger disproportionately large ICMP responses containing UIO,
      enabling amplification attacks or reconnaissance of underlay
      infrastructure.

   *  Recursive Error Loops: An underlay head-end node generating a new
      ICMP error in response to a received ICMP error that itself
      contains a UIO could create infinite error loops.

   *  Content Integrity: Aggregating information from multiple underlay
      sources into a single UIO could produce misleading diagnostic
      data.

   To mitigate these risks, this document defines strict content
   restrictions (Section 3.3) that constrain which ICMP message types
   and extension objects may be encapsulated within a UIO, enforce
   message size limits, prevent loops and recursion, and ensure each UIO
   originates from a single underlay source.  These restrictions are
   essential to making the error origination exception safe for
   deployment.

2.  Conventions and Definitions

   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.

   This document uses the following terms:

   Overlay Network:  A virtual network built on top of an existing
      underlying network infrastructure, often providing services like
      VPNs or tunnels.

   Underlay Network:  The physical or logical network infrastructure
      over which an overlay network operates, responsible for forwarding
      packets between overlay endpoints.




Rajamanickam, et al.     Expires 28 August 2026                 [Page 4]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   Overlay Endpoint:  A device or system that terminates an overlay
      network segment and originates or receives traffic for the
      overlay.

   Underlay Head-End Node:  The node in the underlay network responsible
      for encapsulating overlay traffic and often the first point of
      contact for an overlay packet entering the underlay.

3.  Underlay Information Object

   This section defines a new ICMP extension object called Underlay
   Information Object (UIO) that is encoded as part of ICMP extension
   message.  A new Class-Num value TBA (To Be Assigned) is assigned to
   identify the UIO.  As per [RFC4884], this object MAY be appended to
   one of the following ICMP messages:

   *  ICMPv4 Time Exceeded

   *  ICMPv4 Destination Unreachable

   *  ICMPv4 Parameter Problem

   *  ICMPv6 Time Exceeded

   *  ICMPv6 Destination Unreachable

3.1.  UIO Object Format

   The UIO ICMP extension object has the following format:

    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=TBA |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~        Object-Payload (Other ICMP Extension Objects...)       ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Underlay Information Object Format

   Length (16 bits):  The length of this object, measured in octets,
      including the object header and object payload.  The length MUST
      be a multiple of 4 octets and MUST be at least 8 octets.

   Class-Num (8 bits):  The ICMP extension object class number that




Rajamanickam, et al.     Expires 28 August 2026                 [Page 5]

Internet-Draft        ICMP Underlay Info Extension         February 2026


      identifies this as a UIO object.  IANA is requested to assign a
      value from the "ICMP Extension Object Classes and Class Sub-types"
      registry (see Section 5).

   C-Type (8 bits):  The object sub-type.  This document defines C-Type
      value 0.  Additional C-Type values may be defined in future
      documents.  Implementations MUST set this field to 0 and SHOULD
      ignore the value upon receipt.

   Object-Payload (variable length):  Contains one or more ICMP
      Extension Objects that provide information about underlay nodes.
      The payload MUST contain at least one ICMP extension object.  Each
      encapsulated ICMP extension object MUST be formatted according to
      [RFC4884] and the specifications for that particular object class.

   This ICMP extension object acts as an envelope to carry other ICMP
   extension objects related to the underlay.  Primarily, the UIO ICMP
   extension object is encoded in the ICMP extension message by the
   underlay head-end when it receives an ICMP error message from one of
   its intermediate nodes.

   This UIO ICMP extension object can encapsulate one or more relevant
   ICMP extension objects that are related to the underlay node.  When
   the underlay head-end encodes its ICMP extension object, the first
   object MUST contain the ICMP extension object that carries IP address
   or the hostname of the node where the initial ICMP error was
   generated.  The ICMP extension objects encoded within the UIO ICMP
   extension objects can belong to any address family, irrespective of
   the address family of the source node that decapsulates the UIO ICMP
   extension objects, as opposed to what is stated in Section 4.2 of
   [RFC5837].

   If the node decoding the ICMP extension header does not recognize the
   UIO ICMP extension object, it SHOULD ignore this object and continue
   processing the other objects.

3.2.  Underlay Information Object Encoding Process

   When an underlay head-end node receives an ICMP error message from an
   underlay node and needs to forward information about this error to an
   overlay endpoint, it follows this process:

   1.  The underlay head-end node constructs an ICMP error message
       destined for the overlay endpoint.

   2.  The node appends a UIO ICMP extension object to this ICMP error
       message according to the procedures defined in [RFC4884].




Rajamanickam, et al.     Expires 28 August 2026                 [Page 6]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   3.  Within the UIO object payload, the node includes one or more ICMP
       extension objects that carry information about the underlay node
       where the original error occurred.

   4.  The first ICMP extension object within the UIO payload MUST
       contain addressing information (e.g., using the Interface
       Information Object defined in [RFC5837]) that identifies the
       underlay node that generated the original error.  This ensures
       that the most critical diagnostic information for pinpointing the
       failure source is immediately available.

   5.  Additional ICMP extension objects MAY be included to provide
       supplementary diagnostic information about the underlay path.

   6.  The encapsulated ICMP extension objects within the UIO may belong
       to any address family, regardless of the address family used
       between the underlay head-end and the overlay endpoint.

   7.  The total length of the ICMP message, including all extensions,
       MUST NOT exceed 576 octets for IPv4 or 1280 octets for IPv6 (the
       minimum reassembly buffer sizes defined in [RFC791] and
       [RFC8200], respectively).

   Implementations SHOULD provide configuration options to control which
   underlay information is included in UIO objects, considering security
   and privacy implications discussed in Section 4.

3.3.  Content Restrictions and Filtering

   The Underlay Information Object crosses administrative domain
   boundaries between overlay and underlay networks.  To prevent
   confusion, information leakage, and potential abuse, strict
   restrictions apply to the content that can be encapsulated within a
   UIO.

3.3.1.  Permitted ICMP Message Types

   An underlay head-end node MUST only encapsulate ICMP error messages
   that indicate packet forwarding failures in the underlay network.

   The following ICMP message types MAY be encapsulated:

   *  ICMPv4 Type 11 (Time Exceeded)

   *  ICMPv4 Type 3 (Destination Unreachable)

   *  ICMPv6 Type 1 (Destination Unreachable)




Rajamanickam, et al.     Expires 28 August 2026                 [Page 7]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   *  ICMPv6 Type 2 (Packet Too Big)

   *  ICMPv6 Type 3 (Time Exceeded)

   Other ICMP messages MUST NOT be included under UIO envelope.  The
   overlay host that receives the UIO messages other than the listed
   above MUST be dropped.

3.3.2.  Permitted Extension Objects

   The UIO object payload SHOULD contain only ICMP extension objects
   that provide diagnostic information about the underlay node that
   generated the original ICMP error message.

   The following extension object classes are RECOMMENDED for inclusion:

   *  Interface Information Object (Class-Num 2) [RFC5837]

   *  Node Identification Object (Class-Num 5)
      [I-D.ietf-intarea-extended-icmp-nodeid]

   *  MPLS Label Stack Object (Class-Num 1) [RFC4950]

   Future IETF standards-track ICMP extension objects with diagnostic
   purpose MAY be included, subject to the restrictions below.

   Other ICMP extension objects MUST NOT be included under UIO envelope.
   The overlay host that receives the UIO messages other than the listed
   above MUST be dropped.

3.3.3.  Size Constraints

   The total size of an ICMP message containing a UIO object MUST NOT
   exceed the minimum reassembly buffer size for the IP version being
   used:

   *  576 octets for IPv4 [RFC791]

   *  1280 octets for IPv6 [RFC8200]

   To ensure sufficient space for the ICMP header, original packet
   excerpt (128 octets as per [RFC4884]), and potential additional
   extension objects outside the UIO, implementations SHOULD limit the
   UIO object payload to a maximum of 512 octets.

   If the underlay ICMP error message contains extension objects that
   would cause the UIO payload to exceed this limit, the underlay head-
   end node SHOULD:



Rajamanickam, et al.     Expires 28 August 2026                 [Page 8]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   1.  Include the most critical diagnostic information first (per
       Section 3.2, the Node Identification Object SHOULD be first)

   2.  Truncate or omit less critical extension objects

   3.  NOT fragment the ICMP message

3.3.4.  Loop and Recursion Prevention

   An underlay head-end node MUST NOT generate an ICMP error message in
   response to receiving an ICMP error message that contains a UIO
   object in its extension structure.

   This applies regardless of whether the underlay head-end node would
   normally generate an error (e.g., due to TTL expiration, routing
   failure, etc.).  The packet MUST be silently discarded.

   Additionally, as specified in Section 3.3.2, nested UIO objects (a
   UIO containing another UIO in its payload) MUST NOT be created.

3.3.5.  Single Source Principle

   Each UIO object MUST contain ICMP extension objects from exactly one
   underlay node (the node that generated the original ICMP error
   message received by the underlay head-end).

   An underlay head-end node MUST NOT aggregate ICMP extension objects
   from multiple underlay nodes into a single UIO object, even if
   multiple errors were encountered for related packets.

   If the underlay head-end needs to communicate errors from multiple
   underlay nodes, it MUST generate separate ICMP messages, each with
   its own UIO object.

4.  Security Considerations

   The UIO extension introduces several security considerations that
   implementations and operators must address:

4.1.  Information Disclosure

   The UIO extension reveals information about the underlay network
   topology and addressing to overlay endpoints.  In many deployments,
   the overlay and underlay networks are operated by different
   administrative entities, and underlay topology information may be
   considered sensitive.





Rajamanickam, et al.     Expires 28 August 2026                 [Page 9]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   Implementations MUST provide configuration options to control the
   generation of UIO extensions.  The default configuration MUST disable
   UIO generation.  Operators SHOULD enable UIO only for authenticated
   and authorized overlay endpoints or networks.  The specific
   mechanisms for such authentication and authorization are outside the
   scope of this document but are crucial for secure deployment.

4.2.  Privacy Considerations

   Underlay information may reveal details about network architecture,
   capacity, and routing that could be exploited for reconnaissance or
   targeted attacks.  Operators SHOULD carefully consider which underlay
   information to expose through UIO extensions.

4.3.  Message Size and Amplification

   Including UIO extensions increases ICMP message size.
   Implementations MUST enforce the message size limits specified in
   Section 3.2 to prevent fragmentation issues and potential
   amplification attacks.

4.4.  Spoofing and Forgery

   As with all ICMP messages, UIO extensions are subject to spoofing
   attacks.  The authenticity and integrity of UIO information cannot be
   guaranteed without additional security mechanisms.  Implementations
   and operators SHOULD NOT use UIO information for security-critical
   decisions.

4.5.  Intended Use

   The extensions defined in this document are intended exclusively for
   administrative debugging and troubleshooting purposes.  They provide
   diagnostic information in ICMP responses and are not designed for use
   in production protocols, automation systems, or non-debugging
   applications.

4.6.  Rate Limiting

   Implementations SHOULD apply rate limiting to the generation of ICMP
   messages containing UIO extensions to prevent resource exhaustion and
   potential denial-of-service conditions.









Rajamanickam, et al.     Expires 28 August 2026                [Page 10]

Internet-Draft        ICMP Underlay Info Extension         February 2026


4.7.  Content Filtering and Sanitization

   The UIO mechanism crosses administrative domain boundaries between
   overlay and underlay networks.  This "crossing of streams" creates
   potential security and operational risks if content is not carefully
   filtered.

4.7.1.  Information Disclosure Risks

   Including inappropriate ICMP message types or extension objects in
   UIO could disclose:

   *  Underlay network topology beyond what is necessary for
      troubleshooting

   *  Underlay routing information (e.g., via redirect messages)

   *  Underlay control plane state (e.g., via router discovery)

   *  Proprietary or sensitive configuration details

   The content restrictions in Section 3.3 are designed to limit
   information disclosure to what is necessary for diagnosing forwarding
   failures.  Implementations MUST enforce these restrictions as
   security boundaries.

   Operators SHOULD NOT enable UIO for destinations outside their
   administrative control without careful consideration of what
   information will be disclosed.

4.7.2.  Amplification and Abuse Risks

   Without content and rate restrictions, UIO could be abused for:

   *  Amplification attacks (small query triggers large UIO response)

   *  Reconnaissance of underlay infrastructure

   *  Resource exhaustion at underlay head-end nodes

   *  Information gathering about overlay-underlay relationships

   The following mechanisms mitigate these risks:

   *  Size limits (Section 3.3.3) prevent excessive amplification

   *  Content restrictions (Section 3.3.1, Section 3.3.2) limit
      reconnaissance value



Rajamanickam, et al.     Expires 28 August 2026                [Page 11]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   *  Loop prevention (Section 3.3.4) prevents recursive amplification

   *  Rate limiting (Section 4.6) prevents resource exhaustion

   Implementations MUST enforce these protections and MUST NOT provide
   configuration options that bypass them (e.g., removing size limits or
   allowing nested UIO).

4.8.  Operational Security

   Network operators deploying UIO should:

   *  Start with UIO disabled and enable only for specific, authorized
      overlay destinations

   *  Monitor UIO generation rates and investigate anomalies

   *  Regularly review what information is being disclosed via UIO

   *  Coordinate with overlay operators to understand their diagnostic
      needs and security requirements

   *  Document the security implications of UIO in their deployment
      (e.g., what underlay information is visible to overlay operators)

   In multi-tenant environments, operators should carefully consider
   whether underlay diagnostic information should be visible to all
   tenants or restricted based on tenant relationships and SLAs.

5.  IANA Considerations

5.1.  ICMP Extension Object Class

   IANA is requested to assign a new value from the "ICMP Extension
   Object Classes and Class Sub-types" registry
   (https://www.iana.org/assignments/icmp-parameters/) for the Underlay
   Information Object (UIO) as follows:

        +=============+=============================+============+
        | Class Value | Class Name                  | Reference  |
        +=============+=============================+============+
        | TBA         | Underlay Information Object | [This RFC] |
        +-------------+-----------------------------+------------+

                                 Table 1






Rajamanickam, et al.     Expires 28 August 2026                [Page 12]

Internet-Draft        ICMP Underlay Info Extension         February 2026


5.2.  C-Type Values

   IANA is requested to establish a new sub-registry titled "Underlay
   Information Object C-Types" under the "ICMP Extension Object Classes
   and Class Sub-types" registry.

   Initial values for this registry are as follows:

           +==============+======================+============+
           | C-Type Value | Description          | Reference  |
           +==============+======================+============+
           | 0            | Reserved/Unspecified | [This RFC] |
           +--------------+----------------------+------------+
           | 1-246        | Unassigned           |            |
           +--------------+----------------------+------------+
           | 247-255      | Reserved for Private | [This RFC] |
           |              | or Experimental Use  |            |
           +--------------+----------------------+------------+

                                 Table 2

   The registration procedure for values 1-246 is Standards Action or
   IESG Approval as defined in [RFC8126].

6.  Operational Considerations

6.1.  Configuration

   Operators SHOULD carefully configure which overlay endpoints or
   networks are authorized to receive UIO information.  To effectively
   manage the security and operational aspects of UIO, implementations
   SHOULD provide configuration options, including but not limited to:

   *  Enable/disable UIO generation (default: disabled)

   *  Whitelist of authorized overlay prefixes

   *  Maximum UIO object payload size

   *  Rate limiting parameters

6.2.  Troubleshooting Workflow

   The intended use case for UIO is as follows:

   1.  An overlay operator performs traceroute from an overlay endpoint.

   2.  The traceroute reveals a failure point in the path.



Rajamanickam, et al.     Expires 28 August 2026                [Page 13]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   3.  ICMP error messages include UIO extensions with underlay details.

   4.  The overlay operator uses this information to coordinate with the
       underlay operator for problem resolution.

6.3.  Multi-Vendor Interoperability

   Implementations SHOULD be tested for interoperability, particularly
   when overlay and underlay equipment are from different vendors.

7.  References

7.1.  Normative References

   [RFC792]   Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [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>.

   [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>.

   [RFC4950]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
              Extensions for Multiprotocol Label Switching", RFC 4950,
              DOI 10.17487/RFC4950, August 2007,
              <https://www.rfc-editor.org/info/rfc4950>.

   [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>.

   [RFC5837]  Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen,
              N., and JR. Rivers, "Extending ICMP for Interface and
              Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837,
              April 2010, <https://www.rfc-editor.org/info/rfc5837>.




Rajamanickam, et al.     Expires 28 August 2026                [Page 14]

Internet-Draft        ICMP Underlay Info Extension         February 2026


   [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>.

   [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>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [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>.

   [RFC8883]  Herbert, T., "ICMPv6 Errors for Discarding Packets Due to
              Processing Limits", RFC 8883, DOI 10.17487/RFC8883,
              September 2020, <https://www.rfc-editor.org/info/rfc8883>.

7.2.  Informative References

   [I-D.ietf-intarea-extended-icmp-nodeid]
              Bonica, R., Thomas, R., Linkova, J., Lenart, C., and M.
              Boucadair, "Extending ICMP for Node Identification", Work
              in Progress, Internet-Draft, draft-ietf-intarea-extended-
              icmp-nodeid, 2024, <https://datatracker.ietf.org/doc/
              draft-ietf-intarea-extended-icmp-nodeid/>.

   [IANA.address-family-numbers]
              IANA, "Address Family Numbers",
              <http://www.iana.org/assignments/address-family-numbers>.

Appendix A.  Appendix

A.1.  UIO ICMP Extension Message Examples

   This section lists examples of UIO encoding.

A.1.1.  UIO carrying IPv6 information to the IPv4 source

   In this example, a host receives an IPv4 ICMPv4 Time Exceeded error
   message in response to an ICMP Echo Request as part of the traceroute
   application.  It also contains a UIO ICMP extension object with IPv6
   interface address information as follows.



Rajamanickam, et al.     Expires 28 August 2026                [Page 15]

Internet-Draft        ICMP Underlay Info Extension         February 2026


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                       IPv4 Header                             ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type=11    |    Code=0     |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Unused     |  Length=32    |            Unused             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                 Part of Original Datagram (128 bytes)         ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ver=2 |         Unused         |         Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length=28           | Class-Num=TBA |   C-Type=0    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length=24           | Class-Num=2   |   C-Type=4    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI=2               |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                 IPv6 Address (Original Error Device)          ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: ICMPv4 packet carrying UIO ICMP extension

   The traceroute application displays the IPv6 Address in the UIO to
   allow an administrator to trace the underlay path of the route being
   traced.

A.1.2.  UIO carrying IPv4 information to the IPv6 source

   In this example, a host receives an IPv6 ICMPv6 Time Exceeded error
   message in response to an ICMP Echo Request as part of the traceroute
   application.  It contains a UIO ICMP extension object with IPv4
   interface address information as follows.











Rajamanickam, et al.     Expires 28 August 2026                [Page 16]

Internet-Draft        ICMP Underlay Info Extension         February 2026


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                       IPv6 Header                             ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type=3     |    Code=0     |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length=32    |                    Unused                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   ~                 Part of Original Datagram (128 bytes)         ~
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ver=2 |         Unused         |         Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length=16           | Class-Num=TBA |   C-Type=0    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Length=12           | Class-Num=2   |   C-Type=4    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           AFI=1               |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 IPv4 Address (Original Error Device)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 3: UIO carrying IPv4 information to the IPv6 source

   The traceroute application displays the IPv4 Address in the UIO to
   allow an administrator to trace the underlay path of the route being
   traced.

Acknowledgments

   The authors thank the contributors listed below for their substantial
   input and review.

Contributors

   The following individuals contributed to this document:

   Tamilselvan Murugan
   Cisco Systems, Inc.
   Email: tammurug@cisco.com


   Dhilip Sekar
   Email: dhilipsekar1998@gmail.com



Rajamanickam, et al.     Expires 28 August 2026                [Page 17]

Internet-Draft        ICMP Underlay Info Extension         February 2026


Authors' Addresses

   Jaganbabu Rajamanickam (editor)
   Cisco Systems, Inc.
   Canada
   Email: jrajaman@cisco.com


   Darren Dukes
   Cisco Systems, Inc.
   Canada
   Email: ddukes@cisco.com


   Madhan Sankaranarayanan (editor)
   Cisco Systems, Inc.
   India
   Email: madsanka@cisco.com


   Ron Bonica
   HPE
   United States of America
   Email: ronald.bonica@hpe.com



























Rajamanickam, et al.     Expires 28 August 2026                [Page 18]
