As per Relevance of the word originator, we have this rfc below:
Network Working Group G.
Request for Comments: 1393 Xylogics, Inc
January 1993
Traceroute Using an IP
Status of this
This memo defines an Experimental Protocol for the
community. Discussion and suggestions for improvement are requested
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
Traceroute serves as a valuable network debugging tool. The way
which it is currently implemented has the advantage of
automatically supported by all of the routers. It's two problems
the number of packets it generates and the amount of time it takes
run
This document specifies a new IP option and ICMP message type
duplicates the functionality of the existing traceroute method
generating fewer packets and completing in a shorter time
Table of
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
The existing traceroute operates by sending out a packet with a
To Live (TTL) of 1. The first hop then sends back an ICMP [1]
message indicating that the packet could not be forwarded because
TTL expired. The packet is then resent with a TTL of 2, and
second hop returns the TTL expired. This process continues until
destination is reached. The purpose behind this is to record
source of each ICMP TTL exceeded message to provide a trace of
path the packet took to reach the destination
The advantage of this algorithm, is that every router already has
ability to send TTL exceeded messages. No special code is required
The disadvantages are the number of packets generated (2n, where n
the number of hops), the time it takes to duplicate all the
hops with each successive packet, and the fact that the path
change during this process. Also, this algorithm does not trace
return path, which may differ from the outbound path
2. Traceroute
The proposed traceroute would use a different algorithm to
the same goal, namely, to trace the path to a host. Because the
traceroute uses an ICMP message designed for the purpose,
information, unavailable to the original traceroute user, can be
available
2.1 Basic
A new IP Traceroute option will be defined. The presence of
option in an ICMP Echo (or any other) packet, hereinafter referred
as the Outbound Packet, will cause a router to send the newly
ICMP Traceroute message to the originator of the Outbound Packet.
this way, the path of the Outbound Packet will be logged by
originator with only n+1 (instead of 2n) packets. This
does not suffer from a changing path and allows the response to
Outbound Packet, hereinafter refered to as the Return Packet, to
traced (provided the Outbound Packet's destination preserves the
Traceroute option in the Return Packet).
The disadvantage of this method is that the traceroute function
have to be put into the routers. To counter this disadvantage
however, is the fact that this mechanism may be easily ported to
new IP version
Malkin [Page 2]
RFC 1393 Traceroute January 1993
2.2 IP Traceroute option
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
18 (F+C+Number = 82)
ID
An arbitrary number used by the originator of the Outbound
to identify the ICMP Traceroute messages. It is NOT related
the ID number in the IP header
Originator IP
The IP address of the originator of the Outbound Packet. This
needed so the routers know where to send the ICMP
message for Return Packets. It is also needed for
Packets which have a Source Route option
Outbound Hop Count (OHC
The number of routers through which the Outbound Packet
passed. This field is not incremented by the Outbound Packet'
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
0 8 16 24
+---------------+---------------+---------------+---------------+
| Type | Code | Checksum |
+---------------+---------------+---------------+---------------+
| ID Number | unused |
+---------------+---------------+---------------+---------------+
| Outbound Hop Count | Return Hop Count |
+---------------+---------------+---------------+---------------+
| Output Link Speed |
+---------------+---------------+---------------+---------------+
| Output Link MTU |
+---------------+---------------+---------------+---------------+
30
0 - Outbound Packet successfully
1 - No route for Outbound Packet; packet
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
field should be zero
ID
The ID Number as copied from the IP Traceroute option of
packet which caused this Traceroute message to be sent. This
NOT related to the ID number in the IP header
Outbound Hop
The Outbound Hop Count as copied from the IP Traceroute option
the packet which caused this Traceroute message to be sent
Return Hop
The Return Hop Count as copied from the IP Traceroute option
the packet which caused this Traceroute message to be sent
Malkin [Page 4]
RFC 1393 Traceroute January 1993
Output Link
The speed, in OCTETS per second, of the link over which
Outbound/Return Packet will be sent. Since it will not be
before network speeds exceed 4.3Gb/s, and since some machines
poorly with fields longer than 32 bits, octets per second
chosen over bits per second. If this value cannot be determined
the field should be set to zero
Output Link
The MTU, in bytes, of the link over which the Outbound/
Packet will be sent. MTU refers to the data portion (includes
header; excludes datalink header/trailer) of the packet. If
value cannot be determined, the field should be set to zero
3.
The Outbound Packet which is used to carry the IP Traceroute
should use no special Type Of Service (TOS) or Precedence, unless
purpose is to trace the path of packets with special TOS
Precedence values
The TTL of the Outbound Packet should be set to the default
specified in "Assigned Numbers" [2].
3.1 Hop
The hop counts ultimately provide information on the length of
outbound and return paths to the destination. They also provide
means of determining whether or not any ICMP Traceroute messages
been lost. For example, if a Traceroute message with an OHC of 4
followed by a message with an OHC of 6, then the the message with
OHC of 5 was lost. This is why simply counting Traceroute
is not sufficient for determining path length
The originator of the Outbound Packet should set the OHC to zero
the RHC to 0xFFFF. 0xFFFF is a special value which indicates
routers that the packet is an Outbound Packet rather than a
Packet (which begins with an RHC of zero).
It is important to note that the Traceroute hop counts are
related to the IP TTL. A hop count should only be incremented
an ICMP Traceroute message is sent
Malkin [Page 5]
RFC 1393 Traceroute January 1993
3.2 Destination Node
When a node receives an Outbound Packet with an IP Traceroute option
the Return Packet, if such is required (e.g., ICMP
Request/Reply), should also carry that option. The values in the
Number, OHC, and Originator Address fields should be copied into
Return Packet. The value of the RHC field should be set to zero
The destination should NOT increment any hop counts or send any
Traceroute messages
3.3 Router
When a router forwards a packet with an IP Traceroute option,
should send an ICMP Traceroute message to the host in the
IP Address field of the option. If the value of the RHC field
0xFFFF then the packet is an Outbound Packet and the OHC should
incremented; otherwise, the RHC field should be incremented.
Traceroute message should reflect the incremented hop count.
Output Link Speed field should be set to the speed, in OCTETS
second, of the link over which the Outbound/Return Packet will
sent (e.g., 1,250,000 for an Ethernet) or zero if the output
speed cannot be determined. The Output Link MTU field should be
to the MTU of the link over which the Outbound/Return Packet will
sent or zero if the MTU cannot be determined
The Outbound/Return Packet should be forwarded as though
Traceroute option did not exist; that is, it should take the
path to the destination as an optionless packet
The ICMP Traceroute message should have the same TOS and
values as the Outbound/Return Packet. The TTL should be set to
default defined in "Assigned Numbers".
The ICMP Traceroute message should not carry the IP
option
If the Outbound Packet cannot be forwarded, the ICMP
message should have a Code value of 1. If the Return Packet
be forwarded because there is no route, then there is no need to
a Traceroute message since it could not be forwarded either
Malkin [Page 6]
RFC 1393 Traceroute January 1993
4.
[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
Security issues are not discussed in this memo
6. Author's
Gary Scott
Xylogics, Inc
53 Third
Burlington, MA 01803
Phone: (617) 272-8140
EMail: gmalkin@Xylogics.
Malkin [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
