Extending ICMP for Interface and Next-Hop IdentificationGoogle LLC1600 Amphitheatre ParkwayMountain ViewCalifornia94043USjrmitche@puck.nether.netGoogle LLC1600 Amphitheatre ParkwayMountain ViewCalifornia94043USconsta@google.com
Internet
Internet Area Working GroupICMPIPv4IPv6ICMP UnnumberedICMP Interface IdentificationICMP Next Hop Identification
This memo defines data structures that can be appended to selected ICMP messages.
The ICMP extensions 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.
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.
This document obsoletes RFC 5837. To preserve strict backward compatibility with
legacy implementations, it preserves the original Interface Information Object
(Class-Num 2) as defined in RFC 5837, and introduces a new Extended Interface
Information Object to accommodate new interface roles.
Introduction
IP devices use the Internet Control Message Protocol (ICMPv4 and
ICMPv6) 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.
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 , 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, 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. 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 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
. The ifIndex is also defined in .
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
. The same backward compatibility issues that apply to
apply to this extension.
Relationship to BCP 189 (BCP 189) defines an acceptable use policy for new ICMP message types and
codes. It states that extensions to ICMP SHOULD follow the requirements of
, and it cites as an example of such an extension.
This document is a backward-compatible revision of and adheres to BCP 189
as follows:
It defines no new ICMP message types or codes. The objects defined herein are appended only
to the existing ICMP error messages listed in ,
using the multi-part message framework.
The information conveyed is IP-layer forwarding information about the datagram that
elicited the ICMP error: the IP interfaces upon which it arrived and through which it
would have been forwarded, their sub-IP components, and the IP next hop. This information
allows the error condition to be diagnosed more precisely, which is consistent with the
role of ICMP in reporting errors and supporting IP-layer diagnostics. ICMP is not used
here as a general-purpose routing, management, or transport protocol.
No new request/response exchange is introduced and no state is created on either the
sending or the receiving node. Because the objects are carried only in ICMP error messages
that would be generated in any case, they do not create a new amplification vector, and
the resulting messages remain subject to the existing ICMP size limits and rate limiting
requirements of and .
Generation of each interface role and each information element is subject to local
configuration and policy, as described in and
.
Requirements LanguageThe 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 when, and only when, they appear in
all capitals, as shown here.ApplicationsApplication 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.
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.
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 , 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 ).
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
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 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.
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.
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
of this memo.
An Interface Name Sub-Object, containing a string of no more than 63 octets, MAY be included. That
string, as specified in , is the interface name and SHOULD be the MIB-II
ifName , but MAY be some other human-meaningful name of the interface.
A 32-bit unsigned integer reflecting the MTU MAY be included.
C-Type Meaning in an Interface Information Object
For this object, the C-Type is used to indicate both the role of the
interface and the information that is included. This is illustrated in .
Bit 0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| Interface Role| Rsvd1 | Rsvd2 |ifIndex| IPAddr| name | MTU |
+-------+-------+-------+-------+-------+-------+-------+-------+
The following are bit-field definitions for C-Type:
Interface Role (bits 0-1):
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 1:
This object describes the sub-IP component of an IP interface upon which a
datagram arrived
Value 2:
This object describes the IP interface through which the datagram would have been
forwarded had it been forwardable
Value 3:
This object describes the IP next hop to which the datagram would have been
forwarded
Reserved 1 (bit 2):
This bit is reserved for future use and MUST be set to 0 and MUST be ignored on receipt.
Reserved 2 (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 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 of this memo.
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.
An Interface Information Object in which none of the information-element bits understood by the
receiver are set (for example, one in which bits 4, 5, 6, and 7 are all 0) is not an error. It is
processed as though no information elements were present for that role and does not affect the
processing of any other objects in the message. Whether such an object is logged is a local
implementation matter.
Extended Interface Information Object
To extend the functionality in RFC 5837 without breaking legacy implementations
that strictly validate the C-Type bitmask, this document defines the Extended
Interface Information Object. It has a Class-Num (Object Class Value) of TBA1.
A single instance of the Extended Interface Information Object provides
information regarding interface roles not covered by the original Interface
Information Object.
The Extended Interface Information Object can be appended to the same ICMP messages, and under the
same conditions, as the Interface Information Object (see ).
C-Type Meaning in an Extended Interface Information Object
For this object, the C-Type is used to indicate both the role of the interface
and the information that is included.
Bit 0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| Extended Interface Role |ifIndex| IPAddr| name | MTU |
+-------+-------+-------+-------+-------+-------+-------+-------+
The following are bit-field definitions for C-Type:
Extended Interface Role (bits 0-3):
A 4-bit field indicating the role.
Value 0: the sub-IP component of an IP interface through which the
datagram would have been forwarded had it been forwardable.
Values 1-15: Unassigned.
ifIndex (bit 4):
When set, the 32-bit ifIndex is included.
IP Addr (bit 5):
When set, an IP Address Sub-Object is present.
Interface Name (bit 6):
When set, an Interface Name Sub-Object is included.
MTU (bit 7):
When set, a 32-bit integer representing the MTU is present.
The ordering rules for appending sub-objects (ifIndex, IP Addr, Name, MTU)
remain identical to those described in .
An Extended Interface Information Object in which none of the information-element bits understood
by the receiver are set is not an error. It is processed as though no information elements were
present for that role and does not affect the processing of any other objects in the message.
Whether such an object is logged is a local implementation matter.
Shared Sub-Objects
Both the Interface Information Object and the Extended Interface Information
Object utilize the exact same sub-objects.
Interface IP Address Sub-Object depicts the Interface Address Sub-Object:
0 31
+-------+-------+-------+-------+
| AFI | Reserved |
+-------+-------+-------+-------+
| IP Address ....
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 ). 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.
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.
Interface Name Sub-Object depicts the Interface Name Sub-Object:
octet 0 1 63
+--------+-----------................-----------------+
| length | interface name octets 1-63 |
+--------+-----------................-----------------+
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 , 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 using the
Default Language .
Interface Information Object Examples 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 .
Although examples show an Interface Name Sub-Object of length 64, this is only for illustration and
depicts the maximum allowable length.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+--------------+--------------+--------------+--------------+
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 |
+--------------+--------------+--------------+--------------+
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 |
+--------------+--------------+--------------+--------------+
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 |
+--------------+--------------+--------------+--------------+
Usage
Multiple Interface Information Objects (Class-Num 2) and Extended Interface
Information Objects (Class-Num TBA1) MAY be included within a single ICMP
message, provided that each object specifies a unique role.
A single ICMP message MUST NOT contain two Interface Information Objects
(Class-Num 2) that specify the same role. A single ICMP message MUST NOT contain
two Extended Interface Information Objects (Class-Num TBA1) that specify the
same role.
Implementations sending detailed forwarding information SHOULD send both the
Outgoing IP Interface (Class-Num 2, Role 2) and the Sub-IP Component of the
Outgoing IP Interface (Class-Num TBA1, Role 0) when both are known. Legacy
receivers will process the Class-Num 2 object and safely ignore the unknown
Class-Num TBA1 object, as per the standard multi-part message
framework.
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.
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 or Extended 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.
Network Address Translation Considerations encourages Traditional IP Network Address Translators (Traditional NATs;
see ) 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.
Operational ConsiderationsConfiguration and Disclosure
Implementations SHOULD allow operators to enable or disable the generation of the Interface
Information Object and the Extended Interface Information Object independently for each interface
role, and to control which information elements (ifIndex, IP Address Sub-Object, Interface Name
Sub-Object, and MTU) are included. Operators can use these controls, together with the policy
mechanisms described in , to limit the disclosure of interface information
to the parties that need it.
Accuracy of the Outgoing Sub-IP Component
When the outgoing IP interface is a bundle of sub-IP components (for example, an Ethernet Link
Aggregation Group), the component that would carry a given datagram is typically selected by a
load-balancing function. That function is often implemented in forwarding hardware, can depend on
configurable inputs, and may not have been evaluated for the datagram at the time the ICMP message
is generated. Reporting the wrong component is worse than reporting none, because it can direct
troubleshooting toward a healthy link.
An implementation MUST NOT include an Extended Interface Information Object with the Outgoing Sub-IP
Component role (Extended Interface Role 0) unless it can determine the component that its
forwarding plane would have selected for the datagram that elicited the ICMP message. When the
component cannot be determined reliably, the implementation SHOULD omit that object; it can still
report the outgoing IP interface using the Interface Information Object (Interface Role 2).
Incremental Deployment
Receivers that do not recognize the Extended Interface Information Object ignore it, as specified
by , and continue to process any Interface Information Objects in the same
message. Senders can therefore be upgraded independently of receivers, and operators can enable the
Extended Interface Information Object without losing the information already provided by
implementations. Diagnostic tools, such as traceroute implementations, need
to be updated to decode the new object.
Message Size
Each object appended to an ICMP message consumes octets that would otherwise carry the original
datagram. Implementations need to ensure that the resulting ICMP message does not exceed the
applicable size limit (, ) while still meeting the
requirements for the original datagram field. When necessary, an
implementation can omit optional information elements (for example, the Interface Name Sub-Object)
or lower-priority objects.
Best-Effort Nature
ICMP messages can be rate limited by the sender and filtered or dropped along the return path.
The information defined in this document is therefore best effort, and its absence does not imply
that an interface or sub-IP component has no identity. Applications should not rely on receiving
these objects for every probe.
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).
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 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.
IANA Considerations
IANA is requested to take the following actions:
Maintain the reservation of Class-Num 2 for the "Interface Information Object" in the ICMP Extension Object Classes registry.
Maintain the C-Type values for Class-Num 2 as defined in , updating the reference to this document.
Maintain the Interface Role values for Class-Num 2 as defined in , updating the reference to this document.
Assign a new Class-Num TBA1 for the "Extended Interface Information Object" from the ICMP Extension Object Classes registry, whose registration policy for this range is First Come First Served .
Establish a new C-Type sub-registry for Class-Num TBA1:
Bit 0-3: Extended Interface Role
Bit 4: ifIndex included
Bit 5: IP Address Sub-Object included
Bit 6: Name Sub-Object included
Bit 7: MTU included
All bits are assigned by this document. Any future change to the meaning of these bits
requires Standards Action , consistent with the C-Type sub-registry for
Class-Num 2.
Establish a new registry for "Extended Interface Roles" under Class-Num TBA1, assigning Value 0 to "Outgoing Sub-IP Component" (this document). Values 1-15 are Unassigned. New values are assigned via Standards Action .
Acknowledgments
This document is an update of , 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, Fabricio Pimenta de Avila, and
Ronald P. Bonica for discussions on the approach, and David Lamparter for comments on the accuracy
of outgoing sub-IP component reporting.
ReferencesNormative ReferencesInformative ReferencesUDP Traceroute Message ExtensionChanges from RFC 5837
This document obsoletes . The following technical changes have been made:
Introduced the Extended Interface Information Object (Class-Num TBA1).
Added support for the "Outgoing Sub-IP Component" role using the new Extended Interface Information Object.
Added usage guidelines clarifying that multiple distinct extension classes can be appended to the same ICMP message to provide both the existing IP interface data and the extended interface data simultaneously.
Updated Requirements Language to current IETF standards.
Replaced the requirement that an Interface Information Object with bits 4 through 7 all clear "MUST NOT generate a warning or error" with text stating that such an object is not an error and is processed as though no information elements were present, leaving local logging to the implementation.
In the IP address rules of the Usage section, capitalized "must" to "MUST", consistent with the existing requirement in the Interface IP Address Sub-Object section.
Added Operational Considerations and a description of the relationship to BCP 189 .
Changes from draft-mitchell-intarea-rfc5837bis-01
Added Sorin Constantinescu as a co-author.
Added a section describing how this document adheres to BCP 189 .
Added an Operational Considerations section, including requirements on the accuracy of the reported outgoing sub-IP component.
Clarified that the Extended Interface Information Object can be appended to the same ICMP messages as the Interface Information Object.
Specified Standards Action as the registration policy for the new C-Type and Extended Interface Roles sub-registries.
Replaced the unconditional "MUST NOT generate a warning or error" for objects with no information-element bits set (inherited from RFC 5837) with "not an error, processed as absent, logging is a local matter", for both object classes.
Restored RFC 5837 text that had been dropped in earlier revisions (C-Type introduction, reserved-bit wording, and the ifIndex-clear statement), and asked IANA to update the reference for the Class-Num 2 Interface Role values.
Removed unused XML entity declarations and refreshed the document date.
Changes from draft-mitchell-intarea-rfc5837bis-00
Reverted the structural changes proposed to the Class-Num 2 C-Type bitmask. The 00 draft expanded the role field of the original object by utilizing a reserved bit. Based on working group feedback regarding backward compatibility risks, this approach was discarded.
Adopted the approach of requesting a new ICMP Extension Object (Extended Interface Information Object) with a native 4-bit role field.
Eliminated the requirement for modern senders to drop the "Outgoing IP" object to accommodate the new "Outgoing Sub-IP" object. Both can now be transmitted cleanly via standard multi-part parsing.