]> Arista Networks

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

Internet Internet Area Working Group ICMP IPv6 nexthops Host 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 each 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 or a textual name for the node, in the case where each node may not have a unique IP address (e.g., the IPv6 nexthop deployment case described in draft-chroboczek-intarea-v4-via-v6). 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 identify nodes themselves. 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.

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.

Node Identification Object This section defines the Node Identification Object, an ICMP Extension Object with a Class-Num (Object Class Value) of TBD 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 the node and when local policy or security considerations do not supersede this requirement.

C-Type Meaning in a Node Identification Object C-Type values in a Node Identification Object include:

• 1: Identifies Node by Name

If the Node Identification Object identifies the node by name, the Object Payload contains the configured node name. It is presumed that the operator configures a unique node name for each system that is identified in this manner. If the Object Payload would not otherwise terminate on a 32-bit boundary, it MUST be padded with ASCII NULL characters.

• 2: Identifies Node by Address

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 .

Node Identification Object - C-Type 2 Payload

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 1 (representing a 32-bit IPv4 address) and 2 (representing a 128-bit IPv6 address).
• 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.

Security Considerations It may not be desirable to allow this information to be sent to an arbitrary receiver. The addition of this information SHOULD be configurable, and MUST default to off. An implementation SHOULD determine what objects may be appended to a given message based on the destination IP address of the ICMP message that will contain the objects. 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 This document will ask IANA to allocate an ICMP Extension Object Class referred to as TBD above. But for now this document is just for discussion.

Normative References 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] IRIF, University of Paris Google, LLC Red Hat We propose "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. We describe the technique, and discuss its operational implications. { Editor note: This document was originally published as draft- chroboczek-int-v4-via-v6, and later renamed to draft-chroboczek- intarea-v4-via-v6 . } IANA 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.

Acknowledgments This document derives text heavily from , since the underlying mechanism is identical, and only the content of the messages differ.