]> 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 document extends the ICMP message with a 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.

Introduction As described in , Traceroute is a common TCP/IP tool, which allows 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 uses the ICMP Time Exceeded Message to collect the nodes' information along the route. The basic Traceroute can only collect the IP addresses, and host name of nodes along the route that packet forwarded. redefines some ICMP messages to support multi-part operation. It defines an extension structure which is situated at the end of the ICMP message to carry the additional information. The extension structure includes an extension header followed by one or more extension objects. Based on that, extends the ICMP messages to carry the interface information(including ifIndex, IPv4 address, IPv6 address, name and MTU) by defining a Interface Information Object. Furthermore, defines a new network diagnostic tool called PROBE. It can be used to query the status of a probed interface by sending ICMP Extended Echo Request message and receiving ICMP Extended Echo Reply message. The ICMP Extended Echo Reply message includes a "State" field to reflect the state of the ARP table or Neighbor Cache entry associated with the probed interface, which indicates whether the interface is reachable. However, the extended Echo Request message and Echo Reply message can only be used to probe the state of destination interface, cannot be used to probe the interface state of the nodes along the route. However, when using Traceroute in a multi-path topology, the Traceroute can only get information of one of the available paths. The head end and managers even don't know that there are multiple paths to the destination, which severely impacts the failure location of the network. This document extends the ICMP message with a 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.

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: ECMP: Equal-Cost Multiple Path ICMP: Internet Control Message Protocol

Motivation Traceroute is a common TCP/IP tool, which allows users to learn about the route that packets take from their local host to a remote host. However, Traceroute is typically used to collect the information of a single 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 the information of one of the available paths, and do not know that there are multiple paths. Considering using Traceroute in a DC multi-path topology, the topology is shown in :

A multi-path topology | +--------+ | | C | | | +------+ v +------+ +---+--+ +------+ +------+ | | |switch| |switch| | | | A |<-->| | | |<--->| F | | | | B | | E | | | +------+ +------+ +--+---+ +------+ ^ +------+ | | |switch| | +-----+ +---<----+ | D | +------+ ]]>

In , there are four switches and two endpoints. Equal-Cost Multiple Path (ECMP) is applied at switch B. Endpoint A initiates the Traceroute procedures and the target is endpoint F. When the Traceroute request packets arrived at switch B, B have two egress interfaces that can reach endpoint F, but it can only encapsulate one of the interfaces to the reply packet. For example, the interface to switch C is encapsulated. Then the path gets by traceroute is A->B->C->E->F. However, the traffic packets are forwarded on both paths (A->B->C->E->F and A->B->D->E->F). If switch D fails and affects packet forwarding (e.g. packet loss and latency increase), then it is hard for the users to locate the failure, because switch D is not in the forwarding path detected by the traceroute. Therefore, it is necessary to extend traceroute to enable the multi-path detection.

ICMP extension This section defines the Multi-path Interface Information (MPII) Object, an ICMP extension object with a new Class-Num (Object Class Value). The format of MPII Object is shown in .

Format of Multi-Path Interface Information (MPII) Object

Class-Num: TBD, to be allocated by IANA. C-Type: indicates different types of Multi-Path Interface Information, the descriptions of its values are shown as follows: Description of C-Type values

Value	Description
0	Reserved
1	IPv4 interface
2	IPv6 interface
3-255	Reserved

Sequence Num: 16-bit length, the sequence number of this interface in all of the multi-path interfaces. Total Num: 16-bit length, the total number of multi-path interfaces. Information Indicator: 32-bit length, indicates the followed multi-path interface information in the Object. The format of it is shown in .

Information Indicator Bit Description

The following are bit-field definitions for Information Indicator: ifIndex (bit 0) : When set, the 32-bit ifIndex of the interface is included. When clear, the ifIndex is not included. IP Addr (bit 1) : 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 . Name (bit 2): When set, an Interface Name Sub-Object is included. When clear, it is not included. The Name Sub-Object is described in . MTU (bit 3): When set, a 32-bit integer representing the MTU is present. When clear, this 32-bit integer is not present. NextHop (bit 4): When set, an IP Address Sub-Object for the nexthop is present. When clear, the IP Address Sub-Object for next hop is not present. When both the IP Addr and NextHop bits are set, two IP Address Sub-Objects will be encapsulated in the reply packet. In this case, these two sub-objects MUST be placed in order(the first IP Address Sub-Object is for IP Addr, and the second is for NextHop). State (bit 5): When set, an Interface State Sub-Object is included. When clear, it is not included. The Interface State Sub-Object is described in . Multi-path Interface Information: variable, carries the detail multi-path interface information as specified in the Information Indicator. The MPII Object can be appended to the following messages:

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

Interface State Sub-object The Interface State Sub-object indicates the state of the ARP table or Neighbor Cache entry associated with the interface. The format of it is shown in .

Format of Interface State Sub-object

Where: Length: 8-bit length, indicates the length of this sub-object in octets, its value equals to 4. State: the state of the ARP table or Neighbor Cache entry associated with the interface. Values are (0) Reserved, (1) Incomplete, (2) Reachable, (3) Stale, (4) Delay, (5) Probe, and (6) Failed. Reserved: This field MUST be set to 0 and ignored upon receipt.

Usage Multiple Multi-path Interface Information Object MAY be included within a single ICMP message, provided that each Multi-path Interface Information Object corresponds to a unique interface. A single ICMP message MUST NOT contain two Multi-path Interface Information Object that corresponds to the same interface. ifIndex, IPAddr, Name, MTU, NextHop, and State information MAY be included whenever they are available. For each kind of these information, at most one instance is included in per Multi-path Interface Information Object. The address format of IP Address Sub-Object in a Multi-path Interface Information Object depends on the C-Type:

• If the C-Type value is 1, which means it describes the information of an IPv4 interface. In this case, if an IP Address Sub-Object is included, it must specify an IPv4 address.
• If the C-Type value is 2, which means it describes the information of an IPv6 interface. In this case, if an IP Address Sub-Object is included, it must specify an IPv6 address.

An ICMP message that does not conform to these rules and contains multiple Multi-path Interface Information Object of the same interface is considered illegal; An Multi-path Interface Information Object containing more than one instance of each kind of information is considered illegal. If such an illegal ICMP message is received, it MUST be silently discarded.

Security Considerations This extension makes the ICMP messages carrying excessive information, malicious parties may obtain ingress and egress interface, next-hop, the reachable of next-hop (status of ARP and ND), and detailed information about load balancing paths (number of load balancing paths, next-hop and egress interface for each load balancing path, and corresponding ARP and ND reachability) through traceroute. Based on this information, some further information can be inferred. Considering this risk, it is necessary to formulate corresponding security policies as follows:

Configuration Network operators should have the capability to control the information carried by Traceroute reply packets. To achieve flexible control, the following capabilities should be supported on the device:

1. Enable/disable the capability for Traceroute reply packets to carry ingress and egress interface information.
2. Enable/disable the capability for Traceroute reply packets to carry the next hop and the reachability status of the next hop (ARP/ND status). It is recommended that this capability is not enabled by default.
3. Enable/disable the capability for Traceroute reply packets to carry the number and status of load balancing entries (ARP/ND status). It is recommended that this capability is not enabled by default.
4. Control based on the source IP of the request Traceroute packet, only certain IP addresses are allowed to initiate the corresponding Traceroute function.
5. All the above capabilities can be configured separately at the global and interface levels.

Encryption: As described in , Traceroute uses UDP packets to probe the forwarding path of packets through TTL expiration. For UDP packets, the payload part does not have a specific meaning for Traceroute. So, the payload of UDP packets can be extended to carry the encrypted information. In cases where the intermediate nodes do not recognize or the encrypted information does not match, the reply packets of Traceroute will only carry basic information.

IANA Considerations This document requests IANA to allocate a new Object value for Multi-path Interface Information Object from the "ICMP Extension Object Classes" registry:

Value	Description	Reference
TBD	ICMP Extension Object Classes registry	This document

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] This document describes a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884.

Acknowledgements TBD

Contributors Huawei

China zhaoranxiao@huawei.com

Huawei

China rainsword.wang@huawei.com