RFC 5837
Extending ICMP for Interface and Next-Hop Identification
RFC 5837: Extending ICMP for Interface and Next-Hop Identification 💖
Okay bestie, this one is from the IETF (Internet Engineering Task Force) and it's labeled Request for Comments: 5837 🎀. It's on the Standards Track ✨, which means it's an actual Internet standard, not just a suggestion. It's dated April 2010 and has ISSN 2070-1721. The authors are A. Atlas, Ed. (BT), R. Bonica, Ed. (Juniper Networks), C. Pignataro, Ed. (Cisco Systems), N. Shen (Cisco Systems), and JR. Rivers (Consultant). The three "Ed." people are the editors 🫶. The title block doesn't list anything it obsoletes or updates.
Abstract
This memo defines a data structure that can be appended to selected ICMP messages 🦋. The ICMP extension defined here can identify any combination of the following: the IP interface a datagram arrived on, the sub-IP component of an IP interface a datagram arrived on, the IP interface a datagram would have been forwarded through if it had been forwardable, and the IP next hop it would have been forwarded to 🧚.
Devices can use this ICMP extension to identify interfaces and their components by any combo of these: 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 is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF) 👑. It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more info on Internet Standards, check Section 2 of RFC 5741 🌈.
You can find the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc5837 ✨.
Copyright Notice
Copyright (c) 2010 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 (http://trustee.ietf.org/license-info), as they stand on the date this document was published. Please actually read those, because they spell out your rights and restrictions for this document 🙈. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 📜.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🎀.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . 5
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 . . . . 7
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 . . . . . . . . . . . . . . . . . . 161. Introduction ✨
Okay so IP devices use the Internet Control Message Protocol (ICMPv4 [RFC0792] and ICMPv6 [RFC4443]) to share control info 💅. When an IP device gets a datagram it can't process, it may send an ICMP message back to whoever sent the datagram 🦋. Network operators and higher-level protocols rely on these ICMP messages to detect and diagnose network issues 🔍.
In the simplest case, the source address of the ICMP message tells you which interface the datagram came in on 💖. But honestly, in a lot of cases the ICMP message doesn't identify the incoming interface at all 😭. Here's the breakdown:
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
But the incoming and outgoing interfaces can be different because of an asymmetric return path 🙃. That can happen with asymmetric link costs, parallel links, or Equal Cost Multipath (ECMP) 🧚.
Similarly, [RFC1122] gives guidance on source address selection for multihomed IPv4 hosts 🌸. Those recommendations, like the ones above, don't always make the source address of an ICMPv4 message identify the incoming interface 💀.
ICMPv6 is a little more flexible 🍓. [RFC4443] says 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 can't be processed arrives on an unnumbered interface, neither ICMPv4 nor ICMPv6 can currently identify the incoming interface 😭. Even when an ICMP message is generated so that its source address does identify the incoming interface, the receiver has no way of knowing that's the case 🙈. ICMP extensions are required to explicitly identify the incoming interface 👑.
With the extension defined here, 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 a datagram would have been forwarded over if that datagram had been deliverable 🎀.
The next-hop IP address, the one the datagram would have been forwarded to, can also be identified with this same extension 💜. This info can be used to create a downstream map 🗺️. The next-hop info may not always be available. There are corner cases where it doesn't exist, and there may be implementations where it isn't practical to provide it 💅. This specification gives you an encoding for the next-hop IP address when it is available ✨.
The extension defined here uses the ICMP multi-part message framework defined in [RFC4884]. The same backward compatibility issues that apply to [RFC4884] apply to this extension 🫶.
2. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖.
3. Applications
3.1. Application to Traceroute
The ICMP extensions in this memo give traceroute some extra powers 🦋. An enhanced traceroute application, just like the older implementations, identifies the nodes a datagram visited on its way to its destination 🗺️. The difference is 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 IP next hop to which the datagram would have been forwarded
Enhanced traceroute applications can identify the entities listed above by:
- ifIndex
- IPv4 address
- IPv6 address
- name
- MTU
The ifIndex can be used within a management domain to map to an actual interface, but it's also valuable in public applications 🌈. It works as an opaque token to tell whether two ICMP messages generated from the same router involve the same interface 🔥.
3.2. Policy and MTU Detection
This one is a general application: figuring out 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 it, being able to identify the outgoing interface could be super useful 💀. Another example is supporting Path MTU Discovery (PMTUD), since that would let you identify which outgoing interface can't support a given MTU size 🍓. Like, knowing the problematic interface would let you make an informed request to reconfigure that interface's MTU 🫶💖.
4. Interface Information Object ✨
okay so this section is where the Interface Information Object lives, bestie 🎀 it's an ICMP extension object with a Class-Num (Object Class Value) of 2, and it can get tacked onto these messages:
- ICMPv4 Time Exceeded
- ICMPv4 Destination Unreachable
- ICMPv4 Parameter Problem
- ICMPv6 Time Exceeded
- ICMPv6 Destination Unreachable
ngl the reason it's only these five is explained in [RFC4884], so no other ICMPv4 or ICMPv6 messages can carry it, no matter how much we beg 🙈
The extension MAY be appended to any of the messages above, and it SHOULD be appended whenever it's needed to identify an unnumbered interface, as long as local policy or security considerations don't override that 💅
A single ICMP message can hold as few as zero and as many as four instances of the Interface Information Object. More than four is illegal, because it would mean an interface role got used twice (see Section 4.5) 😭 main character energy has limits, periodt.
One instance of the object can describe any one of these 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
Some examples of sub-IP components a datagram might arrive on:
- Ethernet Link Aggregation Group Member
- Multilink PPP bundle member
- Multilink frame relay bundle member
To keep the number of octets small, an Interface Information Object can carry four different pieces of info 🦋
- The ifIndex of the interface of interest MAY be included. It's the 32-bit ifIndex the device assigns to the interface, as defined by the Interfaces Group MIB [RFC2863].
- An IP Address Sub-Object MAY be included if either of these 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 covered in Section 4.2 of this memo.
- An Interface Name Sub-Object, holding a string of no more than 63 octets, MAY be included. As described in Section 4.3, that string is the interface name and SHOULD be the MIB-II ifName [RFC2863], but MAY be some other human-meaningful name of the interface 🌸
- A 32-bit unsigned integer reflecting the MTU MAY be included.
4.1. C-Type Meaning in an Interface Information Object
okay this part is so cute, the C-Type [RFC4884] is doing double duty here 💖 it tells you both the role of the interface AND what info is packed in. Check out Figure 1:
Bit 0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
| Interface Role| Rsvd1 | Rsvd2 |ifIndex| IPAddr| name | MTU |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 1: C-Type for the Interface Information ObjectHere's the bit-field breakdown for the C-Type:
Interface Role (bits 0-1): these bits tell you the role of the interface being identified. The enumerated values are:
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 forwardedReserved 1 (bit 2): reserved for future use. It MUST be set to 0 and MUST be ignored on receipt 🔒
Reserved 2 (bit 3): also reserved for future use. It 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, it 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. The Name Sub-Object is described in Section 4.3 of this memo.
MTU (bit 7): when set, a 32-bit integer representing the MTU is present. When clear, that 32-bit integer is not present.
Now the tea ☕ the info does NOT self-identify, so the spec sets a specific order for sending it, and you have to follow it:
If bit 4 (ifIndex) is set, 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. So the order is: ifIndex, IP Address Sub-Object, Interface Name Sub-Object, and MTU. Any or all of these pieces can be present or absent, as the C-Type says. Any data that follows these optional pieces MUST be ignored. 🫶
Last bit of drama: it's valid (though pointless until IANA assigns more bits) to receive an Interface Information Object where bits 4, 5, 6, and 7 are all 0. That MUST NOT generate a warning or error 💜
4.2. Interface IP Address Sub-Object
Figure 2 is the layout for the Interface Address Sub-Object 🧚
0 31
+-------+-------+-------+-------+
| AFI | Reserved |
+-------+-------+-------+-------+
| IP Address ....
Figure 2: Interface Address Sub-ObjectThe IP Address Sub-Object has these fields:
- Address Family Identifier (AFI): this 16-bit field identifies the type of address in the IP Address field. It also decides how long that field is and how long the whole sub-object is. The values come from a subset of the IANA registry of Address Family Numbers (available from
<http://www.iana.org>). The valid values are 1 (a 32-bit IPv4 address) and 2 (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 is 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. no mixing and matching, iykyk 💅
4.3. Interface Name Sub-Object
Figure 3 shows the Interface Name Sub-Object:
octet 0 1 63
+--------+-----------................-----------------+
| length | interface name octets 1-63 |
+--------+-----------................-----------------+
Figure 3: Interface Name Sub-ObjectThe Interface Name Sub-Object MUST have a length that is a multiple of 4 octets and MUST NOT exceed 64 octets. 🍓
The Length field is the length of the whole Interface Name Sub-Object, counting both the length and the interface name, in octets. The maximum valid length is 64 octets. That limit is there so there's still room for the start of the original packet and some extra info, which is very thoughtful of them honestly 🥹
The second field holds the human-readable interface name. It SHOULD be the full MIB-II ifName [RFC2863] if it's under 64 octets, or the first 63 octets of the ifName if the ifName is longer. It MAY be some other human-meaningful name of the interface. Having the ifName is useful for cross-correlating with other MIB information and for making it easy for humans to recognize, so it's a whole vibe ✨ If the object wouldn't otherwise end on a 4-octet boundary, the interface name MUST be padded with ASCII NULL characters.
And finally, the interface name MUST be represented in the UTF-8 charset [RFC3629] using the Default Language [RFC2277]. Periodt 👑
4.4. Interface Information Object Examples 🧚
Okay so Figure 4 is giving a full ICMPv4 Time Exceeded message, and it includes the Interface Information Object 💖 That object has to come right after an ICMP Extension Structure Header and an ICMP Object Header, which must be preceded by those two things. Both of those are defined in [RFC4884] ✨
Even though the examples show an Interface Name Sub-Object of length 64, that's just for illustration 🌸 It's the maximum allowable length, so don't panic if yours is shorter.
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
ObjectFigure 5 shows an Interface Information Object for 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 NameFigure 6 is the incoming interface version 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 NameFigure 7 is 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 AddressFigure 8 flips it to 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 Name4.5. Usage 📋
Multiple Interface Information Objects MAY be included within a single ICMP message, as long as each one specifies a unique role. A single ICMP message MUST NOT contain two Interface Information Objects that specify the same role 🙈
ifIndex, MTU, and name information MAY be included whenever it's available. You MUST NOT include more than one instance of each of these three information elements per Interface Information Object 💅
A single instance of IP Address information MAY be included in an Interface Information Object under these 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. No exceptions, bestie 🚫
An ICMP message that doesn't follow these rules and contains multiple instances of the same information is considered illegal 💀 Specifically, an ICMP message with more than one Interface Information Object for the same role is illegal, and so is an ICMP message with a duplicate information element in a given role. If one of these illegal ICMP messages 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, so it contains realm-specific information. That means it also describes possible NAT behaviors when these extensions are around 👀
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's conceivable that a NAT device might translate an ICMP header without translating the extension defined here. In that case, the ICMP message might contain two instances of the same address, one translated and one untranslated. So application developers should not assume the addresses in the extension are in the same realm as the addresses in the datagram's header 😭
It's also conceivable that a NAT device might translate an ICMPv4 message into ICMPv6, or the other way around. If that happened, applications might receive ICMPv6 messages that contain IP Address Sub-Objects specifying IPv4 addresses. Likewise, applications might receive ICMPv4 messages that contain IP Address Sub-Objects specifying IPv6 addresses 🌀
6. Security Considerations 🔥
This extension can give traceroute users extra network information that isn't currently available, so this section is a big deal ✨ 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 share this information with a particular network's operators and not with 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 is provided to ICMP destinations within the local administrative domain, while only traditional information goes to 'external' or untrusted ICMP destinations. Main character security energy 👑
The intended field of use for the extensions defined in this document is administrative debugging and troubleshooting. The extensions defined here 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 it defines. Application developers should be aware that ICMP messages and their contents are easily spoofed. Literally anyone can fake these, so trust carefully 😭🫠
7. IANA Considerations ✨
okay bestie, so IANA is the org that keeps all the Internet's special number lists 📋, and this section tells them what to do 💅
IANA has reserved the number 2 for the Interface Information Object 🎀 it lives in the ICMP Extension Object Classes registry, which you can find at <http://www.iana.org>.
Now for the C-Type of the Interface Information Object, the bits get split up like this 🦋
- Bit 0-1: Interface Role field
- Bit 2: Unallocated - allocatable with Standards Action
- 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
Then IANA reserved these values for Interface Role 🌸
- Value 0: Incoming IP Interface
- Value 1: Sub-IP Component of Incoming IP Interface
- Value 2: Outgoing IP Interface
- Value 3: IP Next Hop
8. Acknowledgments 🫶
the authors wanna thank Sasha Vainshtein, Enke Chen, and Joe Touch for their comments and suggestions 💖 they also thank Dr. Ali Assefi, iykyk 🌈
9. References 📚
9.1. Normative References 🔥
[RFC0792]Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2863]McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.[RFC3629]Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.[RFC4443]Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.[RFC4884]Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
9.2. Informative References ✨
[RFC1122]Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.[RFC1812]Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.[RFC2277]Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.[RFC3022]Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.[RFC5508]Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.[TRACEROUTE-EXT]Shen, N., Pignataro, C., Asati, R., and E. Chen, "UDP Traceroute Message Extension", Work in Progress, June 2008.
Authors' Addresses 🎀
Alia K. Atlas (editor) BT
EMail: alia.atlas@bt.com
Ronald P. Bonica (editor) Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 USA
EMail: rbonica@juniper.net
Carlos Pignataro (editor) Cisco Systems 7200-12 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
EMail: cpignata@cisco.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
EMail: naiming@cisco.com
JR. Rivers Consultant
EMail: jrrivers@yahoo.com
📦 where this page comes from
- ietf: rfc5837 2010-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms