]> Arista Networks

5453 Great America Parkway Santa Clara California 95054 USA fenner@fenron.com

Arista Networks

Global Tech Park Bangalore Karnataka 560103 India reji.thomas@arista.com

Internet Internet Area Working Group ICMP IPv6 next-hops Node identification RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where a given interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., a deployment in which all interfaces have IPv6 addresses and all next-hops are IPv6 next-hops, even for IPv4 routes). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Internet Area Working Group Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In addition to adding incoming interface information to a traceroute using the mechanisms described in , a network operator may be interested in adding information to unambiguously identify nodes themselves. For example, describes a scenario in which individual nodes do not have unique IPv4 addresses to use to reply to an IPv4 traceroute, so additional information is needed. Another scenario is described in : when an IPv6-only node runs the customer-side translator (CLAT, ), traceroute to an IPv4 destination can not represent intermediate IPv6-only routers as they do not have IPv4 addresses. The goal of this specification is to have a mechanism to provide additional useful information about the identification of a node sending an ICMP error, which depends on the actual context and scope of the message being delivered. To this end, it is RECOMMENDED to use a combination of IP Address and Name sub-objects (including combinations where one of the sub-objects is not used) that is unique and meaningful in the actual context and scope. It is explicitly permitted to use an IP address that may have only local meaning (e.g., ULA ), since that information can then be provided to the operator of the domain who can then determine the local meaning. This document defines an ICMP extension that fills that void.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. ICMPv4 is used to refer to Internet Control Message Protocol (ICMP) specified in . ICMPv6 is used to refer to Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) specified in . ICMP is used to refer to both ICMPv4 and ICMPv6.

Node Identification Object This section defines the Node Identification Object, an ICMP Extension Object with a Class-Num (Object Class Value) of 5 (see ). Similar to , this object can be added 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 added to any of the currently defined ICMPv4 or ICMPv6 messages other than those listed above. The extension defined herein, Node Identification Object, MAY be added to any of the above listed messages and MUST be added whenever the responding IP address may not be sufficient to identify the node, unless local policy or security considerations supersede this requirement. (It is permissible to unconditionally include this extension in all of the above messages.) See for suggested configuration regarding including these messages. Similarly to the Interface Identification Object defined in , there are two different pieces of information that can appear in a Node Identification Object:

1. An IP Address Sub-Object MAY be included, containing an address of sufficient scope to identify the node. The IP Address Sub-Object is defined in of this document.
2. A Name Sub-Object MAY be included, as specified in , containing up to 63 octets of the YANG sys:hostname () or another appropriate name uniquely identifying the node.

C-Type Meaning in a Node Identification Object In this object, the C-Type, defined in , contains a bitmask describing what information is included in this Node Identification Object (). The fields in this bitmask are chosen so that the IPAddr and name bits overlap with the same bits as defined in , so that an implementation that supports exactly these bits can reuse packet generation and parsing code.

C-Type for the Node Identification Object

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

• Unassigned (bits 0-4): These bits are reserved for future use and MUST be set to 0 on transmit and ignored on receipt.
• 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 document.
• Name (bit 6): When set, a Name Sub-Object is included. When clear, it is not included. The Name Sub-Object is described in of this document.
• Un2 (bit 7): This bit is reserved for future use and MUST be set to 0 on transmit and ignored on receipt.

The information included does not self-identify, so this specification defines a specific ordering for sending the information that must be followed. If bit 5 (IP Address) is set, an IP Address Sub-Object MUST be sent first. If bit 6 (Name) is set, a Name Sub-Object MUST be sent next. The information order is thus: IP Address Sub-Object, Name Sub-Object. Any or all pieces of information may be present or absent, as indicated by the C-Type. As defined in , future assignments of bits in the C-Type field will result in additional Sub-Objects being sent after these objects. If an implementation does not support these future assignments, these optional pieces of information MUST be ignored. It is valid (though pointless until additional bits are assigned by IANA) to receive a Node Identification Object where bits 5 and 6 are both 0; this MUST NOT generate a warning or error. A packet with such a Node Identification Object MUST be treated as though it contains no Node Identification Object.

Behavior when additional bits are reserved Bit values MUST be assigned from left to right in the diagram above, i.e., starting at zero. The sub-objects associated with each new bit MUST be placed in the packet after the sub-objects defined in this document. For example, if bit 0 is assigned to the Fooblewomp, a packet with bits 0 and 5 set MUST contain the IP Address Sub-Object, followed by the Fooblewomp sub-object. If a bit is set that a receiver does not support, followed by a bit that the receiver does support, the receiver MUST ignore all of the additional data, since the length of the unsupported data is unknown.

IP Address Sub-Object If the Node Identification Object identifies the node by address, the Object Payload contains an address sufficient to identify the node within the appropriate scope - global or as otherwise configured - as depicted in .

IP Address Sub-Object

Payload fields are defined as follows:

• Address Family Identifier (AFI): This 16-bit field identifies the type of address represented by the Address field. Values for this field represent a subset of values found in the IANA registry of Address Family Numbers (available from ). Valid values are as follows:
  • 1: 32-bit IPv4 address
  • 2: 128-bit IPv6 address.
  If this field contains any other value not listed above, it is not possible to determine the size of this variable-length sub-object, so processing of the Node Identification Object MUST be stopped, and the packet handled as though this object was not present. This does not prevent an implementation from handling further ICMP Extension messages, as the length field defined in allows skipping over the partly-handled message. Updates to AFI values and semantics defined in are considered to be updates to this section as well.
• Reserved: This field MUST be set to 0 and ignored upon receipt.
• Address: This variable-length field represents an address of appropriate scope (global, if none other defined) that can be used to identify the node. The length of this field is derived from the AFI (i.e., 32 bits if the AFI field is set to 1, and 128 bits if the AFI is set to 2).

Name Sub-Object depicts the Name Sub-Object:

Name Sub-Object

The Name Sub-Object MUST have a length that is a multiple of 4 octets and MUST NOT exceed 64 octets. If the length field exceeds 64 octets, the receiver MUST ignore the sub-object. The Length field represents the length of the Name Sub-Object, including the length, the node name, and any padding, 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 node name. The node name SHOULD be the YANG sys:hostname , if less than 64 octets, or the first 63 octets of the sys:hostname, if the sys:hostname is longer. The node name MAY be some other human-meaningful name of the node. The node name MUST be padded with ASCII NUL characters if the object would not otherwise terminate on a 4-octet boundary. An example of truncation of a 66-octet node name, beginning "HelpMyAscii" and ending "xyzpdqha" would be encoded as follows: The node name MUST be represented in the UTF-8 charset using the Default Language . When truncating a name to 63 octets, the truncation MUST occur on a character boundary (e.g., if the 63rd octet is the first octet of a 2-octet character, then the truncation will omit that octet altogether, and be padded with an ASCII NUL character to reach the 4-octet boundary.)

Addition of Node Identification Object by Intermediate Nodes An IP/ICMP translator MAY use this extension when translating an ICMP message listed above to include the pre-translation source address of a packet. When doing so, it MUST include the IP Address Sub-Object. If an ICMP Extension Structure is already present in the packet being translated, this Extension Object is added to the existing ICMP Extension Structure and the checksum is updated. If an ICMP Extension Structure is not present in the packet being translated, one is added using the rules of . Further details of this mode of operation are outside the scope of this document. If adding this object results in the ICMP message exceeding the underlying MTU, the translator SHOULD calculate the number of bytes that need to be removed from the "original datagram" field to allow this object to fit, and reduce the length field in the ICMP header by that value, moving any existing ICMP Extension Structure back in the packet appropriately. If this operation is not possible (for example, because the "original datagram" field is already at a minimum size), then the translator MUST NOT add an additional object. (Note that this number of bytes MUST be rounded up to the nearest multiple of 4 for ICMPv4 and 8 for ICMPv6 due to the definition of the length field in the ICMP header; see )

Security Considerations A node name may reveal sensitive information, especially when it encodes semantic information. It may not be desirable to allow this information to be sent to an arbitrary receiver. The addition of this information to the ICMP responses listed in is configurable, and SHOULD be disabled by default, with the exception of IP/ICMP translators . Those translators SHOULD add the Node Identification Extension Object with the IP Address Sub-Object, as described in . An implementation may determine what objects may be added to a given message based on the destination IP address of the ICMP message that will contain the objects. Access control lists (ACLs) may be used to filter the destinations to which this information may be communicated. 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 This IANA has allocated the ICMP Extension Object Class value 5 to the extension described above.

Class Value	Class Name	Reference
5	Node Identification Object	[This document]

IANA is requested to create a corresponding Class Sub-types Registry as follows:

C-Type (Value)	Description	Reference
0-4	Unassigned - allocatable with Standards Action	[This document]
5	IP Address Sub-object included	[This document]
6	Name Sub-object included	[This document]
7	Unassigned - allocatable with Standards Action	[This document]

As indicated in the table above, the remaining bits in the C-Type value are to be allocated via Standards Action . As mentioned in , IANA is requested to assign additional bits starting at zero.

References Normative References ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format. This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field. The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented. This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK] 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. [STANDARDS-TRACK] This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145. IANA Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK] This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. IRIF, Université Paris-Cité Google, LLC Red Hat V4-via-v6 routing is a technique that uses IPv6 next-hop addresses for routing IPv4 packets, and thus makes it possible to route IPv4 packets across a network where some routers have not been assigned IPv4 addresses. This document describes v4-via-v6 routing, and defines related operational procedures, notably the origination of ICMPv4 packets by nodes that might not have an IPv4 address. NetDEF, Inc. Google This document suggests that when a source IPv6 address of an ICMPv6 message can not be translated to an IPv4 address, the protocol translators use the dummy IPv4 address (192.0.0.8) to translate the IPv6 source address, and utilize the ICMP extension for Node Identification (draft-ietf-intarea-extended-icmp-nodeid) to carry the original IPv6 source address of ICMPv6 messages. This document obsoletes RFC6791, Stateless Source Address Mapping for ICMPv6 Packets and updates IP/ICMP Translation Algorithm (RFC7915).

Change history This section is to be removed before publishing as an RFC.

Changes since draft-fenner-intarea-extended-icmp-hostid-00

• Instead of having two different messages with the same Class Value and different CType values, we copy the bitmap implementation from . The re-use of bit positions means that packet parsing and generation code can be largely reused from existing code.

Changes since draft-fenner-intarea-extended-icmp-hostid-01

• Fixed several copy-pasta errors that still referred to interface names instead of node name.

Changes since draft-fenner-intarea-extended-icmp-hostid-02

• Renamed to draft-ietf-intarea-extended-icmp-nodeid-00 to reflect adoption by WG

Changes since draft-ietf-intarea-extended-icmp-nodeid-00

• Several edits suggested by Med Boucadair
• Added to address the needs of XLAT
• Changed title to "Adding Extensions to ICMP Errors for Originating Node Identification"

Changes since draft-ietf-intarea-extended-icmp-nodeid-01

• Added the request to assign bits starting at 0 to the IANA Considerations
• Updated IANA Considerations wording based on RFC8126
• Shortened sub-object names to "IP Address" and "Name", eliminating "Node".

Changes since draft-ietf-intarea-extended-icmp-nodeid-02

• Added table to reflect Object Class assignment to IANA Considerations
• Use SVG for packet figures
• Add example of an encoded, truncated node name
• Be explicit on treatment of a packet with no bits set
• Clarified "defaults to off" in security considerations
• Clarified use of IP address and names

Changes since draft-ietf-intarea-extended-icmp-nodeid-03

• Added Standards Action sentence to IANA Considerations

Changes since draft-ietf-intarea-extended-icmp-nodeid-04

• Changes from AD Review see https://mailarchive.ietf.org/arch/msg/int-area/jhtF0oqj3O0IoKBmb4Q_jwYEzA8/

Changes since draft-ietf-intarea-extended-icmp-nodeid-05

• To address Richard Scheffenegger's TSVdir review and Mohit Sethi's Secdir review, make it explicit that the extension MUST not be processed if the AFI is unknown, but also add that additions to AFI handling in RFC5837 should be considered to be additions to this document.

Acknowledgments This document derives text heavily from , since the underlying mechanism is identical, and only the semantics of the message differs. Thanks are therefore due to that document's authors: Alia K. Atlas, Ronald P. Bonica, Carlos Pignataro, Naiming Shen, and JR. Rivers. Further thanks are due to the following who have provided valuable contributions to this document: Med Boucadair, Jen Linkova, David Lamparter, and Luigi Iannone.