idnits 2.17.1 draft-ietf-idmr-traceroute-ipm-00.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-26) 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. == 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 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.) ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '...working docu-...' == Line 15 has weird spacing: '...t other group...' == Line 16 has weird spacing: '...cuments as In...' == Line 19 has weird spacing: '... may be updat...' == Line 20 has weird spacing: '...other documen...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 13, 1995) is 10392 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Inter-Domain Multicast Routing Working Group 2 INTERNET-DRAFT W. Fenner 3 draft-ietf-idmr-traceroute-ipm-00.txt Xerox PARC 4 S. Casner 5 Precept Software 6 November 13, 1995 7 Expires: 3/31/95 9 A "traceroute" facility for IP Multicast. 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working docu- 14 ments of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a 22 "working draft" or "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Distribution of this document is unlimited. 32 Abstract 34 This draft describes the IGMP multicast traceroute facility. As 35 the deployment of IP multicast has spread, it has become clear that 36 a method for tracing the route that a multicast IP packet takes 37 from a source to a particular receiver is absolutely required. 38 Unlike unicast traceroute, multicast traceroute requires a special 39 packet type and implementation on the part of routers. This 40 specification describes the required functionality. 42 This document is a product of the Inter-Domain Multicast Routing working 43 group within the Internet Engineering Task Force. Comments are soli- 44 cited and should be addressed to the working group's mailing list at 45 idmr@cs.ucl.ac.uk and/or the author(s). 47 1. Introduction 49 The unicast "traceroute" program allows the tracing of a path from one 50 machine to another, using mechanisms that already existed in IP. Unfor- 51 tunately, no such existing mechanisms can be applied to IP multicast 52 paths. The key mechanism for unicast traceroute is the ICMP TTL exceeded 53 message, which is specifically precluded as a response to multicast 54 packets. Thus, we specify the multicast "traceroute" facility to be 55 implemented in multicast routers and accessed by diagnostic programs. 56 While it is a disadvantage that a new mechanism is required, the multi- 57 cast traceroute facility can provide additional information about packet 58 rates and losses that the unicast traceroute cannot, and generally 59 requires fewer packets to be sent. 61 Goals: 63 + To be able to trace the path that a packet would take from some 64 source to some destination. 66 + To be able to isolate packet loss problems (e.g., congestion). 68 + To be able to isolate configuration problems (e.g., TTL threshold). 70 + To minimize packets sent (e.g. no flooding, no implosion). 72 2. Overview 74 Tracing from a source to a multicast destination is hard, since you 75 don't know down which branch of the multicast tree the destination lies. 76 This means that you have to flood the whole tree to find the path from 77 one source to one destination. However, walking up the tree from desti- 78 nation to source is easy, as all existing multicast routing protocols 79 know the previous hop for each source. Tracing from destination to 80 source can involve only routers on the direct path. 82 The party requesting the traceroute (which need be neither the source 83 nor the destination) sends a traceroute request packet to the last-hop 84 multicast router for the given destination. The last-hop router adds a 85 response data block to the request packet containing its interface 86 addresses and packet statistics, and then forwards the request packet 87 via unicast to the router that it believes is the proper previous hop 88 for the given source. Each hop adds its response data to the end of the 89 request packet, then unicast forwards it to the previous hop. The first 90 hop router (the router that believes that packets from the source ori- 91 ginate on one of its directly connected networks) changes the packet 92 type to indicate a response packet and sends the completed response to 93 the response destination address. The response may be returned before 94 reaching the first hop router if an error condition such as "no route" 95 is encountered along the path. 97 3. Request / Response header 99 The header for both requests and responses is as follows: 101 0 1 2 3 102 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | IGMP Type | # hops | checksum | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Multicast Group Address | 107 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 108 | Source Address | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Destination Address | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Response Address | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | resp ttl | Query ID | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 3.1. IGMP Type: 8 bits 119 The IGMP type field is defined to be 0x1F for traceroute requests 120 sent to the last hop router and forwarded hop by hop towards the 121 source. The IGMP type field is changed to 0x1E when the packet is 122 completed and sent as a response from the first hop router to the 123 querier. Two codes are required so that multicast routers won't 124 attempt to process a completed response in those cases where the 125 initial query was issued from a router or the response is sent via 126 multicast. 128 3.2. # hops: 8 bits 130 This field specifies the maximum number of hops that the requester 131 wants to trace. If there is some error condition in the middle of 132 the path that keeps the traceroute request from reaching the 133 first-hop router, this field can be used to perform an expanding- 134 length search to trace the path to just before the problem. 136 3.3. Checksum: 16 bits 138 This is the standard IGMP checksum. 140 3.4. Group address 142 This field specifies the group address to be traced. 144 3.5. Source address 146 This field specifies the IP address of the multicast source for the 147 path being traced. The traceroute request proceeds hop-by-hop from 148 the intended multicast receiver towards this source. 150 3.6. Destination address 152 This field specifies the IP address of the multicast receiver for 153 the path being traced. The trace starts at this destination and 154 proceeds toward the source. 156 3.7. Response Address 158 This field specifies where the completed traceroute response packet 159 gets sent. It can be a unicast address or a multicast address, as 160 explained in section 5.2. 162 3.8. resp ttl: 8 bits 164 This field specifies the TTL at which to multicast the response, if 165 the response address is a multicast address. 167 3.9. Query ID: 24 bits 169 This field is used as a unique identifier for this traceroute 170 request so that duplicate or delayed responses may be detected and 171 to minimize collisions when a multicast response address is used. 173 4. Response data 175 Each router adds a "response data" segment to the traceroute packet be- 176 fore it forwards it on. The response data looks like this: 178 0 1 2 3 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Query Arrival Time | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Incoming Interface Address | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Outgoing Interface Address | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Previous-Hop Router Address | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Input packet count on incoming interface | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Output packet count on outgoing interface | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Total number of packets for this source-group pair | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Rtg Protocol | FwdTTL |MBZ| Src Mask | ForwardingErr | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 4.1. Query Arrival Time 200 The Query Arrival Time is a 32-bit NTP timestamp specifying the 201 arrival time of the traceroute request packet at this router. The 202 32-bit form of an NTP timestamp consists of the middle 32 bits of 203 the full 64-bit form; that is, the low 16 bits of the integer part 204 and the high 16 bits of the fractional part. 206 4.2. Incoming Interface Address 208 This field specifies the address of the interface on which packets 209 from this source are expected to arrive, or 0 if unknown. 211 4.3. Outgoing Interface Address 213 This field specifies the address of the interface on which packets 214 from this source flow to the specified destination, or 0 if unk- 215 nown. 217 4.4. Previous-Hop Router Address 219 This field specifies the router from which this router expects 220 packets from this source, or 0 if unknown. 222 4.5. Input packet count on incoming interface 224 This field contains the number of multicast packets received for 225 all groups and sources on the incoming interface, or 0xffffffff if 226 no count can be reported. 228 4.6. Output packet count on outgoing interface 230 This field contains the number of multicast packets that have been 231 transmitted for all groups and sources on the outgoing interface, 232 or 0xffffffff if no count can be reported. 234 4.7. Total number of packets for this source-group pair 236 This field counts the number of packets from the specified source 237 forwarded by this router to the specified group, or 0xffffffff if 238 no count can be reported. 240 4.8. Rtg Protocol: 8 bits 242 This field describes the routing protocol in use between this 243 router and the previous-hop router. Specified values include: 245 1 - DVMRP 246 2 - MOSPF 247 3 - PIM 248 4 - CBT 250 4.9. FwdTTL: 8 bits 252 This field contains the TTL that a packet is required to have 253 before it will be forwarded over the outgoing interface. 255 4.10. Src Mask: 6 bits 257 This field contains the number of 1's in the netmask this router 258 has for the source (i.e. a value of 24 means the netmask is 259 0xffffff00) 261 4.11. ForwardingErr: 8 bits 263 This field contains a forwarding error code. Specified values 264 include: 266 0x00 No error 267 0x01 Traceroute request arrived on an interface 268 that is not the proper outgoing interface 269 for this source,group,destination. 270 0x02 This router has sent a prune upstream for the group. 271 0x03 The next hop router has pruned the group. 272 0x04 The group is subject to administrative scoping at this hop. 273 0x05 This router has no route for the source. 274 0x07 This router is not forwarding this source,group 275 for an unspecified reason. 276 0x81 There was not enough room to insert another response data block 277 in the packet. 278 0x82 The next hop router does not understand traceroute requests. 280 Note that if a router discovers there is not enough room in a 281 packet to insert its response, it puts the 0x81 error code in the 282 previous router's ForwardingErr field, overwriting any error the 283 previous router placed there. It is expected that a multicast tra- 284 ceroute client, upon receiving this error, will restart the trace 285 at the last hop listed in the packet. 287 The 0x80 bit of the ForwardingErr code is used to indicate a fatal 288 error. A fatal error is one that causes a router to be unable to 289 forward this traceroute request on to the next hop. 291 <<< Note that 0x01 and 0x05 should be fatal, but renumbering would 292 be painful as backwards-compatibility is required. It's not clear 293 that an explicit fatal bit is required because a response issued 294 when the number of hops has not reached the maximum indicates that 295 the trace cannot go further. Feedback from implementors is 296 requested. >>> 298 5. Using multicast traceroute 300 Several problems may arise when attempting to use multicast traceroute. 302 5.1. Last hop router 304 The traceroute querier may not know which is the last hop router, 305 or that router may be behind a firewall that blocks unicast packets 306 but passes multicast packets. In these cases, the traceroute 307 request should be multicasted to the group being traced (since the 308 last hop router listens to that group). All routers except the 309 correct last hop router should ignore any multicast traceroute 310 request received via multicast. 312 5.2. First hop router 314 The traceroute querier may not be unicast reachable from the first 315 hop router. In this case, the querier should set the traceroute 316 response address to a multicast address, and should set the 317 response TTL to a value sufficient for the response from the first 318 hop router to reach the querier. It may be appropriate to start 319 with a small TTL and increase in subsequent attempts until a suffi- 320 cient TTL is reached, up to an appropriate maximum (such as 192). 322 The IANA has assigned 224.0.1.32, MTRACE.MCAST.NET, as the standard 323 multicast group for multicast traceroute responses. 325 5.3. Broken intermediate router 327 A broken intermediate router might simply not understand traceroute 328 packets, and drop them. The querier would then get no response at 329 all from its traceroute requests. It should then perform a search 330 by setting the number of responses field until it gets a response 331 (both linear and binary search are options, but binary is likely to 332 be slower because a failure requires waiting for a timeout). 334 6. Problem Diagnosis 336 6.1. Forwarding Inconsistencies 338 The forwarding error code can tell if a group is unexpectedly 339 pruned or administratively scoped. 341 6.2. TTL problems 343 By taking the maximum of (hops from source + forwarding TTL thres- 344 hold) over all hops, you can discover the TTL required for the 345 source to reach the destination. 347 6.3. Congestion 349 By taking two traces, you can find packet loss information by com- 350 paring the difference in input packet counts to the difference in 351 output packet counts at the previous hop. On a point-to-point 352 link, any difference in these numbers implies packet loss. Since 353 the packet counts may be changing as the trace query is propagat- 354 ing, there may be small errors (off by 1 or 2) in these statistics. 355 However, these errors will not accumulate if multiple traces are 356 taken to expand the measurement period. On a shared link, the 357 count of input packets can be larger than the number of output 358 packets at the previous hop, due to other routers or hosts on the 359 link injecting packets. This appears as "negative loss" which may 360 mask real packet loss. 362 In addition to the counts of input and output packets for all mul- 363 ticast traffic on the interfaces, the response data includes a 364 count of the packets forwarded by a node for the specified source- 365 group pair. Taking the difference in this count between two traces 366 and then comparing those differences between two hops gives a meas- 367 ure of packet loss just for traffic from the specified source to 368 the specified receiver via the specified group. This measure is 369 not affected by shared links. 371 On a point-to-point link that is a multicast tunnel, packet loss is 372 usually due to congestion in unicast routers along the path of that 373 tunnel. On native multicast links, loss is more likely in the out- 374 put queue of one hop, perhaps due to priority dropping, or in the 375 input queue at the next hop. The counters in the response data do 376 not allow these cases to be distinguished. Differences in packet 377 counts between the incoming and outgoing interfaces on one node 378 cannot generally be used to measure queue overflow in the node 379 because some packets may be routed only to or from other interfaces 380 on that node. 382 In the multicast extensions for SunOS 4.1.x from Xerox PARC, both 383 the output packet count and the packet forwarding count for the 384 source-group pair are incremented before priority dropping for rate 385 limiting occurs and before the packets are put onto the interface 386 output queue which may overflow. These drops will appear as (posi- 387 tive) loss on the link even though they occur within the router. 389 In release 3.3/3.4 of the multicast extensions, a multicast packet 390 generated on a router will be counted as having come in an inter- 391 face even though it did not. This can create the appearance of 392 negative loss even on a point-to-point link. 394 In releases up through 3.5/3.6, packets were not counted as input 395 on an interface if the reverse-path forwarding check decided that 396 the packets should be dropped. That causes the packets to appear 397 as lost on the link if they were output by the upstream hop. This 398 situation can arise when two routers on the path for the group 399 being traced are connected by a shared link, and the path for some 400 other group does not flow between those two routers because the 401 downstream router receives packets for the other group on another 402 interface, but the upstream router is the elected forwarder to 403 other routers or hosts on the shared link. 405 6.4. Link Utilization 407 Again, with two traces, you can divide the difference in the input 408 or output packet counts at some hop by the difference in time 409 stamps from the same hop to obtain the packet rate over the link. 410 If the average packet size is known, then the link utilization can 411 also be estimated to see whether packet loss may be due to the rate 412 limit or the physical capacity on a particular link being exceeded. 414 6.5. Time delay 416 If the routers have synchronized clocks, you can estimate propaga- 417 tion and queueing delay from the differences between the timestamps 418 at successive hops. 420 7. Acknowledgments 422 This specification started largely as a transcription of Van Jacobson's 423 slides from the 30th IETF, and the implementation in mrouted 3.3 by Ajit 424 Thyagarajan. Van's original slides credit Steve Casner, Steve Deering, 425 Dino Farinacci and Deb Agrawal. A multicast traceroute client, mtrace, 426 has been implemented by Ajit Thyagarajan and Steve Casner. 428 8. Security Considerations 430 Security issues are not discussed in this memo. 432 9. Authors' Addresses 434 William C. Fenner 435 Xerox PARC 436 3333 Coyote Hill Road 437 Palo Alto, CA 94304 438 Phone: +1 415 812 4816 439 Email: fenner@parc.xerox.com 441 Stephen L. Casner 442 Precept Software, Inc. 443 21580 Stevens Creek Blvd, Suite 207 444 Cupertino, CA 95014 445 Email: casner@precept.com