idnits 2.17.1 draft-ietf-mboned-mtrace-v2-08.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 (January 7, 2011) is 4851 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 1413, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1422, 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: July 11, 2011 ISC 6 W. Fenner 7 Arastra, Inc. 8 S. Casner 9 Packet Design, Inc. 10 January 7, 2011 12 Mtrace Version 2: Traceroute Facility for IP Multicast 13 draft-ietf-mboned-mtrace-v2-08 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 July 11, 2011. 40 Copyright Notice 42 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. # hops: 8 bits . . . . . . . . . . . . . . . . . . . . . . 12 77 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 13 78 5.3. Source Address . . . . . . . . . . . . . . . . . . . . . . 13 79 5.4. Mtrace2 Client Address . . . . . . . . . . . . . . . . . . 13 80 5.5. Query ID: 16 bits . . . . . . . . . . . . . . . . . . . . 13 81 5.6. Client Port # . . . . . . . . . . . . . . . . . . . . . . 13 82 6. IPv4 Mtrace2 Standard Response Block . . . . . . . . . . . . . 14 83 6.1. MBZ: 8 bit . . . . . . . . . . . . . . . . . . . . . . . . 14 84 6.2. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 14 85 6.3. Incoming Interface Address: 32 bits . . . . . . . . . . . 15 86 6.4. Outgoing Interface Address: 32 bits . . . . . . . . . . . 15 87 6.5. Previous-Hop Router Address: 32 bits . . . . . . . . . . . 15 88 6.6. Input packet count on incoming interface: 64 bits . . . . 15 89 6.7. Output packet count on outgoing interface: 64 bits . . . . 16 90 6.8. Total number of packets for this source-group pair: 64 91 bits . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 6.9. Rtg Protocol: 16 bits . . . . . . . . . . . . . . . . . . 16 93 6.10. Multicast Rtg Protocol: 16 bits . . . . . . . . . . . . . 16 94 6.11. Fwd TTL: 8 bits . . . . . . . . . . . . . . . . . . . . . 16 95 6.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 6.13. Src Mask: 7 bits . . . . . . . . . . . . . . . . . . . . . 17 97 6.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 17 98 7. IPv6 Mtrace2 Standard Response Block . . . . . . . . . . . . . 19 99 7.1. MBZ: 8 bit . . . . . . . . . . . . . . . . . . . . . . . . 19 100 7.2. Query Arrival Time: 32 bits . . . . . . . . . . . . . . . 20 101 7.3. Incoming Interface ID: 32 bits . . . . . . . . . . . . . . 20 102 7.4. Outgoing Interface ID: 32 bits . . . . . . . . . . . . . . 20 103 7.5. Local Address . . . . . . . . . . . . . . . . . . . . . . 20 104 7.6. Remote Address . . . . . . . . . . . . . . . . . . . . . . 20 105 7.7. Input packet count on incoming interface . . . . . . . . . 20 106 7.8. Output packet count on outgoing interface . . . . . . . . 21 107 7.9. Total number of packets for this source-group pair . . . . 21 108 7.10. Rtg Protocol: 16 bits . . . . . . . . . . . . . . . . . . 21 109 7.11. Multicast Rtg Protocol: 16 bits . . . . . . . . . . . . . 21 110 7.12. S: 1 bit . . . . . . . . . . . . . . . . . . . . . . . . . 21 111 7.13. Src Prefix Len: 8 bits . . . . . . . . . . . . . . . . . . 21 112 7.14. Forwarding Code: 8 bits . . . . . . . . . . . . . . . . . 21 113 8. Mtrace2 Augmented Response Block . . . . . . . . . . . . . . . 22 114 9. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 23 115 9.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 23 116 9.1.1. Packet Verification . . . . . . . . . . . . . . . . . 23 117 9.1.2. Normal Processing . . . . . . . . . . . . . . . . . . 23 118 9.1.3. Mtrace2 Query Received by Non-Supported Router . . . . 23 119 9.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 24 120 9.2.1. Packet Verification . . . . . . . . . . . . . . . . . 24 121 9.2.2. Normal Processing . . . . . . . . . . . . . . . . . . 24 122 9.2.3. Mtrace2 Request Received by Non-Supported Router . . . 26 123 9.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . . 26 124 9.3.1. Destination Address . . . . . . . . . . . . . . . . . 26 125 9.3.2. Source Address . . . . . . . . . . . . . . . . . . . . 26 126 9.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 27 127 9.4.1. Destination Address . . . . . . . . . . . . . . . . . 27 128 9.4.2. Source Address . . . . . . . . . . . . . . . . . . . . 27 129 9.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . . 27 130 9.6. Hiding Information . . . . . . . . . . . . . . . . . . . . 28 131 10. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 29 132 10.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 29 133 10.1.1. Destination Address . . . . . . . . . . . . . . . . . 29 134 10.1.2. Source Address . . . . . . . . . . . . . . . . . . . . 29 135 10.2. Determining the Path . . . . . . . . . . . . . . . . . . . 29 136 10.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 29 137 10.4. Last Hop Router . . . . . . . . . . . . . . . . . . . . . 29 138 10.5. First Hop Router . . . . . . . . . . . . . . . . . . . . . 30 139 10.6. Broken Intermediate Router . . . . . . . . . . . . . . . . 30 140 10.7. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 30 141 10.7.1. Arriving at source . . . . . . . . . . . . . . . . . . 30 142 10.7.2. Fatal error . . . . . . . . . . . . . . . . . . . . . 30 143 10.7.3. No previous hop . . . . . . . . . . . . . . . . . . . 30 144 10.7.4. Traceroute shorter than requested . . . . . . . . . . 30 145 10.8. Continuing after an error . . . . . . . . . . . . . . . . 31 146 11. Protocol-Specific Considerations . . . . . . . . . . . . . . . 32 147 11.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 32 148 11.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . . 32 149 11.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . . 32 150 11.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . . 32 151 11.5. AMT . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 152 12. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 34 153 12.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . . 34 154 12.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 34 155 12.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 34 156 12.4. Link Utilization . . . . . . . . . . . . . . . . . . . . . 35 157 12.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . . 35 158 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 159 13.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . . 36 160 13.2. UDP Destination Port and IPv6 Address . . . . . . . . . . 36 161 14. Security Considerations . . . . . . . . . . . . . . . . . . . 37 162 14.1. Topology Discovery . . . . . . . . . . . . . . . . . . . . 37 163 14.2. Traffic Rates . . . . . . . . . . . . . . . . . . . . . . 37 164 14.3. Limiting Query/Request Rates . . . . . . . . . . . . . . . 37 165 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 166 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 167 16.1. Normative References . . . . . . . . . . . . . . . . . . . 39 168 16.2. Informative References . . . . . . . . . . . . . . . . . . 39 169 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 171 1. Introduction 173 This document specifies the multicast traceroute facility named 174 mtrace version 2 or mtrace2. Mtrace2 allows the tracing of an IP 175 multicast routing paths. Mtrace2 provides additional information 176 about packet rates and losses, or other diagnosis information. For 177 instance, mtrace2 is used for the following purposes. 179 o To trace the path that a packet would take from some source to 180 some destination. 182 o To isolate packet loss problems (e.g., congestion). 184 o To isolate configuration problems (e.g., TTL threshold). 186 Mtrace2 consists of the client and router programs. The mtrace2 187 client program is invoked from somewhere in the multicast tree, on a 188 host, router, or proxy such as IGMP/MLD proxy [8]. The node invoking 189 the program is called the mtrace2 client. 191 The mtrace2 client program creates the mtrace2 Query message, which 192 includes a source and multicast address specified by the client, and 193 forwards the message to its neighbor router or proxy. This initiates 194 a trace of a multicast routing path from the client toward the 195 specified source, or if no source address is specified, toward a core 196 router if such a router exists. In the case of PIM-SM [6], the core 197 router is an RP maintaining the specified multicast address. 199 When a router or proxy receives an mtrace2 Query message and has the 200 corresponding routing state regarding the source and multicast 201 addresses specified in the Query, the router or proxy invokes the 202 mtrace2 router program. The mtrace2 router program creates an 203 mtrace2 Request message corresponding to the query and forwards the 204 Request toward the specified source or the core router. 206 When a first-hop router or proxy (a single hop from the source 207 specified in the request) or the core router receives an mtrace2 208 Query or Request message, the router or proxy invokes the mtrace2 209 router program. The mtrace2 router program creates an mtrace2 Reply 210 message. The Reply message is forwarded to the mtrace2 client, thus 211 completing the mtrace2 Request. 213 The mtrace2 client program waits for the mtrace2 Reply message and 214 displays the results. When an mtrace2 Reply message does not come 215 due to network congestion, a broken router (see Section 10.6) or a 216 non-responding router (see Section 10.8), the mtrace2 client program 217 can resend an mtrace2 Query with a lower hop count (see Section 5.1) 218 and repeat the process until it receives an mtrace2 Reply message. 220 The mtrace2 client should also be aware that the mtrace2 Query may 221 follow the control path on the routers, in the case of a router's 222 control plane and forwarding plane are not synchronized, e.g., a 223 buggy implementation. In this case, mtrace2 Requests will be 224 forwarded toward the specified source or the core router because the 225 router does not have any forwarding state for the query. 227 The mtrace2 supports both IPv4 and IPv6 multicast traceroute 228 facility. The protocol design, concept, and program behavior are 229 same between IPv4 and IPv6 mtrace2. While the original IPv4 230 multicast traceroute, mtrace, the query and response messages are 231 implemented as IGMP messages [10], all mtrace2 messages are carried 232 on UDP. The packet formats of IPv4 and IPv6 mtrace2 are different 233 because of the different address families, but the syntax is similar. 235 2. Terminology 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 238 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 239 this document are to be interpreted as described in RFC 2119 [1]. 241 Since multicast traceroutes flow in the opposite direction to the 242 data flow, we refer to "upstream" and "downstream" with respect to 243 data, unless explicitly specified. 245 Incoming interface: 246 The interface on which traffic is expected from the specified source 247 and group. 249 Outgoing interface: 250 The interface on which traffic is forwarded from the specified source 251 and group toward the destination. It is the interface on which the 252 mtrace2 Query or Request was received. 254 Previous-hop router: 255 The router that is on the link attached to the Incoming interface and 256 is responsible for forwarding traffic for the specified source and 257 group. 259 Last-hop router: 260 The router that is on the link attached to the Outgoing interface and 261 receives the mtrace2 Query from the adjacent mtrace2 client. 263 Group state: 264 It is the state in which a shared-tree protocol (e.g., PIM-SM [6]) 265 running on a router chooses the previous-hop router toward the core 266 router or Rendezvous Point (RP) as its parent router. In this state, 267 source-specific state is not available for the corresponding 268 multicast address on the router. 270 Source-specific state: 271 It is the state in which a routing protocol running on a router 272 chooses the path that would be followed for a source-specific join. 274 ALL-[protocol]-ROUTERS.MCAST.NET: 275 It is a dedicated multicast address for a multicast router to 276 communicate with other routers that are working with the same routing 277 protocol. For instance, the address of ALL-PIM-ROUTERS.MCAST.NET [6] 278 is '224.0.0.13' for IPv4 and 'ff02::d' for IPv6. 280 3. Overview 282 Given a multicast distribution tree, tracing from a source to a 283 multicast destination is hard, since you do not know down which 284 branch of the multicast tree the destination lies. This means that 285 you have to flood the whole tree to find the path from one source to 286 one destination. However, walking up the tree from destination to 287 source is easy, as most existing multicast routing protocols know the 288 previous hop for each source. Tracing from destination to source can 289 involve only routers on the direct path. 291 The party requesting the multicast traceroute sends a traceroute 292 Query packet to the last-hop multicast router for the given multicast 293 address. The last-hop router turns the Query into a Request packet 294 by changing the packet type and adding a response data block 295 containing its interface addresses and packet statistics, and then 296 forwards the Request packet via unicast to the router that the last- 297 hop router believes is the proper previous hop for the given source 298 and group. Each hop adds its response data to the end of the Request 299 packet, then unicast forwards it to the previous hop. The first-hop 300 router (the router that believes that packets from the source 301 originate on one of its directly connected networks) changes the 302 packet type to indicate a Reply packet and sends the completed Reply 303 to the mtrace2 client address specified in the Query header. The 304 Reply may be returned before reaching the first-hop router if a fatal 305 error condition such as "no route" is encountered along the path or 306 hop count is exceeded. 308 Multicast traceroute uses any information available to it in the 309 router to attempt to determine a previous hop to forward the trace 310 towards. Multicast routing protocols vary in the type and amount of 311 state they keep; multicast traceroute endeavors to work with all of 312 them by using whatever is available. For example, if a PIM-SM router 313 is on the (*,G) tree, it chooses the parent towards the RP as the 314 previous hop. In these cases, no source/group-specific state is 315 available, but the path may still be traced. 317 4. Packet Formats 319 The mtrace2 message is carried as a UDP packet. The destination 320 address of mtrace2 Query messages is either the last-hop router 321 unicast address or multicast address if the mtrace2 client does not 322 know the proper last-hop router address. The destination address of 323 mtrace2 Report messages is the address specified in Previous-Hop 324 Router Address field in the last appended mtrace2 Standard Response 325 Block, which is either the previous-hop router unicast address or 326 multicast address. Detailed in Section 9.3. 328 Mtrace2 message is encoded in TLV format. If an implementation 329 receives a TLV whose length exceeds the TLV length specified in the 330 Length field, the TLV SHOULD be accepted but any additional data 331 SHOULD be ignored. If an implementation receives a TLV whose type 332 value is unknown, the mtrace2 message SHOULD be ignored and silently 333 dropped. 335 4.1. Mtrace2 TLV format 337 0 1 2 3 338 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 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Type | Length | Value .... | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Type (8 bits) 345 Length (16 bits) 347 Value (variable length) 349 4.2. Defined TLVs 351 The following TLV Types are defined: 353 Code Type 354 ====== ====================================== 355 1 Mtrace2 Query 356 2 Mtrace2 Request 357 3 Mtrace2 Reply 358 4 Mtrace2 Standard Response Block 359 5 Mtrace2 Augmented Response Block 361 An mtrace2 message MUST contain exactly one Mtrace2 Query header. A 362 multicast router that sends an mtrace2 Request or Reply message MUST 363 add one mtrace2 Standard Response block to given mtrace2 message but 364 MUST NOT add multiple mtrace2 Standard Response blocks to it. A 365 multicast router that adds one mtrace2 Standard Response block to 366 given mtrace2 message MAY append one or multiple Augmented Response 367 blocks. 369 The TLV type field is defined to be "0x1" and "0x2" for mtrace2 370 Queries and Requests, respectively. An mtrace2 message containing 371 the type "0x1" is an mtrace2 Query. It is sent by an mtrace2 querier 372 (i.e., an mtrace2 client). It is changed to "0x2" by the proper 373 last-hop router. The type field is changed to "0x3" when the packet 374 is completed and sent as an mtrace2 Reply from the first-hop router 375 to the querier. 377 5. Mtrace2 Query Header 379 The mtrace2 supports both IPv4 and IPv6. If the mtrace2 Query or 380 Reply arrives in an IPv4 packet, all addresses specified in the 381 mtrace2 messages must be with IPv4 addresses. 383 The mtrace2 message is carried as a UDP packet. The UDP source port 384 is uniquely selected by the local host operating system. The UDP 385 destination port is the IANA reserved mtrace2 port number (see 386 Section 13). The UDP checksum MUST be valid in mtrace2 messages. 388 The mtrace2 message includes the common mtrace2 Query header as 389 follows. The header is only filled in by the originator of the 390 mtrace2 Query; intermediate routers MUST NOT modify any of the 391 fields. 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+ 396 | # hops | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | | 399 | Multicast Address | 400 | | 401 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 402 | | 403 | Source Address | 404 | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | | 407 | Mtrace2 Client Address | 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Query ID | Client Port # | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 1 415 5.1. # hops: 8 bits 417 This field specifies the maximum number of hops that the mtrace2 418 client wants to trace. If there is some error condition in the 419 middle of the path that prevents an mtrace2 Reply from being received 420 by the client, the client issues another mtrace2 Query with the lower 421 number of hops until it receives a Reply from the first-hop router. 423 5.2. Multicast Address 425 This field specifies the 32 bits length IPv4 or 128 bits length IPv6 426 multicast address to be traced, or is filled with "all 1" in case of 427 IPv4 or with the unspecified address (::) in case of IPv6 if no 428 group-specific information is desired. Note that non-group-specific 429 mtrace2 MUST specify source address. 431 5.3. Source Address 433 This field specifies the 32 bits length IPv4 or 128 bits length IPv6 434 address of the multicast source for the path being traced, or is 435 filled with "all 1" in case of IPv4 or with the unspecified address 436 (::) in case of IPv6 if no source-specific information such as a 437 trace for RPT in PIM-SM is desired. Note that non-source-specific 438 traceroutes may not be possible with certain multicast routing 439 protocols. 441 5.4. Mtrace2 Client Address 443 This field specifies the 32 bits length IPv4 or 128 bits length IPv6 444 global address of the mtrace2 client. The trace starts at this 445 client address and proceeds toward the traffic source. 447 5.5. Query ID: 16 bits 449 This field is used as a unique identifier for this mtrace2 Request so 450 that duplicate or delayed Replies may be detected. 452 5.6. Client Port # 454 Mtrace2 Reply is sent back to the address specified in an Mtrace2 455 Client Address field. This field specifies the UDP port number the 456 router will send Mtrace2 Reply. This client port number MUST NOT be 457 changed by any router. 459 6. IPv4 Mtrace2 Standard Response Block 461 Each intermediate IPv4 router in a trace path appends "response data 462 block" to the forwarded trace packet. The standard response data 463 block looks as follows. 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+ 468 | MBZ | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Query Arrival Time | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Incoming Interface Address | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Outgoing Interface Address | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Previous-Hop Router Address | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | | 479 . Input packet count on incoming interface . 480 | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | 483 . Output packet count on outgoing interface . 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 . Total number of packets for this source-group pair . 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Rtg Protocol | Multicast Rtg Protocol | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Fwd TTL | MBZ |S| Src Mask |Forwarding Code| 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 6.1. MBZ: 8 bit 497 Must be zeroed on transmission and ignored on reception. 499 6.2. Query Arrival Time: 32 bits 501 The Query Arrival Time is a 32-bit NTP timestamp specifying the 502 arrival time of the mtrace2 Request packet at this router. The 32- 503 bit form of an NTP timestamp consists of the middle 32 bits of the 504 full 64-bit form; that is, the low 16 bits of the integer part and 505 the high 16 bits of the fractional part. 507 The following formula converts from a UNIX timeval to a 32-bit NTP 508 timestamp: 510 query_arrival_time 511 = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec << 10) / 15625) 513 The constant 32384 is the number of seconds from Jan 1, 1900 to Jan 514 1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 15625) is a 515 reduction of ((tv.tv_usec / 100000000) << 16). 517 However, mtrace2 does not require synchronizing NTP timestamp among 518 all routers along paths to measure one-way latency. The use of Query 519 Arrival Time is useful to measure the packets per second (PPS). 520 Suppose that a client issues two queries Q1 and Q2, and the 521 corresponding requests R1 and R2 arrive at router X at t1 and t2, 522 then the client would be able to calculate the PPS at router X by 523 using the packet count results at t1 and t2. 525 6.3. Incoming Interface Address: 32 bits 527 This field specifies the address of the interface on which packets 528 from this source and group are expected to arrive, or 0 if unknown or 529 unnumbered. 531 6.4. Outgoing Interface Address: 32 bits 533 This field specifies the address of the interface on which packets 534 from this source and group flow to the specified destination, or 0 if 535 unknown or unnumbered. 537 6.5. Previous-Hop Router Address: 32 bits 539 This field specifies the router from which this router expects 540 packets from this source. This may be a multicast group (e.g. ALL- 541 [protocol]-ROUTERS.MCAST.NET) if the previous hop is not known 542 because of the workings of the multicast routing protocol. However, 543 it should be 0 if the incoming interface address is unknown or 544 unnumbered. 546 6.6. Input packet count on incoming interface: 64 bits 548 This field contains the number of multicast packets received for all 549 groups and sources on the incoming interface, or "all 1" if no count 550 can be reported. This counter may have the same value as 551 ifHCInMulticastPkts from the IF-MIB [12] for this interface. 553 6.7. Output packet count on outgoing interface: 64 bits 555 This field contains the number of multicast packets that have been 556 transmitted or queued for transmission for all groups and sources on 557 the outgoing interface, or "all 1" if no count can be reported. This 558 counter may have the same value as ifHCOutMulticastPkts from the IF- 559 MIB for this interface. 561 6.8. Total number of packets for this source-group pair: 64 bits 563 This field counts the number of packets from the specified source 564 forwarded by this router to the specified group, or "all 1" if no 565 count can be reported. If the S bit is set, the count is for the 566 source network, as specified by the Src Mask field. If the S bit is 567 set and the Src Mask field is 63, indicating no source-specific 568 state, the count is for all sources sending to this group. This 569 counter should have the same value as ipMcastRoutePkts from the 570 IPMROUTE-STD-MIB [13] for this forwarding entry. 572 6.9. Rtg Protocol: 16 bits 574 This field describes the routing protocol used to decide an RPF 575 interface for the requested source. This value should have the same 576 value as ipMcastRouteRtProtocol from the IPMROUTE-STD-MIB [13] for 577 this entry. If the router is not able to obtain this value, "all 0" 578 must be specified. 580 6.10. Multicast Rtg Protocol: 16 bits 582 This field describes the multicast routing protocol in use between 583 this router and the previous-hop router. This value should have the 584 same value as ipMcastRouteProtocol from the IPMROUTE-STD-MIB [13] for 585 this entry. If the router does not able to obtain this value, "all 586 0" must be specified. 588 6.11. Fwd TTL: 8 bits 590 This field contains the TTL that a packet is required to have before 591 it will be forwarded over the outgoing interface. 593 6.12. S: 1 bit 595 This S bit indicates that the packet count for the source-group pair 596 is for the source network, as determined by masking the source 597 address with the Src Mask field. 599 6.13. Src Mask: 7 bits 601 This field contains the number of 1's in the netmask this router has 602 for the source (i.e. a value of 24 means the netmask is 0xffffff00). 603 If the router is forwarding solely on group state, this field is set 604 to 127 (0x7f). 606 6.14. Forwarding Code: 8 bits 608 This field contains a forwarding information/error code. Section 9.2 609 explains how and when the forwarding code is filled. Defined values 610 are as follows; 612 Value Name Description 614 ----- -------------- ------------------------------------------- 616 0x00 NO_ERROR No error 618 0x01 WRONG_IF Mtrace2 Request arrived on an interface 619 to which this router would not forward for 620 this source, group, destination. 622 0x02 PRUNE_SENT This router has sent a prune upstream which 623 applies to the source and group in the 624 mtrace2 Request. 626 0x03 PRUNE_RCVD This router has stopped forwarding for this 627 source and group in response to a request 628 from the next hop router. 630 0x04 SCOPED The group is subject to administrative 631 scoping at this hop. 633 0x05 NO_ROUTE This router has no route for the source or 634 group and no way to determine a potential 635 route. 637 0x06 WRONG_LAST_HOP This router is not the proper last-hop 638 router. 640 0x07 NOT_FORWARDING This router is not forwarding this source, 641 group out the outgoing interface for an 642 unspecified reason. 644 0x08 REACHED_RP Reached Rendezvous Point or Core 646 0x09 RPF_IF Mtrace2 Request arrived on the expected 647 RPF interface for this source and group. 649 0x0A NO_MULTICAST Mtrace2 Request arrived on an interface 650 which is not enabled for multicast. 652 0x0B INFO_HIDDEN One or more hops have been hidden from this 653 trace. 655 0x0C REACHED_GW Mtrace2 Request arrived on a gateway (e.g., 656 a NAT or firewall) that hides the 657 information between this router and the 658 mtrace2 querier 660 0x81 NO_SPACE There was not enough room to insert another 661 response data block in the packet. 663 0x82 ADMIN_PROHIB Mtrace2 is administratively prohibited. 665 Note that if a router discovers there is not enough room in a packet 666 to insert its response, it puts the NO_SPACE code value in the 667 previous router's Forwarding Code field, overwriting any error the 668 previous router placed there. After the router sends the Reply to 669 the Mtrace2 Client Address in the header, the router continues the 670 mtrace2 Query by sending an mtrace2 Request containing the same 671 mtrace2 Query header. Section 9.3 and Section 10.8 include the 672 details. 674 The 0x80 bit of the Forwarding Code is used to indicate a fatal 675 error. A fatal error is one where the router may know the previous 676 hop but cannot forward the message to it. 678 7. IPv6 Mtrace2 Standard Response Block 680 Each intermediate IPv6 router in a trace path appends "response data 681 block" to the forwarded trace packet. The standard response data 682 block looks as follows. 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+ 687 | MBZ | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Query Arrival Time | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Incoming Interface ID | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Outgoing Interface ID | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | | 696 * Local Address * 697 | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | | 700 * Remote Address * 701 | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | | 704 . Input packet count on incoming interface . 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | | 708 . Output packet count on outgoing interface . 709 | | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | | 712 . Total number of packets for this source-group pair . 713 | | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Rtg Protocol | Multicast Rtg Protocol | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | MBZ |S|Src Prefix Len |Forwarding Code| 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 7.1. MBZ: 8 bit 722 Must be zeroed on transmission and ignored on reception. 724 7.2. Query Arrival Time: 32 bits 726 Same definition described in Section 6.2 728 7.3. Incoming Interface ID: 32 bits 730 This field specifies the interface ID on which packets from this 731 source and group are expected to arrive, or 0 if unknown. This ID 732 should be the value taken from InterfaceIndex of the IF-MIB [12] for 733 this interface. This field is carried in network byte order. 735 7.4. Outgoing Interface ID: 32 bits 737 This field specifies the interface ID on which packets from this 738 source and group flow to the specified destination, or 0 if unknown. 739 This ID should be the value taken from InterfaceIndex of the IF-MIB 740 for this interface. This field is carried in network byte order. 742 7.5. Local Address 744 This field specifies a global IPv6 address that uniquely identifies 745 the router. A unique local unicast address [11] SHOULD NOT be used 746 unless the router is only assigned link-local and unique local 747 addresses. If the router is only assigned link-local addresses, its 748 link-local address can be specified in this field. 750 7.6. Remote Address 752 This field specifies the address of the previous-hop router, which, 753 in most cases, is a link-local unicast address for the queried source 754 and destination addresses. 756 Although a link-local address does not have enough information to 757 identify a node, it is possible to detect the previous-hop router 758 with the assistance of Incoming Interface ID and the current router 759 address (i.e., Local Address). 761 This may be a multicast group (e.g., ALL-[protocol]- 762 ROUTERS.MCAST.NET) if the previous hop is not known because of the 763 workings of the multicast routing protocol. However, it should be 764 the unspecified address (::) if the incoming interface address is 765 unknown. 767 7.7. Input packet count on incoming interface 769 Same definition described in Section 6.6 771 7.8. Output packet count on outgoing interface 773 Same definition described in Section 6.7 775 7.9. Total number of packets for this source-group pair 777 This field counts the number of packets from the specified source 778 forwarded by this router to the specified group, or "all 1" if no 779 count can be reported. If the S bit is set, the count is for the 780 source network, as specified by the Src Prefix Len field. If the S 781 bit is set and the Src Prefix Len field is 255, indicating no source- 782 specific state, the count is for all sources sending to this group. 783 This counter should have the same value as ipMcastRoutePkts from the 784 IPMROUTE-STD-MIB for this forwarding entry. 786 7.10. Rtg Protocol: 16 bits 788 Same definition described in Section 6.9 790 7.11. Multicast Rtg Protocol: 16 bits 792 Same definition described in Section 6.10 794 7.12. S: 1 bit 796 This S bit indicates that the packet count for the source-group pair 797 is for the source network, as determined by masking the source 798 address with the Src Prefix Len field. 800 7.13. Src Prefix Len: 8 bits 802 This field contains the prefix length this router has for the source. 803 If the router is forwarding solely on group state, this field is set 804 to 255 (0xff) 806 7.14. Forwarding Code: 8 bits 808 Same definition described in Section 6.14 810 8. Mtrace2 Augmented Response Block 812 In addition to the standard response block, a multicast router on the 813 path will be able to add "augumented response block" when it sends 814 the mtrace2 Request to its upstream router or sends the Reply to the 815 Mtrace2 Client Address. This augmented response block is flexible to 816 add various information. 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+ 821 | MBZ | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Type | Value .... | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 The augmented response block is always appended to mtrace2 TLV header 827 (0x04). The 16 bits Type filed of the augmented response block is 828 defined for various purposes, such as diagnosis (as in Section 12) 829 and protocol verification. The packet length of the augmented 830 response block is specified in the augmented response block TLV 831 header as seen in Section 4.1. 833 The following augmented response block type is defined: 835 Code Type 836 ====== ================================================= 837 0x01 # Mtrace2 Standard Response Blocks Returned 839 When the NO_SPACE error occurs, the router sends back the mtrace2 840 Reply with contained data (i.e., all appended response blocks), and 841 continues the mtrace2 Query by sending an mtrace2 Request as will be 842 described in Section 9.3. In this mtrace2 Request, the router 843 appends the augmented response block with the code "0x01" and the 844 number of returned mtrace2 response blocks. Every router between 845 this router and the first-hop router can recognize the limit number 846 of hops by referring this number and the # hops in the header. 848 This document only defines the above augmented response block type 849 and does not define other augmented response block types. Specifing 850 how to deal with diagnosis information will be also described in 851 separate documents. 853 9. Router Behavior 855 All of these actions are performed in addition to (NOT instead of) 856 forwarding the packet, if applicable. E.g. a multicast packet that 857 has TTL or the hop limit remaining MUST be forwarded normally, as 858 MUST a unicast packet that has TTL or the hop limit remaining and is 859 not addressed to this router. 861 9.1. Receiving Mtrace2 Query 863 An mtrace2 Query message is an mtrace2 message with no response 864 blocks filled in, and uses TLV type 0x1 for IPv4 and IPv6 mtrace2. 866 9.1.1. Packet Verification 868 Upon receiving an mtrace2 Query message, a router must examine the 869 Query to see if it is the proper last-hop router for the destination 870 address in the packet. It is the proper last-hop router if it has a 871 multicast-capable interface on the same subnet as the Mtrace2 Client 872 Address and is the router that would forward traffic from the given 873 (S,G) or (*,G) onto that subnet. 875 If the router determines that it is not the proper last-hop router, 876 or it cannot make that determination, it does one of two things 877 depending if the Query was received via multicast or unicast. If the 878 Query was received via multicast, then it MUST be silently dropped. 879 If it was received via unicast, a forwarding code of WRONG_LAST_HOP 880 is noted and processing continues as in Section 9.2. 882 Duplicate Query messages as identified by the tuple (Mtrace2 Client 883 Address, Query ID) SHOULD be ignored. This MAY be implemented using 884 a simple 1-back cache (i.e. remembering the Mtrace2 Client Address 885 and Query ID of the previous Query message that was processed, and 886 ignoring future messages with the same Mtrace2 Client Address and 887 Query ID). Duplicate Request messages MUST NOT be ignored in this 888 manner. 890 9.1.2. Normal Processing 892 When a router receives an mtrace2 Query and it determines that it is 893 the proper last-hop router, it it changes the TLV type to 0x2 and 894 treats it like an mtrace2 Request and performs the steps listed in 895 Section 9.2. 897 9.1.3. Mtrace2 Query Received by Non-Supported Router 899 When a router that does not support mtrace2 receives an mtrace2 Query 900 message whose destination address is multicast, the router will 901 silently discard the message. When the router receives an mtrace2 902 Query message whose destination address is the router's interface 903 address, the router returns an ICMP Port unreachable to the Mtrace2 904 Client Address. 906 9.2. Receiving Mtrace2 Request 908 An mtrace2 Request is a traceroute message with some number of 909 response blocks filled in, and uses TLV type 0x2 for IPv4 and IPv6 910 mtrace2. 912 9.2.1. Packet Verification 914 If the mtrace2 Request does not come from an adjacent host or router, 915 it MUST be silently ignored. If the mtrace2 Request is not addressed 916 to this router, or if the Request is addressed to a multicast group 917 which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3] 918 for IPv6), it MUST be silently ignored. GTSM [14] SHOULD be used by 919 the router to determine whether the host or router is adjacent or 920 not. 922 9.2.2. Normal Processing 924 When a router receives an mtrace2 Request, it performs the following 925 steps. Note that it is possible to have multiple situations covered 926 by the Forwarding Codes. The first one encountered is the one that 927 is reported, i.e. all "note forwarding code N" should be interpreted 928 as "if forwarding code is not already set, set forwarding code to N". 930 1. If there is room in the current buffer (or the router can 931 efficiently allocate more space to use), insert a new response 932 block into the packet and fill in the Query Arrival Time, 933 Outgoing Interface Address (for IPv4 mtrace2) or Outgoing 934 Interface ID (for IPv6 mtrace2), Output Packet Count, and Fwd 935 TTL (for IPv4 mtrace2). If there was no room, fill in the 936 forwarding code "NO_SPACE" in the *previous* hop's response 937 block, and forward the packet to the address specified in the 938 Mtrace2 Client Address field and continue the trace as described 939 in Section 9.3. 941 2. Attempt to determine the forwarding information for the source 942 and group specified, using the same mechanisms as would be used 943 when a packet is received from the source destined for the 944 group. A state need not be instantiated, it can be "phantom" 945 state created only for the purpose of the trace, such as "dry- 946 run". 948 If using a shared-tree protocol and there is no source-specific 949 state, or if no source-specific information is desired (i.e., 950 "all 1" for IPv4 or unspecified address (::) for IPv6), group 951 state should be used. If there is no group state or no group- 952 specific information is desired, potential source state (i.e., 953 the path that would be followed for a source-specific Join) 954 should be used. If this router is the Core or RP and no source- 955 specific state is available (e.g., this router has been 956 receiving PIM Register messages from the first-hop router), note 957 a code of REACHED_RP. 959 3. If no forwarding information can be determined, the router notes 960 a forwarding code of NO_ROUTE, sets the remaining fields that 961 have not yet been filled in to zero, and then forwards the 962 packet to the mtrace2 client as described in Section 9.3. 964 4. Fill in the Incoming Interface Address, Previous-Hop Router 965 Address, Input Packet Count, Total Number of Packets, Routing 966 Protocol, S, and Src Mask from the forwarding information that 967 was determined. 969 5. If mtrace2 is administratively prohibited, note the appropriate 970 forwarding code (ADMIN_PROHIB). If mtrace2 is administratively 971 prohibited and any of the fields as filled in step 4 are 972 considered private information, zero out the applicable fields. 973 Then the packet is forwarded to the mtrace2 client as described 974 in Section 9.3. 976 6. If the reception interface is not enabled for multicast, note 977 forwarding code NO_MULTICAST. If the reception interface is the 978 interface from which the router would expect data to arrive from 979 the source, note forwarding code RPF_IF. Otherwise, if the 980 reception interface is not one to which the router would forward 981 data from the source to the group, a forwarding code of WRONG_IF 982 is noted. 984 7. If the group is subject to administrative scoping on either the 985 Outgoing or Incoming interfaces, a forwarding code of SCOPED is 986 noted. 988 8. If this router is the Rendezvous Point or Core for the group, a 989 forwarding code of REACHED_RP is noted. 991 9. If this router has sent a prune upstream which applies to the 992 source and group in the mtrace2 Request, it notes forwarding 993 code PRUNE_SENT. If the router has stopped forwarding 994 downstream in response to a prune sent by the next hop router, 995 it notes forwarding code PRUNE_RCVD. If the router should 996 normally forward traffic for this source and group downstream 997 but is not, it notes forwarding code NOT_FORWARDING. 999 10. If this router is a gateway (e.g., a NAT or firewall) that hides 1000 the information between this router and the mtrace2 querier, it 1001 notes forwarding code REACHED_GW. 1003 11. The packet is then sent on to the previous hop or the Mtrace2 1004 Client Address as described in Section 9.3. 1006 9.2.3. Mtrace2 Request Received by Non-Supported Router 1008 When a router that does not understand mtrace2 Request messages 1009 receives an mtrace2 Request message whose destination address is 1010 multicast, the router will silently discard the message. When the 1011 router receives an mtrace2 Request message whose destination address 1012 is the router's interface address, the router returns an ICMP Port 1013 unreachable to the Mtrace2 Client Address, and the mtrace2 client may 1014 then issue another mtrace2 Query with the lower number of # hops. 1016 9.3. Forwarding Mtrace2 Request 1018 9.3.1. Destination Address 1020 If the Previous-hop router for the mtrace2 Request is known for this 1021 request and the number of response blocks is less than the number 1022 requested (i.e., the "# hops" field in the mtrace2 Query header), the 1023 packet is sent to that router. If the Incoming Interface is known 1024 but the Previous-hop router is not known, the packet is sent to an 1025 appropriate multicast address on the Incoming Interface. The 1026 appropriate multicast address may depend on the routing protocol in 1027 use, MUST be a link-scoped group (i.e. 224/24 for IPv4, FF02::/16 for 1028 IPv6), MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 and All 1029 Nodes Address (FF02::1) for IPv6, and MAY be ALL-ROUTERS.MCAST.NET 1030 (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6 if the 1031 routing protocol in use does not define a more appropriate group. 1032 Otherwise, it is sent to the Mtrace2 Client Address in the header. 1034 9.3.2. Source Address 1036 An mtrace2 Request should be sent with the address of the router's 1037 reception interface. However, if the router's interface address is 1038 unnumbered, the router can use one of its numbered interface address 1039 as the source address. 1041 When the REACHED_GW code is noted, the router sends back the mtrace2 1042 Reply as in Section 9.4. In addition to that, it must continue the 1043 mtrace2 Query by proxying the original querier as in Section 9.5. 1045 When the NO_SPACE error occurs, the router sends back the mtrace2 1046 Reply with contained data and the NO_SPACE error code as in 1047 Section 9.4, and continues the mtrace2 Query by sending an mtrace2 1048 Request containing the same mtrace2 Query header and its standard and 1049 augmented response blocks. The corresponding augmented response 1050 block type is "# Mtrace2 Response Blocks Returned" described in 1051 Section 8. 1053 9.4. Sending Mtrace2 Reply 1055 9.4.1. Destination Address 1057 An mtrace2 Reply must be sent to the address specified in the Mtrace2 1058 Client Address field in the mtrace2 Query header. 1060 9.4.2. Source Address 1062 An mtrace2 Reply should be sent with the address of the router's 1063 reception interface. However, if the router's interface address is 1064 unnumbered, the router can use one of its numbered interface address 1065 as the source address. 1067 9.5. Proxying Mtrace2 Query 1069 When a gateway (e.g., a NAT or firewall) that needs to block unicast 1070 packets to the mtrace2 querier or hide information between the 1071 gateway and the mtrace2 querier receives mtrace2 Query from an 1072 adjacent host or mtrace2 Request from an adjacent router, it sends 1073 back the mtrace2 Reply with contained data and the REACHED_GW code to 1074 the address specified in the Mtrace2 Client Address field in the 1075 mtrace2 Query header. 1077 At the same time, the gateway prepares a new mtrace2 Query message. 1078 The gateway uses the original mtrace2 Query header as the base for 1079 the new mtrace2 Query; it sets the Mtrace2 Client Address to its 1080 Incoming Interface address and the Client Port # to its own port 1081 (which may be the same as the mtrace2 port as the gateway is 1082 listening on that port), and decreases # hops according to the number 1083 of standard response blocks in the returned mtrace2 Reply from the 1084 gateway. The mtrace2 Query message is sent to the previous-hop 1085 router or to an appropriate multicast address on the Incoming 1086 Interface. 1088 When the gateway receives the mtrace2 Reply from the first-hop router 1089 or any intermediate router, it MUST forward the mtrace2 Reply back to 1090 the mtrace2 querier with the original mtrace2 Query header. 1092 9.6. Hiding Information 1094 Information about a domain's topology and connectivity may be hidden 1095 from mtrace2 Requests. The INFO_HIDDEN forwarding code may be used 1096 to note that, for example, the incoming interface address and packet 1097 count are for the entrance to the domain and the outgoing interface 1098 address and packet count are the exit from the domain by specifying 1099 "all 1". The source-group packet count (Section 6.8 and Section 7.9) 1100 is from router, but may be "all 1" if it is hidden. 1102 10. Client Behavior 1104 10.1. Sending Mtrace2 Query 1106 10.1.1. Destination Address 1108 Mtrace2 Query packet can be sent to the ALL-ROUTERS.MCAST.NET 1109 (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6. This 1110 will ensure that the packet is received by the last-hop router on the 1111 subnet. Otherwise, if the proper last-hop router is known for the 1112 mtrace2 destination, the Query is unicasted to that router. 1114 See also Section 10.4 on determining the last-hop router. 1116 10.1.2. Source Address 1118 An mtrace2 Query must be sent with the address of the mtrace2 1119 querier's reception interface, which would be the Mtrace2 Client 1120 Address. 1122 10.2. Determining the Path 1124 The client could send a small number of initial query messages with a 1125 large "# hops" field, in order to try to trace the full path. If 1126 this attempt fails, one strategy is to perform a linear search (as 1127 the traditional unicast traceroute program does); set the "# hops" 1128 field to 1 and try to get a Reply, then 2, and so on. If no Reply is 1129 received at a certain hop, the hop count can continue past the non- 1130 responding hop, in the hopes that further hops may respond. These 1131 attempts should continue until a user-defined timeout has occurred. 1133 See also Section 10.6 on receiving the results of a trace. 1135 10.3. Collecting Statistics 1137 After a client has determined that it has traced the whole path or as 1138 much as it can expect to (see Section 10.7), it might collect 1139 statistics by waiting a short time and performing a second trace. If 1140 the path is the same in the two traces, statistics can be displayed 1141 as described in Section 12.3 and Section 12.4. 1143 10.4. Last Hop Router 1145 The mtrace2 querier may not know which is the last-hop router, or 1146 that router may be behind a firewall that blocks unicast packets but 1147 passes multicast packets. In these cases, the mtrace2 Request should 1148 be multicasted to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All 1149 Routers Address (FF02::2) for IPv6. All routers except the correct 1150 last-hop router SHOULD ignore any mtrace2 Request received via 1151 multicast. 1153 10.5. First Hop Router 1155 The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default 1156 multicast group for old IPv4 mtrace (v1) responses, in order to 1157 support mtrace queriers that are not unicast reachable from the 1158 first-hop router. However, mtrace2 does not reserve any IPv4/IPv6 1159 multicast addresses for mtrace2 Replies. Every mtrace2 Reply is sent 1160 to the unicast address specified in the Mtrace2 Client Address field 1161 of the mtrace2 Query header. 1163 10.6. Broken Intermediate Router 1165 A broken intermediate router might simply not understand mtrace2 1166 packets, and drop them. The querier would then get no Reply at all 1167 from its mtrace2 Requests. It should then perform a hop-by-hop 1168 search by setting the number of hops field until it gets a Reply 1169 (both linear and binary search are options, but binary is likely to 1170 be slower because a failure requires waiting for a timeout). 1172 10.7. Mtrace2 Termination 1174 When performing an expanding hop-by-hop trace, it is necessary to 1175 determine when to stop expanding. 1177 10.7.1. Arriving at source 1179 A trace can be determined to have arrived at the source if the 1180 Incoming Interface of the last router in the trace is non-zero, but 1181 the Previous-hop router is zero. 1183 10.7.2. Fatal error 1185 A trace has encountered a fatal error if the last Forwarding Error in 1186 the trace has the 0x80 bit set. 1188 10.7.3. No previous hop 1190 A trace can not continue if the last Previous-hop in the trace is set 1191 to 0. 1193 10.7.4. Traceroute shorter than requested 1195 If the trace that is returned is shorter than requested (i.e. the 1196 number of response blocks is smaller than the "# hops" field), the 1197 trace encountered an error and could not continue. 1199 10.8. Continuing after an error 1201 When the NO_SPACE error occurs, as described in Section 9.3, the 1202 multicast routers sends back the mtrace2 Reply to the address 1203 specified in the Mtrace2 Client Address field in the mtrace2 Query 1204 header. In this case, the mtrace2 client may receive multiple 1205 mtrace2 Replies from different routers (along the path). After the 1206 client receives multiple mtrace2 Reply messages, it integrates (i.e. 1207 constructs) them as a single mtrace2 Reply message. 1209 If a trace times out, it is likely to be because a router in the 1210 middle of the path does not support mtrace2. That router's address 1211 will be in the Previous-hop router field of the last entry in the 1212 last response packet received. A client may be able to determine 1213 (via mrinfo or SNMP [11][13]) a list of neighbors of the non- 1214 responding router. If desired, each of those neighbors could be 1215 probed to determine the remainder of the path. Unfortunately, this 1216 heuristic may end up with multiple paths, since there is no way of 1217 knowing what the non-responding router's algorithm for choosing a 1218 previous-hop router is. However, if all paths but one flow back 1219 towards the non-responding router, it is possible to be sure that 1220 this is the correct path. 1222 11. Protocol-Specific Considerations 1224 11.1. PIM-SM 1226 When an mtrace2 reaches a PIM-SM RP and the RP does not forward the 1227 trace on, it means that the RP has not performed a source-specific 1228 join so there is no more state to trace. However, the path that 1229 traffic would use if the RP did perform a source-specific join can be 1230 traced by setting the trace destination to the RP, the trace source 1231 to the traffic source, and the trace group to 0. This trace Query 1232 may be unicasted to the RP. 1234 11.2. Bi-Directional PIM 1236 Bi-directional PIM [7] is a variant of PIM-SM that builds bi- 1237 directional shared trees connecting multicast sources and receivers. 1238 Along the bi-directional shared trees, multicast data is natively 1239 forwarded from sources to the RPA (Rendezvous Point Address) and from 1240 the RPA to receivers without requiring source-specific state. In 1241 contrast to PIM-SM, RP always has the state to trace. 1243 A Designated Forwarder (DF) for a given RPA is in charge of 1244 forwarding downstream traffic onto its link, and forwarding upstream 1245 traffic from its link towards the RPL (Rendezvous Point Link) that 1246 the RPA belongs to. Hence mtrace2 reports DF addresses or RPA along 1247 the path. 1249 11.3. PIM-DM 1251 Routers running PIM Dense Mode [15] do not know the path packets 1252 would take unless traffic is flowing. Without some extra protocol 1253 mechanism, this means that in an environment with multiple possible 1254 paths with branch points on shared media, mtrace2 can only trace 1255 existing paths, not potential paths. When there are multiple 1256 possible paths but the branch points are not on shared media, the 1257 previous hop router is known, but the last-hop router may not know 1258 that it is the appropriate last hop. 1260 When traffic is flowing, PIM Dense Mode routers know whether or not 1261 they are the last-hop forwarder for the link (because they won or 1262 lost an Assert battle) and know who the previous hop is (because it 1263 won an Assert battle). Therefore, mtrace2 is always able to follow 1264 the proper path when traffic is flowing. 1266 11.4. IGMP/MLD Proxy 1268 When an mtrace2 Query packet reaches an incoming interface of IGMP/ 1269 MLD Proxy [8], it puts a WRONG_IF (0x01) value in Forwarding Code of 1270 mtrace2 standard response block (as in Section 6.14) and sends the 1271 mtrace2 Reply back to the Mtrace2 Client Address. When an mtrace2 1272 Query packet reaches an outgoing interface of IGMP/MLD proxy, it is 1273 forwarded through its incoming interface towards the upstream router. 1275 11.5. AMT 1277 AMT [9] provides the multicast connectivity to the unicast-only 1278 inter-network. To do this, multicast packets being sent to or from a 1279 site are encapsulated in unicast packets. When an mtrace2 Query 1280 packet reaches an AMT pseudo-interface of an AMT gateway, the AMT 1281 gateway encapsulats it to a particular AMT relay reachable across the 1282 unicast-only infrastructure. Then the AMT relay decapsulates the 1283 mtrace2 Query packet and forwards the mtrace2 Request to the 1284 appropriate multicast router. 1286 12. Problem Diagnosis 1288 12.1. Forwarding Inconsistencies 1290 The forwarding error code can tell if a group is unexpectedly pruned 1291 or administratively scoped. 1293 12.2. TTL or Hop Limit Problems 1295 By taking the maximum of hops (from source + forwarding TTL (or hop 1296 limit) threshold) over all hops, it is possible to discover the TTL 1297 or hop limit required for the source to reach the destination. 1299 12.3. Packet Loss 1301 By taking two traces, it is possible to find packet loss information 1302 by comparing the difference in input packet counts to the difference 1303 in output packet counts for the specified source-group address pair 1304 at the previous hop. On a point-to-point link, any difference in 1305 these numbers implies packet loss. Since the packet counts may be 1306 changing as the mtrace2 Query is propagating, there may be small 1307 errors (off by 1 or 2 or more) in these statistics. However, these 1308 errors will not accumulate if multiple traces are taken to expand the 1309 measurement period. On a shared link, the count of input packets can 1310 be larger than the number of output packets at the previous hop, due 1311 to other routers or hosts on the link injecting packets. This 1312 appears as "negative loss" which may mask real packet loss. 1314 In addition to the counts of input and output packets for all 1315 multicast traffic on the interfaces, the response data includes a 1316 count of the packets forwarded by a node for the specified source- 1317 group pair. Taking the difference in this count between two traces 1318 and then comparing those differences between two hops gives a measure 1319 of packet loss just for traffic from the specified source to the 1320 specified receiver via the specified group. This measure is not 1321 affected by shared links. 1323 On a point-to-point link that is a multicast tunnel, packet loss is 1324 usually due to congestion in unicast routers along the path of that 1325 tunnel. On native multicast links, loss is more likely in the output 1326 queue of one hop, perhaps due to priority dropping, or in the input 1327 queue at the next hop. The counters in the response data do not 1328 allow these cases to be distinguished. Differences in packet counts 1329 between the incoming and outgoing interfaces on one node cannot 1330 generally be used to measure queue overflow in the node. 1332 12.4. Link Utilization 1334 Again, with two traces, you can divide the difference in the input or 1335 output packet counts at some hop by the difference in time stamps 1336 from the same hop to obtain the packet rate over the link. If the 1337 average packet size is known, then the link utilization can also be 1338 estimated to see whether packet loss may be due to the rate limit or 1339 the physical capacity on a particular link being exceeded. 1341 12.5. Time Delay 1343 If the routers have synchronized clocks, it is possible to estimate 1344 propagation and queuing delay from the differences between the 1345 timestamps at successive hops. However, this delay includes control 1346 processing overhead, so is not necessarily indicative of the delay 1347 that data traffic would experience. 1349 13. IANA Considerations 1351 The following new assignments can only be made via a Standards Action 1352 as specified in [4]. 1354 13.1. Forwarding Codes 1356 New Forwarding codes must only be created by an RFC that modifies 1357 this document's Section 10, fully describing the conditions under 1358 which the new forwarding code is used. The IANA may act as a central 1359 repository so that there is a single place to look up forwarding 1360 codes and the document in which they are defined. 1362 13.2. UDP Destination Port and IPv6 Address 1364 The IANA should allocate UDP destination port for multicast 1365 traceroute version 2 upon publication of the first RFC. 1367 14. Security Considerations 1369 14.1. Topology Discovery 1371 Mtrace2 can be used to discover any actively-used topology. If your 1372 network topology is a secret, mtrace2 may be restricted at the border 1373 of your domain, using the ADMIN_PROHIB forwarding code. 1375 14.2. Traffic Rates 1377 Mtrace2 can be used to discover what sources are sending to what 1378 groups and at what rates. If this information is a secret, mtrace2 1379 may be restricted at the border of your domain, using the 1380 ADMIN_PROHIB forwarding code. 1382 14.3. Limiting Query/Request Rates 1384 Routers should limit mtrace2 Queries and Requests by ignoring the 1385 received messages. Routers MAY randomly ignore the received messages 1386 to minimize the processing overhead, i.e., to keep fairness in 1387 processing queries. The rate limit is left to the router's 1388 implementation. 1390 15. Acknowledgements 1392 This specification started largely as a transcription of Van 1393 Jacobson's slides from the 30th IETF, and the implementation in 1394 mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve 1395 Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original 1396 multicast traceroute client, mtrace (version 1), has been implemented 1397 by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the 1398 "S" bit to allow statistics for a source subnet is due to Tom 1399 Pusateri. 1401 For the mtrace version 2 specification, extensive comments were 1402 received from Ronald Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Pekka 1403 Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, and Cao 1404 Wei. 1406 16. References 1408 16.1. Normative References 1410 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 1411 levels", RFC 2119, March 1997. 1413 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1414 Specification", RFC 2460, December 1998. 1416 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 1417 Architecture", RFC 2373, July 1998. 1419 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1420 Considerations Section in RFCs", RFC 2434, October 1998. 1422 [5] Braden, B., Borman, D., and C. Partridge, "Computing the 1423 Internet Checksum", RFC 1071, September 1988. 1425 [6] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1426 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1427 Protocol Specification (Revised)", RFC 4601, August 2006. 1429 [7] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1430 "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", 1431 RFC 5015, October 2007. 1433 [8] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 1434 Group Management Protocol (IGMP) / Multicast Listener Discovery 1435 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 1436 RFC 4605, August 2006. 1438 [9] Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T. 1439 Pusateri, "Automatic IP Multicast Without Explicit Tunnels 1440 (AMT)", draft-ietf-mboned-auto-multicast-08.txt (work in 1441 progress), October 2007. 1443 16.2. Informative References 1445 [10] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1446 Thyagarajan, "Internet Group Management Protocol, Version 3", 1447 RFC 3376, October 2002. 1449 [11] Draves, R. and D. Thaler, "Default Router Preferences and More- 1450 Specific Routes", RFC 4191, November 2005. 1452 [12] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", 1453 RFC 2863, June 2000. 1455 [13] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB", 1456 RFC 5132, December 2007. 1458 [14] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, 1459 "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, 1460 October 2007. 1462 [15] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent 1463 Multicast - Dense Mode (PIM-DM): Protocol Specification 1464 (Revised)", RFC 3973, January 2005. 1466 Authors' Addresses 1468 Hitoshi Asaeda 1469 Keio University 1470 Graduate School of Media and Governance 1471 Fujisawa, Kanagawa 252-0882 1472 Japan 1474 Email: asaeda@wide.ad.jp 1475 URI: http://www.sfc.wide.ad.jp/~asaeda/ 1477 Tatuya Jinmei 1478 Internet Systems Consortium 1479 Redwood City, CA 94063 1480 US 1482 Email: Jinmei_Tatuya@isc.org 1484 William C. Fenner 1485 Arastra, Inc. 1486 Menlo Park, CA 94025 1487 US 1489 Email: fenner@fenron.net 1491 Stephen L. Casner 1492 Packet Design, Inc. 1493 Palo Alto, CA 94304 1494 US 1496 Email: casner@packetdesign.com