summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1393.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1393.txt')
-rw-r--r--doc/rfc/rfc1393.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc1393.txt b/doc/rfc/rfc1393.txt
new file mode 100644
index 0000000..f8dfdd6
--- /dev/null
+++ b/doc/rfc/rfc1393.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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]
+ \ No newline at end of file