Traceroute Using an IP Option
RFC 1393

Document Type RFC - Historic (January 1993; No errata)
Obsoleted by RFC 6814
Was draft-malkin-traceroute (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1393 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
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        |
   +---------------+---------------+---------------+---------------+
Show full document text