File: rfc1393.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (395 lines) | stat: -rw-r--r-- 13,140 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
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]