]> Cisco Systems, Inc.

Canada jrajaman@cisco.com

Cisco Systems, Inc.

Canada ddukes@cisco.com

Cisco Systems, Inc.

India madsanka@cisco.com

Internet Internet Area Working Group ICMP Underlay Information Network operators operating overlay networks require the ability to identify hops in an underlay network when traceroute in the overlay. This document defines an ICMP Error extension message to carry the underlay error information to the overlay network endpoint.

Introduction The mechanism allowing ICMP messages to carry additional information is . ICMP message extensions, describing the mechanisms for extending ICMP messages to carry additional information about the system where the error occurred are defined in , and . These messages are transmitted to the source node to provide deeper insight into the error in relation to the node where it occurred. Network operators who administer and overlay and underlay network, such as those with VPN segmentation within their network and an SRv6 core connecting them, find it particularly useful to have ICMP underlay information transmitted to source nodes for the purpose of using traceroute. This ICMP underlay information provides details about errors and failures in the underlay network. The underlay error information described in this document satisfy the need of these network operators.

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.

Underlay Information Object This section defines a new ICMP extension object called Underlay Information Object (UIO) that is encoded as part of ICMP extension message. A new Class-Num value TBA (To Be Assigned) is assigned to identify the UIO. As per , this object MAY be appended to one of the following ICMP messages:

• ICMPv4 Time Exceeded
• ICMPv4 Destination Unreachable
• ICMPv4 Parameter Problem
• ICMPv6 Time Exceeded
• ICMPv6 Destination Unreachable

UIO Object Format This section described the UIO object format.

Underlay Information Object Format

UIO ICMP extension object contains the following fields: Length: 16 bits

• Length of the object, measured in octets, including UIO ICMP extension object header and object payload

Class-Num: 8 bits

• Identifies object class. In the case of UIO, a new value TBA will be assigned from IANA "ICMP Extension Object Classes and Class Sub-types" registry. This object could co-exist with the other ICMP extension objects

C-Type: 8 bits

• Identifies object sub-type. This value MUST be transmitted as zeros and ignored upon receipt.

Object-Payload: Variable Length

• UIO Object payload contains one or more other ICMP Extension Objects that are related to the underlay nodes.

This ICMP extension object acts as an envelope to carry other ICMP extension objects related to the underlay. Primarily, the UIO ICMP extension object is encoded in the ICMP extension message by the underlay head-end when it receives an ICMP error message from one of its intermediate nodes. This UIO ICMP extension object can encapsulate one or more relevant ICMP extension objects that are related to the underlay node. When the underlay head-end encodes its ICMP extension object, the first object MUST contain the ICMP extension object that carries IP address or the hostname of the node where the initial ICMP error was generated. The ICMP extension objects encoded within the UIO ICMP extension objects can belong to any address family, irrespective of the address family of the source node that decapsulates the UIO ICMP extension objects, as opposed to what is stated in Section 4.2. When the UIO is encoded, the total length of the ICMP message, including extensions, MUST NOT exceed the minimum reassembly buffer size. If the node decoding the ICMP extension header does not recognize the UIO ICMP extension message, it SHOULD ignore this message and continue processing the other messages.

Underlay Information Object Encoding Process An underlay head-end node generates an ICMP error directed to a host in the overlay network. The specifics of the ICMP error content are beyond the scope of this document. The error is triggered by the receipt of an underlay error message from an IPv4/IPv6 interface. The encoding and processing of the underlay error are also outside the scope of this document. The underlay head-end appends a UIO ICMP extension object to the ICMP error it generates to the overlay host.

Security Considerations In most of the cases the overlay and underlay networks are owned by different operators, so it may not be advisable to permit the transmission of the underlay information to an arbitrary recipient. The inclusion of this information should be configurable and must default to being disabled. An implementation should decide which objects can be appended as part of the UIO ICMP extension message. The extensions defined in this document are intended for use in administrative debugging and troubleshooting. They provide additional information in ICMP responses. These mechanisms are not designed for use in non-debugging applications.

IANA Considerations This document requests that IANA allocate a value (TBA - To Be Assigned) for the UIO ICMP extension object class value from the "ICMP Extension Object Classes and Class Sub-types" registry to indicate the presence of the UIO ICMP extension class, referred to as TBA above.

Appendix

UIO ICMP Extension Message Examples This section lists the UIO example encoding format

UIO carrying IPv6 information to the IPv4 source In this example, a host receives an IPv4 ICMPv4 Time Exceeded error message in response to an ICMP Echo Request as part of the traceroute application. It also contains an UIO ICMP extension object with IPv6 interface address information as follows.

ICMPv4 packet carrying UIO ICMP extension

The traceroute application displays the IPv6 Address in the UIO to allow an administrator to trace the underlay path of the route being traced.

UIO carrying IPv4 information to the IPv6 source In this example, a host receives an IPv6 ICMPv6 Time Exceeded error message in response to an ICMP Echo Request as part of the traceroute application. It contains a UIO ICMP extension object with IPv4 interface address information as follows.

UIO carrying IPv4 information to the IPv6 source

The traceroute application displays the IPv4 Address in the UIO to allow an administrator to trace the underlay path of the route being traced.

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] This document describes a network diagnostic tool called PROBE. This document specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. 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 and .

Contributors The following people have substantially contributed to this document: