Traceroute Using an IP Option

G. Malkin

doi:10.17487/RFC1393

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC1393

Obsoleted by: 6814 HISTORIC

Network Working Group                                          G. Malkin
Request for Comments: 1393                                Xylogics, Inc.
                                                            January 1993

Traceroute Using an IP Option

Status of this Memo

This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract

Traceroute serves as a valuable network debugging tool. The way in which it is currently implemented has the advantage of being automatically supported by all of the routers. It's two problems are the number of packets it generates and the amount of time it takes to run.

This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time.

Table of Contents

1. Traceroute Today . . . . . . . . . . . . . . . . . . . . . 2
2. Traceroute Tomorrow . . . . . . . . . . . . . . . . . . . . 2
2.1 Basic Algorithm . . . . . . . . . . . . . . . . . . . . . . 2
2.2 IP Traceroute option format . . . . . . . . . . . . . . . . 3
2.3 ICMP Traceroute message format . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Hop Counts . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Destination Node Operation . . . . . . . . . . . . . . . . 6
3.3 Router Operation . . . . . . . . . . . . . . . . . . . . . 6
4. References . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . 7
6. Author's Address . . . . . . . . . . . . . . . . . . . . . 7

Malkin                                                          [Page 1]


RFC 1393                       Traceroute                   January 1993
1.  Traceroute Today

The existing traceroute operates by sending out a packet with a Time To Live (TTL) of 1. The first hop then sends back an ICMP [1] error message indicating that the packet could not be forwarded because the TTL expired. The packet is then resent with a TTL of 2, and the second hop returns the TTL expired. This process continues until the destination is reached. The purpose behind this is to record the source of each ICMP TTL exceeded message to provide a trace of the path the packet took to reach the destination.

The advantage of this algorithm, is that every router already has the ability to send TTL exceeded messages. No special code is required. The disadvantages are the number of packets generated (2n, where n is the number of hops), the time it takes to duplicate all the nearer hops with each successive packet, and the fact that the path may change during this process. Also, this algorithm does not trace the return path, which may differ from the outbound path.

2.  Traceroute Tomorrow

The proposed traceroute would use a different algorithm to achieve the same goal, namely, to trace the path to a host. Because the new traceroute uses an ICMP message designed for the purpose, additional information, unavailable to the original traceroute user, can be made available.

2.1 Basic Algorithm

A new IP Traceroute option will be defined. The presence of this option in an ICMP Echo (or any other) packet, hereinafter referred to as the Outbound Packet, will cause a router to send the newly defined ICMP Traceroute message to the originator of the Outbound Packet. In this way, the path of the Outbound Packet will be logged by the originator with only n+1 (instead of 2n) packets. This algorithm does not suffer from a changing path and allows the response to the Outbound Packet, hereinafter refered to as the Return Packet, to be traced (provided the Outbound Packet's destination preserves the IP Traceroute option in the Return Packet).

The disadvantage of this method is that the traceroute function will have to be put into the routers. To counter this disadvantage, however, is the fact that this mechanism may be easily ported to a new IP version.

Malkin                                                          [Page 2]


RFC 1393                       Traceroute                   January 1993
2.2 IP Traceroute option format

    0               8              16              24
   +-+-+-+-+-+-+-+-+---------------+---------------+---------------+
   |F| C |  Number |    Length     |          ID Number            |
   +-+-+-+-+-+-+-+-+---------------+---------------+---------------+
   |      Outbound Hop Count       |       Return Hop Count        |
   +---------------+---------------+---------------+---------------+
   |                     Originator IP Address                     |
   +---------------+---------------+---------------+---------------+

F (copy to fragments)

0 (do not copy to fragments)

C (class)

2 (Debugging & Measurement)

Number

18 (F+C+Number = 82)

ID Number

An arbitrary number used by the originator of the Outbound Packet to identify the ICMP Traceroute messages. It is NOT related to the ID number in the IP header.

Originator IP Address

The IP address of the originator of the Outbound Packet. This is needed so the routers know where to send the ICMP Traceroute message for Return Packets. It is also needed for Outbound Packets which have a Source Route option.

Outbound Hop Count (OHC)

The number of routers through which the Outbound Packet has passed. This field is not incremented by the Outbound Packet's destination.

Return Hop Count (RHC)

The number of routers through which the Return Packet has passed. This field is not incremented by the Return Packet's destination.

Malkin                                                          [Page 3]


RFC 1393                       Traceroute                   January 1993
2.3  ICMP Traceroute message format

    0               8              16              24
   +---------------+---------------+---------------+---------------+
   |     Type      |     Code      |           Checksum            |
   +---------------+---------------+---------------+---------------+
   |           ID Number           |            unused             |
   +---------------+---------------+---------------+---------------+
   |      Outbound Hop Count       |       Return Hop Count        |
   +---------------+---------------+---------------+---------------+
   |                       Output Link Speed                       |
   +---------------+---------------+---------------+---------------+
   |                        Output Link MTU                        |
   +---------------+---------------+---------------+---------------+

Type

30

Code

0 - Outbound Packet successfully forwarded 1 - No route for Outbound Packet; packet discarded

Checksum

The 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For computing the checksum, the checksum field should be zero.

ID Number

The ID Number as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent. This is NOT related to the ID number in the IP header.

Outbound Hop Count

The Outbound Hop Count as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent.

Return Hop Count

The Return Hop Count as copied from the IP Traceroute option of the packet which caused this Traceroute message to be sent.

Malkin                                                          [Page 4]


RFC 1393                       Traceroute                   January 1993

Output Link Speed

The speed, in OCTETS per second, of the link over which the Outbound/Return Packet will be sent. Since it will not be long before network speeds exceed 4.3Gb/s, and since some machines deal poorly with fields longer than 32 bits, octets per second was chosen over bits per second. If this value cannot be determined, the field should be set to zero.

Output Link MTU

The MTU, in bytes, of the link over which the Outbound/Return Packet will be sent. MTU refers to the data portion (includes IP header; excludes datalink header/trailer) of the packet. If this value cannot be determined, the field should be set to zero.

3.  Protocol

The Outbound Packet which is used to carry the IP Traceroute option should use no special Type Of Service (TOS) or Precedence, unless the purpose is to trace the path of packets with special TOS or Precedence values.

The TTL of the Outbound Packet should be set to the default value specified in "Assigned Numbers" [2].

3.1 Hop Counts

The hop counts ultimately provide information on the length of the outbound and return paths to the destination. They also provide a means of determining whether or not any ICMP Traceroute messages have been lost. For example, if a Traceroute message with an OHC of 4 is followed by a message with an OHC of 6, then the the message with an OHC of 5 was lost. This is why simply counting Traceroute messages is not sufficient for determining path length.

The originator of the Outbound Packet should set the OHC to zero and the RHC to 0xFFFF. 0xFFFF is a special value which indicates to routers that the packet is an Outbound Packet rather than a Return Packet (which begins with an RHC of zero).

It is important to note that the Traceroute hop counts are NOT related to the IP TTL. A hop count should only be incremented when an ICMP Traceroute message is sent.

Malkin                                                          [Page 5]


RFC 1393                       Traceroute                   January 1993
3.2 Destination Node Operation

When a node receives an Outbound Packet with an IP Traceroute option, the Return Packet, if such is required (e.g., ICMP Echo Request/Reply), should also carry that option. The values in the ID Number, OHC, and Originator Address fields should be copied into the Return Packet. The value of the RHC field should be set to zero.

The destination should NOT increment any hop counts or send any ICMP Traceroute messages.

3.3 Router Operation

When a router forwards a packet with an IP Traceroute option, it should send an ICMP Traceroute message to the host in the Originator IP Address field of the option. If the value of the RHC field is 0xFFFF then the packet is an Outbound Packet and the OHC should be incremented; otherwise, the RHC field should be incremented. The Traceroute message should reflect the incremented hop count. The Output Link Speed field should be set to the speed, in OCTETS per second, of the link over which the Outbound/Return Packet will be sent (e.g., 1,250,000 for an Ethernet) or zero if the output link speed cannot be determined. The Output Link MTU field should be set to the MTU of the link over which the Outbound/Return Packet will be sent or zero if the MTU cannot be determined.

The Outbound/Return Packet should be forwarded as though the Traceroute option did not exist; that is, it should take the same path to the destination as an optionless packet.

The ICMP Traceroute message should have the same TOS and Precedence values as the Outbound/Return Packet. The TTL should be set to the default defined in "Assigned Numbers".

The ICMP Traceroute message should not carry the IP Traceroute option.

If the Outbound Packet cannot be forwarded, the ICMP Traceroute message should have a Code value of 1. If the Return Packet cannot be forwarded because there is no route, then there is no need to send a Traceroute message since it could not be forwarded either.

Malkin                                                          [Page 6]


RFC 1393                       Traceroute                   January 1993
4.  References

[1] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981.

[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.

5.  Security Considerations

Security issues are not discussed in this memo.

6.  Author's Address

Gary Scott Malkin Xylogics, Inc. 53 Third Avenue Burlington, MA 01803

Phone: (617) 272-8140 EMail: gmalkin@Xylogics.COM

Malkin [Page 7]

Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.