Extending ICMP for Interface and Next-Hop Identification
Extracted elements (30)
Next-hop IP address information is provided on a best-effort basis because there are corner cases where it does not exist and implementations where it is not practical to supply it. The specification encodes it when available rather than requiring it.
The C-Type field was overloaded to encode both the interface role and the set of included information elements, rather than using separate fields, in order to minimize the number of octets required for the extension.
The extension cannot be appended to ICMP message types beyond the three listed (Time Exceeded, Destination Unreachable, Parameter Problem) due to constraints in the RFC 4884 multi-part message framework, which requires a length field in a specific position not present in other ICMP types.
The ifIndex is included as an opaque token useful even in public traceroute applications: even without mapping it to an interface name, a receiver can use identical ifIndex values across multiple ICMP messages from the same router to determine whether the same interface was involved.
A NAT device may translate the ICMP header without translating the extension, resulting in a message containing both a translated address in the ICMP header and an untranslated address in the extension. Applications MUST NOT assume extension addresses are in the same realm as datagram header addresses.
If a NAT device performs ICMPv4-to-ICMPv6 or ICMPv6-to-ICMPv4 translation, applications may receive ICMP messages with IP Address Sub-Objects whose address family conflicts with the outer ICMP version (e.g., an ICMPv6 message containing an IPv4 address sub-object).
This extension uses the RFC 4884 multi-part ICMP message framework; the same backward compatibility constraints apply. The extension cannot be appended to ICMP message types other than Time Exceeded, Destination Unreachable, and (for ICMPv4) Parameter Problem.
A single ICMP message MUST NOT contain more than four instances of the Interface Information Object; it is illegal to use the same interface role more than once across all objects in a message.
An ICMP message containing more than one Interface Information Object with the same role, or a duplicate information element within a given role, is considered illegal and MUST be silently discarded on receipt.
If the eliciting datagram is IPv4, the IP Address Sub-Object MUST represent an IPv4 address; if IPv6, it MUST represent an IPv6 address. In all other circumstances (address family mismatch), IP address information MUST NOT be included.
Multiple Interface Information Objects MAY be included in a single ICMP message, but each MUST specify a unique role. A single ICMP message MUST NOT contain two Interface Information Objects with the same role.
NAT devices MUST NOT translate or overwrite the ICMP extensions defined in this document; they MUST either remove the extension entirely or pass it through unchanged.
Receiving an Interface Information Object where C-Type bits 4, 5, 6, and 7 are all 0 is valid (though pointless) and MUST NOT generate a warning or error.
Reserved bits 2 and 3 of the C-Type MUST be set to 0 by senders and MUST be ignored on receipt.
The Interface Information Object extension MAY be appended to any of the supported ICMP messages and SHOULD be appended whenever required to identify an unnumbered interface and when local policy or security considerations do not supersede this requirement.
The interface name MUST be represented in the UTF-8 charset using the Default Language. It SHOULD be the full MIB-II ifName (or first 63 octets if longer), but MAY be another human-meaningful name.
The Interface Name Sub-Object MUST have a length that is a multiple of 4 octets and MUST NOT exceed 64 octets total (including the 1-byte length field, leaving at most 63 octets for the name itself).
Within an Interface Information Object, the optional fields MUST appear in a fixed order: ifIndex first, then IP Address Sub-Object, then Interface Name Sub-Object, then MTU. Any data following these optional fields MUST be ignored.
The extension defines four interface roles encoded in C-Type bits 0-1: value 0 (incoming IP interface), value 1 (sub-IP component of the incoming IP interface, e.g., a LAG member or multilink bundle member), value 2 (outgoing IP interface), and value 3 (IP next hop).
The Interface Information Object can carry up to four optional information elements per instance: a 32-bit ifIndex (from IF-MIB), an IP Address Sub-Object, an Interface Name Sub-Object (up to 63 octets), and a 32-bit unsigned MTU value.
The Interface Information Object is an ICMP extension object with Class-Num 2 that can be appended to ICMPv4/ICMPv6 Time Exceeded, Destination Unreachable, and Parameter Problem messages. A single ICMP message may contain zero to four instances, each describing a unique interface role: incoming interface, sub-IP component, outgoing interface, or next-hop.
IANA allocated C-Type bit assignments for the Interface Information Object: bits 0-1 (Interface Role), bits 2-3 (unallocated, allocatable by Standards Action), bit 4 (ifIndex), bit 5 (IP Address Sub-Object), bit 6 (Name Sub-Object), bit 7 (MTU).
IANA allocated Class-Num value 2 in the ICMP Extension Object Classes registry for the Interface Information Object defined by this document.
IANA reserved four Interface Role values in the C-Type bits 0-1 field: 0 (Incoming IP Interface), 1 (Sub-IP Component of Incoming IP Interface), 2 (Outgoing IP Interface), 3 (IP Next Hop).
Implementations SHOULD provide configuration switches to suppress generation of this extension per role (incoming, outgoing, sub-IP) and to conceal specific information types (ifIndex, interface name), enabling operators to control what topology information is revealed to external parties.
Policy controls on what sub-objects to include MAY be implemented based on the destination IP address of the ICMP reply, allowing detailed information (ifIndex, name) to be sent to management addresses within the administrative domain while withholding it from external or untrusted destinations.
This document does not specify an authentication mechanism for the extension. ICMP messages and their extension contents are easily spoofed, and application developers must account for this. The extensions are intended solely for administrative debugging and troubleshooting, not production applications.
The C-Type byte encodes both the interface role (bits 0-1: 0=incoming, 1=sub-IP incoming, 2=outgoing, 3=next-hop) and presence flags for optional fields (bit 4=ifIndex, bit 5=IP Address Sub-Object, bit 6=Interface Name Sub-Object, bit 7=MTU). Bits 2-3 are reserved and MUST be set to 0.
The Interface IP Address Sub-Object contains a 16-bit AFI (1=IPv4, 2=IPv6), a 16-bit Reserved field, and a variable-length IP address field (32 bits for IPv4, 128 bits for IPv6).
The Interface Name Sub-Object begins with a 1-octet length field, followed by up to 63 octets of interface name. The total length MUST be a multiple of 4 octets, MUST NOT exceed 64 octets, and the name MUST be padded with ASCII NUL characters to reach a 4-octet boundary.