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: 2019-Feb-11
Document File: 7 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

G. Malkin: AUTHOR

Related Documents

10.17487/RFC1393: DOI

Abstract

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. This memo defines an Experimental Protocol for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% 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

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

Processing...
Loading...