]> Huawei

China zhangli344@huawei.com

Sea Group

Singapore zhangzz@sea.com

Huawei Cloud

China sunronghua@huawei.com

Huawei Cloud

China sky.wangyang@huawei.com

INT Area intarea Working Group ICMP Traceroute This draft introduces the development and latest situation of Traceroute, which is beneficial for network operators and users to understand the latest capabilities of traceroute, enabling them to utilize traceroute effectively.

Introduction As described in , Traceroute is a common TCP/IP tool, which allos users to learn about the route that packets take from their local host to a remote host. It is often used by network and system managers to learn something about the ever-changing structure of the Internet. Traceroute collects the route's information based on the ICMP Time Exceeded Message (TEM). ICMP TEM has been extended by several RFCs and drafts, however, there is no drafts nor RFCs summarize the current situation and development of Traceroute. This draft introduces the development and latest situation of Traceroute, which is beneficial for network operators and users to understand the latest capabilities of traceroute, enabling them to utilize traceroute effectively.

Requirements Language 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.

Terminology The abbreviations used in this document are: ICMP: Internet Control Message Protocol

General Traceroute gives a general description on Traceroute. The original version of Traceroute works by sending a sequence of User Datagram Protocol (UDP) datagrams to an invalid port address at the remote host. Using the default settings, three datagrams are sent, each with a Time-To-Live (TTL) field value set to one. The TTL value of 1 causes the datagram to "timeout" as soon as it hits the first router in the path; this router will then respond with an ICMP Time Exceeded Message (TEM) indicating that the datagram has expired. Another three UDP messages are now sent, each with the TTL value set to 2, which causes the second router to return ICMP TEMs. This process continues until the packets actually reach the other destination. Since these datagrams are trying to access an invalid port at the destination host, ICMP Destination Unreachable Messages are returned indicating an unreachable port; this event signals the Traceroute program that it is finished! The Traceroute program displays the round-trip delay associated with each of the attempts. (Some implementations of Traceroute use the Record-Route option in IP rather than the method described above.) The original Traceroute just allows users to get the IP address information of the router that packets go through from the source address of TEMs. However, with the enhancment of ICMP, the Traceroute also can provides more richful information.

Traceroute with Interface Information extends the ICMP Time Exceeded Message with a length attribute and an Extension Structure, making it more flexiable to carry more information by one or more objects. Based on , defines the Interface Information Object to carry the ifIndex, IPv4 address, IPv6 address, name, and MTU information. With this extension, Traceroute is enhanced. 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

Traceroute with Node Name Although extends ICMP to carry the interface information, however, for the node along the route, it still can only get the IP address information and can't adapt to the case where each node may not have a unique IP address. In order to solve this problem, introduces a ICMP extension for Node Identification. It defines the Node Identification Object, which allows providing a unique IP address and/or a textual name for the node. There are two different pieces of information that can appear in a Node Identification Object:

• An IP Address Sub-Object MAY be included, containing an address of sufficient scope to identify the node within the domain.
• A Name Sub-Object MAY be included, containing up to 63 octets of the YANG sys:hostname () or another appropriate name uniquely identifying the node.

The detailed description on Node Identification Ob can be found in .

Traceroute with Multi-path Interface Information Although Traceroute has been enhanced a lot, it still have some limitations. On the one hand, it is typically used to collect the information of one path, when using Traceroute in a multi-path topology (there are multiple paths from the source node to the destination node and ECMP, UCMP or other multi-path routing strategy is used.), the Traceroute can only get information of one of the avaialbe paths once. It can’t collect all the path’s information from source node to destination node at once. On the other hand, having a next hop and an outgoing interface does not mean that the next hop and outgoing interface are reachable, the ARP table or Neighbor Cache entry associated with the interface also need to be completed and reachable. Therefore, extends the ICMP message with an Multi-path Interface Information object to carry the egress interface, next hop, and the corresponding ARP or ND information of each multi-path interface of nodes along the route.

Security Considerations This document does not introduce any changes to the existing proctols, nor does it introduce new security risks.

IANA Considerations This document has no IANA actions.

References Normative References 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 memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtain Internet and TCP/IP documents, and some resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. 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] Arista Networks Arista Networks 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 nexthops are IPv6 nexthops, even for IPv4 routes). 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. Huawei Sea Group Huawei Cloud Huawei Cloud This document extends the ICMP message with an Multi-path Interface Information object to carry the egress interface, next hop, and the corresponding ARP or ND information of each multi-path interface of nodes along the route.

Acknowledgements TBD

Contributors Huawei

China zhaoranxiao@huawei.com

Huawei

China rainsword.wang@huawei.com