idnits 2.17.1 draft-ietf-mboned-mtrace-v2-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 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 and authors 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2010) is 5036 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) == Unused Reference: '2' is defined on line 1345, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1354, but no explicit reference was found in the text ** 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. '4') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 1071 (ref. '5') ** Obsolete normative reference: RFC 4601 (ref. '6') (Obsoleted by RFC 7761) == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-08 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 2 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 Intended status: Standards Track T. Jinmei 5 Expires: January 13, 2011 ISC 6 W. Fenner 7 Arastra, Inc. 8 S. Casner 9 Packet Design, Inc. 10 July 12, 2010 12 Mtrace Version 2: Traceroute Facility for IP Multicast 13 draft-ietf-mboned-mtrace-v2-07 15 Abstract 17 This document describes the IP multicast traceroute facility. Unlike 18 unicast traceroute, multicast traceroute requires special 19 implementations on the part of routers. This specification describes 20 the required functionality in multicast routers, as well as how 21 management applications can use the router functionality. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 13, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . . 10 74 4.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . . 10 75 5. Mtrace2 Query Header . . . . . . . . . . . . . . . . . . . . . 11 76 5.1. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 11 77 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 11 78 5.3. Source Address . . . . . . . . . . . . . . . . . . . . . . 12 79 5.4. Destination Address . . . . . . . . . . . . . . . . . . . 12 80 5.5. Query ID: 16 bits . . . . . . . . . . . . . . . . . . . . 12 81 5.6. Client Port # . . . . . . . . . . . . . . . . . . . . . . 12 82 6. IPv4 Mtrace2 Standard Response Block . . . . . . . . . . . . . 13 83 6.1. MBZ: 8 bit . . . . . . . . . . . . . . . . . . . . . . . . 13 84 6.2. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 13 85 6.3. Incoming Interface Address: 32 bits . . . . . . . . . . . 14 86 6.4. Outgoing Interface Address: 32 bits . . . . . . . . . . . 14 87 6.5. Previous-Hop Router Address: 32 bits . . . . . . . . . . . 14 88 6.6. Input packet count on incoming interface: 64 bits . . . . 14 89 6.7. Output packet count on incoming interface: 64 bits . . . . 14 90 6.8. Total number of packets for this source-group pair: 64 91 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 6.9. Rtg Protocol: 16 bits . . . . . . . . . . . . . . . . . . 15 93 6.10. Multicast Rtg Protocol: 16 bits . . . . . . . . . . . . . 15 94 6.11. Fwd TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 15 95 6.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 6.13. Src Mask: 7 bits . . . . . . . . . . . . . . . . . . . . . 15 97 6.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 16 98 7. IPv6 Mtrace2 Standard Response Block . . . . . . . . . . . . . 18 99 7.1. MBZ: 8 bit . . . . . . . . . . . . . . . . . . . . . . . . 18 100 7.2. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 19 101 7.3. Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 19 102 7.4. Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 19 103 7.5. Local Address . . . . . . . . . . . . . . . . . . . . . . 19 104 7.6. Remote Address . . . . . . . . . . . . . . . . . . . . . . 19 105 7.7. Input packet count on incoming interface . . . . . . . . . 19 106 7.8. Output packet count on incoming interface . . . . . . . . 20 107 7.9. Total number of packets for this source-group pair . . . . 20 108 7.10. Rtg Protocol: 16 bits . . . . . . . . . . . . . . . . . . 20 109 7.11. Multicast Rtg Protocol: 16 bits . . . . . . . . . . . . . 20 110 7.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 20 111 7.13. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 20 112 7.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 20 113 8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 21 114 9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 115 9.1. Traceroute Query . . . . . . . . . . . . . . . . . . . . . 22 116 9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 22 117 9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 22 118 9.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . . . 22 119 9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 23 120 9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 23 121 9.3. Forwarding Mtrace2 Requests . . . . . . . . . . . . . . . 25 122 9.4. Sending Mtrace2 Responses . . . . . . . . . . . . . . . . 25 123 9.4.1. Destination Address . . . . . . . . . . . . . . . . . 25 124 9.4.2. Source Address . . . . . . . . . . . . . . . . . . . . 25 125 9.5. Proxying Mtrace2 Queries . . . . . . . . . . . . . . . . . 25 126 9.6. Hiding Information . . . . . . . . . . . . . . . . . . . . 26 127 10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 27 128 10.1. Sending Mtrace2 Queries . . . . . . . . . . . . . . . . . 27 129 10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 27 130 10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 27 131 10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 27 132 10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 28 133 10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 28 134 10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 28 135 10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 28 136 10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 28 137 10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 28 138 10.7.4. Traceroute shorter than requested . . . . . . . . . . 28 139 10.8. Continuing after an error . . . . . . . . . . . . . . . . 29 140 11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 30 141 11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 30 142 11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 30 143 11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 30 144 11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 30 145 11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 146 12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 32 147 12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 32 148 12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 32 149 12.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 32 150 12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 33 151 12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 33 152 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 153 13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 34 154 13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 34 155 14. Security Considerations . . . . . . . . . . . . . . . . . . . 35 156 14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 35 157 14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 35 158 14.3. Limiting Query/Request Rates . . . . . . . . . . . . . . . 35 159 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 160 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 161 16.1. Normative References . . . . . . . . . . . . . . . . . . . 37 162 16.2. Informative References . . . . . . . . . . . . . . . . . . 37 164 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 166 1. Introduction 168 This document specifies the multicast traceroute facility named 169 mtrace version 2 or mtrace2. Mtrace2 allows the tracing of an IP 170 multicast routing paths. Mtrace2 provides additional information 171 about packet rates and losses, or other diagnosis information. For 172 instance, mtrace2 is used for the following purposes. 174 o To trace the path that a packet would take from some source to 175 some destination. 177 o To isolate packet loss problems (e.g., congestion). 179 o To isolate configuration problems (e.g., TTL threshold). 181 Mtrace2 consists of the client and router programs. The mtrace2 182 client program is invoked from somewhere in the multicast tree, on a 183 host, router, or proxy such as IGMP/MLD proxy Section 9.5. The node 184 invoking the program is called the mtrace2 client. 186 The mtrace2 client program creates the mtrace2 Query message, which 187 includes a source and multicast address specified by the client, and 188 forwards the message to its neighbor router or proxy. This initiates 189 a trace of a multicast routing path from the client toward the 190 specified source, or if no source address is specified, toward a core 191 router. In the case of PIM-SM [6], the core router is an RP 192 maintaining the specified multicast address. 194 When a router or proxy receives an mtrace2 Query message and has the 195 corresponding routing state regarding the source and multicast 196 addresses specified in the Query, the router or proxy invokes the 197 mtrace2 router program. The mtrace2 router program creates an 198 mtrace2 Request message corresponding to the query and forwards the 199 Request toward the specified source or the core router. 201 When a first-hop router or proxy (a single hop from the source 202 specified in the request) or the core router receives an mtrace2 203 Query or Request message, the router or proxy invokes the mtrace2 204 router program. The mtrace2 router program creates an mtrace2 205 Response message. The Response message is forwarded to the mtrace2 206 client, thus completing the mtrace2 request. 208 The mtrace2 client program waits for the mtrace2 Response message and 209 displays the results. When an mtrace2 Response message does not come 210 due to network congestion, a broken router (see Section 10.6) or a 211 non-responding router (see Section 10.8), the mtrace2 client program 212 can resend an mtrace2 Query with the lower hop count and repeat the 213 process until it receives an mtrace2 Response message. 215 The mtrace2 client should also be aware that the mtrace2 Query may 216 follow the control path on the routers. It happens when the last-hop 217 or intermediate router's control plane and forwarding plane are not 218 synchronized. In this case, mtrace2 Requests will be forwarded 219 toward the specified source or the core router because the router 220 does not have any forwarding state for the query. 222 The mtrace2 supports both IPv4 and IPv6 multicast traceroute 223 facility. The protocol design, concept, and program behavior are 224 same between IPv4 and IPv6 mtrace2. While the original IPv4 225 multicast traceroute, mtrace, the query and response messages are 226 implemented as IGMP messages [10], all mtrace2 messages are carried 227 on UDP. The packet formats of IPv4 and IPv6 mtrace2 are different 228 because of the different address families, but the syntax is similar. 230 2. Terminology 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 233 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 234 this document are to be interpreted as described in RFC 2119 [1]. 236 Since multicast traceroutes flow in the opposite direction to the 237 data flow, we refer to "upstream" and "downstream" with respect to 238 data, unless explicitly specified. 240 Incoming interface: 241 The interface on which traffic is expected from the specified source 242 and group. 244 Outgoing interface: 245 The interface on which traffic is forwarded from the specified source 246 and group toward the destination. It is the interface on which the 247 multicast traceroute Request was received. 249 Previous-hop router: 250 The router that is on the link attached to the Incoming Interface and 251 is responsible for forwarding traffic for the specified source and 252 group. 254 Group state: 255 It is the state in which a shared-tree protocol (e.g., PIM-SM [6]) 256 running on a router chooses the previous-hop router toward the core 257 router or Rendezvous Point (RP) as its parent router. In this state, 258 source-specific state is not available for the corresponding 259 multicast address on the router. 261 Source-specific state: 262 It is the state in which a routing protocol running on a router 263 chooses the path that would be followed for a source-specific join. 265 ALL-[protocol]-ROUTERS.MCAST.NET: 266 It is a dedicated multicast address for a multicast router to 267 communicate with other routers that are working with the same routing 268 protocol. For instance,the address of ALL-PIM-ROUTERS.MCAST.NET is 269 '224.0.0.13' for IPv4 and 'ff02::d' for IPv6. 271 3. Overview 273 Given a multicast distribution tree, tracing from a source to a 274 multicast destination is hard, since you don't know down which branch 275 of the multicast tree the destination lies. This means that you have 276 to flood the whole tree to find the path from one source to one 277 destination. However, walking up the tree from destination to source 278 is easy, as most existing multicast routing protocols know the 279 previous hop for each source. Tracing from destination to source can 280 involve only routers on the direct path. 282 The party requesting the traceroute sends a traceroute Query packet 283 to the last-hop multicast router for the given multicast address. 284 The last-hop router turns the Query into a Request packet by adding a 285 response data block containing its interface addresses and packet 286 statistics, and then forwards the Request packet via unicast to the 287 router that it believes is the proper previous hop for the given 288 source and group. Each hop adds its response data to the end of the 289 Request packet, then unicast forwards it to the previous hop. The 290 first-hop router (the router that believes that packets from the 291 source originate on one of its directly connected networks) changes 292 the packet type to indicate a Response packet and sends the completed 293 response to the response destination address. The response may be 294 returned before reaching the first-hop router if a fatal error 295 condition such as "no route" is encountered along the path. 297 Multicast traceroute uses any information available to it in the 298 router to attempt to determine a previous hop to forward the trace 299 towards. Multicast routing protocols vary in the type and amount of 300 state they keep; multicast traceroute endeavors to work with all of 301 them by using whatever is available. For example, if a PIM-SM router 302 is on the (*,G) tree, it chooses the parent towards the RP as the 303 previous hop. In these cases, no source/group-specific state is 304 available, but the path may still be traced. 306 4. Packet Formats 308 Mtrace2 message is encoded in TLV format. If an implementation 309 receives a TLV whose length exceeds the TLV length specified in the 310 Length field, the TLV SHOULD be accepted but any additional data 311 SHOULD be ignored. 313 4.1. Mtrace2 TLV format 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Length | Value .... | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Type (8 bits) 323 Length (16 bits) 325 Value (variable length) 327 4.2. Defined TLVs 329 The following TLV Types are defined: 331 Code Type 332 ====== ====================================== 333 1 Mtrace2 Query 334 2 Mtrace2 Request 335 3 Mtrace2 Response 336 4 Mtrace2 Standard Response Block 337 5 Mtrace2 Augmented Response Block 339 An mtrace2 message MUST contain one Mtrace2 Query header. A 340 multicast router that sends an mtrace2 Request or Response message 341 MAY add one mtrace2 Standard Response block to given mtrace2 message 342 but MUST NOT add multiple mtrace2 Standard Response blocks to it. A 343 multicast router that adds one mtrace2 Standard Response block to 344 given mtrace2 message MAY append one or multiple Augmented Response 345 blocks. 347 The type field is defined to be "0x1" and "0x2" for mtrace2 Queries 348 and Requests, respectively. The type field is changed to "0x3" when 349 the packet is completed and sent as a response from the first-hop 350 router to the querier. 352 5. Mtrace2 Query Header 354 The mtrace2 message is carried as a UDP packet. The UDP source port 355 is uniquely selected by the local host operating system. The UDP 356 destination port is the IANA reserved mtrace2 port number (see 357 Section 13). The UDP checksum MUST be valid in mtrace2 messages. 359 The mtrace2 message includes the common mtrace2 Query header as 360 follows. The header is only filled in by the originator of the 361 mtrace2 Query; intermediate routers MUST NOT modify any of the 362 fields. 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 | # hops | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | | 370 | Multicast Address | 371 | | 372 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 373 | | 374 | Source Address | 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 | Destination Address | 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Query ID | Client Port # | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 1 386 5.1. # hops: 8 bits 388 This field specifies the maximum number of hops that the mtrace2 389 client wants to trace. If there is some error condition in the 390 middle of the path that keeps the mtrace2 request from reaching the 391 first-hop router, this field can be used to perform an expanding-ring 392 search to trace the path to just before the problem. 394 5.2. Multicast Address 396 This field specifies the 32 bits length IPv4 or 128 bits length IPv6 397 multicast address to be traced, or is filled with "all 1" in case of 398 IPv4 or with the unspecified address (::) in case of IPv6 if no 399 group-specific information is desired. Note that non-group-specific 400 mtrace2 MUST specify source address. 402 5.3. Source Address 404 This field specifies the 32 bits length IPv4 or 128 bits length IPv6 405 address of the multicast source for the path being traced, or is 406 filled with "all 1" in case of IPv4 or with the unspecified address 407 (::) in case of IPv6 if no source-specific information such as a 408 trace for RPT in PIM-SM is desired. Note that non-source-specific 409 traceroutes may not be possible with certain multicast routing 410 protocols. 412 5.4. Destination Address 414 This field specifies the 32 bits length IPv4 or 128 bits length IPv6 415 address of the mtrace2 client. The trace starts at this destination 416 and proceeds toward the traffic source. 418 5.5. Query ID: 16 bits 420 This field is used as a unique identifier for this traceroute request 421 so that duplicate or delayed responses may be detected. 423 5.6. Client Port # 425 Mtrace2 response is sent back to the address specified in a 426 Destination Address field. This field specifies the UDP port number 427 the router will send Mtrace2 Response. This client port number MUST 428 NOT be changed by any router. 430 6. IPv4 Mtrace2 Standard Response Block 432 Each intermediate IPv4 router in a trace path appends "response data 433 block" to the forwarded trace packet. The standard response data 434 block looks as follows. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+ 439 | MBZ | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Query Arrival Time | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Incoming Interface Address | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Outgoing Interface Address | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Previous-Hop Router Address | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 . Input packet count on incoming interface . 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 . Output packet count on outgoing interface . 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | | 458 . Total number of packets for this source-group pair . 459 | | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Rtg Protocol | Multicast Rtg Protocol | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Fwd TTL | MBZ |S| Src Mask |Forwarding Code| 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 6.1. MBZ: 8 bit 468 Must be zeroed on transmission and ignored on reception. 470 6.2. Query Arrival Time: 32 bits 472 The Query Arrival Time is a 32-bit NTP timestamp specifying the 473 arrival time of the traceroute request packet at this router. The 474 32-bit form of an NTP timestamp consists of the middle 32 bits of the 475 full 64-bit form; that is, the low 16 bits of the integer part and 476 the high 16 bits of the fractional part. 478 The following formula converts from a UNIX timeval to a 32-bit NTP 479 timestamp: 481 query_arrival_time 482 = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec << 10) / 15625) 484 The constant 32384 is the number of seconds from Jan 1, 1900 to Jan 485 1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 15625) is a 486 reduction of ((tv.tv_usec / 100000000) << 16). 488 6.3. Incoming Interface Address: 32 bits 490 This field specifies the address of the interface on which packets 491 from this source and group are expected to arrive, or 0 if unknown or 492 unnumbered. 494 6.4. Outgoing Interface Address: 32 bits 496 This field specifies the address of the interface on which packets 497 from this source and group flow to the specified destination, or 0 if 498 unknown or unnumbered. 500 6.5. Previous-Hop Router Address: 32 bits 502 This field specifies the router from which this router expects 503 packets from this source. This may be a multicast group (e.g. ALL- 504 [protocol]-ROUTERS.MCAST.NET) if the previous hop is not known 505 because of the workings of the multicast routing protocol. However, 506 it should be 0 if the incoming interface address is unknown or 507 unnumbered. 509 6.6. Input packet count on incoming interface: 64 bits 511 This field contains the number of multicast packets received for all 512 groups and sources on the incoming interface, or "all 1" if no count 513 can be reported. This counter may have the same value as 514 ifHCInMulticastPkts from the IF-MIB [12] for this interface. 516 6.7. Output packet count on incoming interface: 64 bits 518 This field contains the number of multicast packets that have been 519 transmitted or queued for transmission for all groups and sources on 520 the outgoing interface, or "all 1" if no count can be reported. This 521 counter may have the same value as ifHCOutMulticastPkts from the IF- 522 MIB for this interface. 524 6.8. Total number of packets for this source-group pair: 64 bits 526 This field counts the number of packets from the specified source 527 forwarded by this router to the specified group, or "all 1" if no 528 count can be reported. If the S bit is set, the count is for the 529 source network, as specified by the Src Mask field. If the S bit is 530 set and the Src Mask field is 63, indicating no source-specific 531 state, the count is for all sources sending to this group. This 532 counter should have the same value as ipMcastRoutePkts from the 533 IPMROUTE-STD-MIB [13] for this forwarding entry. 535 6.9. Rtg Protocol: 16 bits 537 This field describes the routing protocol used to decide an RPF 538 interface for the requested source. This value should have the same 539 value as ipMcastRouteRtProtocol from the IPMROUTE-STD-MIB [13] for 540 this entry. If the router does not able to obtain this value, "all 541 0" must be specified. 543 6.10. Multicast Rtg Protocol: 16 bits 545 This field describes the multicast routing protocol in use between 546 this router and the previous-hop router. This value should have the 547 same value as ipMcastRouteProtocol from the IPMROUTE-STD-MIB [13] for 548 this entry. If the router does not able to obtain this value, "all 549 0" must be specified. 551 6.11. Fwd TTL: 8 bits 553 This field contains the TTL that a packet is required to have before 554 it will be forwarded over the outgoing interface. 556 6.12. S: 1 bit 558 This S bit indicates that the packet count for the source-group pair 559 is for the source network, as determined by masking the source 560 address with the Src Mask field. 562 6.13. Src Mask: 7 bits 564 This field contains the number of 1's in the netmask this router has 565 for the source (i.e. a value of 24 means the netmask is 0xffffff00). 566 If the router is forwarding solely on group state, this field is set 567 to 127 (0x7f). 569 6.14. Forwarding Code: 8 bits 571 This field contains a forwarding information/error code. Section 9.2 572 explains how and when the forwarding code is filled. Defined values 573 are as follows; 575 Value Name Description 577 ----- -------------- ------------------------------------------- 579 0x00 NO_ERROR No error 581 0x01 WRONG_IF Mtrace2 request arrived on an interface 582 to which this router would not forward for 583 this source, group, destination. 585 0x02 PRUNE_SENT This router has sent a prune upstream which 586 applies to the source and group in the 587 traceroute request. 589 0x03 PRUNE_RCVD This router has stopped forwarding for this 590 source and group in response to a request 591 from the next hop router. 593 0x04 SCOPED The group is subject to administrative 594 scoping at this hop. 596 0x05 NO_ROUTE This router has no route for the source or 597 group and no way to determine a potential 598 route. 600 0x06 WRONG_LAST_HOP This router is not the proper last-hop 601 router. 603 0x07 NOT_FORWARDING This router is not forwarding this source, 604 group out the outgoing interface for an 605 unspecified reason. 607 0x08 REACHED_RP Reached Rendezvous Point or Core 609 0x09 RPF_IF Mtrace2 request arrived on the expected 610 RPF interface for this source and group. 612 0x0A NO_MULTICAST Mtrace2 request arrived on an interface 613 which is not enabled for multicast. 615 0x0B INFO_HIDDEN One or more hops have been hidden from this 616 trace. 618 0x0C REACHED_GW Mtrace2 request arrived on a gateway (e.g., 619 a NAT or firewall) that hides the 620 information between this router and the 621 mtrace2 querier 623 0x81 NO_SPACE There was not enough room to insert another 624 response data block in the packet. 626 0x82 OLD_ROUTER The previous-hop router does not understand 627 mtrace2 requests. 629 0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited. 631 Note that if a router discovers there is not enough room in a packet 632 to insert its response, it puts the NO_SPACE error code in the 633 previous router's Forwarding Code field, overwriting any error the 634 previous router placed there. After the router sends the response to 635 the Destination Address in the header, the router continues the 636 mtrace2 query by sending an mtrace2 request containing the same 637 mtrace2 Query header. Section 9.3 and Section 10.8 include the 638 details. 640 The 0x80 bit of the Forwarding Code is used to indicate a fatal 641 error. A fatal error is one where the router may know the previous 642 hop but cannot forward the message to it. 644 7. IPv6 Mtrace2 Standard Response Block 646 Each intermediate IPv6 router in a trace path appends "response data 647 block" to the forwarded trace packet. The standard response data 648 block looks as follows. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+ 653 | MBZ | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Query Arrival Time | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Incoming Interface ID | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Outgoing Interface ID | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | | 662 * Local Address * 663 | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | | 666 * Remote Address * 667 | | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | 670 . Input packet count on incoming interface . 671 | | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | | 674 . Output packet count on outgoing interface . 675 | | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | | 678 . Total number of packets for this source-group pair . 679 | | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Rtg Protocol | Multicast Rtg Protocol | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | MBZ |S|Src Prefix Len |Forwarding Code| 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 7.1. MBZ: 8 bit 688 Must be zeroed on transmission and ignored on reception. 690 7.2. Query Arrival Time: 32 bits 692 Same definition described in Section 6.2 694 7.3. Incoming Interface ID: 32 bits 696 This field specifies the interface ID on which packets from this 697 source and group are expected to arrive, or 0 if unknown. This ID 698 should be the value taken from InterfaceIndex of the IF-MIB [12] for 699 this interface. This field is carried in network byte order. 701 7.4. Outgoing Interface ID: 32 bits 703 This field specifies the interface ID on which packets from this 704 source and group flow to the specified destination, or 0 if unknown. 705 This ID should be the value taken from InterfaceIndex of the IF-MIB 706 for this interface. This field is carried in network byte order. 708 7.5. Local Address 710 This field specifies a global IPv6 address that uniquely identifies 711 the router. A unique local unicast address [11] SHOULD NOT be used 712 unless the router is only assigned link-local and unique local 713 addresses. If the router is only assigned link-local addresses, its 714 link-local address can be specified in this field. 716 7.6. Remote Address 718 This field specifies the address of the previous-hop router, which, 719 in most cases, is a link-local unicast address for the queried source 720 and destination addresses. 722 Although a link-local address does not have enough information to 723 identify a node, it is possible to detect the previous-hop router 724 with the assistance of Incoming Interface ID and the current router 725 address (i.e., Local Address). 727 This may be a multicast group (e.g., ALL-[protocol]- 728 ROUTERS.MCAST.NET) if the previous hop is not known because of the 729 workings of the multicast routing protocol. However, it should be 730 the unspecified address (::) if the incoming interface address is 731 unknown. 733 7.7. Input packet count on incoming interface 735 Same definition described in Section 6.6 737 7.8. Output packet count on incoming interface 739 Same definition described in Section 6.7 741 7.9. Total number of packets for this source-group pair 743 This field counts the number of packets from the specified source 744 forwarded by this router to the specified group, or "all 1" if no 745 count can be reported. If the S bit is set, the count is for the 746 source network, as specified by the Src Prefix Len field. If the S 747 bit is set and the Src Prefix Len field is 255, indicating no source- 748 specific state, the count is for all sources sending to this group. 749 This counter should have the same value as ipMcastRoutePkts from the 750 IPMROUTE-STD-MIB for this forwarding entry. 752 7.10. Rtg Protocol: 16 bits 754 Same definition described in Section 6.9 756 7.11. Multicast Rtg Protocol: 16 bits 758 Same definition described in Section 6.10 760 7.12. S: 1 bit 762 This S bit indicates that the packet count for the source-group pair 763 is for the source network, as determined by masking the source 764 address with the Src Prefix Len field. 766 7.13. Src Prefix Len: 8 bits 768 This field contains the prefix length this router has for the source. 769 If the router is forwarding solely on group state, this field is set 770 to 255 (0xff) 772 7.14. Forwarding Code: 8 bits 774 Same definition described in Section 6.14 776 8. Mtrace2 Augmented Response Block 778 In addition to the standard response block, a multicast router on the 779 path will be able to add "augumented response block" when it sends 780 the request to its upstream router or sends the response to the 781 Destination Address. This augmented response block is flexible to 782 add various information. 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Type | Value .... | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 The augmented response block is always appended to mtrace2 TLV header 791 (0x04). The 16 bits Type filed of the augmented response block is 792 defined for various purposes, such as diagnosis (as in Section 12) 793 and protocol verification. The packet length of the augmented 794 response block is specified in the augmented response block TLV 795 header as seen in Section 4.1. 797 The following augmented response block type is defined: 799 Code Type 800 ====== ================================================= 801 0x01 # Mtrace2 Standard Response Blocks Returned 803 When the NO_SPACE error occurs, the router sends back the mtrace2 804 response with contained data (i.e., all appended response blocks), 805 and continues the mtrace2 query by sending an mtrace2 request as will 806 be described in Section 9.3. In this mtrace2 request, the router 807 appends the augmented response block with the code "0x01" and the 808 number of returned mtrace2 response blocks. Every router between 809 this router and the first-hop router can recognize the limit number 810 of hops by referring this number and the # hops in the header. 812 This document only defines the above augmented response block type 813 and does not define other augmented response block types. Specifing 814 how to deal with diagnosis information will be also described in 815 separate documents. 817 9. Router Behavior 819 All of these actions are performed in addition to (NOT instead of) 820 forwarding the packet, if applicable. E.g. a multicast packet that 821 has TTL or the hop limit remaining MUST be forwarded normally, as 822 MUST a unicast packet that has TTL or the hop limit remaining and is 823 not addressed to this router. 825 9.1. Traceroute Query 827 An mtrace2 Query message is a traceroute message with no response 828 blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6 mtrace2. 830 9.1.1. Packet Verification 832 Upon receiving an mtrace2 Query message, a router must examine the 833 Query to see if it is the proper last-hop router for the destination 834 address in the packet. It is the proper last-hop router if it has a 835 multicast-capable interface on the same subnet as the Destination 836 Address and is the router that would forward traffic from the given 837 (S,G) onto that subnet. 839 If the router determines that it is not the proper last-hop router, 840 or it cannot make that determination, it does one of two things 841 depending if the Query was received via multicast or unicast. If the 842 Query was received via multicast, then it MUST be silently dropped. 843 If it was received via unicast, a forwarding code of WRONG_LAST_HOP 844 is noted and processing continues as in Section 9.2 846 Duplicate Query messages as identified by the tuple (IP Source, Query 847 ID) SHOULD be ignored. This MAY be implemented using a simple 1-back 848 cache (i.e. remembering the IP source and Query ID of the previous 849 Query message that was processed, and ignoring future messages with 850 the same IP Source and Query ID). Duplicate Request messages MUST 851 NOT be ignored in this manner. 853 9.1.2. Normal Processing 855 When a router receives an mtrace2 Query and it determines that it is 856 the proper last-hop router, it treats it like an mtrace2 Request and 857 performs the steps listed in Section 9.2 859 9.2. Mtrace2 Request 861 An mtrace2 Request is a traceroute message with some number of 862 response blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6 863 mtrace2. Routers can tell the difference between Queries and 864 Requests by checking the length of the packet. 866 9.2.1. Packet Verification 868 If the mtrace2 Request does not come from an adjacent host or router, 869 it MUST be silently ignored. If the mtrace2 Request is not addressed 870 to this router, or if the Request is addressed to a multicast group 871 which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3] 872 for IPv6), it MUST be silently ignored. GTSM [14] SHOULD be used by 873 the router to determine whether the host or router is adjacent or 874 not. 876 9.2.2. Normal Processing 878 When a router receives an mtrace2 Request, it performs the following 879 steps. Note that it is possible to have multiple situations covered 880 by the Forwarding Codes. The first one encountered is the one that 881 is reported, i.e. all "note forwarding code N" should be interpreted 882 as "if forwarding code is not already set, set forwarding code to N". 884 1. If there is room in the current buffer (or the router can 885 efficiently allocate more space to use), insert a new response 886 block into the packet and fill in the Query Arrival Time, 887 Outgoing Interface Address (for IPv4 mtrace2) or Outgoing 888 Interface ID (for IPv6 mtrace2), Output Packet Count, and Fwd 889 TTL (for IPv4 mtrace2). If there was no room, fill in the 890 response code "NO_SPACE" in the *previous* hop's response block, 891 and forward the packet to the address specified in the 892 Destination Address field and continue the trace as described in 893 Section 9.3. 895 2. Attempt to determine the forwarding information for the source 896 and group specified, using the same mechanisms as would be used 897 when a packet is received from the source destined for the 898 group. State need not be instantiated, it can be "phantom" 899 state created only for the purpose of the trace, such as "dry- 900 run". 902 If using a shared-tree protocol and there is no source-specific 903 state, or if no source-specific information is desired (i.e., 904 "all 1" for IPv4 or unspecified address (::) for IPv6), group 905 state should be used. If there is no group state or no group- 906 specific information is desired, potential source state (i.e. 907 the path that would be followed for a source-specific Join) 908 should be used. If this router is the Core or RP and no source- 909 specific state is available (e.g., this router has been 910 receiving PIM Register messages from the first-hop router), note 911 a code of REACHED_RP. 913 3. If no forwarding information can be determined, the router notes 914 an error code of NO_ROUTE, sets the remaining fields that have 915 not yet been filled in to zero, and then forwards the packet to 916 the mtrace2 client as described in Section 9.3. 918 4. Fill in the Incoming Interface Address, Previous-Hop Router 919 Address, Input Packet Count, Total Number of Packets, Routing 920 Protocol, S, and Src Mask from the forwarding information that 921 was determined. 923 5. If mtrace2 is administratively prohibited or the previous hop 924 router does not understand mtrace2 requests, note the 925 appropriate forwarding code (ADMIN_PROHIB or OLD_ROUTER). If 926 mtrace2 is administratively prohibited and any of the fields as 927 filled in step 4 are considered private information, zero out 928 the applicable fields. Then the packet is forwarded to the 929 mtrace2 client as described in Section 9.3. 931 6. If the reception interface is not enabled for multicast, note 932 forwarding code NO_MULTICAST. If the reception interface is the 933 interface from which the router would expect data to arrive from 934 the source, note forwarding code RPF_IF. Otherwise, if the 935 reception interface is not one to which the router would forward 936 data from the source to the group, a forwarding code of WRONG_IF 937 is noted. 939 7. If the group is subject to administrative scoping on either the 940 Outgoing or Incoming interfaces, a forwarding code of SCOPED is 941 noted. 943 8. If this router is the Rendezvous Point or Core for the group, a 944 forwarding code of REACHED_RP is noted. 946 9. If this router has sent a prune upstream which applies to the 947 source and group in the mtrace2 Request, it notes forwarding 948 code PRUNE_SENT. If the router has stopped forwarding 949 downstream in response to a prune sent by the next hop router, 950 it notes forwarding code PRUNE_RCVD. If the router should 951 normally forward traffic for this source and group downstream 952 but is not, it notes forwarding code NOT_FORWARDING. 954 10. If this router is a gateway (e.g., a NAT or firewall) that hides 955 the information between this router and the mtrace2 querier, it 956 notes forwarding code REACHED_GW. 958 11. The packet is then sent on to the previous hop or the 959 Destination Address as described in Section 9.3. 961 9.3. Forwarding Mtrace2 Requests 963 If the Previous-hop router is known for this request and the number 964 of response blocks is less than the number requested (i.e., the "# 965 hops" field in mtrace2 Query header), the packet is sent to that 966 router. If the Incoming Interface is known but the Previous-hop 967 router is not known, the packet is sent to an appropriate multicast 968 address on the Incoming Interface. The appropriate multicast address 969 may depend on the routing protocol in use, MUST be a link-scoped 970 group (i.e. 224/24 for IPv4, FF02::/16 for IPv6), MUST NOT be ALL- 971 SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 and All Nodes Address 972 (FF02::1) for IPv6, and MAY be ALL-ROUTERS.MCAST.NET (224.0.0.2) for 973 IPv4 or All Routers Address (FF02::2) for IPv6 if the routing 974 protocol in use does not define a more appropriate group. Otherwise, 975 it is sent to the Destination Address in the header. 977 When the REACHED_GW code is noted, the router sends back the mtrace2 978 response as in Section 9.4. In addition to that, it must continue 979 the mtrace2 query by proxying the original querier as in Section 9.5. 981 When the NO_SPACE error occurs, the router sends back the mtrace2 982 response with contained data and the NO_SPACE error code as in 983 Section 9.4, and continues the mtrace2 query by sending an mtrace2 984 request containing the same mtrace2 Query header and its standard and 985 augmented response blocks. The corresponding augmented response 986 block type is "# Mtrace2 Response Blocks Returned" described in 987 Section 8. 989 9.4. Sending Mtrace2 Responses 991 9.4.1. Destination Address 993 An mtrace2 Response must be sent to the address specified in the 994 Destination Address field in the mtrace2 Query header. 996 9.4.2. Source Address 998 An mtrace2 Response must be sent with the address of the router's 999 reception interface. 1001 9.5. Proxying Mtrace2 Queries 1003 When a gateway (e.g., a NAT or firewall) that needs to block unicast 1004 packets to the mtrace2 querier or hide information between the 1005 gateway and the mtrace2 querier receives mtrace2 query from an 1006 adjacent host or mtrace2 request from an adjacent router, it sends 1007 back the mtrace2 response with contained data and the REACHED_GW code 1008 to the address specified in the Destination Address field in the 1009 mtrace2 Query header. 1011 At the same time, the gateway prepares a new mtrace2 query message. 1012 The gateway uses the original mtrace2 Query header as the base for 1013 the new mtrace2 query; it sets the Destination Address to its 1014 Incoming Interface address and the Client Port # to its own port 1015 (which may be the same as the mtrace2 port as the gateway is 1016 listening on that port), and decreases # hops according to the number 1017 of standard response blocks in the returned mtrace2 response from the 1018 gateway. The mtrace2 query message is sent to the previous-hop 1019 router or to an appropriate multicast address on the Incoming 1020 Interface. 1022 When the gateway receives the mtrace2 response from the first-hop 1023 router or any intermediate router, it MUST forward the mtrace2 1024 response back to the mtrace2 querier with the original mtrace2 Query 1025 header. 1027 9.6. Hiding Information 1029 Information about a domain's topology and connectivity may be hidden 1030 from multicast traceroute requests. The INFO_HIDDEN forwarding code 1031 may be used to note that, for example, the incoming interface address 1032 and packet count are for the entrance to the domain and the outgoing 1033 interface address and packet count are the exit from the domain. The 1034 source-group packet count may be from either router or not specified 1035 (all 1). 1037 10. Client Behavior 1039 10.1. Sending Mtrace2 Queries 1041 When the destination of the mtrace2 is the machine running the 1042 client, the mtrace2 Query packet can be sent to the ALL- 1043 ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address 1044 (FF02::2) for IPv6. This will ensure that the packet is received by 1045 the last-hop router on the subnet. Otherwise, if the proper last-hop 1046 router is known for the mtrace2 destination, the Query could be 1047 unicasted to that router. 1049 See also Section 10.4 on determining the last-hop router. 1051 10.2. Determining the Path 1053 The client could send a small number of initial query messages with a 1054 large "# hops" field, in order to try to trace the full path. If 1055 this attempt fails, one strategy is to perform a linear search (as 1056 the traditional unicast traceroute program does); set the "# hops" 1057 field to 1 and try to get a response, then 2, and so on. If no 1058 response is received at a certain hop, the hop count can continue 1059 past the non-responding hop, in the hopes that further hops may 1060 respond. These attempts should continue until a user-defined timeout 1061 has occurred. 1063 See also Section 10.5 and Section 10.6 on receiving the results of a 1064 trace. 1066 10.3. Collecting Statistics 1068 After a client has determined that it has traced the whole path or as 1069 much as it can expect to (see Section 10.7), it might collect 1070 statistics by waiting a short time and performing a second trace. If 1071 the path is the same in the two traces, statistics can be displayed 1072 as described in Section 12.3 and Section 12.4. 1074 10.4. Last Hop Router 1076 The mtrace2 querier may not know which is the last-hop router, or 1077 that router may be behind a firewall that blocks unicast packets but 1078 passes multicast packets. In these cases, the mtrace2 request should 1079 be multicasted to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All 1080 Routers Address (FF02::2) for IPv6. All routers except the correct 1081 last-hop router should ignore any mtrace2 request received via 1082 multicast. 1084 10.5. First Hop Router 1086 The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default 1087 multicast group for IPv4 mtrace responses, in order to support mtrace 1088 queriers that are not unicast reachable from the first-hop router. 1089 However, mtrace2 does not reserve any IPv4/IPv6 multicast addresses 1090 for mtrace2 responses. Every mtrace2 response is sent to the unicast 1091 address specified in the Destination Address field of the mtrace2 1092 Query header. 1094 10.6. Broken Intermediate Router 1096 A broken intermediate router might simply not understand mtrace2 1097 packets, and drop them. The querier would then get no response at 1098 all from its mtrace2 requests. It should then perform a hop-by-hop 1099 search by setting the number of responses field until it gets a 1100 response (both linear and binary search are options, but binary is 1101 likely to be slower because a failure requires waiting for a 1102 timeout). 1104 10.7. Mtrace2 Termination 1106 When performing an expanding hop-by-hop trace, it is necessary to 1107 determine when to stop expanding. 1109 10.7.1. Arriving at source 1111 A trace can be determined to have arrived at the source if the 1112 Incoming Interface of the last router in the trace is non-zero, but 1113 the Previous-hop router is zero. 1115 10.7.2. Fatal error 1117 A trace has encountered a fatal error if the last Forwarding Error in 1118 the trace has the 0x80 bit set. 1120 10.7.3. No previous hop 1122 A trace can not continue if the last Previous-hop in the trace is set 1123 to 0. 1125 10.7.4. Traceroute shorter than requested 1127 If the trace that is returned is shorter than requested (i.e. the 1128 number of response blocks is smaller than the "# hops" field), the 1129 trace encountered an error and could not continue. 1131 10.8. Continuing after an error 1133 When the NO_SPACE error occurs, as described in Section 9.3, the 1134 multicast routers sends back the mtrace2 Response to the address 1135 specified in the Destination Address field in the mtrace2 Query 1136 header. In this case, the mtrace2 client may receive multiple 1137 mtrace2 responses from different routers (along the path). After the 1138 client receives multiple mtrace2 Response messages, it integrates 1139 (i.e. constructs) them as a single mtrace2 Response message. 1141 If a trace times out, it is likely to be because a router in the 1142 middle of the path does not support mtrace2. That router's address 1143 will be in the Previous-hop router field of the last entry in the 1144 last response packet received. A client may be able to determine 1145 (via mrinfo or SNMP [11][13]) a list of neighbors of the non- 1146 responding router. If desired, each of those neighbors could be 1147 probed to determine the remainder of the path. Unfortunately, this 1148 heuristic may end up with multiple paths, since there is no way of 1149 knowing what the non-responding router's algorithm for choosing a 1150 previous-hop router is. However, if all paths but one flow back 1151 towards the non-responding router, it is possible to be sure that 1152 this is the correct path. 1154 11. Protocol-Specific Considerations 1156 11.1. PIM-SM 1158 When an mtrace2 reaches a PIM-SM RP and the RP does not forward the 1159 trace on, it means that the RP has not performed a source-specific 1160 join so there is no more state to trace. However, the path that 1161 traffic would use if the RP did perform a source-specific join can be 1162 traced by setting the trace destination to the RP, the trace source 1163 to the traffic source, and the trace group to 0. This trace Query 1164 may be unicasted to the RP. 1166 11.2. Bi-Directional PIM 1168 Bi-directional PIM [7] is a variant of PIM-SM that builds bi- 1169 directional shared trees connecting multicast sources and receivers. 1170 Along the bi-directional shared trees, multicast data is natively 1171 forwarded from sources to the RPA (Rendezvous Point Address) and from 1172 the RPA to receivers without requiring source-specific state. In 1173 contrast to PIM-SM, RP always has the state to trace. 1175 A Designated Forwarder (DF) for a given RPA is in charge of 1176 forwarding downstream traffic onto its link, and forwarding upstream 1177 traffic from its link towards the RPL (Rendezvous Point Link) that 1178 the RPA belongs to. Hence mtrace2 reports DF addresses or RPA along 1179 the path. 1181 11.3. PIM-DM 1183 Routers running PIM Dense Mode do not know the path packets would 1184 take unless traffic is flowing. Without some extra protocol 1185 mechanism, this means that in an environment with multiple possible 1186 paths with branch points on shared media, mtrace2 can only trace 1187 existing paths, not potential paths. When there are multiple 1188 possible paths but the branch points are not on shared media, the 1189 previous hop router is known, but the last-hop router may not know 1190 that it is the appropriate last hop. 1192 When traffic is flowing, PIM Dense Mode routers know whether or not 1193 they are the last-hop forwarder for the link (because they won or 1194 lost an Assert battle) and know who the previous hop is (because it 1195 won an Assert battle). Therefore, mtrace2 is always able to follow 1196 the proper path when traffic is flowing. 1198 11.4. IGMP/MLD Proxy 1200 When an mtrace2 Query packet reaches an incoming interface of IGMP/ 1201 MLD Proxy [8], it puts a WRONG_IF (0x01) value in Forwarding Code of 1202 mtrace2 standard response block (as in Section 6.14) and sends the 1203 mtrace2 response back to the Destination Address. When an mtrace2 1204 Query packet reaches an outgoing interface of IGMP/MLD proxy, it is 1205 forwarded through its incoming interface towards the upstream router. 1207 11.5. AMT 1209 AMT [9] provides the multicast connectivity to the unicast-only 1210 inter-network. To do this, multicast packets being sent to or from a 1211 site are encapsulated in unicast packets. When an mtrace2 query 1212 packet reaches an AMT pseudo-interface of an AMT gateway, the AMT 1213 gateway encapsulats it to a particular AMT relay reachable across the 1214 unicast-only infrastructure. Then the AMT relay decapsulates the 1215 mtrace2 query packet and forwards the mtrace2 request to the 1216 appropriate multicast router. 1218 12. Problem Diagnosis 1220 12.1. Forwarding Inconsistencies 1222 The forwarding error code can tell if a group is unexpectedly pruned 1223 or administratively scoped. 1225 12.2. TTL or Hop Limit Problems 1227 By taking the maximum of hops (from source + forwarding TTL (or hop 1228 limit) threshold) over all hops, it is possible to discover the TTL 1229 or hop limit required for the source to reach the destination. 1231 12.3. Packet Loss 1233 By taking two traces, it is possible to find packet loss information 1234 by comparing the difference in input packet counts to the difference 1235 in output packet counts for the specified source-group address pair 1236 at the previous hop. On a point-to-point link, any difference in 1237 these numbers implies packet loss. Since the packet counts may be 1238 changing as the mtrace2 query is propagating, there may be small 1239 errors (off by 1 or 2 or more) in these statistics. However, these 1240 errors will not accumulate if multiple traces are taken to expand the 1241 measurement period. On a shared link, the count of input packets can 1242 be larger than the number of output packets at the previous hop, due 1243 to other routers or hosts on the link injecting packets. This 1244 appears as "negative loss" which may mask real packet loss. 1246 In addition to the counts of input and output packets for all 1247 multicast traffic on the interfaces, the response data includes a 1248 count of the packets forwarded by a node for the specified source- 1249 group pair. Taking the difference in this count between two traces 1250 and then comparing those differences between two hops gives a measure 1251 of packet loss just for traffic from the specified source to the 1252 specified receiver via the specified group. This measure is not 1253 affected by shared links. 1255 On a point-to-point link that is a multicast tunnel, packet loss is 1256 usually due to congestion in unicast routers along the path of that 1257 tunnel. On native multicast links, loss is more likely in the output 1258 queue of one hop, perhaps due to priority dropping, or in the input 1259 queue at the next hop. The counters in the response data do not 1260 allow these cases to be distinguished. Differences in packet counts 1261 between the incoming and outgoing interfaces on one node cannot 1262 generally be used to measure queue overflow in the node. 1264 12.4. Link Utilization 1266 Again, with two traces, you can divide the difference in the input or 1267 output packet counts at some hop by the difference in time stamps 1268 from the same hop to obtain the packet rate over the link. If the 1269 average packet size is known, then the link utilization can also be 1270 estimated to see whether packet loss may be due to the rate limit or 1271 the physical capacity on a particular link being exceeded. 1273 12.5. Time Delay 1275 If the routers have synchronized clocks, it is possible to estimate 1276 propagation and queuing delay from the differences between the 1277 timestamps at successive hops. However, this delay includes control 1278 processing overhead, so is not necessarily indicative of the delay 1279 that data traffic would experience. 1281 13. IANA Considerations 1283 The following new assignments can only be made via a Standards Action 1284 as specified in [4]. 1286 13.1. Forwarding Codes 1288 New Forwarding codes must only be created by an RFC that modifies 1289 this document's Section 10, fully describing the conditions under 1290 which the new forwarding code is used. The IANA may act as a central 1291 repository so that there is a single place to look up forwarding 1292 codes and the document in which they are defined. 1294 13.2. UDP Destination Port and IPv6 Address 1296 The IANA should allocate UDP destination port for multicast 1297 traceroute version 2 upon publication of the first RFC. 1299 14. Security Considerations 1301 14.1. Topology Discovery 1303 Mtrace2 can be used to discover any actively-used topology. If your 1304 network topology is a secret, mtrace2 may be restricted at the border 1305 of your domain, using the ADMIN_PROHIB forwarding code. 1307 14.2. Traffic Rates 1309 Mtrace2 can be used to discover what sources are sending to what 1310 groups and at what rates. If this information is a secret, mtrace2 1311 may be restricted at the border of your domain, using the 1312 ADMIN_PROHIB forwarding code. 1314 14.3. Limiting Query/Request Rates 1316 Routers should limit mtrace2 queries and requests by ignoring the 1317 received messages. Routers MAY randomly ignore the received messages 1318 to minimize the processing overhead, i.e., to keep fairness in 1319 processing queries. 1321 15. Acknowledgements 1323 This specification started largely as a transcription of Van 1324 Jacobson's slides from the 30th IETF, and the implementation in 1325 mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve 1326 Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original 1327 multicast traceroute client, mtrace (version 1), has been implemented 1328 by Ajit Thyagarajan, Steve Casner and Bill Fenner. 1330 The idea of the "S" bit to allow statistics for a source subnet is 1331 due to Tom Pusateri. 1333 For the mtrace version 2 specification, extensive comments were 1334 received from Ronald Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Pekka 1335 Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, and Cao 1336 Wei. 1338 16. References 1340 16.1. Normative References 1342 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 1343 levels", RFC 2119, March 1997. 1345 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1346 Specification", RFC 2460, December 1998. 1348 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 1349 Architecture", RFC 2373, July 1998. 1351 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1352 Considerations Section in RFCs", RFC 2434, October 1998. 1354 [5] Braden, B., Borman, D., and C. Partridge, "Computing the 1355 Internet Checksum", RFC 1071, September 1988. 1357 [6] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1358 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1359 Protocol Specification (Revised)", RFC 4601, August 2006. 1361 [7] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1362 "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", 1363 RFC 5015, October 2007. 1365 [8] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 1366 Group Management Protocol (IGMP) / Multicast Listener Discovery 1367 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 1368 RFC 4605, August 2006. 1370 [9] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 1371 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 1372 (AMT)", draft-ietf-mboned-auto-multicast-08.txt (work in 1373 progress), October 2007. 1375 16.2. Informative References 1377 [10] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1378 Thyagarajan, "Internet Group Management Protocol, Version 3", 1379 RFC 3376, October 2002. 1381 [11] Draves, R. and D. Thaler, "Default Router Preferences and More- 1382 Specific Routes", RFC 4191, November 2005. 1384 [12] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", 1385 RFC 2863, June 2000. 1387 [13] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB", 1388 RFC 5132, December 2007. 1390 [14] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, 1391 "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, 1392 October 2007. 1394 Authors' Addresses 1396 Hitoshi Asaeda 1397 Keio University 1398 Graduate School of Media and Governance 1399 Fujisawa, Kanagawa 252-8520 1400 Japan 1402 Email: asaeda@wide.ad.jp 1403 URI: http://www.sfc.wide.ad.jp/~asaeda/ 1405 Tatuya Jinmei 1406 Internet Systems Consortium 1407 Redwood City, CA 94063 1408 US 1410 Email: Jinmei_Tatuya@isc.org 1412 William C. Fenner 1413 Arastra, Inc. 1414 Menlo Park, CA 94025 1415 US 1417 Email: fenner@fenron.net 1419 Stephen L. Casner 1420 Packet Design, Inc. 1421 Palo Alto, CA 94304 1422 US 1424 Email: casner@packetdesign.com