idnits 2.17.1 draft-ietf-mboned-mtrace-v2-10.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 6 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 09, 2013) is 3937 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (ref. '4') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 4601 (ref. '5') (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group H. Asaeda 3 Internet-Draft NICT 4 Intended status: Standards Track W. Lee, Ed. 5 Expires: January 10, 2014 Juniper Networks, Inc. 6 July 09, 2013 8 Mtrace Version 2: Traceroute Facility for IP Multicast 9 draft-ietf-mboned-mtrace-v2-10 11 Abstract 13 This document describes the IP multicast traceroute facility, named 14 Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 15 requires special implementations on the part of routers. This 16 specification describes the required functionality in multicast 17 routers, as well as how an Mtrace2 client invokes a query and 18 receives a reply. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 10, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . 7 59 3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 7 60 3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 8 61 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 10 62 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 10 63 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 10 64 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 14 65 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 17 66 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 18 67 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 68 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 19 69 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 19 70 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 20 71 4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 20 72 4.2.1. Request Packet Verification . . . . . . . . . . . . . 20 73 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 20 74 4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 22 75 4.3.1. Destination Address . . . . . . . . . . . . . . . . . 22 76 4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 22 77 4.3.3. Appending Standard Response Block . . . . . . . . . . 23 78 4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 23 79 4.4.1. Destination Address . . . . . . . . . . . . . . . . . 23 80 4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 23 81 4.4.3. Appending Standard Response Block . . . . . . . . . . 23 82 4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 24 83 4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 24 84 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25 85 5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 25 86 5.1.1. Destination Address . . . . . . . . . . . . . . . . . 25 87 5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 25 88 5.2. Determining the Path . . . . . . . . . . . . . . . . . . 25 89 5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 25 90 5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 25 91 5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 26 92 5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 26 93 5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 26 94 5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27 95 5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 27 96 5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 27 97 5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 27 98 5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 27 99 5.9. Continuing after an Error . . . . . . . . . . . . . . . . 27 100 6. Protocol-Specific Considerations . . . . . . . . . . . . . . 28 101 6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 28 103 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 29 105 7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 29 106 7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 29 107 7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 29 108 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 29 109 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 30 110 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30 111 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 112 8.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . 30 113 8.2. UDP Destination Port . . . . . . . . . . . . . . . . . . 31 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 115 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 31 116 9.2. Topology Discovery . . . . . . . . . . . . . . . . . . . 31 117 9.3. Characteristics of Multicast Channel . . . . . . . . . . 31 118 9.4. Limiting Query/Request Rates . . . . . . . . . . . . . . 31 119 9.5. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 31 120 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 121 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 122 11.1. Normative References . . . . . . . . . . . . . . . . . . 32 123 11.2. Informative References . . . . . . . . . . . . . . . . . 33 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 126 1. Introduction 128 Given a multicast distribution tree, tracing from a multicast source 129 to a receiver is difficult, since we do not know which branch of the 130 multicast tree the receiver lies. This means that we have to flood 131 the whole tree to find the path from a source to a receiver. On the 132 other hand, walking up the tree from a receiver to a source is easy, 133 as most existing multicast routing protocols know the upstream router 134 for each source. Tracing from a receiver to a source can involve 135 only the routers on the direct path. 137 This document specifies the multicast traceroute facility named 138 Mtrace version 2 or Mtrace2 which allows the tracing of an IP 139 multicast routing path. Mtrace2 is usually initiated from a Mtrace2 140 client towards a specified source, or a Rendezvous Point (RP) if no 141 source address is specified. RP is a special router where the source 142 and receiver meet in PIM-SM [5]. Moreover, Mtrace2 provides 143 additional information such as the packet rates and losses, as well 144 as other diagnosis information. Especially, Mtrace2 can be used for 145 the following purposes: 147 o To trace the path that a packet would take from a source to a 148 receiver. 150 o To isolate packet loss problems (e.g., congestion). 152 o To isolate configuration problems (e.g., TTL threshold). 154 Figure 1 shows a typical case on how Mtrace2 is used. FHR represents 155 the first-hop router, LHR represents the last-hop router, and the 156 arrow lines represent the Mtrace2 messages that are sent from one 157 node to another. The numbers before the Mtrace2 messages represent 158 the sequence of the messages that would happen. Source, Receiver and 159 Mtrace2 client are typically a host on the Internet. 161 2. Request 2. Request 162 +----+ +----+ 163 | | | | 164 v | v | 165 +--------+ +-----+ +-----+ +----------+ 166 | Source |----| FHR |----- The Internet -----| LHR |----| Receiver | 167 +--------+ +-----+ | +-----+ +----------+ 168 \ | ^ 169 \ | / 170 \ | / 171 \ | / 172 3. Reply \ | / 1. Query 173 \ | / 174 \ | / 175 \ +---------+ / 176 v | Mtrace2 |/ 177 | client | 178 +---------+ 180 Figure 1 182 When an Mtrace2 client initiates a multicast trace anywhere on the 183 Internet, it sends an Mtrace2 Query packet to the LHR for a multicast 184 group and a source address. The LHR turns the Query packet into a 185 Request, appends a standard response block containing its interface 186 addresses and packet statistics to the Request packet, then forwards 187 the packet towards the source. The Request packet is either 188 unicasted to its upstream router towards the source, or multicasted 189 to the group if the upstream router's IP address is not known. In a 190 similar fashion, each router along the path to the source appends a 191 standard response block to the end of the Request packet before 192 forwarding it to its upstream router. When the FHR receives the 193 Request packet, it appends its own standard response block, turns the 194 Request packet into a Reply, and unicasts the Reply back to the 195 Mtrace2 client. 197 The Mtrace2 Reply may be returned before reaching the FHR if it 198 reaches the RP first, or a fatal error condition such as "no route" 199 is encountered along the path, or the hop count is exceeded. 201 The Mtrace2 client waits for the Mtrace2 Reply message and displays 202 the results. When not receiving an Mtrace2 Reply message due to 203 network congestion, a broken router (see Section 5.6), or a non- 204 responding router (see Section 5.7), the Mtrace2 client may resend 205 another Mtrace2 Query with a lower hop count (see Section 3.2.1), and 206 repeat the process until it receives an Mtrace2 Reply message. The 207 details are Mtrace2 client specific, and it is outside the scope of 208 this document. 210 Note that when a router's control plane and forwarding plane are out 211 of sync, the Mtrace2 Requests might be forwarded based on the control 212 states instead. In which case, the traced path might not represent 213 the real path the data packets would follow. 215 Mtrace2 supports both IPv4 and IPv6. Unlike the previous version of 216 Mtrace, which implements its query and response as IGMP messages [8], 217 all Mtrace2 messages are UDP-based. Although the packet formats of 218 IPv4 and IPv6 Mtrace2 are different because of the address families, 219 the syntax between them is similar. 221 2. Terminology 223 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 224 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 225 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], 226 and indicate requirement levels for compliant Mtrace2 227 implementations. 229 2.1. Definitions 230 Since Mtrace2 Queries and Requests flow in the opposite direction to 231 the data flow, we refer to "upstream" and "downstream" with respect 232 to data, unless explicitly specified. 234 Incoming interface 235 The interface on which data is expected to arrive from the 236 specified source and group. 238 Outgoing interface 239 The interface to which data from the source or RP is expected to 240 transmit for the specified source and group. It is also the 241 interface on which the Mtrace2 Request will be received. 243 Upstream router 244 The router, connecting to the Incoming interface of the current 245 router, which is responsible for forwarding data for the specified 246 source and group to the current router. 248 First-hop router (FHR) 249 The router that is directly connected to the source the Mtrace2 250 Query specifies. 252 Last-hop router (LHR) 253 The router that is directly connected to the receivers. It is 254 also the router that receives the Mtrace2 Query from an Mtrace2 255 client. 257 Group state 258 It is the state a shared-tree protocol, such as PIM-SM [5], uses 259 to choose the upstream router towards the RP for the specified 260 group. In this state, source-specific state is not available for 261 the corresponding group address on the router. 263 Source-specific state 264 It is the state that is used to choose the path towards the source 265 for the specified source and group. 267 ALL-[protocol]-ROUTERS.MCAST.NET 268 It is a link-local multicast address for multicast routers to 269 communicate with their adjacent routers that are running the same 270 routing protocol. For instance, the address of ALL-PIM- 271 ROUTERS.MCAST.NET [5] is '224.0.0.13' for IPv4 and 'ff02::d' for 272 IPv6. 274 3. Packet Formats 276 This section describes the details of the packet formats for Mtrace2 277 messages. 279 All Mtrace2 messages are encoded in TLV format (see Section 3.1). If 280 an implementation receives an unknown TLV, it SHOULD ignored and 281 silently discarded the unknown TLV. If the length of a TLV exceeds 282 the length specified in the TLV, the TLV SHOULD be accepted; however, 283 any additional data after the TLV SHOULD be ignored. 285 All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 Query and 286 Request messages MUST NOT be fragmented. For IPv6, the packet size 287 for the Mtrace2 messages MUST NOT exceed 1280 bytes, which is the 288 smallest MTU for an IPv6 interface [2]. The source port is uniquely 289 selected by the local host operating system. The destination port is 290 the IANA reserved Mtrace2 port number (see Section 8). All Mtrace2 291 messages MUST have a valid UDP checksum. 293 Additionally, Mtrace2 supports both IPv4 and IPv6, but not mixed. 294 For example, if an Mtrace2 Query or Request message arrives in as an 295 IPv4 packet, all addresses specified in the Mtrace2 messages MUST be 296 IPv4 as well. Same rule applies to IPv6 Mtrace2 messages. 298 3.1. Mtrace2 TLV format 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type | Length | Value .... | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Type: 8 bits 308 Describes the format of the Value field. For all the available 309 types, please see Section 3.2 311 Length: 16 bits 313 Length of Type, Length, and Value fields in octets. Minimum 314 length required is 6 octets. The maximum TLV length is not 315 defined; however the entire Mtrace2 packet length should not 316 exceed the available MTU. 318 Value: variable length 320 The format is based on the Type value. The length of the value 321 field is Length field minus 3. All reserved fields in the Value 322 field MUST be transmitted as zeros and ignored on receipt. 324 3.2. Defined TLVs 325 The following TLV Types are defined: 327 Code Type 328 ==== ================================ 329 0x01 Mtrace2 Query 330 0x02 Mtrace2 Request 331 0x03 Mtrace2 Reply 332 0x04 Mtrace2 Standard Response Block 333 0x05 Mtrace2 Augmented Response Block 334 0x06 Mtrace2 Extended Query Block 336 Each Mtrace2 message MUST begin with either a Query, Request or Reply 337 TLV. The first TLV determines the type of each Mtrace2 message. 338 Following a Query TLV, there can be a sequence of optional Extended 339 Query Blocks. In the case of a Request or a Reply TLV, it is then 340 followed by a sequence of Standard Response Blocks, each from a 341 multicast router on the path towards the source or the RP. In the 342 case more information is needed, a Standard Response Block can be 343 followed by one or multiple Augmented Response Blocks. 345 We will describe each message type in details in the next few 346 sections. 348 3.2.1. Mtrace2 Query 350 An Mtrace2 Query is usually originated by an Mtrace2 client which 351 sends an Mtrace2 Query message to the LHR. When tracing towards the 352 source or the RP, the intermediate routers MUST NOT modify the Query 353 message except the Type field. 355 An Mtrace2 Query message is shown as follows: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | Length | # Hops | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 | Multicast Address | 364 | | 365 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 366 | | 367 | Source Address | 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | | 371 | Mtrace2 Client Address | 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Query ID | Client Port # | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 2 379 # Hops: 8 bits 380 This field specifies the maximum number of hops that the Mtrace2 381 client wants to trace. If there are some error conditions in the 382 middle of the path that prevent an Mtrace2 Reply from being 383 received by the client, the client MAY issues another Mtrace2 384 Query with the lower number of hops until it receives a Reply. 386 Multicast Address: 32 bits or 128 bits 387 This field specifies an IPv4 or IPv6 address, which can be either: 389 m-1: a multicast group address to be traced; or, 391 m-2: all 1's in case of IPv4 or the unspecified address (::) in 392 case of IPv6 if no group-specific information is desired. 394 Source Address: 32 bits or 128 bits 395 This field specifies an IPv4 or IPv6 address, which can be either: 397 s-1: an unicast address of the source to be traced; or, 399 s-2: all 1's in case of IPv4 or the unspecified address (::) in 400 case of IPv6 if no source-specific information is desired. 401 For example, the client is tracing a (*,g) group state. 403 Note that it is invalid to have a source-group combination of 404 (s-2, m-2). If a router receives such combination in an Mtrace2 405 Query, it MUST silently discard the Query. 407 Mtrace2 Client Address: 32 bits or 128 bits 408 This field specifies the Mtrace2 client's IPv4 address or IPv6 409 global address. This address MUST be a valid unicast address, and 410 therefore, MUST NOT be all 1's or an unspecified address. The 411 Mtrace2 Reply will be sent to this address. 413 Query ID: 16 bits 414 This field is used as a unique identifier for this Mtrace2 Query 415 so that duplicate or delayed Reply messages may be detected. 417 Client Port #: 16 bits 418 This field specifies the destination UDP port number for receiving 419 the Mtrace2 Reply packet. 421 3.2.2. Mtrace2 Request 423 The format of an Mtrace2 Request message is similar to an Mtrace2 424 Query except the Type field is 0x02. 426 When a LHR receives an Mtrace2 Query message, it would turn the Query 427 into a Request by changing the Type field of the Query from 0x01 to 428 0x02. The LHR would then append an Mtrace2 Standard Response Block 429 (see Section 3.2.4) of its own to the Request message before sending 430 it upstream. The upstream routers would do the same without changing 431 the Type field until one of them is ready to send a Reply. 433 3.2.3. Mtrace2 Reply 435 The format of an Mtrace2 Reply message is similar to an Mtrace2 Query 436 except the Type field is 0x03. 438 When a FHR or a RP receives an Mtrace2 Request message which is 439 destined to itself, it would append an Mtrace2 Standard Response 440 Block (see Section 3.2.4) of its own to the Request message. Next, 441 it would turn the Request message into a Reply by changing the Type 442 field of the Request from 0x02 to 0x03. The Reply message would then 443 be unicasted to the Mtrace2 client specified in the Mtrace2 Client 444 Address field. 446 There are a number of cases an intermediate router might return a 447 Reply before a Request reaches the FHR or the RP. See Section 4.1.1, 448 Section 4.2.2, Section 4.3.3, and Section 4.5 for more details. 450 3.2.4. IPv4 Mtrace2 Standard Response Block 452 This section describes the message format of an IPv4 Mtrace2 Standard 453 Response Block. The Type field is 0x04. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length | MBZ | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Query Arrival Time | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Incoming Interface Address | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Outgoing Interface Address | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Upstream Router Address | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 . Input packet count on incoming interface . 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | | 473 . Output packet count on outgoing interface . 474 | | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 . Total number of packets for this source-group pair . 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Rtg Protocol | Multicast Rtg Protocol | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Fwd TTL | MBZ |S| Src Mask |Forwarding Code| 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 MBZ: 8 bits 486 This field must be zeroed on transmission and ignored on 487 reception. 489 Query Arrival Time: 32 bits 490 The Query Arrival Time is a 32-bit NTP timestamp specifying the 491 arrival time of the Mtrace2 Query or Request packet at this 492 router. The 32-bit form of an NTP timestamp consists of the 493 middle 32 bits of the full 64-bit form; that is, the low 16 bits 494 of the integer part and the high 16 bits of the fractional part. 496 The following formula converts from a UNIX timeval to a 32-bit NTP 497 timestamp: 499 query_arrival_time 500 = (tv.tv_sec + 32384) << 16 + ((tv.tv_usec << 10) / 15625) 502 The constant 32384 is the number of seconds from Jan 1, 1900 to 503 Jan 1, 1970 truncated to 16 bits. ((tv.tv_usec << 10) / 15625) is 504 a reduction of ((tv.tv_usec / 100000000) << 16). 506 Note that Mtrace2 does not require all the routers on the path to 507 have synchronized clocks in order to measure one-way latency. 509 Additionally, Query Arrival Time is useful for measuring the 510 packet rate. For example, suppose that a client issues two 511 queries, and the corresponding requests R1 and R2 arrive at router 512 X at time T1 and T2, then the client would be able to compute the 513 packet rate on router X by using the packet count information 514 stored in the R1 and R2, and the time T1 and T2. 516 Incoming Interface Address: 32 bits 517 This field specifies the address of the interface on which packets 518 from the source or the RP are expected to arrive, or 0 if unknown 519 or unnumbered. 521 Outgoing Interface Address: 32 bits 522 This field specifies the address of the interface on which packets 523 from the source or the RP are expected to transmit towards the 524 receiver, or 0 if unknown or unnumbered. This is also the address 525 of the interface on which the Mtrace2 Query or Request arrives. 527 Upstream Router Address: 32 bits 528 This field specifies the address of the upstream router from which 529 this router expects packets from this source. This may be a 530 multicast group (e.g. ALL-[protocol]-ROUTERS.MCAST.NET) if the 531 upstream router is not known because of the workings of the 532 multicast routing protocol. However, it should be 0 if the 533 incoming interface address is unknown or unnumbered. 535 Input packet count on incoming interface: 64 bits 536 This field contains the number of multicast packets received for 537 all groups and sources on the incoming interface, or all 1's if no 538 count can be reported. This counter may have the same value as 539 ifHCInMulticastPkts from the IF-MIB [10] for this interface. 541 Output packet count on outgoing interface: 64 bit 542 This field contains the number of multicast packets that have been 543 transmitted or queued for transmission for all groups and sources 544 on the outgoing interface, or all 1's if no count can be reported. 545 This counter may have the same value as ifHCOutMulticastPkts from 546 the IF-MIB [10] for this interface. 548 Total number of packets for this source-group pair: 64 bits 549 This field counts the number of packets from the specified source 550 forwarded by the router to the specified group, or all 1's if no 551 count can be reported. If the S bit is set (see below), the count 552 is for the source network, as specified by the Src Mask field (see 553 below). If the S bit is set and the Src Mask field is 63, 554 indicating no source-specific state, the count is for all sources 555 sending to this group. This counter should have the same value as 556 ipMcastRoutePkts from the IPMROUTE-STD-MIB [11] for this 557 forwarding entry. 559 Rtg Protocol: 16 bits 560 This field describes the unicast routing protocol running between 561 this router and the upstream router, and it is used to determine 562 the RPF interface for the specified source or RP. This value 563 should have the same value as ipMcastRouteRtProtocol from the 564 IPMROUTE-STD-MIB [11] for this entry. If the router is not able 565 to obtain this value, all 0's must be specified. 567 Multicast Rtg Protocol: 16 bits 568 This field describes the multicast routing protocol in use between 569 the router and the upstream router. This value should have the 570 same value as ipMcastRouteProtocol from the IPMROUTE-STD-MIB [11] 571 for this entry. If the router cannot obtain this value, all 0's 572 must be specified. 574 Fwd TTL: 8 bits 575 This field contains the configured multicast TTL threshold, if 576 any, of the outgoing interface. 578 S: 1 bit 579 If this bit is set, it indicates that the packet count for the 580 source-group pair is for the source network, as determined by 581 masking the source address with the Src Mask field. 583 Src Mask: 7 bits 584 This field contains the number of 1's in the netmask the router 585 has for the source (i.e. a value of 24 means the netmask is 586 0xffffff00). If the router is forwarding solely on group state, 587 this field is set to 127 (0x7f). 589 Forwarding Code: 8 bits 590 This field contains a forwarding information/error code. 591 Section 4.1 and Section 4.2 will explain how and when the 592 Forwarding Code is filled. Defined values are as follows: 594 Value Name Description 595 ----- -------------- ---------------------------------------------- 596 0x00 NO_ERROR No error 597 0x01 WRONG_IF Mtrace2 Request arrived on an interface 598 to which this router would not forward for 599 the specified group towards the source or RP. 600 0x02 PRUNE_SENT This router has sent a prune upstream which 601 applies to the source and group in the 602 Mtrace2 Request. 603 0x03 PRUNE_RCVD This router has stopped forwarding for this 604 source and group in response to a request 605 from the downstream router. 606 0x04 SCOPED The group is subject to administrative 607 scoping at this router. 608 0x05 NO_ROUTE This router has no route for the source or 609 group and no way to determine a potential 610 route. 611 0x06 WRONG_LAST_HOP This router is not the proper LHR. 613 0x07 NOT_FORWARDING This router is not forwarding this source and 614 group out the outgoing interface for an 615 unspecified reason. 616 0x08 REACHED_RP Reached the Rendezvous Point. 617 0x09 RPF_IF Mtrace2 Request arrived on the expected 618 RPF interface for this source and group. 619 0x0A NO_MULTICAST Mtrace2 Request arrived on an interface 620 which is not enabled for multicast. 621 0x0B INFO_HIDDEN One or more hops have been hidden from this 622 trace. 623 0x0C REACHED_GW Mtrace2 Request arrived on a gateway (e.g., 624 a NAT or firewall) that hides the 625 information between this router and the 626 Mtrace2 client. 627 0x0D UNKNOWN_QUERY A non-transitive Extended Query Type was 628 received by a router which does not support 629 the type. 630 0x80 FATAL_ERROR A fatal error is one where the router may 631 know the upstream router but cannot forward 632 the message to it. 633 0x81 NO_SPACE There was not enough room to insert another 634 Standard Response Block in the packet. 635 0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited. 637 3.2.5. IPv6 Mtrace2 Standard Response Block 639 This section describes the message format of an IPv6 Mtrace2 Standard 640 Response Block. The Type field is also 0x04. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Type | Length | MBZ | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Query Arrival Time | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Incoming Interface ID | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Outgoing Interface ID | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 * Local Address * 655 | | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | 658 * Remote Address * 659 | | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | | 662 . Input packet count on incoming interface . 663 | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | | 666 . Output packet count on outgoing interface . 667 | | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | 670 . Total number of packets for this source-group pair . 671 | | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Rtg Protocol | Multicast Rtg Protocol | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | MBZ 2 |S|Src Prefix Len |Forwarding Code| 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 MBZ: 8 bits 679 This field must be zeroed on transmission and ignored on 680 reception. 682 Query Arrival Time: 32 bits 683 Same definition as in IPv4. 685 Incoming Interface ID: 32 bits 686 This field specifies the interface ID on which packets from the 687 source or RP are expected to arrive, or 0 if unknown. This ID 688 should be the value taken from InterfaceIndex of the IF-MIB [10] 689 for this interface. 691 Outgoing Interface ID: 32 bits 692 This field specifies the interface ID to which packets from the 693 source or RP are expected to transmit, or 0 if unknown. This ID 694 should be the value taken from InterfaceIndex of the IF-MIB [10] 695 for this interface 697 Local Address: 128 bits 698 This field specifies a global IPv6 address that uniquely 699 identifies the router. An unique local unicast address [9] SHOULD 700 NOT be used unless the router is only assigned link-local and 701 unique local addresses. If the router is only assigned link-local 702 addresses, its link-local address can be specified in this field. 704 Remote Address: 128 bits 705 This field specifies the address of the upstream router, which, in 706 most cases, is a link-local unicast address for the upstream 707 router. 709 Although a link-local address does not have enough information to 710 identify a node, it is possible to detect the upstream router with 711 the assistance of Incoming Interface ID and the current router 712 address (i.e., Local Address). 714 Note that this may be a multicast group (e.g., 715 ALL-[protocol]-ROUTERS.MCAST.NET) if the upstream router is not 716 known because of the workings of a multicast routing protocol. 717 However, it should be the unspecified address (::) if the incoming 718 interface address is unknown. 720 Input packet count on incoming interface: 64 bits 721 Same definition as in IPv4. 723 Output packet count on outgoing interface: 64 bits 724 Same definition as in IPv4. 726 Total number of packets for this source-group pair: 64 bits 727 Same definition as in IPv4, except if the S bit is set (see 728 below), the count is for the source network, as specified by the 729 Src Prefix Len field. If the S bit is set and the Src Prefix Len 730 field is 255, indicating no source-specific state, the count is 731 for all sources sending to this group. This counter should have 732 the same value as ipMcastRoutePkts from the IPMROUTE-STD-MIB [11] 733 for this forwarding entry. 735 Rtg Protocol: 16 bits 736 Same definition as in IPv4. 738 Multicast Rtg Protocol: 16 bits 739 Same definition as in IPv4. 741 MBZ 2: 15 bits 742 This field must be zeroed on transmission and ignored on 743 reception. 745 S: 1 bit 746 Same definition as in IPv4, except the Src Prefix Len field is 747 used to mask the source address. 749 Src Prefix Len: 8 bits 750 This field contains the prefix length this router has for the 751 source. If the router is forwarding solely on group state, this 752 field is set to 255 (0xff). 754 Forwarding Code: 8 bits 755 Same definition as in IPv4. 757 3.2.6. Mtrace2 Augmented Response Block 759 In addition to the Standard Response Block, a multicast router on the 760 traced path can optionally add one or multiple Augmented Response 761 Blocks before sending the Request to its upstream router. 763 The Augmented Response Block is flexible for various purposes such as 764 providing diagnosis information (see Section 7) and protocol 765 verification. Its Type field is 0x05, and its format is as follows: 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Type | Length | MBZ | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Augmented Response Type | Value .... | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 MBZ: 8 bits 776 This field must be zeroed on transmission and ignored on 777 reception. 779 Augmented Response Type: 16 bits 780 This field specifies the type of various responses from a 781 multicast router that might need to communicate back to the 782 Mtrace2 client as well as the multicast routers on the traced 783 path. 785 The Augmented Response Type is defined as follows: 787 Code Type 788 ==== =============================================== 789 0x01 # of the returned Standard Response Blocks 791 When the NO_SPACE error occurs on a router, the router should send 792 the original Mtrace2 Request received from the downstream router 793 as a Reply back to the Mtrace2 client, and continue with a new 794 Mtrace2 Request. In the new Request, the router would add a 795 Standard Response Block followed by an Augmented Response Block 796 with 0x01 as the Augmented Response Type, and the number of the 797 returned Mtrace2 Standard Response Blocks as the Value. 799 Each upstream router would recognize the total number of hops the 800 Request has been traced so far by adding this number and the 801 number of the Standard Response Block in the current Request 802 message. 804 This document only defines one Augmented Response Type in the 805 Augmented Response Block. The description on how to provide 806 diagnosis information using the Augmented Response Block is out of 807 the scope of this document, and will be addressed in separate 808 documents. 810 Value: variable length 811 The format is based on the Augmented Response Type value. The 812 length of the value field is Length field minus 6. 814 3.2.7. Mtrace2 Extended Query Block 816 There may be a sequence of optional Extended Query Blocks that follow 817 an Mtrace2 Query to further specify any information needed for the 818 Query. For example, an Mtrace2 client might be interested in tracing 819 the path the specified source and group would take based on a certain 820 topology. In which case, the client can pass in the multi-topology 821 ID as the Value for an Extended Query Type (see below). The Extended 822 Query Type is extensible and the behavior of the new types will be 823 addressed by separate documents. 825 The Mtrace2 Extended Query Block's Type field is 0x06, and is 826 formatted as follows: 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Type | Length | MBZ |T| 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Extended Query Type | Value .... | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 MBZ: 7 bits 837 This field must be zeroed on transmission and ignored on 838 reception. 840 T-bit (Transitive Attribute): 1 bit 841 If the TLV type is unrecognized by the receiving router, then this 842 TLV is either discarded or forwarded along with the Query, 843 depending on the value of this bit. If this bit is set, then the 844 router MUST forward this TLV. If this bit is clear, the router 845 MUST send an Mtrace2 Reply with an UNKNOWN_QUERY error. 847 Extended Query Type: 16 bits 848 This field specifies the type of the Extended Query Block. 850 Value: 16 bits 851 This field specifies the value of this Extended Query. 853 4. Router Behavior 855 This section describes the router behavior in the context of Mtrace2 856 in details. 858 4.1. Receiving Mtrace2 Query 860 An Mtrace2 Query message is an Mtrace2 message with no response 861 blocks filled in, and uses TLV type of 0x01. 863 4.1.1. Query Packet Verification 865 Upon receiving an Mtrace2 Query message, a router MUST examine 866 whether the Multicast Address and the Source Address are a valid 867 combination as specified in Section 3.2.1, and whether the Mtrace2 868 Client Address is a valid IP unicast address. If either one is 869 invalid, the Query MUST be silently ignored. 871 Mtrace2 supports non-local client to the LHR. It is up to the 872 implementation to filter out such queries. 874 In the case when it is a local client, the router must then examine 875 the Query to see if it is the proper LHR for the destination address 876 in the packet. It is the proper LHR if it has a multicast-capable 877 interface on the same subnet as the Mtrace2 Client Address and is the 878 router that would forward traffic from the given (S,G) or (*,G) onto 879 that subnet. 881 If the router determines that it is not the proper LHR, or it cannot 882 make that determination, it does one of two things depending on 883 whether the Query was received via multicast or unicast. If the 884 Query was received via multicast, then it MUST be silently discarded. 885 If it was received via unicast, the router turns the Query into a 886 Reply message by changing the TLV type to 0x03 and appending a 887 Standard Response Block with a Forwarding Code of WRONG_LAST_HOP. 888 The rest of the fields in the Standard Response Block MUST be zeroed. 889 The router then sends the Reply message to the Mtrace2 Client Address 890 on the Client Port # as specified in the Mtrace2 Query. 892 Duplicate Query messages as identified by the tuple (Mtrace2 Client 893 Address, Query ID) SHOULD be ignored. This MAY be implemented using 894 a cache of previously processed queries keyed by the Mtrace2 Client 895 Address and Query ID pair. The duration of the cached entries is 896 implementation specific. Duplicate Request messages MUST NOT be 897 ignored in this manner. 899 4.1.2. Query Normal Processing 901 When a router receives an Mtrace2 Query and it determines that it is 902 the proper LHR, it turns the Query to a Request by changing the TLV 903 type from 0x01 to 0x02, and performs the steps listed in Section 4.2. 905 4.2. Receiving Mtrace2 Request 907 An Mtrace2 Request is an Mtrace2 message that uses TLV type of 0x02. 908 With the exception of the LHR, whose Request was just converted from 909 a Query, each Request received by a router should have at least one 910 Standard Response Block filled in. 912 4.2.1. Request Packet Verification 914 If the Mtrace2 Request does not come from an adjacent router, or if 915 the Request is not addressed to this router, or if the Request is 916 addressed to a multicast group which is not a link-scoped group (i.e. 917 224/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be silently 918 ignored. GTSM [12] SHOULD be used by the router to determine whether 919 the router is adjacent or not. 921 If the sum of the number of the Standard Response Blocks in the 922 received Mtrace2 Request and the value of the Augmented Response Type 923 of 0x01, if any, is equal or more than the # Hops in the Mtrace2 924 Request, it MUST be silently ignored. 926 4.2.2. Request Normal Processing 928 When a router receives an Mtrace2 Request message, it performs the 929 following steps. Note that it is possible to have multiple 930 situations covered by the Forwarding Codes. The first one 931 encountered is the one that is reported, i.e. all "note Forwarding 932 Code N" should be interpreted as "if Forwarding Code is not already 933 set, set Forwarding Code to N". 935 1. Prepare a Standard Response Block to be appended to the packet 936 and fill in the Query Arrival Time, Outgoing Interface Address 937 (for IPv4) or Outgoing Interface ID (for IPv6), Output Packet 938 Count, and Fwd TTL (for IPv4). Note that the Outgoing Interface 939 is the one on which the Mtrace2 Request message arrives. 941 2. Attempt to determine the forwarding information for the 942 specified source and group, using the same mechanisms as would 943 be used when a packet is received from the source destined for 944 the group. A state need not be instantiated, it can be a 945 "phantom" state created only for the purpose of the trace, such 946 as "dry-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's 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. 956 3. If no forwarding information can be determined, the router notes 957 a Forwarding Code of NO_ROUTE, sets the remaining fields that 958 have not yet been filled in to zero, and then sends an Mtrace2 959 Reply back to the Mtrace2 client. 961 4. Fill in the Incoming Interface Address, Upstream Router Address, 962 Input Packet Count, Total Number of Packets, Routing Protocol, 963 S, and Src Mask (or Src Prefix Len for IPv6) using the 964 forwarding information determined by the step 2. 966 5. If Mtrace2 is administratively prohibited, note the Forwarding 967 Code of ADMIN_PROHIB. If Mtrace2 is administratively prohibited 968 and any of the fields as filled in the step 4 are considered 969 private information, zero out the applicable fields. 971 6. If the Outgoing interface is not enabled for multicast, note 972 Forwarding Code of NO_MULTICAST. If the Outgoing interface is 973 the interface from which the router would expect data to arrive 974 from the source, note forwarding code RPF_IF. If the Outgoing 975 interface is not one to which the router would forward data from 976 the source or RP to the group, a Forwarding code of WRONG_IF is 977 noted. In the above three cases, the router will return an 978 Mtrace2 Reply and terminate the trace. 980 7. If the group is subject to administrative scoping on either the 981 Outgoing or Incoming interfaces, a Forwarding Code of SCOPED is 982 noted. 984 8. If this router is the RP for the group, note a Forwarding Code 985 of REACHED_RP. The router will send an Mtrace2 Reply and 986 terminate the trace. 988 9. If this router has sent a prune upstream which applies to the 989 source and group in the Mtrace2 Request, it notes Forwarding 990 Code of PRUNE_SENT. If the router has stopped forwarding 991 downstream in response to a prune sent by the downstream router, 992 it notes Forwarding Code of PRUNE_RCVD. If the router should 993 normally forward traffic downstream for this source and group 994 but is not, it notes Forwarding Code of NOT_FORWARDING. 996 10. If this router is a gateway (e.g., a NAT or firewall) that hides 997 the information between this router and the Mtrace2 client, it 998 notes Forwarding Code of REACHED_GW. The router continues the 999 processing as described in Section 4.5. 1001 11. If the total number of the Standard Response Blocks, including 1002 the newly prepared one, and the value of the Augmented Response 1003 Type of 0x01, if any, is less than the # Hops in the Request, 1004 the packet is then forwarded to the upstream router as described 1005 in Section 4.3; otherwise, the packet is sent as an Mtrace2 1006 Reply to the Mtrace2 client as described in Section 4.4. 1008 4.3. Forwarding Mtrace2 Request 1010 This section describes how an Mtrace2 Request should be forwarded. 1012 4.3.1. Destination Address 1014 If the upstream router for the Mtrace2 Request is known for this 1015 request, the Mtrace2 Request is sent to that router. If the Incoming 1016 interface is known but the upstream router is not, the Mtrace2 1017 Request is sent to an appropriate multicast address on the Incoming 1018 interface. The multicast address SHOULD depend on the multicast 1019 routing protocol in use, such as ALL-[protocol]-ROUTERS.MCAST.NET. 1020 It MUST be a link-scoped group (i.e. 224/24 for IPv4, FF02::/16 for 1021 IPv6), and MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 and 1022 All Nodes Address (FF02::1) for IPv6. It MAY also be ALL- 1023 ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address 1024 (FF02::2) for IPv6 if the routing protocol in use does not define a 1025 more appropriate multicast address. 1027 4.3.2. Source Address 1029 An Mtrace2 Request should be sent with the address of the Incoming 1030 interface. However, if the Incoming interface is unnumbered, the 1031 router can use one of its numbered interface address as the source 1032 address. 1034 4.3.3. Appending Standard Response Block 1036 An Mtrace2 Request MUST be sent upstream towards the source or the RP 1037 after appending a Standard Response Block to the end of the received 1038 Mtrace2 Request. The Standard Response Block includes the multicast 1039 states and statistics information of the router described in 1040 Section 3.2.4. 1042 If appending the Standard Response Block would make the Mtrace2 1043 Request packet longer than the MTU of the Incoming Interface, or, in 1044 the case of IPv6, longer than 1280 bytes, the router MUST change the 1045 Forwarding Code in the last Standard Response Block of the received 1046 Mtrace2 Request into NO_SPACE. The router then turns the Request 1047 into a Reply, and sends the Reply as described in Section 4.4. 1049 The router will continue with a new Request by copying from the old 1050 Request excluding all the response blocks, followed by the previously 1051 prepared Standard Response Block, and an Augmented Response Block 1052 with Augmented Response Type of 0x01 and the number of the returned 1053 Standard Response Blocks as the value. The new Request is then 1054 forwarded upstream. 1056 4.4. Sending Mtrace2 Reply 1058 An Mtrace2 Reply MUST be returned to the client by a router if the 1059 total number of the traced routers is equal to the # Hops in the 1060 Request. The total number of the traced routers is the sum of the 1061 Standard Response Blocks in the Request (including the one just 1062 added) and the number of the returned blocks, if any. 1064 4.4.1. Destination Address 1066 An Mtrace2 Reply MUST be sent to the address specified in the Mtrace2 1067 Client Address field in the Mtrace2 Request. 1069 4.4.2. Source Address 1071 An Mtrace2 Reply SHOULD be sent with the address of the router's 1072 Outgoing interface. However, if the Outgoing interface address is 1073 unnumbered, the router can use one of its numbered interface address 1074 as the source address. 1076 4.4.3. Appending Standard Response Block 1078 An Mtrace2 Reply MUST be sent with the prepared Standard Response 1079 Block appended at the end of the received Mtrace2 Request except in 1080 the case of NO_SPACE forwarding code. 1082 4.5. Proxying Mtrace2 Query 1084 When a gateway (e.g., a NAT or firewall), which needs to block 1085 unicast packets to the Mtrace2 client, or hide information between 1086 the gateway and the Mtrace2 client, receives an Mtrace2 Query from an 1087 adjacent host or Mtrace2 Request from an adjacent router, it appends 1088 a Standard Response Block with REACHED_GW as the Forwarding Code, and 1089 turns the Query or Request as a Reply, and sends the Reply back to 1090 the client. 1092 At the same time, the gateway originates a new Mtrace2 Query message 1093 by copying the original Mtrace2 header (the Query or Request without 1094 any of the response blocks), and makes the changes as follows: 1096 o sets the RPF interface's address as the Mtrace2 Client Address; 1098 o uses its own port number as the Client Port #; and, 1100 o decreases # Hops by the number of the Standard Response Block that 1101 was just returned as a Reply. 1103 The new Mtrace2 Query message is then sent to the upstream router or 1104 to an appropriate multicast address on the RPF interface. 1106 When the gateway receives an Mtrace2 Reply whose Query ID matches the 1107 one in the original Mtrace2 header, it MUST relay the Mtrace2 Reply 1108 back to the Mtrace2 client by replacing the Reply's header with the 1109 original Mtrace2 header. If the gateway does not receive the 1110 corresponding Mtrace2 Reply within the [Mtrace Reply Timeout] period 1111 (see Section 5.8.4), then it silently discards the original Mtrace2 1112 Query or Request message, and terminates the trace. 1114 4.6. Hiding Information 1116 Information about a domain's topology and connectivity may be hidden 1117 from the Mtrace2 Requests. The Forwarding Code of INFO_HIDDEN may be 1118 used to note that. For example, the incoming interface address and 1119 packet count on the ingress router of a domain, and the outgoing 1120 interface address and packet count on the egress router of the domain 1121 can be specified as all 1's. Additionally, the source-group packet 1122 count (see Section 3.2.4 and Section 3.2.5) within the domain may be 1123 all 1's if it is hidden. 1125 5. Client Behavior 1127 This section describes the behavior of an Mtrace2 client in details. 1129 5.1. Sending Mtrace2 Query 1131 An Mtrace2 client initiates an Mtrace2 Query by sending the Query to 1132 the LHR of interest. 1134 5.1.1. Destination Address 1136 If an Mtrace2 client knows the proper LHR, it unicasts an Mtrace2 1137 Query packet to that router; otherwise, it MAY send the Mtrace2 Query 1138 packet to the ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All 1139 Routers Address (FF02::2) for IPv6. This will ensure that the packet 1140 is received by the LHR on the subnet. 1142 See also Section 5.4 on determining the LHR. 1144 5.1.2. Source Address 1146 An Mtrace2 Query MUST be sent with the client's interface address, 1147 which would be the Mtrace2 Client Address. 1149 5.2. Determining the Path 1151 An Mtrace2 client could send an initial Query messages with a large # 1152 Hops, in order to try to trace the full path. If this attempt fails, 1153 one strategy is to perform a linear search (as the traditional 1154 unicast traceroute program does); set the # Hops field to 1 and try 1155 to get a Reply, then 2, and so on. If no Reply is received at a 1156 certain hop, the hop count can continue past the non-responding hop, 1157 in the hopes that further hops may respond. These attempts should 1158 continue until the [Mtrace Reply Timeout] timeout has occurred. 1160 See also Section 5.6 on receiving the results of a trace. 1162 5.3. Collecting Statistics 1164 After a client has determined that it has traced the whole path or as 1165 much as it can expect to (see Section 5.8), it might collect 1166 statistics by waiting a short time and performing a second trace. If 1167 the path is the same in the two traces, statistics can be displayed 1168 as described in Section 7.3 and Section 7.4. 1170 5.4. Last Hop Router (LHR) 1171 The Mtrace2 client may not know which is the last-hop router, or that 1172 router may be behind a firewall that blocks unicast packets but 1173 passes multicast packets. In these cases, the Mtrace2 Request should 1174 be multicasted to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All 1175 Routers Address (FF02::2) for IPv6. All routers except the correct 1176 last-hop router SHOULD ignore any Mtrace2 Request received via 1177 multicast. 1179 5.5. First Hop Router (FHR) 1181 The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default 1182 multicast group for old IPv4 mtrace (v1) responses, in order to 1183 support mtrace clients that are not unicast reachable from the first- 1184 hop router. Mtrace2, however, does not require any IPv4/IPv6 1185 multicast addresses for the Mtrace2 Replies. Every Mtrace2 Reply is 1186 sent to the unicast address specified in the Mtrace2 Client Address 1187 field of the Mtrace2 Reply. 1189 5.6. Broken Intermediate Router 1191 A broken intermediate router might simply not understand Mtrace2 1192 packets, and drop them. The Mtrace2 client will get no Reply at all 1193 as a result. It should then perform a hop-by-hop search by setting 1194 the # Hops field until it gets an Mtrace2 Reply. The client may use 1195 linear or binary search; however, the latter is likely to be slower 1196 because a failure requires waiting for the [Mtrace Reply Timeout] 1197 period. 1199 5.7. Non-Supported Router 1201 When a non-supported router receives an Mtrace2 Query or Request 1202 message whose destination address is a multicast address, the router 1203 will silently discard the message. 1205 When the router receives an Mtrace2 Query which is destined to 1206 itself, the router would return an ICMP port unreachable to the 1207 Mtrace2 client. On the other hand, when the router receives an 1208 Mtrace2 Request which is destined to itself, the router would return 1209 an ICMP port unreachable to its adjacent router from which the 1210 Request receives. Therefore, the Mtrace2 client needs to terminate 1211 the trace when the [Mtrace Reply Timeout] timeout has occurred, and 1212 may then issue another Query with a lower number of # Hops. 1214 5.8. Mtrace2 Termination 1216 When performing an expanding hop-by-hop trace, it is necessary to 1217 determine when to stop expanding. 1219 5.8.1. Arriving at Source 1221 A trace can be determined to have arrived at the source if the 1222 Incoming Interface of the last router in the trace is non-zero, but 1223 the Upstream Router is zero. 1225 5.8.2. Fatal Error 1227 A trace has encountered a fatal error if the last Forwarding Error in 1228 the trace has the 0x80 bit set. 1230 5.8.3. No Upstream Router 1232 A trace can not continue if the last Upstream Router in the trace is 1233 set to 0. 1235 5.8.4. Reply Timeout 1237 This document defines the [Mtrace Reply Timeout] value, which is used 1238 to time out an Mtrace2 Reply as seen in Section 4.5, Section 5.2, and 1239 Section 5.7. The default [Mtrace Reply Timeout] value is 10 1240 (seconds), and can be manually changed on the Mtrace2 client and 1241 routers. 1243 5.9. Continuing after an Error 1245 When the NO_SPACE error occurs, as described in Section 4.2, a router 1246 will send back an Mtrace2 Reply to the Mtrace2 client, and continue 1247 with a new Request (see Section 4.3.3). In which case, the Mtrace2 1248 client may receive multiple Mtrace2 Replies from different routers 1249 along the path. When this happens, the client MUST treat them as a 1250 single Mtrace2 Reply message. 1252 If a trace times out, it is very likely that a router in the middle 1253 of the path does not support Mtrace2. That router's address will be 1254 in the Upstream Router field of the last Standard Response Block in 1255 the last received Reply. A client may be able to determine (via 1256 mrinfo or SNMP [9][11]) a list of neighbors of the non-responding 1257 router. If desired, each of those neighbors could be probed to 1258 determine the remainder of the path. Unfortunately, this heuristic 1259 may end up with multiple paths, since there is no way of knowing what 1260 the non-responding router's algorithm for choosing an upstream router 1261 is. However, if all paths but one flow back towards the non- 1262 responding router, it is possible to be sure that this is the correct 1263 path. 1265 6. Protocol-Specific Considerations 1267 This section describes the Mtrace2 behavior with the present of 1268 different multicast protocols. 1270 6.1. PIM-SM 1272 When an Mtrace2 reaches a PIM-SM RP, and the RP does not forward the 1273 trace on, it means that the RP has not performed a source-specific 1274 join so there is no more state to trace. However, the path that 1275 traffic would use if the RP did perform a source-specific join can be 1276 traced by setting the trace destination to the RP, the trace source 1277 to the traffic source, and the trace group to 0. This Mtrace2 Query 1278 may be unicasted to the RP. 1280 6.2. Bi-Directional PIM 1282 Bi-directional PIM [6] is a variant of PIM-SM that builds bi- 1283 directional shared trees connecting multicast sources and receivers. 1284 Along the bi-directional shared trees, multicast data is natively 1285 forwarded from the sources to the Rendezvous Point Link (RPL), and 1286 from which, to receivers without requiring source-specific state. In 1287 contrast to PIM-SM, Bi-directional PIM always has the state to trace. 1289 A Designated Forwarder (DF) for a given Rendezvous Point Address 1290 (RPA) is in charge of forwarding downstream traffic onto its link, 1291 and forwarding upstream traffic from its link towards the RPL that 1292 the RPA belongs to. Hence Mtrace2 Reply reports DF addresses or RPA 1293 along the path. 1295 6.3. PIM-DM 1297 Routers running PIM Dense Mode [13] do not know the path packets 1298 would take unless traffic is flowing. Without some extra protocol 1299 mechanism, this means that in an environment with multiple possible 1300 paths with branch points on shared media, Mtrace2 can only trace 1301 existing paths, not potential paths. When there are multiple 1302 possible paths but the branch points are not on shared media, the 1303 upstream router is known, but the LHR may not know that it is the 1304 appropriate last hop. 1306 When traffic is flowing, PIM Dense Mode routers know whether or not 1307 they are the LHR for the link (because they won or lost an Assert 1308 battle) and know who the upstream router is (because it won an Assert 1309 battle). Therefore, Mtrace2 is always able to follow the proper path 1310 when traffic is flowing. 1312 6.4. IGMP/MLD Proxy 1314 When an IGMP/MLD Proxy [7] receives an Mtrace2 Query packet on an 1315 incoming interface, it notes a WRONG_IF in the Forwarding Code of the 1316 last Standard Response Block (see Section 3.2.4), and sends the 1317 Mtrace2 Reply back to the Mtrace2 client. On the other hand, when an 1318 Mtrace2 Query packet reaches an outgoing interface of the IGMP/MLD 1319 proxy, it is forwarded onto its incoming interface towards the 1320 upstream router. 1322 7. Problem Diagnosis 1324 This section describes different scenarios Mtrace2 can be used to 1325 diagnose the multicast problems. 1327 7.1. Forwarding Inconsistencies 1329 The Forwarding Error code can tell if a group is unexpectedly pruned 1330 or administratively scoped. 1332 7.2. TTL or Hop Limit Problems 1334 By taking the maximum of hops from the source and forwarding TTL 1335 threshold over all hops, it is possible to discover the TTL or hop 1336 limit required for the source to reach the destination. 1338 7.3. Packet Loss 1340 By taking two traces, it is possible to find packet loss information 1341 by comparing the difference in input packet counts to the difference 1342 in output packet counts for the specified source-group address pair 1343 at the previous hop. On a point-to-point link, any difference in 1344 these numbers implies packet loss. Since the packet counts may be 1345 changing as the Mtrace2 Request is propagating, there may be small 1346 errors (off by 1 or 2 or more) in these statistics. However, these 1347 errors will not accumulate if multiple traces are taken to expand the 1348 measurement period. On a shared link, the count of input packets can 1349 be larger than the number of output packets at the previous hop, due 1350 to other routers or hosts on the link injecting packets. This 1351 appears as "negative loss" which may mask real packet loss. 1353 In addition to the counts of input and output packets for all 1354 multicast traffic on the interfaces, the Standard Response Block 1355 includes a count of the packets forwarded by a node for the specified 1356 source-group pair. Taking the difference in this count between two 1357 traces and then comparing those differences between two hops gives a 1358 measure of packet loss just for traffic from the specified source to 1359 the specified receiver via the specified group. This measure is not 1360 affected by shared links. 1362 On a point-to-point link that is a multicast tunnel, packet loss is 1363 usually due to congestion in unicast routers along the path of that 1364 tunnel. On native multicast links, loss is more likely in the output 1365 queue of one hop, perhaps due to priority dropping, or in the input 1366 queue at the next hop. The counters in the Standard Response Block 1367 do not allow these cases to be distinguished. Differences in packet 1368 counts between the incoming and outgoing interfaces on one node 1369 cannot generally be used to measure queue overflow in the node. 1371 7.4. Link Utilization 1373 Again, with two traces, you can divide the difference in the input or 1374 output packet counts at some hop by the difference in time stamps 1375 from the same hop to obtain the packet rate over the link. If the 1376 average packet size is known, then the link utilization can also be 1377 estimated to see whether packet loss may be due to the rate limit or 1378 the physical capacity on a particular link being exceeded. 1380 7.5. Time Delay 1382 If the routers have synchronized clocks, it is possible to estimate 1383 propagation and queuing delay from the differences between the 1384 timestamps at successive hops. However, this delay includes control 1385 processing overhead, so is not necessarily indicative of the delay 1386 that data traffic would experience. 1388 8. IANA Considerations 1390 The following new assignments can only be made via a Standards Action 1391 as specified in [4]. 1393 8.1. Forwarding Codes 1395 New Forwarding Codes must only be created by an RFC that modifies 1396 this document's Section 3.2.4 and Section 3.2.5, fully describing the 1397 conditions under which the new Forwarding Code is used. The IANA may 1398 act as a central repository so that there is a single place to look 1399 up Forwarding Codes and the document in which they are defined. 1401 8.2. UDP Destination Port 1403 The IANA should allocate UDP destination port for Mtrace2 upon 1404 publication of the first RFC. 1406 9. Security Considerations 1408 This section addresses some of the security considerations related to 1409 Mtrace2. 1411 9.1. Addresses in Mtrace2 Header 1413 An Mtrace2 header includes three addresses, source address, multicast 1414 address, and Mtrace2 client address. These addresses MUST be 1415 congruent with the definition defined in Section 3.2.1 and forwarding 1416 Mtrace2 messages having invalid addresses MUST be prohibited. For 1417 instance, if Mtrace2 Client Address specified in an Mtrace2 header is 1418 a multicast address, then a router that receives the Mtrace2 message 1419 MUST silently discard it. 1421 9.2. Topology Discovery 1423 Mtrace2 can be used to discover any actively-used topology. If your 1424 network topology is a secret, Mtrace2 may be restricted at the border 1425 of your domain, using the ADMIN_PROHIB forwarding code. 1427 9.3. Characteristics of Multicast Channel 1429 Mtrace2 can be used to discover what sources are sending to what 1430 groups and at what rates. If this information is a secret, Mtrace2 1431 may be restricted at the border of your domain, using the 1432 ADMIN_PROHIB forwarding code. 1434 9.4. Limiting Query/Request Rates 1436 A router may limit Mtrace2 Queries and Requests by ignoring some of 1437 the consecutive messages. The router MAY randomly ignore the 1438 received messages to minimize the processing overhead, i.e., to keep 1439 fairness in processing queries, or prevent traffic amplification. 1440 The rate limit is left to the router's implementation. 1442 9.5. Limiting Reply Rates 1444 The proxying and NO_SPACE behaviors may result in one Query returning 1445 multiple Reply messages. In order to prevent abuse, the routers in 1446 the traced MAY need to rate-limit the Replies. The rate limit 1447 function is left to the router's implementation. 1449 10. Acknowledgements 1451 This specification started largely as a transcription of Van 1452 Jacobson's slides from the 30th IETF, and the implementation in 1453 mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve 1454 Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original 1455 multicast traceroute client, mtrace (version 1), has been implemented 1456 by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the 1457 "S" bit to allow statistics for a source subnet is due to Tom 1458 Pusateri. 1460 For the Mtrace version 2 specification, the authors would like to 1461 give special thanks to Tatsuya Jinmei, Bill Fenner, and Steve Casner. 1462 Also, extensive comments were received from David L. Black, Ronald 1463 Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert W. Kebler, Heidi Ou, 1464 Pekka Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, and 1465 Cao Wei. 1467 11. References 1469 11.1. Normative References 1471 [1] Bradner, S., "Key words for use in RFCs to indicate 1472 requirement levels", RFC 2119, March 1997. 1474 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1475 (IPv6) Specification", RFC 2460, December 1998. 1477 [3] Hinden, R. and S. Deering, "IP Version 6 Addressing 1478 Architecture", RFC 4291, February 2006. 1480 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1481 IANA Considerations Section in RFCs", RFC 5226, May 2008. 1483 [5] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1484 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1485 Protocol Specification (Revised)", RFC 4601, August 2006. 1487 [6] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1488 "Bidirectional Protocol Independent Multicast (BIDIR- 1489 PIM)", RFC 5015, October 2007. 1491 [7] Fenner, B., He, H., Haberman, B., and H. Sandick, 1492 "Internet Group Management Protocol (IGMP) / Multicast 1493 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 1494 /MLD Proxying")", RFC 4605, August 2006. 1496 11.2. Informative References 1498 [8] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1499 Thyagarajan, "Internet Group Management Protocol, Version 1500 3", RFC 3376, October 2002. 1502 [9] Draves, R. and D. Thaler, "Default Router Preferences and 1503 More-Specific Routes", RFC 4191, November 2005. 1505 [10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 1506 MIB", RFC 2863, June 2000. 1508 [11] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast 1509 MIB", RFC 5132, December 2007. 1511 [12] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1512 Pignataro, "The Generalized TTL Security Mechanism 1513 (GTSM)", RFC 5082, October 2007. 1515 [13] Adams, A., Nicholas, J., and W. Siadak, "Protocol 1516 Independent Multicast - Dense Mode (PIM-DM): Protocol 1517 Specification (Revised)", RFC 3973, January 2005. 1519 Authors' Addresses 1521 Hitoshi Asaeda 1522 National Institute of Information and Communications Technology 1523 4-2-1 Nukui-Kitamachi 1524 Koganei, Tokyo 184-8795 1525 Japan 1527 Email: asaeda@nict.go.jp 1529 WeeSan Lee (editor) 1530 Juniper Networks, Inc. 1531 1194 North Mathilda Avenue 1532 Sunnyvale, CA 94089-1206 1533 US 1535 Email: weesan@juniper.net