Extending ICMP for Multi-path

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 2 June 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

As described in [RFC2151], 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 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.¶

[RFC4884] 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, [RFC5837] extends the ICMP messages to carry the interface information(including ifIndex, IPv4 address, IPv6 address, name and MTU) by defining a Interface Information Object.¶

Futhuremore, [RFC8335] defines a new network diagnostic tool called PROBE. It can be used to query the status of a probed interface by sednding 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 extened Echo Request message and Echo Reply message can only be used to probe the state of destination interface, can not 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 avaialbe paths once. It can’t collect all the path’s information from source node to destination node at once.¶

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.¶

                          +------+
                          |switch|
                   ++---->|      +--------+
                   |      |  C   |        |
                   |      +------+        v
   +------+    +---+--+               +------+     +------+
   |      |    |switch|               |switch|     |      |
   |  A   |<-->|      |               |      |<--->|  F   |
   |      |    |  B   |               |  E   |     |      |
   +------+    +------+               +--+---+     +------+
                   ^     +------+        |
                   |     |switch|        |
                   +-----+      +---<----+
                         |  D   |
                         +------+

2. 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 Figure 2.¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Length                |  Class-Num    |  C-Type       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Sequence Num        |         Total Num             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Information Indicator(bit)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /              Multi-path Interface Information                 /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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:¶

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 Figure 3.¶

Bit    0        1        2      3         4         5       6-31
   +-------+---------+-------+------+----------+--------+---------+
   |ifIndex|IPAddr(1)|Name(1)|MTU(1)|NextHop(1)|State(1)|Reserved)|
   +-------+---------+-------+------+----------+--------+---------+

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 Section 4.2 of [RFC5837].¶

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 Section 4.3 of [RFC5837].¶

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 Section 2.1.¶

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¶

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Length    |State|                Reserved                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. 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.¶

4. 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 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:¶

5. 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:¶

6. References

Acknowledgements

TBD¶

Contributors

Authors' Addresses