summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5837.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5837.txt')
-rw-r--r--doc/rfc/rfc5837.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc5837.txt b/doc/rfc/rfc5837.txt
new file mode 100644
index 0000000..760281b
--- /dev/null
+++ b/doc/rfc/rfc5837.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Atlas, Ed.
+Request for Comments: 5837 BT
+Category: Standards Track R. Bonica, Ed.
+ISSN: 2070-1721 Juniper Networks
+ C. Pignataro, Ed.
+ N. Shen
+ Cisco Systems
+ JR. Rivers
+ Consultant
+ April 2010
+
+
+ Extending ICMP for Interface and Next-Hop Identification
+
+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, 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5837.
+
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 1]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+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) 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 Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, 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, except to format
+ it for publication as an RFC or to translate 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 . . . . . . . . . . . . . . . . . . 16
+
+
+
+
+Atlas, et al. Standards Track [Page 2]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+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.
+
+ 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:
+
+ o one of the IP addresses associated with the physical interface
+ over which the ICMPv4 message is transmitted
+
+ o 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:
+
+ o the device sends an ICMPv4 message through the same interface upon
+ which the original datagram was received
+
+ o 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:
+
+ o 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
+
+
+
+Atlas, et al. Standards Track [Page 3]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ 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:
+
+ o ifIndex
+
+ o IPv4 address
+
+ o IPv6 address
+
+ o name
+
+ o 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.
+
+
+
+
+Atlas, et al. Standards Track [Page 4]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+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
+
+ 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:
+
+ o the IP interface upon which a datagram arrived
+
+ o the sub-IP component of an IP interface upon which a datagram
+ arrived
+
+ o the IP interface through which the datagram would have been
+ forwarded had it been forwardable
+
+ o the IP next hop to which the datagram would have been forwarded
+
+ Enhanced traceroute applications can identify the above listed
+ entities by:
+
+ o ifIndex
+
+ o IPv4 address
+
+ o IPv6 address
+
+ o name
+
+ o 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.
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 5]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+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:
+
+ o ICMPv4 Time Exceeded
+
+ o ICMPv4 Destination Unreachable
+
+ o ICMPv4 Parameter Problem
+
+ o ICMPv6 Time Exceeded
+
+ o 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:
+
+ o the IP interface upon which a datagram arrived
+
+
+
+
+Atlas, et al. Standards Track [Page 6]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ o the sub-IP component of an IP interface upon which a datagram
+ arrived
+
+ o the IP interface through which the datagram would have been
+ forwarded had it been forwardable
+
+ o 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:
+
+ o Ethernet Link Aggregation Group Member
+
+ o Multilink PPP bundle member
+
+ o 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.
+
+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.
+
+
+
+
+
+Atlas, et al. Standards Track [Page 7]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ 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 Object
+
+ The following are bit-field definitions for C-Type:
+
+ Interface Role (bits 0-1): These bits indicates 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 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.
+
+ 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.
+
+
+
+Atlas, et al. Standards Track [Page 8]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ 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:
+
+ o 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).
+
+ o Reserved: This 16-bit field MUST be set to zero and ignored upon
+ receipt.
+
+ o 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.
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 9]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+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.
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 10]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ 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
+
+
+
+
+Atlas, et al. Standards Track [Page 11]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ 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
+
+
+
+
+Atlas, et al. Standards Track [Page 12]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ 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.
+
+ 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:
+
+ o 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.
+
+ o 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
+
+
+
+Atlas, et al. Standards Track [Page 13]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ 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).
+
+ 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.
+
+
+
+Atlas, et al. Standards Track [Page 14]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ 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:
+
+ o Bit 0-1: Interface Role field
+
+ o Bit 2: Unallocated - allocatable with Standards Action
+
+ o Bit 3: Unallocated - allocatable with Standards Action
+
+ o Bit 4: ifIndex included
+
+ o Bit 5: IP Address Sub-Object included
+
+ o Bit 6: Name Sub-Object included
+
+ o Bit 7: MTU included
+
+ IANA has reserved the following values for Interface Role:
+
+ o Value 0: Incoming IP Interface
+
+ o Value 1: Sub-IP Component of Incoming IP Interface
+
+
+
+Atlas, et al. Standards Track [Page 15]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ o Value 2: Outgoing IP Interface
+
+ o Value 3: IP Next Hop
+
+8. Acknowledgments
+
+ The authors would like to thank Sasha Vainshtein, Enke Chen, and Joe
+ Touch for their comments and suggestions. They would also like to
+ thank Dr. Ali Assefi.
+
+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.
+
+
+
+
+
+Atlas, et al. Standards Track [Page 16]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 17]
+
+RFC 5837 ICMP Unnumbered April 2010
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Standards Track [Page 18]
+