Browse Prior Art Database

Traceroute Using an IP Option (RFC1393)

IP.com Disclosure Number: IPCOM000002217D
Original Publication Date: 1993-Jan-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 6 page(s) / 12K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Malkin: AUTHOR

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 text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 23% of the total text.

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

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