idnits 2.17.1 draft-ietf-idmr-traceroute-ipm-02.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-23) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 9) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 12. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 11. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances 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 222 has weird spacing: '... packet be-...' -- 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 (April 1998) is 9505 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? 'Bradner97' on line 53 looks like a reference -- Missing reference section? 'Katz97' on line 596 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 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-02.txt Xerox PARC 4 S. Casner 5 Precept Software 6 November 21, 1997 7 Expires April 1998 9 A ''traceroute'' facility for IP Multicast. 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute working 16 documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six months. 19 Internet Drafts may be updated, replaced, or obsoleted by other 20 documents at any time. It is not appropriate to use Internet Drafts as 21 reference material or to cite them other than as a "working draft" or 22 "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 44 solicited 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. Key Words 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC 2119 52 [Bradner97]. 54 2. Introduction 56 The unicast "traceroute" program allows the tracing of a path from one 57 machine to another, using a mechanism that already existed in IP. 58 Unfortunately, no such existing mechanism can be applied to IP multicast 59 paths. The key mechanism for unicast traceroute is the ICMP TTL exceeded 60 message, which is specifically precluded as a response to multicast 61 packets. Thus, we specify the multicast "traceroute" facility to be 62 implemented in multicast routers and accessed by diagnostic programs. 63 While it is a disadvantage that a new mechanism is required, the 64 multicast traceroute facility can provide additional information about 65 packet rates and losses that the unicast traceroute cannot, and 66 generally requires fewer packets to be sent. 68 Goals: 70 + To be able to trace the path that a packet would take from some 71 source to some destination. 73 + To be able to isolate packet loss problems (e.g., congestion). 75 + To be able to isolate configuration problems (e.g., TTL threshold). 77 + To minimize packets sent (e.g. no flooding, no implosion). 79 3. Overview 81 Tracing from a source to a multicast destination is hard, since you 82 don't know down which branch of the multicast tree the destination lies. 83 This means that you have to flood the whole tree to find the path from 84 one source to one destination. However, walking up the tree from 85 destination to source is easy, as all existing multicast routing 86 protocols know the previous hop for each source. Tracing from 87 destination to source can involve only routers on the direct path. 89 The party requesting the traceroute (which need be neither the source 90 nor the destination) sends a traceroute Query packet to the last-hop 91 multicast router for the given destination. The last-hop router turns 92 the Query into a Request packet by adding a response data block 93 containing its interface addresses and packet statistics, and then 94 forwards the Request packet via unicast to the router that it believes 95 is the proper previous hop for the given source and group. Each hop 96 adds its response data to the end of the Request packet, then unicast 97 forwards it to the previous hop. The first hop router (the router that 98 believes that packets from the source originate on one of its directly 99 connected networks) changes the packet type to indicate a Response 100 packet and sends the completed response to the response destination 101 address. The response may be returned before reaching the first hop 102 router if a fatal error condition such as "no route" is encountered 103 along the path. 105 Multicast traceroute uses any information available to it in the router 106 to attempt to determine a previous hop to forward the trace towards. 107 Multicast routing protocols vary in the type and amount of state they 108 keep; multicast traceroute endeavors to work with all of them by using 109 whatever is available. For example, if a DVMRP router has no active 110 state for a particular source but does have a DVMRP route, it chooses 111 the parent of the DVMRP route as the previous hop. If a PIM-SM router 112 is on the (*,G) tree, it chooses the parent towards the RP as the 113 previous hop. In these cases, no source/group-specific state is 114 available, but the path may still be traced. 116 4. Multicast Traceroute header 118 The header for all multicast traceroute packets is as follows: 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | IGMP Type | # hops | checksum | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Multicast Group Address | 126 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 127 | Source Address | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Destination Address | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Response Address | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | resp ttl | Query ID | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 4.1. IGMP Type: 8 bits 138 The IGMP type field is defined to be 0x1F for traceroute queries 139 and requests. The IGMP type field is changed to 0x1E when the 140 packet is completed and sent as a response from the first hop 141 router to the querier. Two codes are required so that multicast 142 routers won't attempt to process a completed response in those 143 cases where the initial query was issued from a router or the 144 response is sent via multicast. 146 4.2. # hops: 8 bits 148 This field specifies the maximum number of hops that the requester 149 wants to trace. If there is some error condition in the middle of 150 the path that keeps the traceroute request from reaching the 151 first-hop router, this field can be used to perform an expanding- 152 length search to trace the path to just before the problem. 154 4.3. Checksum: 16 bits 156 The checksum is the 16-bit one's complement of the one's complement 157 sum of the whole IGMP message (the entire IP payload). For 158 computing the checksum, the checksum field is set to zero. When 159 transmitting packets, the checksum MUST be computed and inserted 160 into this field. When receiving packets, the checksum MUST be 161 verified before processing a packet. 163 4.4. Group address 165 This field specifies the group address to be traced, or zero if no 166 group-specific information is desired. Note that non-group- 167 specific traceroutes may not be possible with certain multicast 168 routing protocols. 170 4.5. Source address 172 This field specifies the IP address of the multicast source for the 173 path being traced, or 0xFFFFFFFF if no source-specific information 174 is desired. Note that non-source-specific traceroutes may not be 175 possible with certain multicast routing protocols. 177 4.6. Destination address 179 This field specifies the IP address of the multicast receiver for 180 the path being traced. The trace starts at this destination and 181 proceeds toward the traffic source. 183 4.7. Response Address 185 This field specifies where the completed traceroute response packet 186 gets sent. It can be a unicast address or a multicast address, as 187 explained in section 6.2. 189 4.8. resp ttl: 8 bits 191 This field specifies the TTL at which to multicast the response, if 192 the response address is a multicast address. 194 4.9. Query ID: 24 bits 196 This field is used as a unique identifier for this traceroute 197 request so that duplicate or delayed responses may be detected and 198 to minimize collisions when a multicast response address is used. 200 5. Definitions 202 Since multicast traceroutes flow in the opposite direction to the data 203 flow, we always refer to "upstream" and "downstream" with respect to 204 data, unless explicitly specified. 206 Incoming Interface 207 The interface on which traffic is expected from the specified 208 source and group. 210 Outgoing Interface 211 The interface on which traffic is forwarded from the specified 212 source and group towards the destination. Also called the 213 "Reception Interface", since it is the interface on which the 214 multicast traceroute Request was received. 216 Previous-Hop Router 217 The router, on the Incoming Interface, which is responsible for 218 forwarding traffic for the specified source and group. 220 6. Response data 222 Each router adds a "response data" segment to the traceroute packet be- 223 fore it forwards it on. The response data looks like this: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Query Arrival Time | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Incoming Interface Address | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Outgoing Interface Address | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Previous-Hop Router Address | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Input packet count on incoming interface | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Output packet count on outgoing interface | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Total number of packets for this source-group pair | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | |M| | | | 243 | Rtg Protocol | FwdTTL |B|S| Src Mask |Forwarding Code| 244 | | |Z| | | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 6.1. Query Arrival Time 249 The Query Arrival Time is a 32-bit NTP timestamp specifying 250 the arrival time of the traceroute request packet at this 251 router. The 32-bit form of an NTP timestamp consists of the 252 middle 32 bits of the full 64-bit form; that is, the low 16 253 bits of the integer part and the high 16 bits of the 254 fractional part. 256 The following formula converts from a UNIX timeval to a 32-bit 257 NTP timestamp: 259 query_arrival_time = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec 260 << 10) / 15625) 262 The constant 32384 is the number of seconds from Jan 1, 1900 263 to Jan 1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 264 15625) is a reduction of ((tv.tv_usec / 100000000) << 16). 266 6.2. Incoming Interface Address 268 This field specifies the address of the interface on which 269 packets from this source and group are expected to arrive, or 270 0 if unknown. 272 6.3. Outgoing Interface Address 274 This field specifies the address of the interface on which 275 packets from this source and group flow to the specified 276 destination, or 0 if unknown. 278 6.4. Previous-Hop Router Address 280 This field specifies the router from which this router expects 281 packets from this source. This may be a multicast group if 282 the previous hop is not known because of the workings of the 283 multicast routing protocol. However, it should be 0 if the 284 incoming interface address is unknown. 286 6.5. Input packet count on incoming interface 288 This field contains the number of multicast packets received 289 for all groups and sources on the incoming interface, or 290 0xffffffff if no count can be reported. 292 6.6. Output packet count on outgoing interface 294 This field contains the number of multicast packets that have 295 been transmitted for all groups and sources on the outgoing 296 interface, or 0xffffffff if no count can be reported. 298 6.7. Total number of packets for this source-group pair 300 This field counts the number of packets from the specified 301 source forwarded by this router to the specified group, or 302 0xffffffff if no count can be reported. If the S bit is set, 303 the count is for the source network, as specified by the Src 304 Mask field. If the S bit is set and the Src Mask field is 63, 305 indicating no source-specific state, the count is for all 306 sources sending to this group. 308 6.8. Rtg Protocol: 8 bits 310 This field describes the routing protocol in use between this 311 router and the previous-hop router. Specified values include: 313 1 DVMRP 314 2 MOSPF 315 3 PIM 316 4 CBT 317 5 PIM using special routing table 318 6 PIM using a static route 319 7 DVMRP using a static route 321 6.9. FwdTTL: 8 bits 323 This field contains the TTL that a packet is required to have 324 before it will be forwarded over the outgoing interface. 326 6.10. MBZ: 1 bit 328 Must be zeroed on transmission and ignored on reception. 330 6.11. S: 1 bit 332 If this bit is set, it indicates that the packet count for the 333 source-group pair is for the source network, as determined by 334 masking the source address with the Src Mask field. 336 6.12. Src Mask: 6 bits 338 This field contains the number of 1's in the netmask this 339 router has for the source (i.e. a value of 24 means the 340 netmask is 0xffffff00). If the router is forwarding solely on 341 group state, this field is set to 63 (0x2f). 343 6.13. Forwarding Code: 8 bits 345 This field contains a forwarding information/error code. 346 Defined values include: 348 0x00 No error 349 0x01 350 Traceroute request arrived on an interface to 351 which this router would not forward for this 352 source,group,destination. 353 0x02 354 This router has sent a prune upstream which 355 applies to the source and group in the traceroute 356 request. 357 0x03 358 This router has stopped forwarding for this source 359 and group in response to a request from the next 360 hop router. 362 0x04 363 The group is subject to administrative scoping at 364 this hop. 365 0x05 This router has no route for the source. 366 0x06 This router is not the proper last-hop router. 367 0x07 368 This router is not forwarding this source,group 369 for an unspecified reason. 370 0x08 Reached Rendez-vous Point or Core 371 0x09 372 Traceroute request arrived on the expected RPF 373 interface for this source,group. 374 0x0A 375 Traceroute request arrived on an interface which 376 is not enabled for multicast. 377 0x81 378 There was not enough room to insert another 379 response data block in the packet. 380 0x82 381 The previous hop router does not understand 382 traceroute requests. 383 0x83 Traceroute is administratively prohibited. 385 Note that if a router discovers there is not enough room in a 386 packet to insert its response, it puts the 0x81 error code in 387 the previous router's Forwarding Code field, overwriting any 388 error the previous router placed there. It is expected that a 389 multicast traceroute client, upon receiving this error, will 390 restart the trace at the last hop listed in the packet. 392 The 0x80 bit of the Forwarding Code is used to indicate a 393 fatal error. A fatal error is one where the router may know 394 the previous hop but cannot forward the message to it. 396 7. Router Behavior 398 All of these actions are performed in addition to (NOT instead of) 399 forwarding the packet, if applicable. E.g. a multicast packet that 400 has TTL remaining MUST be forwarded normally, as should a unicast 401 packet that has TTL remaining and is not addressed to this router. 403 7.1. Traceroute Query 405 A traceroute Query message is a traceroute message with no 406 response blocks filled in, and uses IGMP type 0x1F. 408 7.1.1. Packet Verification 410 Upon receiving a traceroute Query message, a router must 411 examine the Query to see if it is the proper last-hop router 412 for the destination address in the packet. It is the proper 413 last-hop router if it has a multicast-capable interface on the 414 same subnet as the Destination Address and is the router that 415 would forward traffic from the given source onto that subnet. 417 A router may receive a traceroute Query message via either 418 unicast or multicast. If received via multicast and it 419 determines that it is not the proper last-hop router, the 420 packet MUST be silently dropped. If received via unicast and 421 the packet was addressed to this router, an error code of 0x06 422 should be noted and normal processing should occur. 424 Duplicate Query messages as identified by the tuple (IP 425 Source, Query ID) SHOULD be ignored. 427 7.1.2. Normal Processing 429 When a router receives a traceroute Query and it determines 430 that it is the proper last-hop router, it treats it like a 431 traceroute Request and performs the steps listed under Normal 432 Processing of a Traceroute Request, below. 434 7.2. Traceroute Request 436 A traceroute Request is a traceroute message with some number 437 of response blocks filled in, and also uses IGMP type 0x1F. 438 Routers can tell the difference between Queries and Requests 439 by checking the length of the packet. 441 7.2.1. Packet Verification 443 If the traceroute Request is not addressed to this router, or 444 if the Request is addressed to a multicast group which is not 445 a link-scoped group (e.g. 224.0.0.x), it MUST be silently 446 ignored. 448 7.2.2. Normal Processing 450 When a router receives a traceroute Request, it performs the 451 following steps. Note that it is possible to have multiple 452 situations covered by the Forwarding Codes. The first one 453 encountered is the one that is reported, i.e. all "note 454 forwarding code N" should be interpreted as "if forwarding 455 code is not already set, set forwarding code to N". 457 1. Insert a new response block into the packet and fill in 458 the Query Arrival Time, Outgoing Interface Address, 459 Output Packet Count, and FwdTTL. 461 2. Attempt to determine the forwarding information for the 462 source and group specified, using the same mechanisms as 463 would be used when a packet is received from the source 464 destined for the group. State need not be instantiated, 465 it can be "phantom" state created only for the purpose of 466 the trace. 468 3. If no forwarding information can be determined, an error 469 code of 0x05 is inserted in the Forwarding Code field, 470 the remaining fields that have not yet been filled in are 471 set to zero, and the packet is forwarded to the requester 472 as described in "Forwarding Traceroute Requests". 474 4. Fill in the Incoming Interface Address, Previous-Hop 475 Router Address, Input Packet Count, Total Number of 476 Packets, Routing Protocol, S, and Src Mask from the 477 forwarding information that was determined. 479 5. If traceroute is administratively prohibited or the 480 previous hop router does not understand traceroute 481 requests, note the appropriate forwarding code. If 482 traceroute is administratively prohibited and any of the 483 fields as filled in step 4 is considered private 484 information, zero out the applicable fields. Then the 485 packet is forwarded to the requester as described in 486 "Forwarding Traceroute Requests". 488 6. If the reception interface is not enabled for multicast, 489 note forwarding code 0xA. If the reception interface is 490 the interface from which the router would expect data to 491 arrive from the source, a forwarding code of 0x9 is 492 noted. Otherwise, if the reception interface is not one 493 to which the router would forward data from the source, a 494 forwarding code of 0x1 is noted. 496 7. If the group is subject to administrative scoping on 497 either the Outgoing or Incoming interfaces, a forwarding 498 code of 0x4 is noted. 500 8. If this router is the Rendez-vous Point or Core for the 501 group, a forwarding code of 0x8 is noted. (NOTE: should 502 this be earlier?) 504 9. If this router has sent a prune upstream which applies to 505 the source and group in the traceroute Request, it notes 506 forwarding code 0x2. If the router has stopped 507 forwarding downstream in response to a prune sent by the 508 next hop router, it notes forwarding code 0x3. If the 509 router should normally forward traffic for this source 510 and group downstream but is not, it notes forwarding code 511 0x7. 513 10. The packet is then sent on to the previous hop or the 514 requester as described in "Forwarding Traceroute 515 Requests". 517 7.3. Traceroute response 519 A router must forward all traceroute response packets 520 normally, with no special processing. If a router has 521 initiated a traceroute with a Query or Request message, it may 522 listen for Responses to that traceroute but MUST still forward 523 them as well. 525 7.4. Forwarding Traceroute Requests 527 If the Previous-hop router is known for the source and group 528 (or, if no group is specified, the previous-hop router for the 529 source, or if no source is specified, the previous-hop router 530 for the group) and the number of response blocks is less than 531 the number requested, the packet is sent to that router. If 532 the Incoming Interface is known but the Previous-hop router is 533 not known, the packet is sent to an appropriate multicast 534 address on the Incoming Interface. The appropriate multicast 535 address may depend on the routing protocol in use, MUST be a 536 link-scoped group (i.e. 224.0.0.x), MUST NOT be ALL- 537 SYSTEMS.MCAST.NET (224.0.0.1) and may be ALL-ROUTERS.MCAST.NET 538 (224.0.0.2) if the routing protocol in use does not define a 539 more appropriate group. Otherwise, it is sent to the Response 540 Address in the header, as described in "Sending Traceroute 541 Responses". 543 7.5. Sending Traceroute Responses 545 7.5.1. Destination Address 547 A traceroute response must be sent to the Response Address in 548 the traceroute header. 550 7.5.2. TTL 552 If the Response Address is unicast, the router inserts its 553 normal unicast TTL in the IP header. If the Response Address 554 is multicast, the router copies the Response TTL from the 555 traceroute header into the IP header. 557 7.5.3. Source Address 559 If the Response Address is unicast, the router may use any of 560 its interface addresses as the source address. Since some 561 multicast routing protocols forward based on source address, 562 if the Response Address is multicast, the router MUST use an 563 address that is known in the multicast routing table if it can 564 make that determination. 566 7.5.4. Sourcing Multicast Responses 568 When a router sources a multicast response, the response 569 packet MUST be sent on a single interface, then forwarded as 570 if it were received on that interface. It MUST NOT source the 571 response packet individually on each interface, since that 572 causes duplicate packets. 574 8. Using multicast traceroute 576 <> Several problems may arise when attempting to use 579 multicast traceroute. 581 8.1. Last hop router 583 The traceroute querier may not know which is the last hop 584 router, or that router may be behind a firewall that blocks 585 unicast packets but passes multicast packets. In these cases, 586 the traceroute request should be multicasted to the group 587 being traced (since the last hop router listens to that 588 group). All routers except the correct last hop router should 589 ignore any multicast traceroute request received via 590 multicast. Traceroute requests which are multicasted to the 591 group being traced must include the Router Alert IP option 592 [Katz97]. 594 Another alternative is to unicast to the trace destination. 595 Traceroute requests which are unicasted to the trace 596 destination must include the Router Alert IP option [Katz97], 597 in order that the last-hop router is aware of the packet. 599 If the traceroute querier is attached to the same router as 600 the destination of the request, the traceroute request may be 601 multicasted to 224.0.0.2 (ALL-ROUTERS.MCAST.NET) if the last- 602 hop router is not known. 604 8.2. First hop router 606 The traceroute querier may not be unicast reachable from the 607 first hop router. In this case, the querier should set the 608 traceroute response address to a multicast address, and should 609 set the response TTL to a value sufficient for the response 610 from the first hop router to reach the querier. It may be 611 appropriate to start with a small TTL and increase in 612 subsequent attempts until a sufficient TTL is reached, up to 613 an appropriate maximum (such as 192). 615 The IANA has assigned 224.0.1.32, MTRACE.MCAST.NET, as the 616 default multicast group for multicast traceroute responses. 617 Other groups may be used if needed, e.g. when using mtrace to 618 diagnose problems with the IANA-assigned group. 620 8.3. Broken intermediate router 622 A broken intermediate router might simply not understand 623 traceroute packets, and drop them. The querier would then get 624 no response at all from its traceroute requests. It should 625 then perform a hop-by-hop search by setting the number of 626 responses field until it gets a response (both linear and 627 binary search are options, but binary is likely to be slower 628 because a failure requires waiting for a timeout). 630 8.4. Trace termination 632 When performing an expanding hop-by-hop trace, it is necessary 633 to determine when to stop expanding. 635 8.4.1. Arriving at source 637 A trace can be determined to have arrived at the source if the 638 Incoming Interface of the last router in the trace is non- 639 zero, but the Previous Hop router is zero. (XXX Need to 640 actually check if this heuristic really works) <> <> 644 8.4.2. Fatal Error 646 A trace has encountered a fatal error if the last Forwarding 647 Error in the trace has the 0x80 bit set. 649 8.4.3. No Previous Hop 651 A trace can not continue if the last Previous Hop in the trace 652 is set to 0. 654 9. Problem Diagnosis 656 9.1. Forwarding Inconsistencies 658 The forwarding error code can tell if a group is unexpectedly 659 pruned or administratively scoped. 661 9.2. TTL problems 663 By taking the maximum of (hops from source + forwarding TTL 664 threshold) over all hops, you can discover the TTL required 665 for the source to reach the destination. 667 9.3. Congestion 669 By taking two traces, you can find packet loss information by 670 comparing the difference in input packet counts to the 671 difference in output packet counts at the previous hop. On a 672 point-to-point link, any difference in these numbers implies 673 packet loss. Since the packet counts may be changing as the 674 trace query is propagating, there may be small errors (off by 675 1 or 2) in these statistics. However, these errors will not 676 accumulate if multiple traces are taken to expand the 677 measurement period. On a shared link, the count of input 678 packets can be larger than the number of output packets at the 679 previous hop, due to other routers or hosts on the link 680 injecting packets. This appears as "negative loss" which may 681 mask real packet loss. 683 In addition to the counts of input and output packets for all 684 multicast traffic on the interfaces, the response data 685 includes a count of the packets forwarded by a node for the 686 specified source-group pair. Taking the difference in this 687 count between two traces and then comparing those differences 688 between two hops gives a measure of packet loss just for 689 traffic from the specified source to the specified receiver 690 via the specified group. This measure is not affected by 691 shared links. 693 On a point-to-point link that is a multicast tunnel, packet 694 loss is usually due to congestion in unicast routers along the 695 path of that tunnel. On native multicast links, loss is more 696 likely in the output queue of one hop, perhaps due to priority 697 dropping, or in the input queue at the next hop. The counters 698 in the response data do not allow these cases to be 699 distinguished. Differences in packet counts between the 700 incoming and outgoing interfaces on one node cannot generally 701 be used to measure queue overflow in the node because some 702 packets may be routed only to or from other interfaces on that 703 node. 705 In the multicast extensions for SunOS 4.1.x from Xerox PARC, 706 both the output packet count and the packet forwarding count 707 for the source-group pair are incremented before priority 708 dropping for rate limiting occurs and before the packets are 709 put onto the interface output queue which may overflow. These 710 drops will appear as (positive) loss on the link even though 711 they occur within the router. 713 In release 3.3/3.4 of the UNIX multicast extensions, a 714 multicast packet generated on a router will be counted as 715 having come in an interface even though it did not. This can 716 create the appearance of negative loss even on a point-to- 717 point link. 719 In releases up through 3.5/3.6, packets were not counted as 720 input on an interface if the reverse-path forwarding check 721 decided that the packets should be dropped. That causes the 722 packets to appear as lost on the link if they were output by 723 the upstream hop. This situation can arise when two routers 724 on the path for the group being traced are connected by a 725 shared link, and the path for some other group does not flow 726 between those two routers because the downstream router 727 receives packets for the other group on another interface, but 728 the upstream router is the elected forwarder to other routers 729 or hosts on the shared link. 731 9.4. Link Utilization 733 Again, with two traces, you can divide the difference in the 734 input or output packet counts at some hop by the difference in 735 time stamps from the same hop to obtain the packet rate over 736 the link. If the average packet size is known, then the link 737 utilization can also be estimated to see whether packet loss 738 may be due to the rate limit or the physical capacity on a 739 particular link being exceeded. 741 9.5. Time delay 743 If the routers have synchronized clocks, it is possible to 744 estimate propagation and queueing delay from the differences 745 between the timestamps at successive hops. 747 10. Acknowledgments 749 This specification started largely as a transcription of Van 750 Jacobson's slides from the 30th IETF, and the implementation in 751 mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit 752 Steve Casner, Steve Deering, Dino Farinacci and Deb Agrawal. A 753 multicast traceroute client, mtrace, has been implemented by Ajit 754 Thyagarajan, Steve Casner and Bill Fenner. 756 The idea of unicasting a multicast traceroute Query to the 757 destination of the trace with RA set is due to Tony Ballardie. The 758 idea of the "S" bit to allow statistics for a source subnet is due 759 to Tom Pusateri. 761 11. IANA Considerations 763 11.1. Routing Protocols 765 Should the IANA be responsible for allocating new Routing 766 Protocol codes? 768 11.2. Forwarding Codes 770 Should the IANA be responsible for allocating new Forwarding 771 Codes? 773 12. Security Considerations 775 12.1. Topology discovery 777 mtrace can be used to discover any actively-used topology. If 778 your network topology is a secret, you should restrict mtrace 779 at the border of your domain. 781 12.2. Traffic rates 783 mtrace can be used to discover what sources are sending to 784 what groups and at what rates. If this information is a 785 secret, you should restrict mtrace at the border of your 786 domain. 788 ...more... 790 13. References 792 Bradner97 Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", RFC 2119/BCP 14, Harvard 794 University, March 1997. 796 Katz97 Katz, D., "IP Router Alert Option," RFC 2113, Cisco 797 Systems, February 1997. 799 14. Authors' Addresses 801 William C. Fenner 802 Xerox PARC 803 3333 Coyote Hill Road 804 Palo Alto, CA 94304 805 Phone: +1 650 812 4816 806 Email: fenner@parc.xerox.com 808 Stephen L. Casner 809 Precept Software, Inc. 810 1072 Arastradero Road 811 Palo Alto, CA 94304 812 Email: casner@precept.com