



Internet Area Working Group                                  J. Mitchell
Internet-Draft                                                Google LLC
Obsoletes: 5837 (if approved)                                 March 2026
Intended status: Standards Track                                        
Expires: 19 September 2026


        Extending ICMP for Interface and Next-Hop Identification
                  draft-mitchell-intarea-rfc5837bis-00

Abstract

   This memo defines a data structure that can be appended to selected
   ICMP messages.  The ICMP extension defined herein can be used to
   identify any combination of the following: the IP interface upon
   which a datagram arrived, the sub-IP component of an IP interface
   upon which a datagram arrived, the IP interface through which the
   datagram would have been forwarded had it been forwardable, the sub-
   IP component of an IP interface through which the datagram would have
   been forwarded had it been forwardable, and the IP next hop to which
   the datagram would have been forwarded.  This document obsoletes RFC
   5837.

   Devices can use this ICMP extension to identify interfaces and their
   components by any combination of the following: ifIndex, IPv4
   address, IPv6 address, name, and MTU.  ICMP-aware devices can use
   these extensions to identify both numbered and unnumbered interfaces.

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 2 September 2026.







Mitchell                Expires 19 September 2026               [Page 1]

Internet-Draft              ICMP Interface ID                 March 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
   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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Application to Traceroute . . . . . . . . . . . . . . . .   5
     3.2.  Policy and MTU Detection  . . . . . . . . . . . . . . . .   6
   4.  Interface Information Object  . . . . . . . . . . . . . . . .   6
     4.1.  C-Type Meaning in an Interface Information Object . . . .   8
     4.2.  Interface IP Address Sub-Object . . . . . . . . . . . . .   9
     4.3.  Interface Name Sub-Object . . . . . . . . . . . . . . . .  10
     4.4.  Interface Information Object Examples . . . . . . . . . .  10
     4.5.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Network Address Translation Considerations  . . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Appendix A.  Changes from RFC 5837  . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   IP devices use the Internet Control Message Protocol (ICMPv4
   [RFC0792] and ICMPv6 [RFC4443]) to convey control information.  In
   particular, when an IP device receives a datagram that it cannot
   process, it may send an ICMP message to the datagram's originator.
   Network operators and higher-level protocols use these ICMP messages
   to detect and diagnose network issues.






Mitchell                Expires 19 September 2026               [Page 2]

Internet-Draft              ICMP Interface ID                 March 2026


   In the simplest case, the source address of the ICMP message
   identifies the interface upon which the datagram arrived.  However,
   in many cases, the incoming interface is not identified by the ICMP
   message at all.  Details follow:

   According to [RFC1812], when a router generates an ICMPv4 message,
   the source address of that message MUST be one of the following:

   *  one of the IP addresses associated with the physical interface
      over which the ICMPv4 message is transmitted

   *  if that interface has no IP addresses associated with it, the
      device's router-id or host-id is used instead

   If all of the following conditions are true, the source address of
   the ICMPv4 message identifies the interface upon which the original
   datagram arrived:

   *  the device sends an ICMPv4 message through the same interface upon
      which the original datagram was received

   *  that interface is numbered

   However, the incoming and outgoing interfaces may be different due to
   an asymmetric return path, which can occur due to asymmetric link
   costs, parallel links, or Equal Cost Multipath (ECMP).

   Similarly, [RFC1122] provides guidance for source address selection
   for multihomed IPv4 hosts.  These recommendations, like those stated
   above, do not always cause the source address of an ICMPv4 message to
   identify the incoming interface.

   ICMPv6 is somewhat more flexible.  [RFC4443] states that for
   responses to messages sent to a non-local interface, the source
   address must be chosen as follows:

   *  the Source Address of the ICMPv6 packet MUST be a unicast address
      belonging to the node.  The address SHOULD be chosen according to
      the rules that would be used to select the source address for any
      other packet originated by the node, given the destination address
      of the packet.  However, it MAY be selected in an alternative way
      if this would lead to a more informative choice of address
      reachable from the destination of the ICMPv6 packet.

   When a datagram that cannot be processed arrives on an unnumbered
   interface, neither ICMPv4 nor ICMPv6 is currently capable of
   identifying the incoming interface.  Even when an ICMP message is
   generated such that the ICMP source address identifies the incoming



Mitchell                Expires 19 September 2026               [Page 3]

Internet-Draft              ICMP Interface ID                 March 2026


   interface, the receiver of that ICMP message has no way of knowing if
   this is the case.  ICMP extensions are required to explicitly
   identify the incoming interface.

   Using the extension defined herein, a device can explicitly identify
   the incoming IP interface or its sub-IP components by any combination
   of the following:

   *  ifIndex

   *  IPv4 address

   *  IPv6 address

   *  name

   *  MTU

   The interface name SHOULD be identical to the first 63 octets of the
   ifName, as defined in [RFC2863].  The ifIndex is also defined in
   [RFC2863].

   Using the same extension, an IP device can explicitly identify by the
   above the outgoing interface over which a datagram would have been
   forwarded if that datagram had been deliverable.

   The next-hop IP address, to which the datagram would have been
   forwarded, can also be identified using this same extension.  This
   information can be used for creating a downstream map.  The next-hop
   information may not always be available.  There are corner-cases
   where it doesn't exist and there may be implementations where it is
   not practical to provide this information.  This specification
   provides an encoding for providing the next-hop IP address when it is
   available.

   The extension defined herein uses the ICMP multi-part message
   framework defined in [RFC4884].  The same backward compatibility
   issues that apply to [RFC4884] apply to this extension.

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





Mitchell                Expires 19 September 2026               [Page 4]

Internet-Draft              ICMP Interface ID                 March 2026


3.  Applications

3.1.  Application to Traceroute

   ICMP extensions defined in this memo provide additional capability to
   traceroute.  An enhanced traceroute application, like older
   implementations, identifies nodes that a datagram visited en route to
   its destination.  It differs from older implementations in that it
   can explicitly identify the following at each node:

   *  the IP interface upon which a datagram arrived

   *  the sub-IP component of an IP interface upon which a datagram
      arrived

   *  the IP interface through which the datagram would have been
      forwarded had it been forwardable

   *  the sub-IP component of an IP interface through which the datagram
      would have been forwarded had it been forwardable

   *  the IP next hop to which the datagram would have been forwarded

   Enhanced traceroute applications can identify the above listed
   entities by:

   *  ifIndex

   *  IPv4 address

   *  IPv6 address

   *  name

   *  MTU

   The ifIndex can be utilized within a management domain to map to an
   actual interface, but it is also valuable in public applications.
   The ifIndex can be used as an opaque token to discern whether or not
   two ICMP messages generated from the same router involve the same
   interface.










Mitchell                Expires 19 September 2026               [Page 5]

Internet-Draft              ICMP Interface ID                 March 2026


3.2.  Policy and MTU Detection

   A general application would be to identify which outgoing interface
   triggered a given function for the original packet.  For example, if
   an access control list (ACL) drops the packet and Dest Unreachable/
   Admin Prohibited denies the packet, being able to identify the
   outgoing interface might be useful.  Another example would be to
   support Path MTU Discovery (PMTUD), since this would allow
   identification of which outgoing interface can't support a given MTU
   size.  For example, knowledge of the problematic interface would
   allow an informed request for reconfiguration of the MTU of that
   interface.

4.  Interface Information Object

   This section defines the Interface Information Object, an ICMP
   extension object with a Class-Num (Object Class Value) of 2 that can
   be appended to the following messages:

   *  ICMPv4 Time Exceeded

   *  ICMPv4 Destination Unreachable

   *  ICMPv4 Parameter Problem

   *  ICMPv6 Time Exceeded

   *  ICMPv6 Destination Unreachable

   For reasons described in [RFC4884], this extension cannot be appended
   to any of the currently defined ICMPv4 or ICMPv6 messages other than
   those listed above.

   The extension defined herein MAY be appended to any of the above
   listed messages and SHOULD be appended whenever required to identify
   an unnumbered interface and when local policy or security
   considerations do not supersede this requirement.

   A single ICMP message can contain as few as zero and as many as four
   instances of the Interface Information Object.  It is illegal if it
   contains more than four instances, because that means that an
   interface role is used more than once (see Section 4.5).

   A single instance of the Interface Information Object can provide
   information regarding any one of the following interface roles:

   *  the IP interface upon which a datagram arrived




Mitchell                Expires 19 September 2026               [Page 6]

Internet-Draft              ICMP Interface ID                 March 2026


   *  the sub-IP component of an IP interface upon which a datagram
      arrived

   *  the IP interface through which the datagram would have been
      forwarded had it been forwardable

   *  the sub-IP component of an IP interface through which the datagram
      would have been forwarded had it been forwardable

   *  the IP next hop to which the datagram would have been forwarded

   The following are examples of sub-IP components of IP interfaces upon
   which a datagram might arrive:

   *  Ethernet Link Aggregation Group Member

   *  Multilink PPP bundle member

   *  Multilink frame relay bundle member

   To minimize the number of octets required for this extension, there
   are four different pieces of information that can appear in an
   Interface Information Object.

   1.  The ifIndex of the interface of interest MAY be included.  This
       is the 32-bit ifIndex assigned to the interface by the device as
       specified by the Interfaces Group MIB [RFC2863].

   2.  An IP Address Sub-Object MAY be included if either of the
       following conditions is true: a) the eliciting datagram is IPv4
       and the identified interface has at least one IPv4 address
       associated with it, or b) the eliciting datagram is IPv6 and the
       identified interface has at least one IPv6 address associated
       with it.  The IP Address Sub-Object is described in Section 4.2
       of this memo.

   3.  An Interface Name Sub-Object, containing a string of no more than
       63 octets, MAY be included.  That string, as specified in
       Section 4.3, is the interface name and SHOULD be the MIB-II
       ifName [RFC2863], but MAY be some other human-meaningful name of
       the interface.

   4.  A 32-bit unsigned integer reflecting the MTU MAY be included.








Mitchell                Expires 19 September 2026               [Page 7]

Internet-Draft              ICMP Interface ID                 March 2026


4.1.  C-Type Meaning in an Interface Information Object

   For this object, the C-Type [RFC4884] is used to indicate both the
   role of the interface and the information that is included.  This is
   illustrated in Figure 1.

   Bit     0       1       2       3       4       5       6       7
       +-------+-------+-------+-------+-------+-------+-------+-------+
       |     Interface Role    | Rsvd1 |ifIndex| IPAddr|  name |  MTU  |
       +-------+-------+-------+-------+-------+-------+-------+-------+

           Figure 1: C-Type for the Interface Information Object

   The following are bit-field definitions for C-Type:

   Interface Role (bits 0-2):  These bits indicate the role of the
      interface being identified.  The enumerated values are given
      below:

      Value 0:  This object describes the IP interface upon which a
         datagram arrived

      Value 2:  This object describes the sub-IP component of an IP
         interface upon which a datagram arrived

      Value 4:  This object describes the IP interface through which the
         datagram would have been forwarded had it been forwardable

      Value 5:  This object describes the sub-IP component of an IP
         interface through which the datagram would have been forwarded
         had it been forwardable

      Value 6:  This object describes the IP next hop to which the
         datagram would have been forwarded

   Reserved 1 (bit 3):  This bit is reserved for future use and MUST be
      set to 0 and MUST be ignored on receipt.

   ifIndex (bit 4):  When set, the 32-bit ifIndex of the interface is
      included.  When clear, the ifIndex is not included.

   IP Addr (bit 5):  When set, an IP Address Sub-Object is present.
      When clear, an IP Address Sub-Object is not present.  The IP
      Address Sub-Object is described in Section 4.2 of this memo.

   Interface Name (bit 6):  When set, an Interface Name Sub-Object is
      included.  When clear, it is not included.  The Name Sub-Object is
      described in Section 4.3 of this memo.



Mitchell                Expires 19 September 2026               [Page 8]

Internet-Draft              ICMP Interface ID                 March 2026


   MTU (bit 7):  When set, a 32-bit integer representing the MTU is
      present.  When clear, this 32-bit integer is not present.

   The information included does not self-identify, so this
   specification defines a specific ordering for sending the information
   that must be followed.

   If bit 4 (ifIndex) is set, then the 32-bit ifIndex MUST be sent
   first.  If bit 5 (IP Address) is set, an IP Address Sub-Object MUST
   be sent next.  If bit 6 (Name) is set, an Interface Name Sub-Object
   MUST be sent next.  If bit 7 is set, an MTU MUST be sent next.  The
   information order is thus: ifIndex, IP Address Sub-Object, Interface
   Name Sub-Object, and MTU.  Any or all pieces of information may be
   present or absent, as indicated by the C-Type.  Any data that follows
   these optional pieces of information MUST be ignored.

   It is valid (though pointless until additional bits are assigned by
   IANA) to receive an Interface Information Object where bits 4, 5, 6,
   and 7 are all 0; this MUST NOT generate a warning or error.

4.2.  Interface IP Address Sub-Object

   Figure 2 depicts the Interface Address Sub-Object:

    0                            31
   +-------+-------+-------+-------+
   |      AFI      |    Reserved   |
   +-------+-------+-------+-------+
   |         IP Address   ....

                   Figure 2: Interface Address Sub-Object

   The IP Address Sub-Object contains the following fields:

   *  Address Family Identifier (AFI): This 16-bit bit field identifies
      the type of address represented by the IP Address field.  It also
      determines the length of that field and the length of the entire
      sub-object.  Values for this field represent a subset of values
      found in the IANA registry of Address Family Numbers (available
      from http://www.iana.org).  Valid values are 1 (representing a
      32-bit IPv4 address) and 2 (representing a 128-bit IPv6 address).

   *  Reserved: This 16-bit field MUST be set to zero and ignored upon
      receipt.

   *  IP Address: This variable-length field represents an IP address
      associated with the identified interface.




Mitchell                Expires 19 September 2026               [Page 9]

Internet-Draft              ICMP Interface ID                 March 2026


   If the eliciting datagram was IPv4, the IP Interface Sub-Object MUST
   represent an IPv4 address.  Likewise, if the eliciting datagram was
   IPv6, the IP Interface Sub-Object MUST represent an IPv6 address.

4.3.  Interface Name Sub-Object

   Figure 3 depicts the Interface Name Sub-Object:

   octet    0        1                                   63
        +--------+-----------................-----------------+
        | length |   interface name octets 1-63               |
        +--------+-----------................-----------------+

                    Figure 3: Interface Name Sub-Object

   The Interface Name Sub-Object MUST have a length that is a multiple
   of 4 octets and MUST NOT exceed 64 octets.

   The Length field represents the length of the Interface Name Sub-
   Object, including the length and the interface name in octets.  The
   maximum valid length is 64 octets.  The length is constrained to
   ensure there is space for the start of the original packet and
   additional information.

   The second field contains the human-readable interface name.  The
   interface name SHOULD be the full MIB-II ifName [RFC2863], if less
   than 64 octets, or the first 63 octets of the ifName, if the ifName
   is longer.  The interface name MAY be some other human-meaningful
   name of the interface.  It is useful to provide the ifName for cross-
   correlation with other MIB information and for human-reader
   familiarity.  The interface name MUST be padded with ASCII NULL
   characters if the object would not otherwise terminate on a 4-octet
   boundary.

   The interface name MUST be represented in the UTF-8 charset [RFC3629]
   using the Default Language [RFC2277].

4.4.  Interface Information Object Examples

   Figure 4 shows a full ICMPv4 Time Exceeded message, including the
   Interface Information Object, which MUST be preceded by an ICMP
   Extension Structure Header and an ICMP Object Header.  Both are
   defined in [RFC4884].

   Although examples show an Interface Name Sub-Object of length 64,
   this is only for illustration and depicts the maximum allowable
   length.




Mitchell                Expires 19 September 2026              [Page 10]

Internet-Draft              ICMP Interface ID                 March 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     unused    |    Length     |          unused               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Internet Header + leading octets of original datagram    |
    |                                                               |
    |                           //                                  |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Ver=2 |      (Reserved)       |           Checksum            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             Length            |Class-Num=2 | C-Type=00001010b |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Interface ifIndex                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Interface Name Sub-Object, 32-bit word 1       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                                                             ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Interface Name Sub-Object, 32-bit word 16      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 4: ICMPv4 Time Exceeded Message with Interface Information
                                   Object

   Figure 5 depicts an Interface Information Object representing an
   incoming interface identified by ifIndex and Name.

         Class-Num = 2
         C-Type = 00001010b   // Indicates incoming interface
         Length = 72 (4 + 4 + 64)

            0              1              2              3
    +--------------+--------------+--------------+--------------+
    |                    Interface ifIndex                      |
    +--------------+--------------+--------------+--------------+
    |    Length    |      Name, word 1                          |
    +--------------+--------------+--------------+--------------+
   ...                                                         ...
    +--------------+--------------+--------------+--------------+
    |                     Name, word 16                         |
    +--------------+--------------+--------------+--------------+

             Figure 5: Incoming Interface: By ifIndex and Name




Mitchell                Expires 19 September 2026              [Page 11]

Internet-Draft              ICMP Interface ID                 March 2026


   Figure 6 depicts an Interface Information Object representing an
   incoming interface identified by ifIndex, IPv4 Address, and Name.

         Class-Num = 2
         C-Type = 00001110b   // Indicates incoming interface
         Length = 80 (4 + 4 + 8 + 64)

            0              1              2              3
    +--------------+--------------+--------------+--------------+
    |                    Interface ifIndex                      |
    +--------------+--------------+--------------+--------------+
    |             AFI             |          Reserved           |
    +--------------+--------------+--------------+--------------+
    |                    IPv4 address                           |
    +--------------+--------------+--------------+--------------+
    |    Length    |      Name, word 1                          |
    +--------------+--------------+--------------+--------------+
   ...                                                         ...
    +--------------+--------------+--------------+--------------+
    |                     Name, word 16                         |
    +--------------+--------------+--------------+--------------+

      Figure 6: Incoming Interface: by ifIndex, IPv4 Address, and Name

   Figure 7 depicts an Interface Information Object representing an
   incoming interface identified by ifIndex and IPv6 Address.

       Class-Num = 2
       C-Type = 00001100b   // Indicates incoming interface
       Length = 28 (4 + 4 + 20)

          0              1              2              3
   +--------------+--------------+--------------+--------------+
   |                    Interface ifIndex                      |
   +--------------+--------------+--------------+--------------+
   |             AFI             |          Reserved           |
   +--------------+--------------+--------------+--------------+
   |                    IPv6 address, 32-bit word 1            |
   +--------------+--------------+--------------+--------------+
   |                    IPv6 address, 32-bit word 2            |
   +--------------+--------------+--------------+--------------+
   |                    IPv6 address, 32-bit word 3            |
   +--------------+--------------+--------------+--------------+
   |                    IPv6 address, 32-bit word 4            |
   +--------------+--------------+--------------+--------------+

         Figure 7: Incoming Interface: By ifIndex and IPv6 Address




Mitchell                Expires 19 September 2026              [Page 12]

Internet-Draft              ICMP Interface ID                 March 2026


   Figure 8 depicts an Interface Information Object representing an
   outgoing interface identified by ifIndex and Name.

       Class-Num = 2
       C-Type = 10001010b   // Indicates outgoing interface
       Length = 72 (4 + 4 + 64)

            0              1              2              3
    +--------------+--------------+--------------+--------------+
    |                    Interface ifIndex                      |
    +--------------+--------------+--------------+--------------+
    |    Length    |      Name, word 1                          |
    +--------------+--------------+--------------+--------------+
   ...                                                         ...
    +--------------+--------------+--------------+--------------+
    |                     Name, word 16                         |
    +--------------+--------------+--------------+--------------+

             Figure 8: Outgoing Interface: By ifIndex and Name

4.5.  Usage

   Multiple Interface Information Objects MAY be included within a
   single ICMP message, provided that each Interface Information Object
   specifies a unique role.  A single ICMP message MUST NOT contain two
   Interface Information Objects that specify the same role.  For this
   reason, if sending an ICMP message with both an Outgoing IP Interface
   and Outgoing Sub-IP Component of an interface, to support backward
   compatibility with legacy receivers that only support [RFC5837],
   implementations SHOULD only send the Outgoing Sub-IP Component of an
   IP Interface.

   ifIndex, MTU, and name information MAY be included whenever it is
   available; more than one instance of each of these three information
   elements MUST NOT be included per Interface Information Object.

   A single instance of IP Address information MAY be included in an
   Interface Information Object under the following circumstances:

   *  if the eliciting datagram is IPv4 and an IPv4 address is
      associated with the identified interface.  In this case, if an IP
      Address Sub-Object is included, it MUST specify an IPv4 address.

   *  if the eliciting datagram is IPv6 and an IPv6 address is
      associated with the identified interface.  In this case, if an IP
      Address Sub-Object is included, it MUST specify an IPv6 address.





Mitchell                Expires 19 September 2026              [Page 13]

Internet-Draft              ICMP Interface ID                 March 2026


   In all other circumstances, IP address information MUST NOT be
   included.

   An ICMP message that does not conform to these rules and contains
   multiple instances of the same information is considered illegal;
   specifically, an ICMP message containing more than one Interface
   Information Object with the same role, as well as an ICMP message
   containing a duplicate information element in a given role are
   considered illegal.  If such an illegal ICMP message is received, it
   MUST be silently discarded.

5.  Network Address Translation Considerations

   [RFC5508] encourages Traditional IP Network Address Translators
   (Traditional NATs; see [RFC3022]) to support ICMP extension objects.
   This document defines an ICMP extension that includes IP addresses
   and therefore contains realm-specific information, and consequently
   describes possible NAT behaviors in the presence of these extensions.

   NAT devices MUST NOT translate or overwrite the ICMP extensions
   described herein.  That is, they MUST either remove the extension
   entirely or pass it unchanged.

   It is conceivable that a NAT device might translate an ICMP header
   without translating the extension defined herein.  In this case, the
   ICMP message might contain two instances of the same address, one
   translated and the other untranslated.  Therefore, application
   developers should not assume addresses in the extension are of the
   same realm as the addresses in the datagram's header.

   It also is conceivable that a NAT device might translate an ICMPv4
   message into ICMPv6 or vice versa.  If that were to occur,
   applications might receive ICMPv6 messages that contain IP Address
   Sub-Objects that specify IPv4 addresses.  Likewise, applications
   might receive ICMPv4 messages that contain IP Address Sub-Objects
   that specify IPv6 addresses.

6.  Security Considerations

   This extension can provide the user of traceroute with additional
   network information that is not currently available.  Implementations
   SHOULD provide configuration switches that suppress the generation of
   this extension based upon role (i.e., incoming interface, outgoing
   interface, sub-IP data).  Implementations SHOULD also provide
   configuration switches that conceal various types of information
   (e.g., ifIndex, interface name).





Mitchell                Expires 19 September 2026              [Page 14]

Internet-Draft              ICMP Interface ID                 March 2026


   It may be desirable to provide this information to a particular
   network's operators and not to others.  If such policy controls are
   desirable, then an implementation could determine what sub-objects to
   include based upon the destination IP address of the ICMP message
   that will contain the sub-objects.  The implementation of policy
   controls could also be based upon the mechanisms described in
   [TRACEROUTE-EXT] for those limited cases supported.

   For instance, the IP address may be included for all potential
   recipients.  The ifIndex and interface name could be included as well
   if the destination IP address is a management address of the network
   that has administrative control of the router.

   Another example use case would be where the detailed information in
   these extensions may be provided to ICMP destinations within the
   local administrative domain, but only traditional information is
   provided to 'external' or untrusted ICMP destinations.

   The intended field of use for the extensions defined in this document
   is administrative debugging and troubleshooting.  The extensions
   herein defined supply additional information in ICMP responses.
   These mechanisms are not intended to be used in non-debugging
   applications.

   This document does not specify an authentication mechanism for the
   extension that it defines.  Application developers should be aware
   that ICMP messages and their contents are easily spoofed.

7.  IANA Considerations

   IANA has reserved 2 for the Interface Information Object from the
   ICMP Extension Object Classes registry available from
   http://www.iana.org.

   From the Interface Information Object's C-Type, IANA has reserved
   values as follows:

   *  Bit 0-2: Interface Role field

   *  Bit 3: Unallocated - allocatable with Standards Action

   *  Bit 4: ifIndex included

   *  Bit 5: IP Address Sub-Object included

   *  Bit 6: Name Sub-Object included

   *  Bit 7: MTU included



Mitchell                Expires 19 September 2026              [Page 15]

Internet-Draft              ICMP Interface ID                 March 2026


   IANA has reserved the following values for Interface Role:

   *  Value 0: Incoming IP Interface

   *  Value 2: Sub-IP Component of Incoming IP Interface

   *  Value 4: Outgoing IP Interface

   *  Value 5: Sub-IP Component of Outgoing IP Interface

   *  Value 6: IP Next Hop

8.  Acknowledgments

   This document is an update of [RFC5837], and only minimally changes
   its text to support the additional use case.  Thanks are therefore
   due to that document's authors: Alia K.  Atlas, Ronald P.  Bonica,
   Carlos Pignataro, Naiming Shen, and JR.  Rivers.  Additionally, the
   authors wish to thank Nachikethas Jagadeesan and Fabricio Pimenta de
   Avila for noticing the outgoing sub-IP component omission and initial
   thoughts on the approach.

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

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
              <https://www.rfc-editor.org/info/rfc2863>.

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

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

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



Mitchell                Expires 19 September 2026              [Page 16]

Internet-Draft              ICMP Interface ID                 March 2026


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

9.2.  Informative References

   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
              RFC 1812, DOI 10.17487/RFC1812, June 1995,
              <https://www.rfc-editor.org/info/rfc1812>.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
              Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
              January 1998, <https://www.rfc-editor.org/info/rfc2277>.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              DOI 10.17487/RFC3022, January 2001,
              <https://www.rfc-editor.org/info/rfc3022>.

   [RFC5508]  Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
              Behavioral Requirements for ICMP", BCP 148, RFC 5508,
              DOI 10.17487/RFC5508, April 2009,
              <https://www.rfc-editor.org/info/rfc5508>.

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

   [TRACEROUTE-EXT]
              Shen, N., Pignataro, C., Asati, R., and E. Chen, "UDP
              Traceroute Message Extension", Work in Progress, Internet-
              Draft, draft-shen-udp-traceroute-ext-01, October 2008,
              <https://datatracker.ietf.org/doc/html/draft-shen-udp-
              traceroute-ext-01>.






Mitchell                Expires 19 September 2026              [Page 17]

Internet-Draft              ICMP Interface ID                 March 2026


Appendix A.  Changes from RFC 5837

   This document obsoletes RFC 5837.  The following technical changes
   and clarifications have been made:

   Interface Role Field Expansion
      The Interface Role field has been expanded from 2 bits to 3 bits
      by utilizing one previously reserved bit.  This change provides
      additional space for future role definitions while maintaining the
      existing structure of the C-Type bit-mask.

   Role Value Renumbering
      Due to the expansion of the Interface Role field, the decimal
      representations of the roles have been updated.  These new values
      reflect the 3-bit field width but remain bit-aligned with the
      original definitions to ensure consistency with the underlying
      binary structure.

   Outgoing Sub-IP Component
      Support has been added for the "Outgoing Sub-IP Component" role.
      This allows for the identification of specific sub-interface
      components (e.g., VLANs or virtual circuits) through which a
      datagram would have been forwarded.

   Multiple Interface Roles Guidance
      New guidance and restrictions have been added regarding the
      transmission of multiple interface roles within a single object.
      While an object may describe multiple roles, specific rules are
      now provided to govern these combinations for better
      interoperability.

   Sub-IP Backward Compatibility
      This document introduces a requirement that if both an Outgoing IP
      Interface and its corresponding Sub-IP Component are known,
      implementations SHOULD only send the "Outgoing Sub-IP Component."
      This ensures that legacy RFC 5837 receivers can correctly
      interpret the most specific information available.

   Updated Requirements Language
      The document's requirements language has been updated to comply
      with current IETF standards, referencing BCP 14 (RFC 2119 and RFC
      8174).

Author's Address







Mitchell                Expires 19 September 2026              [Page 18]

Internet-Draft              ICMP Interface ID                 March 2026


   Jon Mitchell
   Google LLC
   1600 Amphitheatre Parkway
   Mountain View, California 94043
   United States of America
   Email: jrmitche@puck.nether.net













































Mitchell                Expires 19 September 2026              [Page 19]
