idnits 2.17.1 draft-ietf-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 1478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1502. 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 (November 12, 2007) is 6010 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. '5') (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. '11') (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: May 15, 2008 T. Jinmei 5 Toshiba Corporation 6 W. Fenner 7 AT&T Research 8 S. Casner 9 Packet Design, Inc. 10 November 12, 2007 12 Mtrace Version 2: Traceroute Facility for IP Multicast 13 draft-ietf-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 May 15, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document describes the IP multicast traceroute facility. Unlike 47 unicast traceroute, multicast traceroute requires special 48 implementations on the part of routers. This specification describes 49 the required functionality in multicast routers, as well as how 50 management applications can use the new router functionality. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. IPv4 Multicast Traceroute Header . . . . . . . . . . . . . . . 8 58 4.1. Type: 8 bits . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.2. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 8 60 4.3. Checksum: 16 bits . . . . . . . . . . . . . . . . . . . . 9 61 4.4. Multicast Address . . . . . . . . . . . . . . . . . . . . 9 62 4.5. Source Address . . . . . . . . . . . . . . . . . . . . . . 9 63 4.6. Destination Address . . . . . . . . . . . . . . . . . . . 9 64 4.7. Response Address . . . . . . . . . . . . . . . . . . . . . 9 65 4.8. Resp TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 9 66 4.9. Query ID: 24 bits . . . . . . . . . . . . . . . . . . . . 9 67 5. IPv4 Multicast Traceroute Response Data . . . . . . . . . . . 10 68 5.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 10 69 5.2. Incoming Interface Address . . . . . . . . . . . . . . . . 11 70 5.3. Outgoing Interface Address . . . . . . . . . . . . . . . . 11 71 5.4. Previous-Hop Router Address . . . . . . . . . . . . . . . 11 72 5.5. Packet counts . . . . . . . . . . . . . . . . . . . . . . 11 73 5.6. Input packet count on incoming interface . . . . . . . . . 11 74 5.7. Output packet count on incoming interface . . . . . . . . 11 75 5.8. Total number of packets for this source-group pair . . . . 11 76 5.9. Rtg Protocol: 8 bits . . . . . . . . . . . . . . . . . . . 12 77 5.10. Fwd TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 12 78 5.11. MBZ: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.13. Src Mask: 6 bits . . . . . . . . . . . . . . . . . . . . . 12 81 5.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 13 82 6. IPv6 Multicast Traceroute Header . . . . . . . . . . . . . . . 15 83 6.1. Type: 8 bits . . . . . . . . . . . . . . . . . . . . . . . 16 84 6.2. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 16 85 6.3. Checksum: 16 bits . . . . . . . . . . . . . . . . . . . . 16 86 6.4. Reserved: 32 bits . . . . . . . . . . . . . . . . . . . . 16 87 6.5. Multicast Address . . . . . . . . . . . . . . . . . . . . 16 88 6.6. Source Address . . . . . . . . . . . . . . . . . . . . . . 16 89 6.7. Destination Address . . . . . . . . . . . . . . . . . . . 16 90 6.8. Response Address . . . . . . . . . . . . . . . . . . . . . 16 91 6.9. Resp Hop Limit: 8 bits . . . . . . . . . . . . . . . . . . 17 92 6.10. Query ID: 24 bits . . . . . . . . . . . . . . . . . . . . 17 93 7. IPv6 Multicast Traceroute Response Data . . . . . . . . . . . 18 94 7.1. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 19 95 7.2. Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 19 96 7.3. Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 19 97 7.4. Local Address . . . . . . . . . . . . . . . . . . . . . . 19 98 7.5. Remote Address . . . . . . . . . . . . . . . . . . . . . . 19 99 7.6. Input packet count on incoming interface . . . . . . . . . 20 100 7.7. Output packet count on incoming interface . . . . . . . . 20 101 7.8. Total number of packets for this source-group pair . . . . 20 102 7.9. Rtg Protocol: 8 bits . . . . . . . . . . . . . . . . . . . 20 103 7.10. Fwd Hop Limit: 8 bits . . . . . . . . . . . . . . . . . . 20 104 7.11. MBZ: 7 bits . . . . . . . . . . . . . . . . . . . . . . . 20 105 7.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 7.13. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 20 107 7.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 21 108 7.15. Reserved: 24 bit . . . . . . . . . . . . . . . . . . . . . 21 109 8. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 110 8.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 22 111 8.1.1. Packet Verification . . . . . . . . . . . . . . . . . 22 112 8.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 22 113 8.2. Traceroute Request . . . . . . . . . . . . . . . . . . . . 22 114 8.2.1. Packet Verification . . . . . . . . . . . . . . . . . 23 115 8.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 23 116 8.3. Traceroute Response . . . . . . . . . . . . . . . . . . . 24 117 8.4. Forwarding Traceroute Requests . . . . . . . . . . . . . . 24 118 8.5. Sending Traceroute Responses . . . . . . . . . . . . . . . 25 119 8.5.1. Destination Address . . . . . . . . . . . . . . . . . 25 120 8.5.2. TTL and Hop Limit . . . . . . . . . . . . . . . . . . 25 121 8.5.3. Source Address . . . . . . . . . . . . . . . . . . . . 25 122 8.5.4. Sourcing multicast responses . . . . . . . . . . . . . 25 123 8.6. Hiding information . . . . . . . . . . . . . . . . . . . . 26 124 9. Using multicast traceroute . . . . . . . . . . . . . . . . . . 27 125 9.1. Sample client . . . . . . . . . . . . . . . . . . . . . . 27 126 9.1.1. Sending initial query . . . . . . . . . . . . . . . . 27 127 9.1.2. Determining the Path . . . . . . . . . . . . . . . . . 27 128 9.1.3. Collecting statistics . . . . . . . . . . . . . . . . 27 129 9.2. Last hop router . . . . . . . . . . . . . . . . . . . . . 28 130 9.3. First hop router . . . . . . . . . . . . . . . . . . . . . 28 131 9.4. Broken intermediate router . . . . . . . . . . . . . . . . 28 132 9.5. Mtrace2 termination . . . . . . . . . . . . . . . . . . . 29 133 9.5.1. Arriving at source . . . . . . . . . . . . . . . . . . 29 134 9.5.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 29 135 9.5.3. No previous hop . . . . . . . . . . . . . . . . . . . 29 136 9.5.4. Traceroute shorter than requested . . . . . . . . . . 29 137 9.6. Continuing after an error . . . . . . . . . . . . . . . . 29 138 9.7. Multicast Traceroute and shared tree routing protocols . . 30 139 9.7.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 30 140 9.7.2. Bi-directional PIM . . . . . . . . . . . . . . . . . . 30 141 9.7.3. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 30 142 9.8. Protocol-specific considerations . . . . . . . . . . . . . 31 143 9.8.1. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 31 144 9.8.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 31 145 10. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 32 146 10.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 32 147 10.2. TTL or hop limit problems . . . . . . . . . . . . . . . . 32 148 10.3. Packet loss . . . . . . . . . . . . . . . . . . . . . . . 32 149 10.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 33 150 10.5. Time delay . . . . . . . . . . . . . . . . . . . . . . . . 33 151 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 152 11.1. Routing protocols . . . . . . . . . . . . . . . . . . . . 34 153 11.2. Forwarding codes . . . . . . . . . . . . . . . . . . . . . 34 154 11.3. UDP destination port and IPv6 address . . . . . . . . . . 34 155 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 156 12.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 35 157 12.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 35 158 12.3. Unicast Replies . . . . . . . . . . . . . . . . . . . . . 35 159 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 160 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 161 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 162 14.2. Informative References . . . . . . . . . . . . . . . . . . 37 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 164 Intellectual Property and Copyright Statements . . . . . . . . . . 39 166 1. Introduction 168 The unicast "traceroute" program allows the tracing of a path from 169 one machine to another. The key mechanism for unicast traceroute is 170 the ICMP TTL exceeded message, which is specifically precluded as a 171 response to multicast packets. On the other hand, the multicast 172 traceroute facility allows the tracing of an IP multicast routing 173 paths. In this document, we specify the new multicast "traceroute" 174 facility to be implemented in multicast routers and accessed by 175 diagnostic programs. The new multicast traceroute, mtrace version 2 176 or mtrace2, can provide additional information about packet rates and 177 losses that the unicast traceroute cannot, and generally requires 178 fewer packets to be sent. 180 o. To be able to trace the path that a packet would take from some 181 source to some destination. 183 o. To be able to isolate packet loss problems (e.g., congestion). 185 o. To be able to isolate configuration problems (e.g., TTL 186 threshold). 188 o. To minimize packets sent (e.g. no flooding, no implosion). 190 This document supports both IPv4 and IPv6 multicast traceroute 191 facility. The protocol design, concept, and program behavior are 192 same between IPv4 and IPv6 mtrace2. Regarding the previous IPv4 193 multicast traceroute, mtrace, the query and response messages for 194 IPv4 mtrace are implemented as IGMP messages [4]. On the other hand, 195 mtrace2 messages are carried on UDP, whereas the packet formats of 196 IPv4 and IPv6 mtrace2 are different (but similar) because of the 197 different address family. 199 2. Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 202 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 203 this document are to be interpreted as described in RFC 2119 [1]. 205 Since multicast traceroutes flow in the opposite direction to the 206 data flow, we refer to "upstream" and "downstream" with respect to 207 data, unless explicitly specified. 209 Incoming interface: 210 The interface on which traffic is expected from the specified source 211 and group. 213 Outgoing interface: 214 The interface on which traffic is forwarded from the specified source 215 and group toward the destination. It is the interface on which the 216 multicast traceroute Request was received. 218 Previous-hop router: 219 The router that is on the link attached to the Incoming Interface and 220 is responsible for forwarding traffic for the specified source and 221 group. 223 Group state: 224 It is the state in which a shared-tree protocol (e.g., PIM-SM [11]) 225 running on a router chooses the previous-hop router toward the core 226 router (or RP) as its parent router. In this state, source-specific 227 state is not available for the corresponding multicast address on the 228 router. 230 Source-specific state: 231 It is the state in which a routing protocol running on a router 232 chooses the path that would be followed for a source-specific join. 234 3. Overview 236 Given a multicast distribution tree, tracing from a source to a 237 multicast destination is hard, since you don't know down which branch 238 of the multicast tree the destination lies. This means that you have 239 to flood the whole tree to find the path from one source to one 240 destination. However, walking up the tree from destination to source 241 is easy, as most existing multicast routing protocols know the 242 previous hop for each source. Tracing from destination to source can 243 involve only routers on the direct path. 245 The party requesting the traceroute (which need be neither the source 246 nor the destination) sends a traceroute Query packet to the last-hop 247 multicast router for the given destination. The last-hop router 248 turns the Query into a Request packet by adding a response data block 249 containing its interface addresses and packet statistics, and then 250 forwards the Request packet via unicast to the router that it 251 believes is the proper previous hop for the given source and group. 252 Each hop adds its response data to the end of the Request packet, 253 then unicast forwards it to the previous hop. The first hop router 254 (the router that believes that packets from the source originate on 255 one of its directly connected networks) changes the packet type to 256 indicate a Response packet and sends the completed response to the 257 response destination address. The response may be returned before 258 reaching the first hop router if a fatal error condition such as "no 259 route" is encountered along the path. 261 Multicast traceroute uses any information available to it in the 262 router to attempt to determine a previous hop to forward the trace 263 towards. Multicast routing protocols vary in the type and amount of 264 state they keep; multicast traceroute endeavors to work with all of 265 them by using whatever is available. For example, if a DVMRP router 266 has no active state for a particular source but does have a DVMRP 267 route, it chooses the parent of the DVMRP route as the previous hop. 268 If a PIM-SM router is on the (*,G) tree, it chooses the parent 269 towards the RP as the previous hop. In these cases, no source/ 270 group-specific state is available, but the path may still be traced. 272 4. IPv4 Multicast Traceroute Header 274 The mtrace2 message is carried as a UDP packet. The UDP source port 275 is uniquely selected by the local host operating system. The UDP 276 destination port is the IANA reserved mtrace2 port number (see 277 Section 11). The UDP checksum MUST be valid in mtrace2 control 278 messages. 280 The IPv4 mtrace2 includes the common packet header as follows. The 281 header is only filled in by the originator of the traceroute Query; 282 intermediate routers MUST NOT modify any of the fields. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Reserved | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Multicast Address | 290 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 291 | Source Address | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Destination Address | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Response Address | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |Resp TTL/HopLim| Query ID | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 4.1. Type: 8 bits 302 The UDP type field is defined to be "0x1" for traceroute queries and 303 requests. The UDP type field is changed to "0x2" when the packet is 304 completed and sent as a response from the first hop router to the 305 querier. Two codes are required so that multicast routers won't 306 attempt to process a completed response in those cases where the 307 initial query was issued from a router or the response is sent via 308 multicast. 310 4.2. # hops: 8 bits 312 This field specifies the maximum number of hops that the requester 313 wants to trace. If there is some error condition in the middle of 314 the path that keeps the traceroute request from reaching the first- 315 hop router, this field can be used to perform an expanding-ring 316 search to trace the path to just before the problem. 318 4.3. Checksum: 16 bits 320 The checksum is the 16-bit one's complement of the one's complement 321 sum of the whole UDP message (the entire IP payload) [7]. When 322 computing the checksum, the checksum field is set to zero. When 323 transmitting packets, the checksum MUST be computed and inserted into 324 this field. When receiving packets, the checksum MUST be verified 325 before processing a packet. 327 4.4. Multicast Address 329 This field specifies the multicast address to be traced, or zero if 330 no group-specific information is desired. Note that non-group- 331 specific traceroutes may not be possible with certain multicast 332 routing protocols. 334 4.5. Source Address 336 This field specifies the IP address of the multicast source for the 337 path being traced, or 0xffffffff if no source-specific information is 338 desired. Note that non-source-specific traceroutes may not be 339 possible with certain multicast routing protocols. 341 4.6. Destination Address 343 This field specifies the IP address of the multicast receiver for the 344 path being traced. The trace starts at this destination and proceeds 345 toward the traffic source. 347 4.7. Response Address 349 This field specifies IP address to which the completed traceroute 350 response packet gets sent. It can be a unicast address or a 351 multicast address, as explained in Section 8.2 353 4.8. Resp TTL: 8 bits 355 This field specifies the TTL at which to multicast the response, if 356 the response address is a multicast address. 358 4.9. Query ID: 24 bits 360 This field is used as a unique identifier for this traceroute request 361 so that duplicate or delayed responses may be detected and to 362 minimize collisions when a multicast response address is used. 364 5. IPv4 Multicast Traceroute Response Data 366 Each intermediate router in a trace path appends "response data" to 367 the forwarded trace packet. The response data looks as follows. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Query Arrival Time | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Incoming Interface Address | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Outgoing Interface Address | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Previous-Hop Router Address | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 | Input packet count on incoming interface | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | | 384 | Output packet count on outgoing interface | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 | Total number of packets for this source-group pair | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | |M| | | | 390 | Rtg Protocol | Fwd TTL |B|S| Src Mask |Forwarding Code| 391 | | |Z| | | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 5.1. Query Arrival Time: 32 bits 396 The Query Arrival Time is a 32-bit NTP timestamp specifying the 397 arrival time of the traceroute request packet at this router. The 398 32-bit form of an NTP timestamp consists of the middle 32 bits of the 399 full 64-bit form; that is, the low 16 bits of the integer part and 400 the high 16 bits of the fractional part. 402 The following formula converts from a UNIX timeval to a 32-bit NTP 403 timestamp: 405 query_arrival_time 406 = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec << 10) / 15625) 408 The constant 32384 is the number of seconds from Jan 1, 1900 to Jan 409 1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 15625) is a 410 reduction of ((tv.tv_usec / 100000000) << 16). 412 5.2. Incoming Interface Address 414 This field specifies the address of the interface on which packets 415 from this source and group are expected to arrive, or 0 if unknown. 417 5.3. Outgoing Interface Address 419 This field specifies the address of the interface on which packets 420 from this source and group flow to the specified destination, or 0 if 421 unknown. 423 5.4. Previous-Hop Router Address 425 This field specifies the router from which this router expects 426 packets from this source. This may be a multicast group (e.g. ALL- 427 [protocol]-ROUTERS.MCAST.NET) if the previous hop is not known 428 because of the workings of the multicast routing protocol. However, 429 it should be 0 if the incoming interface address is unknown. 431 5.5. Packet counts 433 Note that these packet counts SHOULD be as up to date as possible. 434 If packet counts are not being maintained on the processor that 435 handles the traceroute request in a multi-processor router 436 architecture, the packet SHOULD be delayed while the counters are 437 gathered from the remote processor(s). If this occurs, the Query 438 Arrival Time should be updated to reflect the time at which the 439 packet counts were learned. 441 5.6. Input packet count on incoming interface 443 This field contains the number of multicast packets received for all 444 groups and sources on the incoming interface, or 0xffffffffffffffff 445 if no count can be reported. This counter should have the same value 446 as ifInMulticastPkts from the IF-MIB [9] for this interface. 448 5.7. Output packet count on incoming interface 450 This field contains the number of multicast packets that have been 451 transmitted or queued for transmission for all groups and sources on 452 the outgoing interface, or 0xffffffffffffffff if no count can be 453 reported. This counter should have the same value as 454 ifOutMulticastPkts from the IF-MIB for this interface. 456 5.8. Total number of packets for this source-group pair 458 This field counts the number of packets from the specified source 459 forwarded by this router to the specified group, or 460 0xffffffffffffffff if no count can be reported. If the S bit is set, 461 the count is for the source network, as specified by the Src Mask 462 field. If the S bit is set and the Src Mask field is 63, indicating 463 no source-specific state, the count is for all sources sending to 464 this group. This counter should have the same value as 465 ipMcastRoutePkts from the IPMROUTE-STD-MIB [10] for this forwarding 466 entry. 468 5.9. Rtg Protocol: 8 bits 470 This field describes the routing protocol in use between this router 471 and the previous-hop router. Specified values include: 473 1 DVMRP 474 2 MOSPF 475 3 PIM 476 4 CBT 477 5 PIM using special routing table 478 6 PIM using a static route 479 7 DVMRP using a static route 480 8 PIM using MBGP route 481 9 CBT using special routing table 482 10 CBT using a static route 483 11 PIM using state created by Assert processing 484 12 Bi-directional PIM 486 Note that some of the routing protocols or functions are not 487 supported or not used in either of IPv4 multicast nor IPv6 multicast. 489 5.10. Fwd TTL: 8 bits 491 This field contains the TTL that a packet is required to have before 492 it will be forwarded over the outgoing interface. 494 5.11. MBZ: 1 bit 496 Must be zeroed on transmission and ignored on reception. 498 5.12. S: 1 bit 500 This S bit indicates that the packet count for the source-group pair 501 is for the source network, as determined by masking the source 502 address with the Src Mask field. 504 5.13. Src Mask: 6 bits 506 This field contains the number of 1's in the netmask this router has 507 for the source (i.e. a value of 24 means the netmask is 0xffffff00). 509 If the router is forwarding solely on group state, this field is set 510 to 63 (0x3f). 512 5.14. Forwarding Code: 8 bits 514 This field contains a forwarding information/error code. Defined 515 values are as follows; 517 Value Name Description 519 ----- -------------- ------------------------------------------- 521 0x00 NO_ERROR No error 523 0x01 WRONG_IF Traceroute request arrived on an interface 524 to which this router would not forward for 525 this source,group,destination. 527 0x02 PRUNE_SENT This router has sent a prune upstream which 528 applies to the source and group in the 529 traceroute request. 531 0x03 PRUNE_RCVD This router has stopped forwarding for this 532 source and group in response to a request 533 from the next hop router. 535 0x04 SCOPED The group is subject to administrative 536 scoping at this hop. 538 0x05 NO_ROUTE This router has no route for the source or 539 group and no way to determine a potential 540 route. 542 0x06 WRONG_LAST_HOP This router is not the proper last-hop 543 router. 545 0x07 NOT_FORWARDING This router is not forwarding this source, 546 group out the outgoing interface for an 547 unspecified reason. 549 0x08 REACHED_RP Reached Rendez-vous Point or Core 551 0x09 RPF_IF Traceroute request arrived on the expected 552 RPF interface for this source, group. 554 0x0A NO_MULTICAST Traceroute request arrived on an interface 555 which is not enabled for multicast. 557 0x0B INFO_HIDDEN One or more hops have been hidden from this 558 trace. 560 0x81 NO_SPACE There was not enough room to insert another 561 response data block in the packet. 563 0x82 OLD_ROUTER The previous-hop router does not understand 564 traceroute requests. 566 0x83 ADMIN_PROHIB Traceroute is administratively prohibited. 568 Note that if a router discovers there is not enough room in a packet 569 to insert its response, it puts the 0x81 error code in the previous 570 router's Forwarding Code field, overwriting any error the previous 571 router placed there. A multicast traceroute client, upon receiving 572 this error, MAY restart the trace at the last hop listed in the 573 packet. 575 The 0x80 bit of the Forwarding Code is used to indicate a fatal 576 error. A fatal error is one where the router may know the previous 577 hop but cannot forward the message to it. 579 6. IPv6 Multicast Traceroute Header 581 IPv6 mtrace2 includes the common packet header as follows. Because 582 of the specification of the IPv6 address, all IPv6 addresses used in 583 each field consume 128 bits length. 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Type | # hops | Checksum | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Reserved | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | 593 * * 594 | | 595 * Multicast Address * 596 | | 597 * * 598 | | 599 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 600 | | 601 * * 602 | | 603 * Source Address * 604 | | 605 * * 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | | 609 * * 610 | | 611 * Destination Address * 612 | | 613 * * 614 | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | | 617 * * 618 | | 619 * Response Address * 620 | | 621 * * 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |Resp Hop Limit | Query ID | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 6.1. Type: 8 bits 629 The UDP type field is defined to be "0x1" for traceroute queries and 630 requests. The UDP type field is changed to "0x2" when the packet is 631 completed and sent as a response from the first hop router to the 632 querier. Two codes are required so that multicast routers won't 633 attempt to process a completed response in those cases where the 634 initial query was issued from a router or the response is sent via 635 multicast. 637 6.2. # hops: 8 bits 639 Same definition described in Section 4.2 641 6.3. Checksum: 16 bits 643 As defined in [2], the checksum is the 16-bit one's complement of the 644 one's complement sum of the entire UDP message, starting with the UDP 645 message type field, and prepended with a "pseudo-header" of IPv6 646 header fields. 648 6.4. Reserved: 32 bits 650 Initialized to zero by the sender; ignored by receivers. 652 6.5. Multicast Address 654 Same definition described in Section 4.4 656 6.6. Source Address 658 This field specifies the IPv6 address of the multicast source for the 659 path being traced, or is filled with the unspecified address (::) if 660 no source-specific information is desired. Note that non-source- 661 specific traceroutes may not be possible with certain multicast 662 routing protocols. 664 6.7. Destination Address 666 Same definition described in Section 4.6 668 6.8. Response Address 670 Same definition described in Section 4.7 672 6.9. Resp Hop Limit: 8 bits 674 This field specifies the hop limit at which to multicast the 675 response, if the response address is a multicast address. 677 6.10. Query ID: 24 bits 679 Same definition described in Section 4.9 681 7. IPv6 Multicast Traceroute Response Data 683 Each intermediate router in a trace path appends "response data" to 684 the forwarded trace packet. The response data looks as follows. 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Query Arrival Time | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Incoming Interface ID | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Outgoing Interface ID | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | | 696 * * 697 | | 698 * Local Address * 699 | | 700 * * 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | | 704 * * 705 | | 706 * Remote Address * 707 | | 708 * * 709 | | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | | 712 | Input packet count on incoming interface | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | | 715 | Output packet count on outgoing interface | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | | 718 | Total number of packets for this source-group pair | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Rtg Protocol | Fwd Hop Limit | MBZ |S|Src Prefix Len | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 |Forwarding Code| Reserved | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 7.1. Query Arrival Time: 32 bits 727 Same definition described in Section 5.1 729 7.2. Incoming Interface ID: 32 bits 731 This field specifies the interface ID on which packets from this 732 source and group are expected to arrive, or 0 if unknown. This ID 733 should be the value taken from InterfaceIndex of the IF-MIB for this 734 interface. This field is carried in network byte order. 736 7.3. Outgoing Interface ID: 32 bits 738 This field specifies the interface ID on which packets from this 739 source and group flow to the specified destination, or 0 if unknown. 740 This ID should be the value taken from InterfaceIndex of the IF-MIB 741 for this interface. This field is carried in network byte order. 743 7.4. Local Address 745 This field specifies a global IPv6 address that uniquely identifies 746 the router. A unique local unicast address [6] SHOULD NOT be used 747 unless the node is only assigned link-local and unique local 748 addresses. [TBD: What if the node is only assigned link-local 749 addresses? It should be very unlikely case, but is possible even for 750 a properly working router.] 752 Note that since interface indices used in the Incoming and Outgoing 753 Interface ID fields are node-local information, a global identifier 754 is needed to specify the router. 756 7.5. Remote Address 758 This field specifies the address of the previous-hop router, which, 759 in most cases, is a link-local unicast address for the queried source 760 and destination addresses. 762 Although a link-local address does not have enough information to 763 identify a node, it is possible to detect the previous-hop router 764 with the assistance of Incoming Interface ID and the current router 765 address (i.e., Local Address). 767 This may be a multicast group (e.g., ALL-[protocol]- 768 ROUTERS.MCAST.NET) if the previous hop is not known because of the 769 workings of the multicast routing protocol. However, it should be 770 the unspecified address (::) if the incoming interface address is 771 unknown. 773 7.6. Input packet count on incoming interface 775 Same definition described in Section 5.6 777 7.7. Output packet count on incoming interface 779 Same definition described in Section 5.7 781 7.8. Total number of packets for this source-group pair 783 This field counts the number of packets from the specified source 784 forwarded by this router to the specified group, or 785 0xffffffffffffffff if no count can be reported. If the S bit is set, 786 the count is for the source network, as specified by the Src Prefix 787 Len field. If the S bit is set and the Src Prefix Len field is 255, 788 indicating no source-specific state, the count is for all sources 789 sending to this group. This counter should have the same value as 790 ipMcastRoutePkts from the IPMROUTE-STD-MIB for this forwarding entry. 792 7.9. Rtg Protocol: 8 bits 794 Same definition described in Section 5.9 796 Note that some of the routing protocols or functions are not 797 supported or not used in IPv6 multicast. 799 7.10. Fwd Hop Limit: 8 bits 801 This field contains the hop limit that a packet is required to have 802 before it will be forwarded over the outgoing interface. 804 7.11. MBZ: 7 bits 806 Must be zeroed on transmission and ignored on reception. 808 7.12. S: 1 bit 810 This S bit indicates that the packet count for the source-group pair 811 is for the source network, as determined by masking the source 812 address with the Src Prefix Len field. 814 7.13. Src Prefix Len: 8 bits 816 This field contains the decimal number of the prefix length this 817 router has for the source. If the router is forwarding solely on 818 group state, this field is set to 255 (0xff) 820 7.14. Forwarding Code: 8 bits 822 Same definition described in Section 5.14 824 7.15. Reserved: 24 bit 826 Initialized to zero by the sender; ignored by receivers. 828 8. Router Behavior 830 All of these actions are performed in addition to (NOT instead of) 831 forwarding the packet, if applicable. E.g. a multicast packet that 832 has TTL or the hop limit remaining MUST be forwarded normally, as 833 MUST a unicast packet that has TTL or the hop limit remaining and is 834 not addressed to this router. 836 8.1. Traceroute Query 838 A traceroute Query message is a traceroute message with no response 839 blocks filled in, and uses UDP type 0x1 for IPv4 and IPv6 mtrace2. 841 8.1.1. Packet Verification 843 Upon receiving a traceroute Query message, a router must examine the 844 Query to see if it is the proper last-hop router for the destination 845 address in the packet. It is the proper last-hop router if it has a 846 multicast-capable interface on the same subnet as the Destination 847 Address and is the router that would forward traffic from the given 848 source onto that subnet. 850 If the router determines that it is not the proper last-hop router, 851 or it cannot make that determination, it does one of two things 852 depending if the Query was received via multicast or unicast. If the 853 Query was received via multicast, then it MUST be silently dropped. 854 If it was received via unicast, a forwarding code of WRONG_LAST_HOP 855 is noted and processing continues as in Section 8.2 857 Duplicate Query messages as identified by the tuple (IP Source, Query 858 ID) SHOULD be ignored. This MAY be implemented using a simple 1-back 859 cache (i.e. remembering the IP source and Query ID of the previous 860 Query message that was processed, and ignoring future messages with 861 the same IP Source and Query ID). Duplicate Request messages MUST 862 NOT be ignored in this manner. 864 8.1.2. Normal Processing 866 When a router receives a traceroute Query and it determines that it 867 is the proper last-hop router, it treats it like a traceroute Request 868 and performs the steps listed in Section 8.2 870 8.2. Traceroute Request 872 A traceroute Request is a traceroute message with some number of 873 response blocks filled in, and uses UDP type 0x1 for IPv4 and IPv6 874 mtrace2. Routers can tell the difference between Queries and 875 Requests by checking the length of the packet. 877 8.2.1. Packet Verification 879 If the traceroute Request is not addressed to this router, or if the 880 Request is addressed to a multicast group which is not a link-scoped 881 group (i.e. 224/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be 882 silently ignored. 884 8.2.2. Normal Processing 886 When a router receives a traceroute Request, it performs the 887 following steps. Note that it is possible to have multiple 888 situations covered by the Forwarding Codes. The first one 889 encountered is the one that is reported, i.e. all "note forwarding 890 code N" should be interpreted as "if forwarding code is not already 891 set, set forwarding code to N". 893 1. If there is room in the current buffer (or the router can 894 efficiently allocate more space to use), insert a new response 895 block into the packet and fill in the Query Arrival Time, 896 Outgoing Interface Address (for IPv4 mtrace2) or Outgoing 897 Interface ID (for IPv6 mtrace2), Output Packet Count, and Fwd 898 TTL or Fwd Hop Limit. If there was no room, fill in the 899 response code "NO_SPACE" in the *previous* hop's response block, 900 and forward the packet to the requester as described in 901 "Forwarding Traceroute Requests". 903 2. Attempt to determine the forwarding information for the source 904 and group specified, using the same mechanisms as would be used 905 when a packet is received from the source destined for the 906 group. State need not be instantiated, it can be "phantom" 907 state created only for the purpose of the trace. 909 If using a shared-tree protocol and there is no source-specific 910 state, or if the source is specified as 0xFFFFFFFF, group state 911 should be used. If there is no group state or the group is 912 specified as 0, potential source state (i.e. the path that would 913 be followed for a source-specific Join) should be used. If this 914 router is the Core or RP and no source-specific information is 915 available, note an error code of REACHED_RP. 917 3. If no forwarding information can be determined, the router notes 918 an error code of NO_ROUTE, sets the remaining fields that have 919 not yet been filled in to zero, and then forwards the packet to 920 the requester as described in "Forwarding Traceroute Requests". 922 4. Fill in the Incoming Interface Address, Previous-Hop Router 923 Address, Input Packet Count, Total Number of Packets, Routing 924 Protocol, S, and Src Mask from the forwarding information that 925 was determined. 927 5. If traceroute is administratively prohibited or the previous hop 928 router does not understand traceroute requests, note the 929 appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If 930 traceroute is administratively prohibited and any of the fields 931 as filled in step 4 are considered private information, zero out 932 the applicable fields. Then the packet is forwarded to the 933 requester as described in "Forwarding Traceroute Requests". 935 6. If the reception interface is not enabled for multicast, note 936 forwarding code NO_MULTICAST. If the reception interface is the 937 interface from which the router would expect data to arrive from 938 the source, note forwarding code RPF_IF. Otherwise, if the 939 reception interface is not one to which the router would forward 940 data from the source to the group, a forwarding code of WRONG_IF 941 is noted. 943 7. If the group is subject to administrative scoping on either the 944 Outgoing or Incoming interfaces, a forwarding code of SCOPED is 945 noted. 947 8. If this router is the Rendez-vous Point or Core for the group, a 948 forwarding code of REACHED_RP is noted. 950 9. If this router has sent a prune upstream which applies to the 951 source and group in the traceroute Request, it notes forwarding 952 code PRUNE_SENT. If the router has stopped forwarding 953 downstream in response to a prune sent by the next hop router, 954 it notes forwarding code PRUNE_RCVD. If the router should 955 normally forward traffic for this source and group downstream 956 but is not, it notes forwarding code NOT_FORWARDING. 958 10. The packet is then sent on to the previous hop or the requester 959 as described in Section 8.4. 961 8.3. Traceroute Response 963 A router must forward all traceroute response packets normally, with 964 no special processing. If a router has initiated a traceroute with a 965 Query or Request message, it may listen for Responses to that 966 traceroute but MUST still forward them as well. 968 8.4. Forwarding Traceroute Requests 970 If the Previous-hop router is known for this request and the number 971 of response blocks is less than the number requested, the packet is 972 sent to that router. If the Incoming Interface is known but the 973 Previous-hop router is not known, the packet is sent to an 974 appropriate multicast address on the Incoming Interface. The 975 appropriate multicast address may depend on the routing protocol in 976 use, MUST be a link-scoped group (i.e. 224/24 for IPv4, FF02::/16 for 977 IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 and All 978 Nodes Address (FF02::1) for IPv6, and MAY be ALL-ROUTERS.MCAST.NET 979 (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6 if the 980 routing protocol in use does not define a more appropriate group. 981 Otherwise, it is sent to the Response Address in the header, as 982 described in Section 8.5. 984 Note that it is not an error for the number of response blocks to be 985 greater than the number requested; such a packet should simply be 986 forwarded to the requester as described in Section 8.5. 988 8.5. Sending Traceroute Responses 990 8.5.1. Destination Address 992 A traceroute response must be sent to the Response Address in the 993 traceroute header. 995 8.5.2. TTL and Hop Limit 997 If the Response Address is unicast, the router inserts its normal 998 unicast TTL or hop limit in the IP header, and may use any of its 999 interface addresses as the source address. If the Response Address 1000 is multicast, the router copies the Response TTL or hop limit from 1001 the traceroute header into the IP header. 1003 8.5.3. Source Address 1005 If the Response Address is unicast, the router may use any of its 1006 interface addresses as the source address. Since some multicast 1007 routing protocols forward based on source address, if the Response 1008 Address is multicast, the router MUST use an address that is known in 1009 the multicast routing topology if it can make that determination. 1011 8.5.4. Sourcing multicast responses 1013 When a router sources a multicast response, the response packet MUST 1014 be sent on a single interface, then forwarded as if it were received 1015 on that interface. It MUST NOT source the response packet 1016 individually on each interface, in order to avoid duplicate packets. 1018 8.6. Hiding information 1020 Information about a domain's topology and connectivity may be hidden 1021 from multicast traceroute requests. The exact mechanism is not 1022 specified here; however, the INFO_HIDDEN forwarding code may be used 1023 to note that, for example, the incoming interface address and packet 1024 count are for the entrance to the domain and the outgoing interface 1025 address and packet count are the exit from the domain. The source- 1026 group packet count may be from either router or not specified 1027 (0xffffffff). 1029 9. Using multicast traceroute 1031 9.1. Sample client 1033 This section describes the behavior of an example multicast 1034 traceroute client. 1036 9.1.1. Sending initial query 1038 When the destination of the mtrace2 is the machine running the 1039 client, the mtrace2 Query packet can be sent to the ALL- 1040 ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address 1041 (FF02::2) for IPv6. This will ensure that the packet is received by 1042 the last-hop router on the subnet. Otherwise, if the proper last-hop 1043 router is known for the mtrace2 destination, the Query could be 1044 unicasted to that router. Otherwise, the Query packet should be 1045 multicasted to the group being queried; if the destination of the 1046 mtrace2 is a member of the group, this will get the Query to the 1047 proper last-hop router. In this final case, the packet should 1048 contain the Router Alert option [8], to make sure that routers that 1049 are not members of the multicast group notice the packet. 1051 See also Section 9.2 on determining the last-hop router. 1053 9.1.2. Determining the Path 1055 The client could send a small number of initial query messages with a 1056 large "# hops" field, in order to try to trace the full path. If 1057 this attempt fails, one strategy is to perform a linear search (as 1058 the traditional unicast traceroute program does); set the "# hops" 1059 field to 1 and try to get a response, then 2, and so on. If no 1060 response is received at a certain hop, the hop count can continue 1061 past the non-responding hop, in the hopes that further hops may 1062 respond. These attempts should continue until a user-defined timeout 1063 has occurred. 1065 See also Section 9.3 and Section 9.4 on receiving the results of a 1066 trace. 1068 9.1.3. Collecting statistics 1070 After a client has determined that it has traced the whole path or as 1071 much as it can expect to (see Section 9.5), it might collect 1072 statistics by waiting a short time and performing a second trace. If 1073 the path is the same in the two traces, statistics can be displayed 1074 as described in Section 10.3 and Section 10.4. 1076 9.2. Last hop router 1078 The mtrace2 querier may not know which is the last hop router, or 1079 that router may be behind a firewall that blocks unicast packets but 1080 passes multicast packets. In these cases, the mtrace2 request should 1081 be multicasted to the group being traced (since the last hop router 1082 listens to that group). All routers except the correct last hop 1083 router should ignore any mtrace2 request received via multicast. 1084 Mtrace2 requests which are multicasted to the group being traced must 1085 include the Router Alert option [8]. 1087 Another alternative is to unicast to the trace destination. 1088 Traceroute requests which are unicasted to the trace destination must 1089 include the Router Alert option, in order that the last-hop router is 1090 aware of the packet. 1092 If the traceroute querier is attached to the same router as the 1093 destination of the request, the traceroute request may be multicasted 1094 to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address 1095 (FF02::2) for IPv6 if the last-hop router is not known. 1097 9.3. First hop router 1099 The mtrace2 querier may not be unicast reachable from the first hop 1100 router. In this case, the querier should set the traceroute response 1101 address to a multicast address, and should set the response TTL (or 1102 hop limit) to a value sufficient for the response from the first hop 1103 router to reach the querier. It may be appropriate to start with a 1104 small TTL and increase in subsequent attempts until a sufficient TTL 1105 is reached, up to an appropriate maximum (such as 192). 1107 The IANA has assigned 224.0.1.32, MTRACE.MCAST.NET as the default 1108 multicast group for IPv4 mtrace2 responses, and will assign 1109 MTRACE2_IPV6RESPADDR (TBD (see Section 11)) for IPv6 mtrace2 1110 responses. Other groups may be used if needed, e.g. when using 1111 mtrace2 to diagnose problems with the IANA-assigned group. 1113 9.4. Broken intermediate router 1115 A broken intermediate router might simply not understand traceroute 1116 packets, and drop them. The querier would then get no response at 1117 all from its traceroute requests. It should then perform a hop-by- 1118 hop search by setting the number of responses field until it gets a 1119 response (both linear and binary search are options, but binary is 1120 likely to be slower because a failure requires waiting for a 1121 timeout). 1123 9.5. Mtrace2 termination 1125 When performing an expanding hop-by-hop trace, it is necessary to 1126 determine when to stop expanding. 1128 9.5.1. Arriving at source 1130 A trace can be determined to have arrived at the source if the 1131 Incoming Interface of the last router in the trace is non-zero, but 1132 the Previous Hop router is zero. 1134 9.5.2. Fatal error 1136 A trace has encountered a fatal error if the last Forwarding Error in 1137 the trace has the 0x80 bit set. 1139 9.5.3. No previous hop 1141 A trace can not continue if the last Previous Hop in the trace is set 1142 to 0. 1144 9.5.4. Traceroute shorter than requested 1146 If the trace that is returned is shorter than requested (i.e. the 1147 number of Response blocks is smaller than the "# hops" field), the 1148 trace encountered an error and could not continue. 1150 9.6. Continuing after an error 1152 When the NO_SPACE error occurs, the client might try to continue the 1153 trace by starting it at the last hop in the trace. It can do this by 1154 unicasting to this router's outgoing interface address, keeping all 1155 fields the same. If this results in a single hop and a "WRONG_IF" 1156 error, the client may try setting the trace destination to the same 1157 outgoing interface address. 1159 If a trace times out, it is likely to be because a router in the 1160 middle of the path does not support multicast traceroute. That 1161 router's address will be in the Previous Hop field of the last entry 1162 in the last reply packet received. A client may be able to determine 1163 (via mrinfo or SNMP [6][10]) a list of neighbors of the non- 1164 responding router. If desired, each of those neighbors could be 1165 probed to determine the remainder of the path. Unfortunately, this 1166 heuristic may end up with multiple paths, since there is no way of 1167 knowing what the non-responding router's algorithm for choosing a 1168 previous-hop router is. However, if all paths but one flow back 1169 towards the non-responding router, it is possible to be sure that 1170 this is the correct path. 1172 9.7. Multicast Traceroute and shared tree routing protocols 1174 When using shared-tree routing protocols like PIM-SM and CBT, a more 1175 advanced client may use multicast traceroute to determine paths or 1176 potential paths. 1178 9.7.1. PIM-SM 1180 When a multicast traceroute reaches a PIM-SM RP and the RP does not 1181 forward the trace on, it means that the RP has not performed a 1182 source-specific join so there is no more state to trace. However, 1183 the path that traffic would use if the RP did perform a source- 1184 specific join can be traced by setting the trace destination to the 1185 RP, the trace source to the traffic source, and the trace group to 0. 1186 This trace Query may be unicasted to the RP. 1188 9.7.2. Bi-directional PIM 1190 Bi-directional PIM [13] is a variant of PIM-SM that builds bi- 1191 directional shared trees connecting multicast sources and receivers. 1192 Along the bi-directional shared trees, multicast data is natively 1193 forwarded from sources to the RPA (Rendezvous Point Address) and from 1194 the RPA to receivers without requiring source-specific state. In 1195 contrast to PIM-SM, RP always has the state to trace. 1197 A Designated Forwarder (DF) for a given RPA is in charge of 1198 forwarding downstream traffic onto its link, and forwarding upstream 1199 traffic from its link towards the RPL (Rendezvous Point Link) that 1200 the RPA belongs to. Hence mtrace2 reports DF addresses or RPA along 1201 the path. 1203 9.7.3. CBT 1205 When a multicast traceroute reaches a CBT [12] Core, it must simply 1206 stop since CBT does not have source-specific state. However, a 1207 second trace can be performed, setting the trace destination to the 1208 traffic source, the trace group to the group being traced, and the 1209 trace source to the Core (or to 0, since CBT does not have source- 1210 specific state). This trace Query may be unicasted to the Core. 1211 There are two possibilities when combining the two traces: 1213 9.7.3.1. No overlap 1215 If there is no overlap between the two traces, the second trace can 1216 be reversed and appended to the first trace. This composite trace 1217 shows the full path from the source to the destination. 1219 9.7.3.2. Overlapping paths 1221 If there is a portion of the path that is common to the ends of the 1222 two traces, that portion is removed from both traces. Then, as in 1223 the no overlap case, the second trace is reversed and appended to the 1224 first trace, and the composite trace again contains the full path. 1226 This algorithm works whether the source has joined the CBT tree or 1227 not. 1229 9.8. Protocol-specific considerations 1231 9.8.1. DVMRP 1233 DVMRP's dominant router election and route exchange guarantees that 1234 DVMRP routers know whether or not they are the last-hop forwarder for 1235 the link and who the previous hop is. 1237 9.8.2. PIM-DM 1239 Routers running PIM Dense Mode do not know the path packets would 1240 take unless traffic is flowing. Without some extra protocol 1241 mechanism, this means that in an environment with multiple possible 1242 paths with branch points on shared media, multicast traceroute can 1243 only trace existing paths, not potential paths. When there are 1244 multiple possible paths but the branch points are not on shared 1245 media, the previous hop router is known, but the last hop router may 1246 not know that it is the appropriate last hop. 1248 When traffic is flowing, PIM Dense Mode routers know whether or not 1249 they are the last-hop forwarder for the link (because they won or 1250 lost an Assert battle) and know who the previous hop is (because it 1251 won an Assert battle). Therefore, multicast traceroute is always 1252 able to follow the proper path when traffic is flowing. 1254 10. Problem Diagnosis 1256 10.1. Forwarding Inconsistencies 1258 The forwarding error code can tell if a group is unexpectedly pruned 1259 or administratively scoped. 1261 10.2. TTL or hop limit problems 1263 By taking the maximum of (hops from source + forwarding TTL (or hop 1264 limit) threshold) over all hops, you can discover the TTL required 1265 for the source to reach the destination. 1267 10.3. Packet loss 1269 By taking two traces, you can find packet loss information by 1270 comparing the difference in input packet counts to the difference in 1271 output packet counts at the previous hop. On a point-to-point link, 1272 any difference in these numbers implies packet loss. Since the 1273 packet counts may be changing as the trace query is propagating, 1274 there may be small errors (off by 1 or 2) in these statistics. 1275 However, these errors will not accumulate if multiple traces are 1276 taken to expand the measurement period. On a shared link, the count 1277 of input packets can be larger than the number of output packets at 1278 the previous hop, due to other routers or hosts on the link injecting 1279 packets. This appears as "negative loss" which may mask real packet 1280 loss. 1282 In addition to the counts of input and output packets for all 1283 multicast traffic on the interfaces, the response data includes a 1284 count of the packets forwarded by a node for the specified source- 1285 group pair. Taking the difference in this count between two traces 1286 and then comparing those differences between two hops gives a measure 1287 of packet loss just for traffic from the specified source to the 1288 specified receiver via the specified group. This measure is not 1289 affected by shared links. 1291 On a point-to-point link that is a multicast tunnel, packet loss is 1292 usually due to congestion in unicast routers along the path of that 1293 tunnel. On native multicast links, loss is more likely in the output 1294 queue of one hop, perhaps due to priority dropping, or in the input 1295 queue at the next hop. The counters in the response data do not 1296 allow these cases to be distinguished. Differences in packet counts 1297 between the incoming and outgoing interfaces on one node cannot 1298 generally be used to measure queue overflow in the node. 1300 10.4. Link Utilization 1302 Again, with two traces, you can divide the difference in the input or 1303 output packet counts at some hop by the difference in time stamps 1304 from the same hop to obtain the packet rate over the link. If the 1305 average packet size is known, then the link utilization can also be 1306 estimated to see whether packet loss may be due to the rate limit or 1307 the physical capacity on a particular link being exceeded. 1309 10.5. Time delay 1311 If the routers have synchronized clocks, it is possible to estimate 1312 propagation and queuing delay from the differences between the 1313 timestamps at successive hops. However, this delay includes control 1314 processing overhead, so is not necessarily indicative of the delay 1315 that data traffic would experience. 1317 11. IANA Considerations 1319 The following new assignments can only be made via a Standards Action 1320 as specified in [5]. 1322 11.1. Routing protocols 1324 The IANA is responsible for allocating new Routing Protocol codes. 1325 The Routing Protocol code is somewhat problematic, since in the case 1326 of protocols like CBT and PIM it must encode both a unicast routing 1327 algorithm and a multicast tree-building protocol. The space was not 1328 divided into two fields because it was already small and some 1329 combinations (e.g. DVMRP) would be wasted. 1331 11.2. Forwarding codes 1333 New Forwarding codes must only be created by an RFC that modifies 1334 this document's Section 9, fully describing the conditions under 1335 which the new forwarding code is used. The IANA may act as a central 1336 repository so that there is a single place to look up forwarding 1337 codes and the document in which they are defined. 1339 11.3. UDP destination port and IPv6 address 1341 The IANA should allocate UDP destination port for multicast 1342 traceroute version 2 upon publication of the first RFC. 1343 Additionally, the well-known multicast address (MTRACE2_IPV6RESPADDR) 1344 intended for default use by IPv6 multicast traceroute should be 1345 registered and defined by the first RFC published. 1347 12. Security Considerations 1349 12.1. Topology Discovery 1351 Mtrace2 can be used to discover any actively-used topology. If your 1352 network topology is a secret, mtrace2 may be restricted at the border 1353 of your domain, using the ADMIN_PROHIB forwarding code. 1355 12.2. Traffic Rates 1357 Mtrace2 can be used to discover what sources are sending to what 1358 groups and at what rates. If this information is a secret, mtrace2 1359 may be restricted at the border of your domain, using the 1360 ADMIN_PROHIB forwarding code. 1362 12.3. Unicast Replies 1364 The "Response address" field may be used to send a single packet (the 1365 traceroute Reply packet) to an arbitrary unicast address. It is 1366 possible to use this facility as a packet amplifier, as a small 1367 multicast traceroute Query may turn into a large Reply packet. 1369 13. Acknowledgements 1371 This specification started largely as a transcription of Van 1372 Jacobson's slides from the 30th IETF, and the implementation in 1373 mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve 1374 Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original 1375 multicast traceroute client, mtrace (version 1), has been implemented 1376 by Ajit Thyagarajan, Steve Casner and Bill Fenner. 1378 The idea of unicasting a multicast traceroute Query to the 1379 destination of the trace with Router Alert set is due to Tony 1380 Ballardie. The idea of the "S" bit to allow statistics for a source 1381 subnet is due to Tom Pusateri. 1383 14. References 1385 14.1. Normative References 1387 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 1388 levels", RFC 2119, March 1997. 1390 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1391 Specification", RFC 2460, December 1998. 1393 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 1394 Architecture", RFC 2373, July 1998. 1396 [4] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1397 Thyagarajan, "Internet Group Management Protocol, Version 3", 1398 RFC 3376, October 2002. 1400 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1401 Considerations Section in RFCs", RFC 2434, October 1998. 1403 14.2. Informative References 1405 [6] Draves, R. and D. Thaler, "Default Router Preferences and More- 1406 Specific Routes", RFC 4191, November 2005. 1408 [7] Braden, B., Borman, D., and C. Partridge, "Computing the 1409 Internet Checksum", RFC 1071, September 1988. 1411 [8] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. 1413 [9] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", 1414 RFC 2863, June 2000. 1416 [10] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB", 1417 draft-ietf-mboned-ip-mcast-mib-05.txt (work in progress), 1418 March 2007. 1420 [11] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1421 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1422 Protocol Specification (Revised)", RFC 4601, August 2006. 1424 [12] Ballardie, T., "Core Based Trees (CBT version 2) Multicast 1425 Routing -- Protocol Specification --", RFC 2189, 1426 September 1997. 1428 [13] Handley, M., Kouvelas, I., and T. Speakman, "Bi-directional 1429 Protocol Independent Multicast (BIDIR-PIM)", 1430 draft-ietf-pim-bidir-09.txt (work in progress), February 2007. 1432 Authors' Addresses 1434 Hitoshi Asaeda 1435 Keio University 1436 Graduate School of Media and Governance 1437 Fujisawa, Kanagawa 252-8520 1438 Japan 1440 Email: asaeda@wide.ad.jp 1442 Tatsuya Jinmei 1443 Toshiba Corporation 1444 Corporate Research & Development Center 1445 Kawasaki, Kanagawa 212-8582 1446 Japan 1448 Email: jinmei@isl.rdc.toshiba.co.jp 1450 William C. Fenner 1451 AT&T Research 1452 Menlo Park, CA 94025 1453 US 1455 Email: fenner@research.att.com 1457 Stephen L. Casner 1458 Packet Design, Inc. 1459 Palo Alto, CA 94304 1460 US 1462 Email: casner@packetdesign.com 1464 Full Copyright Statement 1466 Copyright (C) The IETF Trust (2007). 1468 This document is subject to the rights, licenses and restrictions 1469 contained in BCP 78, and except as set forth therein, the authors 1470 retain all their rights. 1472 This document and the information contained herein are provided on an 1473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1475 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1476 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1477 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1480 Intellectual Property 1482 The IETF takes no position regarding the validity or scope of any 1483 Intellectual Property Rights or other rights that might be claimed to 1484 pertain to the implementation or use of the technology described in 1485 this document or the extent to which any license under such rights 1486 might or might not be available; nor does it represent that it has 1487 made any independent effort to identify any such rights. Information 1488 on the procedures with respect to rights in RFC documents can be 1489 found in BCP 78 and BCP 79. 1491 Copies of IPR disclosures made to the IETF Secretariat and any 1492 assurances of licenses to be made available, or the result of an 1493 attempt made to obtain a general license or permission for the use of 1494 such proprietary rights by implementers or users of this 1495 specification can be obtained from the IETF on-line IPR repository at 1496 http://www.ietf.org/ipr. 1498 The IETF invites any interested party to bring to its attention any 1499 copyrights, patents or patent applications, or other proprietary 1500 rights that may cover technology that may be required to implement 1501 this standard. Please address the information to the IETF at 1502 ietf-ipr@ietf.org. 1504 Acknowledgment 1506 Funding for the RFC Editor function is provided by the IETF 1507 Administrative Support Activity (IASA).