idnits 2.17.1 draft-malkin-traceroute-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 1992) is 11509 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 281 looks like a reference -- Missing reference section? '2' on line 284 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Malkin 3 Internet Draft Xylogics 4 October 1992 6 Traceroute 8 Abstract 10 Traceroute serves as a valuable network debugging tool. The way in 11 which it is currently implemented has the advantage of being 12 automatically supported by all of the routers. It's two problems are 13 the number of packets it generates and the amount of time it takes to 14 run. 16 This document specifies a new IP option and ICMP message type which 17 duplicates the functionality of the existing traceroute method while 18 generating fewer packets and completing in a shorter time. 20 Status of this Memo 22 This document is an Internet Draft. Internet Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its Areas, 24 and its Working Groups. Note that other groups may also distribute 25 working documents as Internet Drafts). 27 Internet Drafts are draft documents valid for a maximum of six 28 months. Internet Drafts may be updated, replaced, or obsoleted by 29 other documents at any time. It is not appropriate to use Internet 30 Drafts as reference material or to cite them other than as a "working 31 draft" or "work in progress." 33 Please check the I-D abstract listing contained in each Internet 34 Draft directory to learn the current status of this or any other 35 Internet Draft. 37 It is intended that this document will be submitted to the IESG for 38 consideration as a standards document. Distribution of this document 39 is unlimited. 41 Table of Contents 43 1. Traceroute Today . . . . . . . . . . . . . . . . . . . . . 2 44 2. Traceroute Tomorrow . . . . . . . . . . . . . . . . . . . . 2 45 2.1 Basic Algorithm . . . . . . . . . . . . . . . . . . . . . . 2 46 2.2 IP Traceroute option format . . . . . . . . . . . . . . . . 3 47 2.3 ICMP Traceroute message format . . . . . . . . . . . . . . 4 48 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.1 Hop Counts . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3.2 Destination Node Operation . . . . . . . . . . . . . . . . 6 51 3.3 Router Operation . . . . . . . . . . . . . . . . . . . . . 6 52 4. References . . . . . . . . . . . . . . . . . . . . . . . . 6 53 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 54 6. Author's Address . . . . . . . . . . . . . . . . . . . . . 7 56 1. Traceroute Today 58 The existing traceroute operates by sending out a packet with a Time 59 To Live (TTL) of 1. The first hop then sends back an ICMP [1] error 60 message indicating that the packet could not be forwarded because the 61 TTL expired. The packet is then resent with a TTL of 2, and the 62 second hop returns the TTL expired. This process continues until the 63 destination is reached. The purpose behind this is to record the 64 source of each ICMP TTL exceeded message to provide a trace of the 65 path the packet took to reach the destination. 67 The advantage of this algorithm, is that every router already has the 68 ability to send TTL exceeded messages. No special code is required. 69 The disadvantages are the number of packets generated (2n, where n is 70 the number of hops), the time it takes to duplicate all the nearer 71 hops with each successive packet, and the fact that the path may 72 change during this process. Also, this algorithm does not trace the 73 return path, which may differ from the outbound path. 75 2. Traceroute Tomorrow 77 The proposed traceroute would use a different algorithm to achieve 78 the same goal, namely, to trace the path to a host. Because the new 79 traceroute uses an ICMP message designed for the purpose, additional 80 information, unavailable to the original traceroute user, can be made 81 available. 83 2.1 Basic Algorithm 85 A new IP Traceroute option will be defined. The presence of this 86 option in a ICMP Echo (or any other) packet will cause a router to 87 send the newly defined ICMP Traceroute message to the originator of 88 the packet. In this way, the outbound path of the packet will be 89 logged by the originator with only n+1 (instead of 2n) packets. This 90 algorithm does not suffer from a changing path and allows the return 91 packet's path to be traced (provided the destination preserves the IP 92 Traceroute option. 94 The disadvantage of this method is that the traceroute function will 95 have to be put into the routers. To counter this disadvantage, 96 however, is the fact that this mechanism is easily ported to the new 97 IP version 7 work which is being done in the IETF. 99 2.2 IP Traceroute option format 101 0 8 16 24 102 +-+-+-+-+-+-+-+-+---------------+---------------+---------------+ 103 |F| C | Number | Length | ID Number | 104 +-+-+-+-+-+-+-+-+---------------+---------------+---------------+ 105 | Originator IP Address | 106 +---------------+---------------+---------------+---------------+ 107 | OHC | RHC | 108 +- - - - - - - -+- - - - - - - -+ 110 F (copy to fragments) 112 0 (do not copy to fragments) 114 C (class) 116 2 (Debugging & Measurement) 118 Number 120 To Be Assigned 122 ID Number 124 An arbitrary number used by the originator of the ping packet to 125 identify the ICMP Traceroute messages. 127 Originator IP Address 129 The IP address of the originator of the ping packet. 131 OHC (Outbound Hop Count) 133 The number of routers through which the outbound ping packet has 134 passed. The OHC field is optional. If the length of the option 135 is 8, then there are no hop counts. If the length is 9 136 (indicating that this is the outgoing packet), then there is an 137 OHC which must be incremented by each router (but NOT the 138 destination). If the length is 10 (indicating that this is the 139 return packet), then the OHC is not incremented. 141 RHC (Return Hop Count) 143 The number of routers through which the return packet has passed. 145 The RHC field is optional. If the length of the option is less 146 than 10, then there is no RHC to increment. If the length is 10, 147 then the RHC must be incremented by each router (but NOT the 148 originator, which is the destination of the return packet). 150 2.3 ICMP Traceroute message format 152 0 8 16 24 153 +---------------+---------------+---------------+---------------+ 154 | Type | Code | Checksum | 155 +---------------+---------------+---------------+---------------+ 156 | ID Number | OHC | RHC | 157 +---------------+---------------+---------------+---------------+ 158 | Output Link Speed | 159 +---------------+---------------+---------------+---------------+ 160 | Output Link MTU | unused | 161 +---------------+---------------+---------------+---------------+ 163 Type 165 To Be Assigned 167 Code 169 0 - Outbound ping packet successfully forwarded 170 1 - No route for outbound ping packet; packet discarded 172 Checksum 174 The 16 bit one's complement of the one's complement sum of all 16 175 bit words in the header. For computing the checksum, the checksum 176 field should be zero. 178 ID Number 180 The ID Number as copied from the IP Traceroute option of the 181 packet which caused this Traceroute message to be sent. 183 OHC 185 The Outbound Hop Count as copied from the IP Traceroute option of 186 the packet which caused this Traceroute message to be sent. If 187 there is no OHC is the Traceroute option, this field will have a 188 value of zero. 190 RHC 192 The Return Hop Count as copied from the IP Traceroute option of 193 the packet which caused this Traceroute message to be sent. If 194 there is no RHC is the Traceroute option, this field will have a 195 value of zero. 197 Output Link Speed 199 The speed, in bits per second, of the link over which the ping 200 packet will be sent. If this value cannot be determined, the 201 field should be set to zero. 203 Output Link MTU 205 The MTU, in bytes, of the link over which the ping packet will be 206 sent. MTU refers to the data portion (includes IP header; 207 excludes datalink header/trailer) of the packet. If this value 208 cannot be determined, the field should be set to zero. 210 3. Protocol 212 The ping packet which is used to carry the IP Traceroute option 213 should use no special Type Of Service (TOS) or Precedence, unless the 214 purpose is to trace the path of packets with special TOS or 215 Precedence values. 217 The TTL of the ping packet should be set to the default value 218 specified in "Assigned Numbers" [2]. 220 3.1 Hop Counts 222 The hop count fields in the IP Traceroute option are optional. By 223 not including them (and specifying an option length of 8), the 224 routers will have less to do (no increment or checksum 225 recalculation). The hop counts may be used to detect the loss of 226 ICMP Traceroute messages. If the number of Traceroute messages 227 received is less than the hop count, then some Traceroute messages 228 were lost. 230 To use hop counts, the originator sets the option length to 9 and 231 pads the option with 4 zero bytes (OHC, RHC and 2 end-of-option-list 232 options). When a router sees a Traceroute option with a length of 9, 233 it increments the OHC by one before generating the ICMP Traceroute 234 message. When a router sees a Traceroute option with a length of 10, 235 it increments the RHC by one before generating the ICMP Traceroute 236 message. 238 It is important to note that the Traceroute hop counts are NOT the 239 same as the IP TTL. A hop count should only be incremented when an 240 ICMP Traceroute message is sent. 242 3.2 Destination Node Operation 244 When a destination node receives a ping packet with an IP Traceroute 245 option, the return packet should also carry that option. The value 246 in the ID Number field should be copied into the return packet. If 247 the option length is 9 (outbound hops were being counted), the value 248 of the OHC field should also be copied and the option length 249 increased to 10. The destination should NOT increment any hop 250 counts. 252 3.3 Router Operation 254 When a router forwards a ping packet with an IP Traceroute option, it 255 should send an ICMP Traceroute message to the IP address in the 256 Originator IP Address field of the option. If the Traceroute option 257 length is 9, the OHC field should be incremented. If the option 258 length is 10, the RHC field should be incremented. The Traceroute 259 message should reflect the incremented hop count. The Output Link 260 Speed field should be set to the speed of the link over which the 261 ping packet will be sent (e.g. 10,000,000 for an Ethernet), or zero 262 if the output link speed cannot be determined. The Output Link MTU 263 field should be set to the MTU of the link over which the ping packet 264 will be sent or zero if the MTU cannot be determined. 266 The ping packet should be forwarded as though the Traceroute option 267 did not exist; that is, it should take the same path to the 268 destination. 270 The ICMP Traceroute message should have TOS and Precedence values of 271 zero (default). The TTL should be set to the default defined in 272 "Assigned Numbers". 274 If the outbound ping packet cannot be forwarded, the ICMP Traceroute 275 message should have a Code value of one. If the return ping packet 276 cannot be forwarded because there is no route, then there is no need 277 to send a Traceroute message since it could not be forwarded either. 279 4. References 281 [1] Postel, J., "Internet Control Message Protocol", RFC 792, 282 USC/Information Sciences Institute, September 1981. 284 [2] Reynolds, J., J. Postel, "Assigned Numbers", RFC 1340, 285 USC/Information Sciences Institute, July, 1992. 287 5. Security Considerations 289 Security is not discussed in this memo. 291 6. Author's Address 293 Gary Scott Malkin 294 Xylogics, Inc. 295 53 Third Avenue 296 Burlington, MA 01803 298 Phone: (617) 272-8140 299 EMail: gmalkin@Xylogics.COM