idnits 2.17.1 draft-asaeda-mboned-mtrace-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1496. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances 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: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 2, 2007) is 6137 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) ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) == Outdated reference: A later version (-07) exists of draft-ietf-mboned-ip-mcast-mib-05 -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. '12') (Obsoleted by RFC 7761) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group H. Asaeda 3 Internet-Draft Keio University 4 Expires: January 3, 2008 T. Jinmei 5 Toshiba Corporation 6 W. Fenner 7 AT&T Research 8 S. Casner 9 Packet Design, Inc. 10 July 2, 2007 12 Mtrace Version 2: Traceroute Facility for IP Multicast 13 draft-asaeda-mboned-mtrace-v2-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 3, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document describes the IGMP and the ICMPv6 multicast traceroute 47 facility. Unlike unicast traceroute, multicast traceroute requires 48 special packet types and implementations on the part of routers. 49 This specification describes the required functionality in multicast 50 routers, as well as how management applications can use the new 51 router functionality. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. IPv4 Multicast Traceroute Header . . . . . . . . . . . . . . . 8 59 4.1. IGMP Type: 8 bits . . . . . . . . . . . . . . . . . . . . 8 60 4.2. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 8 61 4.3. Checksum: 16 bits . . . . . . . . . . . . . . . . . . . . 8 62 4.4. Multicast Address . . . . . . . . . . . . . . . . . . . . 9 63 4.5. Source Address . . . . . . . . . . . . . . . . . . . . . . 9 64 4.6. Destination Address . . . . . . . . . . . . . . . . . . . 9 65 4.7. Response Address . . . . . . . . . . . . . . . . . . . . . 9 66 4.8. Resp TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 9 67 4.9. Query ID: 24 bits . . . . . . . . . . . . . . . . . . . . 9 68 5. IPv4 Multicast Traceroute Response Data . . . . . . . . . . . 10 69 5.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 10 70 5.2. Incoming Interface Address . . . . . . . . . . . . . . . . 11 71 5.3. Outgoing Interface Address . . . . . . . . . . . . . . . . 11 72 5.4. Previous-Hop Router Address . . . . . . . . . . . . . . . 11 73 5.5. Packet counts . . . . . . . . . . . . . . . . . . . . . . 11 74 5.6. Input packet count on incoming interface . . . . . . . . . 11 75 5.7. Output packet count on incoming interface . . . . . . . . 11 76 5.8. Total number of packets for this source-group pair . . . . 11 77 5.9. Rtg Protocol: 8 bits . . . . . . . . . . . . . . . . . . . 12 78 5.10. Fwd TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 12 79 5.11. MBZ: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 5.13. Src Mask: 6 bits . . . . . . . . . . . . . . . . . . . . . 12 82 5.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 13 83 6. IPv6 Multicast Traceroute Header . . . . . . . . . . . . . . . 15 84 6.1. ICMPv6 Type: 8 bits . . . . . . . . . . . . . . . . . . . 16 85 6.2. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 16 86 6.3. Checksum: 16 bits . . . . . . . . . . . . . . . . . . . . 16 87 6.4. Reserved: 32 bits . . . . . . . . . . . . . . . . . . . . 16 88 6.5. Multicast Address . . . . . . . . . . . . . . . . . . . . 16 89 6.6. Source Address . . . . . . . . . . . . . . . . . . . . . . 16 90 6.7. Destination Address . . . . . . . . . . . . . . . . . . . 16 91 6.8. Response Address . . . . . . . . . . . . . . . . . . . . . 16 92 6.9. Resp Hop Limit: 8 bits . . . . . . . . . . . . . . . . . . 17 93 6.10. Query ID: 24 bits . . . . . . . . . . . . . . . . . . . . 17 94 7. IPv6 Multicast Traceroute Response Data . . . . . . . . . . . 18 95 7.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 18 96 7.2. Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 19 97 7.3. Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 19 98 7.4. Local Address . . . . . . . . . . . . . . . . . . . . . . 19 99 7.5. Remote Address . . . . . . . . . . . . . . . . . . . . . . 19 100 7.6. Input packet count on incoming interface . . . . . . . . . 19 101 7.7. Output packet count on incoming interface . . . . . . . . 20 102 7.8. Total number of packets for this source-group pair . . . . 20 103 7.9. Rtg Protocol: 8 bits . . . . . . . . . . . . . . . . . . . 20 104 7.10. Fwd Hop Limit: 8 bits . . . . . . . . . . . . . . . . . . 20 105 7.11. MBZ: 7 bits . . . . . . . . . . . . . . . . . . . . . . . 20 106 7.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 7.13. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 20 108 7.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 20 109 7.15. Reserved: 24 bit . . . . . . . . . . . . . . . . . . . . . 21 110 8. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 111 8.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 22 112 8.1.1. Packet Verification . . . . . . . . . . . . . . . . . 22 113 8.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 22 114 8.2. Traceroute Request . . . . . . . . . . . . . . . . . . . . 22 115 8.2.1. Packet Verification . . . . . . . . . . . . . . . . . 23 116 8.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 23 117 8.3. Traceroute Response . . . . . . . . . . . . . . . . . . . 24 118 8.4. Forwarding Traceroute Requests . . . . . . . . . . . . . . 25 119 8.5. Sending Traceroute Responses . . . . . . . . . . . . . . . 25 120 8.5.1. Destination Address . . . . . . . . . . . . . . . . . 25 121 8.5.2. TTL and Hop Limit . . . . . . . . . . . . . . . . . . 25 122 8.5.3. Source Address . . . . . . . . . . . . . . . . . . . . 25 123 8.5.4. Sourcing multicast responses . . . . . . . . . . . . . 25 124 8.6. Hiding information . . . . . . . . . . . . . . . . . . . . 26 125 9. Using multicast traceroute . . . . . . . . . . . . . . . . . . 27 126 9.1. Sample client . . . . . . . . . . . . . . . . . . . . . . 27 127 9.1.1. Sending initial query . . . . . . . . . . . . . . . . 27 128 9.1.2. Determining the Path . . . . . . . . . . . . . . . . . 27 129 9.1.3. Collecting statistics . . . . . . . . . . . . . . . . 27 130 9.2. Last hop router . . . . . . . . . . . . . . . . . . . . . 28 131 9.3. First hop router . . . . . . . . . . . . . . . . . . . . . 28 132 9.4. Broken intermediate router . . . . . . . . . . . . . . . . 28 133 9.5. Mtrace termination . . . . . . . . . . . . . . . . . . . . 29 134 9.5.1. Arriving at source . . . . . . . . . . . . . . . . . . 29 135 9.5.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 29 136 9.5.3. No previous hop . . . . . . . . . . . . . . . . . . . 29 137 9.5.4. Traceroute shorter than requested . . . . . . . . . . 29 138 9.6. Continuing after an error . . . . . . . . . . . . . . . . 29 139 9.7. Multicast Traceroute and shared tree routing protocols . . 30 140 9.7.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 30 141 9.7.2. Bi-directional PIM . . . . . . . . . . . . . . . . . . 30 142 9.7.3. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 30 143 9.8. Protocol-specific considerations . . . . . . . . . . . . . 31 144 9.8.1. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 31 145 9.8.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 31 146 10. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 32 147 10.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 32 148 10.2. TTL or hop limit problems . . . . . . . . . . . . . . . . 32 149 10.3. Packet loss . . . . . . . . . . . . . . . . . . . . . . . 32 150 10.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 33 151 10.5. Time delay . . . . . . . . . . . . . . . . . . . . . . . . 33 152 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 153 11.1. Routing protocols . . . . . . . . . . . . . . . . . . . . 34 154 11.2. Forwarding codes . . . . . . . . . . . . . . . . . . . . . 34 155 11.3. IPv6 mtrace . . . . . . . . . . . . . . . . . . . . . . . 34 156 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 157 12.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 35 158 12.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 35 159 12.3. Unicast Replies . . . . . . . . . . . . . . . . . . . . . 35 160 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 161 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 162 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 163 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 165 Intellectual Property and Copyright Statements . . . . . . . . . . 40 167 1. Introduction 169 The unicast "traceroute" program allows the tracing of a path from 170 one machine to another. The key mechanism for unicast traceroute is 171 the ICMP TTL exceeded message, which is specifically precluded as a 172 response to multicast packets. On the other hand, the multicast 173 traceroute facility allows the tracing of an IP multicast routing 174 paths. In this document, we specify the new multicast "traceroute" 175 facility to be implemented in multicast routers and accessed by 176 diagnostic programs. The new multicast traceroute facility, mtrace 177 version 2, can provide additional information about packet rates and 178 losses that the unicast traceroute cannot, and generally requires 179 fewer packets to be sent. 181 o. To be able to trace the path that a packet would take from some 182 source to some destination. 184 o. To be able to isolate packet loss problems (e.g., congestion). 186 o. To be able to isolate configuration problems (e.g., TTL 187 threshold). 189 o. To minimize packets sent (e.g. no flooding, no implosion). 191 This document supports both IPv4 and IPv6 multicast traceroute 192 facility. The protocol design, concept, and program behavior are 193 same between IPv4 and IPv6 mtrace, whereas the packet formats are 194 different because of the different address family. For instance, the 195 query and response messages for IPv4 mtrace are implemented as IGMP 196 messages [4], whereas IPv6 mtrace messages are of ICMPv6 messages 197 [5]. This document clarifies the unique points or properties of each 198 mtrace if exist. 200 2. Terminology 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 203 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 204 this document are to be interpreted as described in RFC 2119 [1]. 206 Since multicast traceroutes flow in the opposite direction to the 207 data flow, we refer to "upstream" and "downstream" with respect to 208 data, unless explicitly specified. 210 Incoming interface: 211 The interface on which traffic is expected from the specified source 212 and group. 214 Outgoing interface: 215 The interface on which traffic is forwarded from the specified source 216 and group toward the destination. It is the interface on which the 217 multicast traceroute Request was received. 219 Previous-hop router: 220 The router that is on the link attached to the Incoming Interface and 221 is responsible for forwarding traffic for the specified source and 222 group. 224 Group state: 225 It is the state in which a shared-tree protocol (e.g., PIM-SM [12]) 226 running on a router chooses the previous-hop router toward the core 227 router (or RP) as its parent router. In this state, source-specific 228 state is not available for the corresponding multicast address on the 229 router. 231 Source-specific state: 232 It is the state in which a routing protocol running on a router 233 chooses the path that would be followed for a source-specific join. 235 3. Overview 237 Given a multicast distribution tree, tracing from a source to a 238 multicast destination is hard, since you don't know down which branch 239 of the multicast tree the destination lies. This means that you have 240 to flood the whole tree to find the path from one source to one 241 destination. However, walking up the tree from destination to source 242 is easy, as most existing multicast routing protocols know the 243 previous hop for each source. Tracing from destination to source can 244 involve only routers on the direct path. 246 The party requesting the traceroute (which need be neither the source 247 nor the destination) sends a traceroute Query packet to the last-hop 248 multicast router for the given destination. The last-hop router 249 turns the Query into a Request packet by adding a response data block 250 containing its interface addresses and packet statistics, and then 251 forwards the Request packet via unicast to the router that it 252 believes is the proper previous hop for the given source and group. 253 Each hop adds its response data to the end of the Request packet, 254 then unicast forwards it to the previous hop. The first hop router 255 (the router that believes that packets from the source originate on 256 one of its directly connected networks) changes the packet type to 257 indicate a Response packet and sends the completed response to the 258 response destination address. The response may be returned before 259 reaching the first hop router if a fatal error condition such as "no 260 route" is encountered along the path. 262 Multicast traceroute uses any information available to it in the 263 router to attempt to determine a previous hop to forward the trace 264 towards. Multicast routing protocols vary in the type and amount of 265 state they keep; multicast traceroute endeavors to work with all of 266 them by using whatever is available. For example, if a DVMRP router 267 has no active state for a particular source but does have a DVMRP 268 route, it chooses the parent of the DVMRP route as the previous hop. 269 If a PIM-SM router is on the (*,G) tree, it chooses the parent 270 towards the RP as the previous hop. In these cases, no source/ 271 group-specific state is available, but the path may still be traced. 273 4. IPv4 Multicast Traceroute Header 275 IPv4 mtrace includes the common packet header as follows. The header 276 is only filled in by the originator of the traceroute Query; 277 intermediate routers MUST NOT modify any of the fields. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | IGMP Type | # hops | Checksum | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Multicast Address | 285 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 286 | Source Address | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Destination Address | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Response Address | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Resp TTL | Query ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 4.1. IGMP Type: 8 bits 297 The IGMP type field is defined to be 0x1F for traceroute queries and 298 requests. The IGMP type field is changed to 0x1E when the packet is 299 completed and sent as a response from the first hop router to the 300 querier. Two codes are required so that multicast routers won't 301 attempt to process a completed response in those cases where the 302 initial query was issued from a router or the response is sent via 303 multicast. 305 4.2. # hops: 8 bits 307 This field specifies the maximum number of hops that the requester 308 wants to trace. If there is some error condition in the middle of 309 the path that keeps the traceroute request from reaching the first- 310 hop router, this field can be used to perform an expanding-ring 311 search to trace the path to just before the problem. 313 4.3. Checksum: 16 bits 315 The checksum is the 16-bit one's complement of the one's complement 316 sum of the whole IGMP message (the entire IP payload) [8]. When 317 computing the checksum, the checksum field is set to zero. When 318 transmitting packets, the checksum MUST be computed and inserted into 319 this field. When receiving packets, the checksum MUST be verified 320 before processing a packet. 322 4.4. Multicast Address 324 This field specifies the multicast address to be traced, or zero if 325 no group-specific information is desired. Note that non-group- 326 specific traceroutes may not be possible with certain multicast 327 routing protocols. 329 4.5. Source Address 331 This field specifies the IP address of the multicast source for the 332 path being traced, or 0xffffffff if no source-specific information is 333 desired. Note that non-source-specific traceroutes may not be 334 possible with certain multicast routing protocols. 336 4.6. Destination Address 338 This field specifies the IP address of the multicast receiver for the 339 path being traced. The trace starts at this destination and proceeds 340 toward the traffic source. 342 4.7. Response Address 344 This field specifies IP address to which the completed traceroute 345 response packet gets sent. It can be a unicast address or a 346 multicast address, as explained in Section 8.2 348 4.8. Resp TTL: 8 bits 350 This field specifies the TTL at which to multicast the response, if 351 the response address is a multicast address. 353 4.9. Query ID: 24 bits 355 This field is used as a unique identifier for this traceroute request 356 so that duplicate or delayed responses may be detected and to 357 minimize collisions when a multicast response address is used. 359 5. IPv4 Multicast Traceroute Response Data 361 Each intermediate router in a trace path appends "response data" to 362 the forwarded trace packet. The response data looks as follows. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Query Arrival Time | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Incoming Interface Address | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Outgoing Interface Address | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Previous-Hop Router Address | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Input packet count on incoming interface | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Output packet count on outgoing interface | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Total number of packets for this source-group pair | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | | |M| | | | 382 | Rtg Protocol | Fwd TTL |B|S| Src Mask |Forwarding Code| 383 | | |Z| | | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 5.1. Query Arrival Time: 32 bits 388 The Query Arrival Time is a 32-bit NTP timestamp specifying the 389 arrival time of the traceroute request packet at this router. The 390 32-bit form of an NTP timestamp consists of the middle 32 bits of the 391 full 64-bit form; that is, the low 16 bits of the integer part and 392 the high 16 bits of the fractional part. 394 The following formula converts from a UNIX timeval to a 32-bit NTP 395 timestamp: 397 query_arrival_time 398 = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec << 10) / 15625) 400 The constant 32384 is the number of seconds from Jan 1, 1900 to Jan 401 1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 15625) is a 402 reduction of ((tv.tv_usec / 100000000) << 16). 404 5.2. Incoming Interface Address 406 This field specifies the address of the interface on which packets 407 from this source and group are expected to arrive, or 0 if unknown. 409 5.3. Outgoing Interface Address 411 This field specifies the address of the interface on which packets 412 from this source and group flow to the specified destination, or 0 if 413 unknown. 415 5.4. Previous-Hop Router Address 417 This field specifies the router from which this router expects 418 packets from this source. This may be a multicast group (e.g. ALL- 419 [protocol]-ROUTERS.MCAST.NET) if the previous hop is not known 420 because of the workings of the multicast routing protocol. However, 421 it should be 0 if the incoming interface address is unknown. 423 5.5. Packet counts 425 Note that these packet counts SHOULD be as up to date as possible. 426 If packet counts are not being maintained on the processor that 427 handles the traceroute request in a multi-processor router 428 architecture, the packet SHOULD be delayed while the counters are 429 gathered from the remote processor(s). If this occurs, the Query 430 Arrival Time should be updated to reflect the time at which the 431 packet counts were learned. 433 5.6. Input packet count on incoming interface 435 This field contains the number of multicast packets received for all 436 groups and sources on the incoming interface, or 0xffffffff if no 437 count can be reported. This counter should have the same value as 438 ifInMulticastPkts from the IF-MIB [10] for this interface. 440 5.7. Output packet count on incoming interface 442 This field contains the number of multicast packets that have been 443 transmitted or queued for transmission for all groups and sources on 444 the outgoing interface, or 0xffffffff if no count can be reported. 445 This counter should have the same value as ifOutMulticastPkts from 446 the IF-MIB for this interface. 448 5.8. Total number of packets for this source-group pair 450 This field counts the number of packets from the specified source 451 forwarded by this router to the specified group, or 0xffffffff if no 452 count can be reported. If the S bit is set, the count is for the 453 source network, as specified by the Src Mask field. If the S bit is 454 set and the Src Mask field is 63, indicating no source-specific 455 state, the count is for all sources sending to this group. This 456 counter should have the same value as ipMcastRoutePkts from the 457 IPMROUTE-STD-MIB [11] for this forwarding entry. 459 5.9. Rtg Protocol: 8 bits 461 This field describes the routing protocol in use between this router 462 and the previous-hop router. Specified values include: 464 1 DVMRP 465 2 MOSPF 466 3 PIM 467 4 CBT 468 5 PIM using special routing table 469 6 PIM using a static route 470 7 DVMRP using a static route 471 8 PIM using MBGP route 472 9 CBT using special routing table 473 10 CBT using a static route 474 11 PIM using state created by Assert processing 475 12 Bi-directional PIM 477 Note that some of the routing protocols or functions are not 478 supported or not used in either of IPv4 multicast nor IPv6 multicast. 480 5.10. Fwd TTL: 8 bits 482 This field contains the TTL that a packet is required to have before 483 it will be forwarded over the outgoing interface. 485 5.11. MBZ: 1 bit 487 Must be zeroed on transmission and ignored on reception. 489 5.12. S: 1 bit 491 This S bit indicates that the packet count for the source-group pair 492 is for the source network, as determined by masking the source 493 address with the Src Mask field. 495 5.13. Src Mask: 6 bits 497 This field contains the number of 1's in the netmask this router has 498 for the source (i.e. a value of 24 means the netmask is 0xffffff00). 499 If the router is forwarding solely on group state, this field is set 500 to 63 (0x3f). 502 5.14. Forwarding Code: 8 bits 504 This field contains a forwarding information/error code. Defined 505 values are as follows; 507 Value Name Description 509 ----- -------------- ------------------------------------------- 511 0x00 NO_ERROR No error 513 0x01 WRONG_IF Traceroute request arrived on an interface 514 to which this router would not forward for 515 this source,group,destination. 517 0x02 PRUNE_SENT This router has sent a prune upstream which 518 applies to the source and group in the 519 traceroute request. 521 0x03 PRUNE_RCVD This router has stopped forwarding for this 522 source and group in response to a request 523 from the next hop router. 525 0x04 SCOPED The group is subject to administrative 526 scoping at this hop. 528 0x05 NO_ROUTE This router has no route for the source or 529 group and no way to determine a potential 530 route. 532 0x06 WRONG_LAST_HOP This router is not the proper last-hop 533 router. 535 0x07 NOT_FORWARDING This router is not forwarding this source, 536 group out the outgoing interface for an 537 unspecified reason. 539 0x08 REACHED_RP Reached Rendez-vous Point or Core 541 0x09 RPF_IF Traceroute request arrived on the expected 542 RPF interface for this source, group. 544 0x0A NO_MULTICAST Traceroute request arrived on an interface 545 which is not enabled for multicast. 547 0x0B INFO_HIDDEN One or more hops have been hidden from this 548 trace. 550 0x81 NO_SPACE There was not enough room to insert another 551 response data block in the packet. 553 0x82 OLD_ROUTER The previous-hop router does not understand 554 traceroute requests. 556 0x83 ADMIN_PROHIB Traceroute is administratively prohibited. 558 Note that if a router discovers there is not enough room in a packet 559 to insert its response, it puts the 0x81 error code in the previous 560 router's Forwarding Code field, overwriting any error the previous 561 router placed there. A multicast traceroute client, upon receiving 562 this error, MAY restart the trace at the last hop listed in the 563 packet. 565 The 0x80 bit of the Forwarding Code is used to indicate a fatal 566 error. A fatal error is one where the router may know the previous 567 hop but cannot forward the message to it. 569 6. IPv6 Multicast Traceroute Header 571 IPv6 mtrace includes the common packet header as follows. Because of 572 the specification of the IPv6 address, all IPv6 addresses used in 573 each field consume 128 bits length. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type | # hops | Checksum | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Reserved | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | | 583 * * 584 | | 585 * Multicast Address * 586 | | 587 * * 588 | | 589 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 590 | | 591 * * 592 | | 593 * Source Address * 594 | | 595 * * 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | | 599 * * 600 | | 601 * Destination Address * 602 | | 603 * * 604 | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | | 607 * * 608 | | 609 * Response Address * 610 | | 611 * * 612 | | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 |Resp Hop Limit | Query ID | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 6.1. ICMPv6 Type: 8 bits 619 The ICMPv6 type field is defined to be MTRACE6_QRYREQ (TBD (see 620 Section 11)) for traceroute queries and requests. The ICMPv6 type 621 field is changed to MTRACE6_RESP (TBD) when the packet is completed 622 and sent as a response from the first hop router to the querier. Two 623 codes are required so that multicast routers won't attempt to process 624 a completed response in those cases where the initial query was 625 issued from a router or the response is sent via multicast. 627 6.2. # hops: 8 bits 629 Same definition described in Section 4.2 631 6.3. Checksum: 16 bits 633 As defined in [2], the checksum is the 16-bit one's complement of the 634 one's complement sum of the entire ICMPv6 message, starting with the 635 ICMPv6 message type field, and prepended with a "pseudo-header" of 636 IPv6 header fields. 638 6.4. Reserved: 32 bits 640 Initialized to zero by the sender; ignored by receivers. 642 6.5. Multicast Address 644 Same definition described in Section 4.4 646 6.6. Source Address 648 This field specifies the IPv6 address of the multicast source for the 649 path being traced, or is filled with the unspecified address (::) if 650 no source-specific information is desired. Note that non-source- 651 specific traceroutes may not be possible with certain multicast 652 routing protocols. 654 6.7. Destination Address 656 Same definition described in Section 4.6 658 6.8. Response Address 660 Same definition described in Section 4.7 662 6.9. Resp Hop Limit: 8 bits 664 This field specifies the hop limit at which to multicast the 665 response, if the response address is a multicast address. 667 6.10. Query ID: 24 bits 669 Same definition described in Section 4.9 671 7. IPv6 Multicast Traceroute Response Data 673 Each intermediate router in a trace path appends "response data" to 674 the forwarded trace packet. The response data looks as follows. 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Query Arrival Time | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Incoming Interface ID | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Outgoing Interface ID | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | | 686 * * 687 | | 688 * Local Address * 689 | | 690 * * 691 | | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | | 694 * * 695 | | 696 * Remote Address * 697 | | 698 * * 699 | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Input packet count on incoming interface | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Output packet count on outgoing interface | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Total number of packets for this source-group pair | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Rtg Protocol | Fwd Hop Limit | MBZ |S|Src Prefix Len | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 |Forwarding Code| Reserved | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 7.1. Query Arrival Time: 32 bits 714 Same definition described in Section 5.1 716 7.2. Incoming Interface ID: 32 bits 718 This field specifies the interface ID on which packets from this 719 source and group are expected to arrive, or 0 if unknown. This ID 720 should be the value taken from InterfaceIndex of the IF-MIB for this 721 interface. This field is carried in network byte order. 723 7.3. Outgoing Interface ID: 32 bits 725 This field specifies the interface ID on which packets from this 726 source and group flow to the specified destination, or 0 if unknown. 727 This ID should be the value taken from InterfaceIndex of the IF-MIB 728 for this interface. This field is carried in network byte order. 730 7.4. Local Address 732 This field specifies a global IPv6 address that uniquely identifies 733 the router. A unique local unicast address [7] SHOULD NOT be used 734 unless the node is only assigned link-local and unique local 735 addresses. [TBD: What if the node is only assigned link-local 736 addresses? It should be very unlikely case, but is possible even for 737 a properly working router.] 739 Note that since interface indices used in the Incoming and Outgoing 740 Interface ID fields are node-local information, a global identifier 741 is needed to specify the router. 743 7.5. Remote Address 745 This field specifies the address of the previous-hop router, which, 746 in most cases, is a link-local unicast address for the queried source 747 and destination addresses. 749 Although a link-local address does not have enough information to 750 identify a node, it is possible to detect the previous-hop router 751 with the assistance of Incoming Interface ID and the current router 752 address (i.e., Local Address). 754 This may be a multicast group (e.g., ALL-[protocol]- 755 ROUTERS.MCAST.NET) if the previous hop is not known because of the 756 workings of the multicast routing protocol. However, it should be 757 the unspecified address (::) if the incoming interface address is 758 unknown. 760 7.6. Input packet count on incoming interface 762 Same definition described in Section 5.6 764 7.7. Output packet count on incoming interface 766 Same definition described in Section 5.7 768 7.8. Total number of packets for this source-group pair 770 This field counts the number of packets from the specified source 771 forwarded by this router to the specified group, or 0xffffffff if no 772 count can be reported. If the S bit is set, the count is for the 773 source network, as specified by the Src Prefix Len field. If the S 774 bit is set and the Src Prefix Len field is 255, indicating no source- 775 specific state, the count is for all sources sending to this group. 776 This counter should have the same value as ipMcastRoutePkts from the 777 IPMROUTE-STD-MIB for this forwarding entry. 779 7.9. Rtg Protocol: 8 bits 781 Same definition described in Section 5.9 783 Note that some of the routing protocols or functions are not 784 supported or not used in IPv6 multicast. 786 7.10. Fwd Hop Limit: 8 bits 788 This field contains the hop limit that a packet is required to have 789 before it will be forwarded over the outgoing interface. 791 7.11. MBZ: 7 bits 793 Must be zeroed on transmission and ignored on reception. 795 7.12. S: 1 bit 797 This S bit indicates that the packet count for the source-group pair 798 is for the source network, as determined by masking the source 799 address with the Src Prefix Len field. 801 7.13. Src Prefix Len: 8 bits 803 This field contains the decimal number of the prefix length this 804 router has for the source. If the router is forwarding solely on 805 group state, this field is set to 255 (0xff) 807 7.14. Forwarding Code: 8 bits 809 Same definition described in Section 5.14 811 7.15. Reserved: 24 bit 813 Initialized to zero by the sender; ignored by receivers. 815 8. Router Behavior 817 All of these actions are performed in addition to (NOT instead of) 818 forwarding the packet, if applicable. E.g. a multicast packet that 819 has TTL or the hop limit remaining MUST be forwarded normally, as 820 MUST a unicast packet that has TTL or the hop limit remaining and is 821 not addressed to this router. 823 8.1. Traceroute Query 825 A traceroute Query message is a traceroute message with no response 826 blocks filled in, and uses IGMP type 0x1F for IPv4 mtrace or ICMPv6 827 type MTRACE6_QRYREQ (TBD) for IPv6 mtrace. 829 8.1.1. Packet Verification 831 Upon receiving a traceroute Query message, a router must examine the 832 Query to see if it is the proper last-hop router for the destination 833 address in the packet. It is the proper last-hop router if it has a 834 multicast-capable interface on the same subnet as the Destination 835 Address and is the router that would forward traffic from the given 836 source onto that subnet. 838 If the router determines that it is not the proper last-hop router, 839 or it cannot make that determination, it does one of two things 840 depending if the Query was received via multicast or unicast. If the 841 Query was received via multicast, then it MUST be silently dropped. 842 If it was received via unicast, a forwarding code of WRONG_LAST_HOP 843 is noted and processing continues as in Section 8.2 845 Duplicate Query messages as identified by the tuple (IP Source, Query 846 ID) SHOULD be ignored. This MAY be implemented using a simple 1-back 847 cache (i.e. remembering the IP source and Query ID of the previous 848 Query message that was processed, and ignoring future messages with 849 the same IP Source and Query ID). Duplicate Request messages MUST 850 NOT be ignored in this manner. 852 8.1.2. Normal Processing 854 When a router receives a traceroute Query and it determines that it 855 is the proper last-hop router, it treats it like a traceroute Request 856 and performs the steps listed in Section 8.2 858 8.2. Traceroute Request 860 A traceroute Request is a traceroute message with some number of 861 response blocks filled in, and also uses IGMP type 0x1F for IPv4 862 mtrace or ICMPv6 type MTRACE6_QRYREQ (TBD) for IPv6 mtrace. Routers 863 can tell the difference between Queries and Requests by checking the 864 length of the packet. 866 8.2.1. Packet Verification 868 If the traceroute Request is not addressed to this router, or if the 869 Request is addressed to a multicast group which is not a link-scoped 870 group (i.e. 224/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be 871 silently ignored. 873 8.2.2. Normal Processing 875 When a router receives a traceroute Request, it performs the 876 following steps. Note that it is possible to have multiple 877 situations covered by the Forwarding Codes. The first one 878 encountered is the one that is reported, i.e. all "note forwarding 879 code N" should be interpreted as "if forwarding code is not already 880 set, set forwarding code to N". 882 1. If there is room in the current buffer (or the router can 883 efficiently allocate more space to use), insert a new response 884 block into the packet and fill in the Query Arrival Time, 885 Outgoing Interface Address (for IPv4 mtrace) or Outgoing 886 Interface ID (for IPv6 mtrace), Output Packet Count, and Fwd TTL 887 or Fwd Hop Limit. If there was no room, fill in the response 888 code "NO_SPACE" in the *previous* hop's response block, and 889 forward the packet to the requester as described in "Forwarding 890 Traceroute Requests". 892 2. Attempt to determine the forwarding information for the source 893 and group specified, using the same mechanisms as would be used 894 when a packet is received from the source destined for the 895 group. State need not be instantiated, it can be "phantom" 896 state created only for the purpose of the trace. 898 If using a shared-tree protocol and there is no source-specific 899 state, or if the source is specified as 0xFFFFFFFF, group state 900 should be used. If there is no group state or the group is 901 specified as 0, potential source state (i.e. the path that would 902 be followed for a source-specific Join) should be used. If this 903 router is the Core or RP and no source-specific information is 904 available, note an error code of REACHED_RP. 906 3. If no forwarding information can be determined, the router notes 907 an error code of NO_ROUTE, sets the remaining fields that have 908 not yet been filled in to zero, and then forwards the packet to 909 the requester as described in "Forwarding Traceroute Requests". 911 4. Fill in the Incoming Interface Address, Previous-Hop Router 912 Address, Input Packet Count, Total Number of Packets, Routing 913 Protocol, S, and Src Mask from the forwarding information that 914 was determined. 916 5. If traceroute is administratively prohibited or the previous hop 917 router does not understand traceroute requests, note the 918 appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If 919 traceroute is administratively prohibited and any of the fields 920 as filled in step 4 are considered private information, zero out 921 the applicable fields. Then the packet is forwarded to the 922 requester as described in "Forwarding Traceroute Requests". 924 6. If the reception interface is not enabled for multicast, note 925 forwarding code NO_MULTICAST. If the reception interface is the 926 interface from which the router would expect data to arrive from 927 the source, note forwarding code RPF_IF. Otherwise, if the 928 reception interface is not one to which the router would forward 929 data from the source to the group, a forwarding code of WRONG_IF 930 is noted. 932 7. If the group is subject to administrative scoping on either the 933 Outgoing or Incoming interfaces, a forwarding code of SCOPED is 934 noted. 936 8. If this router is the Rendez-vous Point or Core for the group, a 937 forwarding code of REACHED_RP is noted. 939 9. If this router has sent a prune upstream which applies to the 940 source and group in the traceroute Request, it notes forwarding 941 code PRUNE_SENT. If the router has stopped forwarding 942 downstream in response to a prune sent by the next hop router, 943 it notes forwarding code PRUNE_RCVD. If the router should 944 normally forward traffic for this source and group downstream 945 but is not, it notes forwarding code NOT_FORWARDING. 947 10. The packet is then sent on to the previous hop or the requester 948 as described in Section 8.4. 950 8.3. Traceroute Response 952 A router must forward all traceroute response packets normally, with 953 no special processing. If a router has initiated a traceroute with a 954 Query or Request message, it may listen for Responses to that 955 traceroute but MUST still forward them as well. 957 8.4. Forwarding Traceroute Requests 959 If the Previous-hop router is known for this request and the number 960 of response blocks is less than the number requested, the packet is 961 sent to that router. If the Incoming Interface is known but the 962 Previous-hop router is not known, the packet is sent to an 963 appropriate multicast address on the Incoming Interface. The 964 appropriate multicast address may depend on the routing protocol in 965 use, MUST be a link-scoped group (i.e. 224/24 for IPv4, FF02::/16 for 966 IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 and All 967 Nodes Address (FF02::1) for IPv6, and MAY be ALL-ROUTERS.MCAST.NET 968 (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6 if the 969 routing protocol in use does not define a more appropriate group. 970 Otherwise, it is sent to the Response Address in the header, as 971 described in Section 8.5. 973 Note that it is not an error for the number of response blocks to be 974 greater than the number requested; such a packet should simply be 975 forwarded to the requester as described in Section 8.5. 977 8.5. Sending Traceroute Responses 979 8.5.1. Destination Address 981 A traceroute response must be sent to the Response Address in the 982 traceroute header. 984 8.5.2. TTL and Hop Limit 986 If the Response Address is unicast, the router inserts its normal 987 unicast TTL or hop limit in the IP header, and may use any of its 988 interface addresses as the source address. If the Response Address 989 is multicast, the router copies the Response TTL or hop limit from 990 the traceroute header into the IP header. 992 8.5.3. Source Address 994 If the Response Address is unicast, the router may use any of its 995 interface addresses as the source address. Since some multicast 996 routing protocols forward based on source address, if the Response 997 Address is multicast, the router MUST use an address that is known in 998 the multicast routing topology if it can make that determination. 1000 8.5.4. Sourcing multicast responses 1002 When a router sources a multicast response, the response packet MUST 1003 be sent on a single interface, then forwarded as if it were received 1004 on that interface. It MUST NOT source the response packet 1005 individually on each interface, in order to avoid duplicate packets. 1007 8.6. Hiding information 1009 Information about a domain's topology and connectivity may be hidden 1010 from multicast traceroute requests. The exact mechanism is not 1011 specified here; however, the INFO_HIDDEN forwarding code may be used 1012 to note that, for example, the incoming interface address and packet 1013 count are for the entrance to the domain and the outgoing interface 1014 address and packet count are the exit from the domain. The source- 1015 group packet count may be from either router or not specified 1016 (0xffffffff). 1018 9. Using multicast traceroute 1020 9.1. Sample client 1022 This section describes the behavior of an example multicast 1023 traceroute client. 1025 9.1.1. Sending initial query 1027 When the destination of the mtrace is the machine running the client, 1028 the mtrace Query packet can be sent to the ALL-ROUTERS.MCAST.NET 1029 (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6. This 1030 will ensure that the packet is received by the last-hop router on the 1031 subnet. Otherwise, if the proper last-hop router is known for the 1032 mtrace destination, the Query could be unicasted to that router. 1033 Otherwise, the Query packet should be multicasted to the group being 1034 queried; if the destination of the mtrace is a member of the group, 1035 this will get the Query to the proper last-hop router. In this final 1036 case, the packet should contain the Router Alert option [9], to make 1037 sure that routers that are not members of the multicast group notice 1038 the packet. 1040 See also Section 9.2 on determining the last-hop router. 1042 9.1.2. Determining the Path 1044 The client could send a small number of initial query messages with a 1045 large "# hops" field, in order to try to trace the full path. If 1046 this attempt fails, one strategy is to perform a linear search (as 1047 the traditional unicast traceroute program does); set the "# hops" 1048 field to 1 and try to get a response, then 2, and so on. If no 1049 response is received at a certain hop, the hop count can continue 1050 past the non-responding hop, in the hopes that further hops may 1051 respond. These attempts should continue until a user-defined timeout 1052 has occurred. 1054 See also Section 9.3 and Section 9.4 on receiving the results of a 1055 trace. 1057 9.1.3. Collecting statistics 1059 After a client has determined that it has traced the whole path or as 1060 much as it can expect to (see Section 9.5), it might collect 1061 statistics by waiting a short time and performing a second trace. If 1062 the path is the same in the two traces, statistics can be displayed 1063 as described in Section 10.3 and Section 10.4. 1065 9.2. Last hop router 1067 The mtrace querier may not know which is the last hop router, or that 1068 router may be behind a firewall that blocks unicast packets but 1069 passes multicast packets. In these cases, the mtrace request should 1070 be multicasted to the group being traced (since the last hop router 1071 listens to that group). All routers except the correct last hop 1072 router should ignore any mtrace request received via multicast. 1073 Mtrace requests which are multicasted to the group being traced must 1074 include the Router Alert option [9]. 1076 Another alternative is to unicast to the trace destination. 1077 Traceroute requests which are unicasted to the trace destination must 1078 include the Router Alert option, in order that the last-hop router is 1079 aware of the packet. 1081 If the traceroute querier is attached to the same router as the 1082 destination of the request, the traceroute request may be multicasted 1083 to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address 1084 (FF02::2) for IPv6 if the last-hop router is not known. 1086 9.3. First hop router 1088 The mtrace querier may not be unicast reachable from the first hop 1089 router. In this case, the querier should set the traceroute response 1090 address to a multicast address, and should set the response TTL (or 1091 hop limit) to a value sufficient for the response from the first hop 1092 router to reach the querier. It may be appropriate to start with a 1093 small TTL and increase in subsequent attempts until a sufficient TTL 1094 is reached, up to an appropriate maximum (such as 192). 1096 The IANA has assigned 224.0.1.32, MTRACE.MCAST.NET as the default 1097 multicast group for IPv4 mtrace responses, and will assign 1098 MTRACE6_RESPADDR (TBD) for IPv6 mtrace responses. Other groups may 1099 be used if needed, e.g. when using mtrace to diagnose problems with 1100 the IANA-assigned group. 1102 9.4. Broken intermediate router 1104 A broken intermediate router might simply not understand traceroute 1105 packets, and drop them. The querier would then get no response at 1106 all from its traceroute requests. It should then perform a hop-by- 1107 hop search by setting the number of responses field until it gets a 1108 response (both linear and binary search are options, but binary is 1109 likely to be slower because a failure requires waiting for a 1110 timeout). 1112 9.5. Mtrace termination 1114 When performing an expanding hop-by-hop trace, it is necessary to 1115 determine when to stop expanding. 1117 9.5.1. Arriving at source 1119 A trace can be determined to have arrived at the source if the 1120 Incoming Interface of the last router in the trace is non-zero, but 1121 the Previous Hop router is zero. 1123 9.5.2. Fatal error 1125 A trace has encountered a fatal error if the last Forwarding Error in 1126 the trace has the 0x80 bit set. 1128 9.5.3. No previous hop 1130 A trace can not continue if the last Previous Hop in the trace is set 1131 to 0. 1133 9.5.4. Traceroute shorter than requested 1135 If the trace that is returned is shorter than requested (i.e. the 1136 number of Response blocks is smaller than the "# hops" field), the 1137 trace encountered an error and could not continue. 1139 9.6. Continuing after an error 1141 When the NO_SPACE error occurs, the client might try to continue the 1142 trace by starting it at the last hop in the trace. It can do this by 1143 unicasting to this router's outgoing interface address, keeping all 1144 fields the same. If this results in a single hop and a "WRONG_IF" 1145 error, the client may try setting the trace destination to the same 1146 outgoing interface address. 1148 If a trace times out, it is likely to be because a router in the 1149 middle of the path does not support multicast traceroute. That 1150 router's address will be in the Previous Hop field of the last entry 1151 in the last reply packet received. A client may be able to determine 1152 (via mrinfo or SNMP [7][11]) a list of neighbors of the non- 1153 responding router. If desired, each of those neighbors could be 1154 probed to determine the remainder of the path. Unfortunately, this 1155 heuristic may end up with multiple paths, since there is no way of 1156 knowing what the non-responding router's algorithm for choosing a 1157 previous-hop router is. However, if all paths but one flow back 1158 towards the non-responding router, it is possible to be sure that 1159 this is the correct path. 1161 9.7. Multicast Traceroute and shared tree routing protocols 1163 When using shared-tree routing protocols like PIM-SM and CBT, a more 1164 advanced client may use multicast traceroute to determine paths or 1165 potential paths. 1167 9.7.1. PIM-SM 1169 When a multicast traceroute reaches a PIM-SM RP and the RP does not 1170 forward the trace on, it means that the RP has not performed a 1171 source-specific join so there is no more state to trace. However, 1172 the path that traffic would use if the RP did perform a source- 1173 specific join can be traced by setting the trace destination to the 1174 RP, the trace source to the traffic source, and the trace group to 0. 1175 This trace Query may be unicasted to the RP. 1177 9.7.2. Bi-directional PIM 1179 Bi-directional PIM [14] is a variant of PIM-SM that builds bi- 1180 directional shared trees connecting multicast sources and receivers. 1181 Along the bi-directional shared trees, multicast data is natively 1182 forwarded from sources to the RPA (Rendezvous Point Address) and from 1183 the RPA to receivers without requiring source-specific state. In 1184 contrast to PIM-SM, RP always has the state to trace. 1186 A Designated Forwarder (DF) for a given RPA is in charge of 1187 forwarding downstream traffic onto its link, and forwarding upstream 1188 traffic from its link towards the RPL (Rendezvous Point Link) that 1189 the RPA belongs to. Hence mtrace reports DF addresses or RPA along 1190 the path. 1192 9.7.3. CBT 1194 When a multicast traceroute reaches a CBT [13] Core, it must simply 1195 stop since CBT does not have source-specific state. However, a 1196 second trace can be performed, setting the trace destination to the 1197 traffic source, the trace group to the group being traced, and the 1198 trace source to the Core (or to 0, since CBT does not have source- 1199 specific state). This trace Query may be unicasted to the Core. 1200 There are two possibilities when combining the two traces: 1202 9.7.3.1. No overlap 1204 If there is no overlap between the two traces, the second trace can 1205 be reversed and appended to the first trace. This composite trace 1206 shows the full path from the source to the destination. 1208 9.7.3.2. Overlapping paths 1210 If there is a portion of the path that is common to the ends of the 1211 two traces, that portion is removed from both traces. Then, as in 1212 the no overlap case, the second trace is reversed and appended to the 1213 first trace, and the composite trace again contains the full path. 1215 This algorithm works whether the source has joined the CBT tree or 1216 not. 1218 9.8. Protocol-specific considerations 1220 9.8.1. DVMRP 1222 DVMRP's dominant router election and route exchange guarantees that 1223 DVMRP routers know whether or not they are the last-hop forwarder for 1224 the link and who the previous hop is. 1226 9.8.2. PIM-DM 1228 Routers running PIM Dense Mode do not know the path packets would 1229 take unless traffic is flowing. Without some extra protocol 1230 mechanism, this means that in an environment with multiple possible 1231 paths with branch points on shared media, multicast traceroute can 1232 only trace existing paths, not potential paths. When there are 1233 multiple possible paths but the branch points are not on shared 1234 media, the previous hop router is known, but the last hop router may 1235 not know that it is the appropriate last hop. 1237 When traffic is flowing, PIM Dense Mode routers know whether or not 1238 they are the last-hop forwarder for the link (because they won or 1239 lost an Assert battle) and know who the previous hop is (because it 1240 won an Assert battle). Therefore, multicast traceroute is always 1241 able to follow the proper path when traffic is flowing. 1243 10. Problem Diagnosis 1245 10.1. Forwarding Inconsistencies 1247 The forwarding error code can tell if a group is unexpectedly pruned 1248 or administratively scoped. 1250 10.2. TTL or hop limit problems 1252 By taking the maximum of (hops from source + forwarding TTL (or hop 1253 limit) threshold) over all hops, you can discover the TTL required 1254 for the source to reach the destination. 1256 10.3. Packet loss 1258 By taking two traces, you can find packet loss information by 1259 comparing the difference in input packet counts to the difference in 1260 output packet counts at the previous hop. On a point-to-point link, 1261 any difference in these numbers implies packet loss. Since the 1262 packet counts may be changing as the trace query is propagating, 1263 there may be small errors (off by 1 or 2) in these statistics. 1264 However, these errors will not accumulate if multiple traces are 1265 taken to expand the measurement period. On a shared link, the count 1266 of input packets can be larger than the number of output packets at 1267 the previous hop, due to other routers or hosts on the link injecting 1268 packets. This appears as "negative loss" which may mask real packet 1269 loss. 1271 In addition to the counts of input and output packets for all 1272 multicast traffic on the interfaces, the response data includes a 1273 count of the packets forwarded by a node for the specified source- 1274 group pair. Taking the difference in this count between two traces 1275 and then comparing those differences between two hops gives a measure 1276 of packet loss just for traffic from the specified source to the 1277 specified receiver via the specified group. This measure is not 1278 affected by shared links. 1280 On a point-to-point link that is a multicast tunnel, packet loss is 1281 usually due to congestion in unicast routers along the path of that 1282 tunnel. On native multicast links, loss is more likely in the output 1283 queue of one hop, perhaps due to priority dropping, or in the input 1284 queue at the next hop. The counters in the response data do not 1285 allow these cases to be distinguished. Differences in packet counts 1286 between the incoming and outgoing interfaces on one node cannot 1287 generally be used to measure queue overflow in the node. 1289 10.4. Link Utilization 1291 Again, with two traces, you can divide the difference in the input or 1292 output packet counts at some hop by the difference in time stamps 1293 from the same hop to obtain the packet rate over the link. If the 1294 average packet size is known, then the link utilization can also be 1295 estimated to see whether packet loss may be due to the rate limit or 1296 the physical capacity on a particular link being exceeded. 1298 10.5. Time delay 1300 If the routers have synchronized clocks, it is possible to estimate 1301 propagation and queuing delay from the differences between the 1302 timestamps at successive hops. However, this delay includes control 1303 processing overhead, so is not necessarily indicative of the delay 1304 that data traffic would experience. 1306 11. IANA Considerations 1308 The following new assignments can only be made via a Standards Action 1309 as specified in [6]. 1311 11.1. Routing protocols 1313 The IANA is responsible for allocating new Routing Protocol codes. 1314 The Routing Protocol code is somewhat problematic, since in the case 1315 of protocols like CBT and PIM it must encode both a unicast routing 1316 algorithm and a multicast tree-building protocol. The space was not 1317 divided into two fields because it was already small and some 1318 combinations (e.g. DVMRP) would be wasted. 1320 11.2. Forwarding codes 1322 New Forwarding codes must only be created by an RFC that modifies 1323 this document's Section 9, fully describing the conditions under 1324 which the new forwarding code is used. The IANA may act as a central 1325 repository so that there is a single place to look up forwarding 1326 codes and the document in which they are defined. 1328 11.3. IPv6 mtrace 1330 The IANA should allocate ICMPv6 types (MTRACE6_QRYREQ and 1331 MTRACE6_RESP) for IPv6 multicast traceroute upon publication of the 1332 first RFC. Additionally, the well-known multicast address 1333 (MTRACE6_RESPADDR) intended for default use by IPv6 multicast 1334 traceroute should be registered and defined by the first RFC 1335 published. 1337 12. Security Considerations 1339 12.1. Topology Discovery 1341 mtrace can be used to discover any actively-used topology. If your 1342 network topology is a secret, mtrace may be restricted at the border 1343 of your domain, using the ADMIN_PROHIB forwarding code. 1345 12.2. Traffic Rates 1347 mtrace can be used to discover what sources are sending to what 1348 groups and at what rates. If this information is a secret, mtrace 1349 may be restricted at the border of your domain, using the 1350 ADMIN_PROHIB forwarding code. 1352 12.3. Unicast Replies 1354 The "Response address" field may be used to send a single packet (the 1355 traceroute Reply packet) to an arbitrary unicast address. It is 1356 possible to use this facility as a packet amplifier, as a small 1357 multicast traceroute Query may turn into a large Reply packet. 1359 13. Acknowledgements 1361 This specification started largely as a transcription of Van 1362 Jacobson's slides from the 30th IETF, and the implementation in 1363 mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve 1364 Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original 1365 multicast traceroute client, mtrace (version 1), has been implemented 1366 by Ajit Thyagarajan, Steve Casner and Bill Fenner. 1368 The idea of unicasting a multicast traceroute Query to the 1369 destination of the trace with Router Alert set is due to Tony 1370 Ballardie. The idea of the "S" bit to allow statistics for a source 1371 subnet is due to Tom Pusateri. 1373 14. References 1375 14.1. Normative References 1377 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 1378 levels", RFC 2119, March 1997. 1380 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1381 Specification", RFC 2460, December 1998. 1383 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 1384 Architecture", RFC 2373, July 1998. 1386 [4] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1387 Thyagarajan, "Internet Group Management Protocol, Version 3", 1388 RFC 3376, October 2002. 1390 [5] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 1391 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1392 Specification", RFC 4443, March 2006. 1394 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1395 Considerations Section in RFCs", RFC 2434, October 1998. 1397 14.2. Informative References 1399 [7] Draves, R. and D. Thaler, "Default Router Preferences and More- 1400 Specific Routes", RFC 4191, November 2005. 1402 [8] Braden, B., Borman, D., and C. Partridge, "Computing the 1403 Internet Checksum", RFC 1071, September 1988. 1405 [9] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 1407 [10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", 1408 RFC 2863, June 2000. 1410 [11] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB", 1411 draft-ietf-mboned-ip-mcast-mib-05.txt (work in progress), 1412 March 2007. 1414 [12] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1415 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1416 Protocol Specification (Revised)", RFC 4601, August 2006. 1418 [13] Ballardie, T., "Core Based Trees (CBT version 2) Multicast 1419 Routing -- Protocol Specification --", RFC 2189, 1420 September 1997. 1422 [14] Handley, M., Kouvelas, I., and T. Speakman, "Bi-directional 1423 Protocol Independent Multicast (BIDIR-PIM)", 1424 draft-ietf-pim-bidir-09.txt (work in progress), February 2007. 1426 Authors' Addresses 1428 Hitoshi Asaeda 1429 Keio University 1430 Graduate School of Media and Governance 1431 Fujisawa, Kanagawa 252-8520 1432 Japan 1434 Email: asaeda@wide.ad.jp 1436 Tatsuya Jinmei 1437 Toshiba Corporation 1438 Corporate Research & Development Center 1439 Kawasaki, Kanagawa 212-8582 1440 Japan 1442 Email: jinmei@isl.rdc.toshiba.co.jp 1444 William C. Fenner 1445 AT&T Research 1446 Menlo Park, CA 94025 1447 US 1449 Email: fenner@research.att.com 1451 Stephen L. Casner 1452 Packet Design, Inc. 1453 Palo Alto, CA 94304 1454 US 1456 Email: casner@packetdesign.com 1458 Full Copyright Statement 1460 Copyright (C) The IETF Trust (2007). 1462 This document is subject to the rights, licenses and restrictions 1463 contained in BCP 78, and except as set forth therein, the authors 1464 retain all their rights. 1466 This document and the information contained herein are provided on an 1467 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1468 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1469 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1470 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1471 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1474 Intellectual Property 1476 The IETF takes no position regarding the validity or scope of any 1477 Intellectual Property Rights or other rights that might be claimed to 1478 pertain to the implementation or use of the technology described in 1479 this document or the extent to which any license under such rights 1480 might or might not be available; nor does it represent that it has 1481 made any independent effort to identify any such rights. Information 1482 on the procedures with respect to rights in RFC documents can be 1483 found in BCP 78 and BCP 79. 1485 Copies of IPR disclosures made to the IETF Secretariat and any 1486 assurances of licenses to be made available, or the result of an 1487 attempt made to obtain a general license or permission for the use of 1488 such proprietary rights by implementers or users of this 1489 specification can be obtained from the IETF on-line IPR repository at 1490 http://www.ietf.org/ipr. 1492 The IETF invites any interested party to bring to its attention any 1493 copyrights, patents or patent applications, or other proprietary 1494 rights that may cover technology that may be required to implement 1495 this standard. Please address the information to the IETF at 1496 ietf-ipr@ietf.org. 1498 Acknowledgment 1500 Funding for the RFC Editor function is provided by the IETF 1501 Administrative Support Activity (IASA).