--- 1/draft-ietf-mboned-mtrace-v2-15.txt 2016-10-31 17:17:41.165769393 -0700 +++ 2/draft-ietf-mboned-mtrace-v2-16.txt 2016-10-31 17:17:41.241771277 -0700 @@ -1,20 +1,20 @@ MBONED Working Group H. Asaeda Internet-Draft NICT Intended status: Standards Track K. Meyer -Expires: February 14, 2017 Cisco +Expires: May 4, 2017 Cisco W. Lee, Ed. - August 13, 2016 + October 31, 2016 Mtrace Version 2: Traceroute Facility for IP Multicast - draft-ietf-mboned-mtrace-v2-15 + draft-ietf-mboned-mtrace-v2-16 Abstract This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a query and receives a reply. @@ -26,45 +26,45 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 14, 2017. + This Internet-Draft will expire on May 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . 7 - 3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 8 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 10 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 11 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 14 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 17 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 18 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 19 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 19 @@ -103,22 +103,23 @@ 6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 28 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 29 7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 29 7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 29 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 30 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 30 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 - 8.1. Forwarding Codes . . . . . . . . . . . . . . . . . . . . 31 - 8.2. UDP Destination Port . . . . . . . . . . . . . . . . . . 31 + 8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 31 + 8.2. "Mtrace2 TLV Types" registry . . . . . . . . . . . . . . 31 + 8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 31 9.2. Filtering of Clients . . . . . . . . . . . . . . . . . . 31 9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 32 9.4. Characteristics of Multicast Channel . . . . . . . . . . 32 9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 32 9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 33 @@ -131,41 +132,46 @@ to a receiver is difficult, since we do not know which branch of the multicast tree the receiver lies. This means that we have to flood the whole tree to find the path from a source to a receiver. On the other hand, walking up the tree from a receiver to a source is easy, as most existing multicast routing protocols know the upstream router for each source. Tracing from a receiver to a source can involve only the routers on the direct path. This document specifies the multicast traceroute facility named Mtrace version 2 or Mtrace2 which allows the tracing of an IP - multicast routing path. Mtrace2 is usually initiated from a Mtrace2 - client towards a specified source, or a Rendezvous Point (RP) if no - source address is specified. RP is a special router where the source - and receiver meet in PIM-SM [5]. Moreover, Mtrace2 provides - additional information such as the packet rates and losses, as well - as other diagnosis information. Especially, Mtrace2 can be used for - the following purposes: + multicast routing path. Mtrace2 is usually initiated from an Mtrace2 + client by sending an Mtrace2 Query to a Last Hop Router (LHR) or to a + Rendezvous Point (RP). The RP is a special router where sources and + receivers meet in PIM-SM [5]. From the LHR/RP receiving the query, + the tracing is directed towards a specified source if a source + address is specified and source specific state exists on the + receiving router. If no source address is specified or if no source + specific state exists on a receiving LHR, the tracing is directed + toward the RP for the specified group address. Moreover, Mtrace2 + provides additional information such as the packet rates and losses, + as well as other diagnostic information. Mtrace2 is primarily + intended for the following purposes: o To trace the path that a packet would take from a source to a receiver. o To isolate packet loss problems (e.g., congestion). o To isolate configuration problems (e.g., TTL threshold). Figure 1 shows a typical case on how Mtrace2 is used. FHR represents the first-hop router, LHR represents the last-hop router, and the arrow lines represent the Mtrace2 messages that are sent from one node to another. The numbers before the Mtrace2 messages represent the sequence of the messages that would happen. Source, Receiver and - Mtrace2 client are typically a host on the Internet. + Mtrace2 client are typically hosts. 2. Request 2. Request +----+ +----+ | | | | v | v | +--------+ +-----+ +-----+ +----------+ | Source |----| FHR |----- The Internet -----| LHR |----| Receiver | +--------+ +-----+ | +-----+ +----------+ \ | ^ \ | / @@ -174,38 +180,43 @@ 3. Reply \ | / 1. Query \ | / \ | / \ +---------+ / v | Mtrace2 |/ | client | +---------+ Figure 1 - When an Mtrace2 client initiates a multicast trace anywhere on the - Internet, it sends an Mtrace2 Query packet to the LHR or RP for a - multicast group and a source address. The LHR/RP turns the Query - packet into a Request, appends a standard response block containing - its interface addresses and packet statistics to the Request packet, - then forwards the packet towards the source. The Request packet is - either unicasted to its upstream router towards the source, or + When an Mtrace2 client initiates a multicast trace, it sends an + Mtrace2 Query packet to the LHR or RP for a multicast group and, + optionally, a source address. The LHR/RP turns the Query packet into + a Request. The Request message type enables each of the upstream + routers processing the message to apply different packet and message + validation rules than those required for handling of a Query message. + The LHR/RP then appends a standard response block containing its + interface addresses and packet statistics to the Request packet, then + forwards the packet towards the source/RP. The Request packet is + either unicasted to its upstream router towards the source/RP, or multicasted to the group if the upstream router's IP address is not known. In a similar fashion, each router along the path to the - source appends a standard response block to the end of the Request + source/RP appends a standard response block to the end of the Request packet before forwarding it to its upstream router. When the FHR receives the Request packet, it appends its own standard response block, turns the Request packet into a Reply, and unicasts the Reply back to the Mtrace2 client. - The Mtrace2 Reply may be returned before reaching the FHR if it - reaches the RP first, or a fatal error condition such as "no route" - is encountered along the path, or the hop count is exceeded. + The Mtrace2 Reply may be returned before reaching the FHR under some + circumstances. This can happen if a Request packet is received at an + RP or gateway, or when any of several types of error or exception + conditions occur which prevent sending of a request to the next + upstream router. The Mtrace2 client waits for the Mtrace2 Reply message and displays the results. When not receiving an Mtrace2 Reply message due to network congestion, a broken router (see Section 5.6), or a non- responding router (see Section 5.7), the Mtrace2 client may resend another Mtrace2 Query with a lower hop count (see Section 3.2.1), and repeat the process until it receives an Mtrace2 Reply message. The details are Mtrace2 client specific, and it is outside the scope of this document. @@ -232,37 +243,37 @@ Since Mtrace2 Queries and Requests flow in the opposite direction to the data flow, we refer to "upstream" and "downstream" with respect to data, unless explicitly specified. Incoming interface The interface on which data is expected to arrive from the specified source and group. Outgoing interface - The interface to which data from the source or RP is expected to - transmit for the specified source and group. It is also the - interface on which the Mtrace2 Request will be received. + This is one of the interfaces to which data from the source or RP + is expected to be transmitted for the specified source and group. + It is also the interface on which the Mtrace2 Request was + received. Upstream router The router, connecting to the Incoming interface of the current router, which is responsible for forwarding data for the specified source and group to the current router. First-hop router (FHR) The router that is directly connected to the source the Mtrace2 Query specifies. Last-hop router (LHR) - The router that is directly connected to the receivers. It is - also the router that receives the Mtrace2 Query from an Mtrace2 - client. + A router that is directly connected to a receiver. It is also the + router that receives the Mtrace2 Query from an Mtrace2 client. Group state It is the state a shared-tree protocol, such as PIM-SM [5], uses to choose the upstream router towards the RP for the specified group. In this state, source-specific state is not available for the corresponding group address on the router. Source-specific state It is the state that is used to choose the path towards the source for the specified source and group. @@ -272,25 +283,37 @@ communicate with their adjacent routers that are running the same routing protocol. For instance, the address of ALL-PIM- ROUTERS.MCAST.NET [5] is '224.0.0.13' for IPv4 and 'ff02::d' for IPv6. 3. Packet Formats This section describes the details of the packet formats for Mtrace2 messages. - All Mtrace2 messages are encoded in TLV format (see Section 3.1). If - an implementation receives an unknown TLV, it SHOULD ignore and - silently discard the unknown TLV. If the length of a TLV exceeds the - length specified in the TLV, the TLV SHOULD be accepted; however, any - additional data after the specified TLV length SHOULD be ignored. + All Mtrace2 messages are encoded in TLV format (see Section 3.1). + The first TLV of a message is a message header TLV specifying the + type of message and additional context information required for + processing of the message and for parsing of subsequent TLVs in the + message. Subsequent TLVs in a message, referred to as Blocks, are + appended after the header TLV to provide additional information + associated with the message. If an implementation receives an + unknown TLV type for the first TLV in a message, it SHOULD ignore and + silently discard the TLV and any subsequent TLVs in the packet + containing the TLV. If an implementation receives an unknown TLV + type for a subsequent TLV within a message, it SHOULD ignore and + silently discard the TLV. If the length of a TLV exceeds the + available space in the containing packet, the implementation MUST + ignore and silently discard the TLV and any remaining portion of the + containing packet. Any data in the packet after the specified TLV + length is considered to be outside the boundary of the TLV and MUST + be ignored during processing of the TLV. All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 Query and Request messages MUST NOT be fragmented. For IPv6, the packet size for the Mtrace2 messages MUST NOT exceed 1280 bytes, which is the smallest MTU for an IPv6 interface [2]. The source port is uniquely selected by the local host operating system. The destination port is the IANA reserved Mtrace2 port number (see Section 8). All Mtrace2 messages MUST have a valid UDP checksum. Additionally, Mtrace2 supports both IPv4 and IPv6, but not mixed. @@ -307,22 +330,22 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 8 bits Describes the format of the Value field. For all the available types, please see Section 3.2 Length: 16 bits Length of Type, Length, and Value fields in octets. Minimum - length required is 6 octets. The maximum TLV length is not - defined; however the entire Mtrace2 packet length should not + length required is 3 octets. The maximum TLV length is not + defined; however the entire Mtrace2 packet length SHOULD NOT exceed the available MTU. Value: variable length The format is based on the Type value. The length of the value field is Length field minus 3. All reserved fields in the Value field MUST be transmitted as zeros and ignored on receipt. 3.2. Defined TLVs @@ -480,21 +503,21 @@ | | . Total number of packets for this source-group pair . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtg Protocol | Multicast Rtg Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fwd TTL | MBZ |S| Src Mask |Forwarding Code| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MBZ: 8 bits - This field must be zeroed on transmission and ignored on + This field MUST be zeroed on transmission and ignored on reception. Query Arrival Time: 32 bits The Query Arrival Time is a 32-bit NTP timestamp specifying the arrival time of the Mtrace2 Query or Request packet at this router. The 32-bit form of an NTP timestamp consists of the middle 32 bits of the full 64-bit form; that is, the low 16 bits of the integer part and the high 16 bits of the fractional part. The following formula converts from a UNIX timeval to a 32-bit NTP @@ -584,23 +607,25 @@ source-group pair is for the source network, as determined by masking the source address with the Src Mask field. Src Mask: 7 bits This field contains the number of 1's in the netmask the router has for the source (i.e. a value of 24 means the netmask is 0xffffff00). If the router is forwarding solely on group state, this field is set to 127 (0x7f). Forwarding Code: 8 bits - This field contains a forwarding information/error code. - Section 4.1 and Section 4.2 will explain how and when the - Forwarding Code is filled. Defined values are as follows: + This field contains a forwarding information/error code. Values + with the high order bit set (0x80-0xff) are intended for use as + error or exception codes. Section 4.1 and Section 4.2 explain how + and when the Forwarding Code is filled. Defined values are as + follows: Value Name Description ----- -------------- ---------------------------------------------- 0x00 NO_ERROR No error 0x01 WRONG_IF Mtrace2 Request arrived on an interface to which this router would not forward for the specified group towards the source or RP. 0x02 PRUNE_SENT This router has sent a prune upstream which applies to the source and group in the Mtrace2 Request. @@ -672,21 +697,21 @@ | | . Total number of packets for this source-group pair . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtg Protocol | Multicast Rtg Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ 2 |S|Src Prefix Len |Forwarding Code| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MBZ: 8 bits - This field must be zeroed on transmission and ignored on + This field MUST be zeroed on transmission and ignored on reception. Query Arrival Time: 32 bits Same definition as in IPv4. Incoming Interface ID: 32 bits This field specifies the interface ID on which packets from the source or RP are expected to arrive, or 0 if unknown. This ID should be the value taken from InterfaceIndex of the IF-MIB [10] for this interface. @@ -735,21 +760,21 @@ the same value as ipMcastRoutePkts from the IPMROUTE-STD-MIB [11] for this forwarding entry. Rtg Protocol: 16 bits Same definition as in IPv4. Multicast Rtg Protocol: 16 bits Same definition as in IPv4. MBZ 2: 15 bits - This field must be zeroed on transmission and ignored on + This field MUST be zeroed on transmission and ignored on reception. S: 1 bit Same definition as in IPv4, except the Src Prefix Len field is used to mask the source address. Src Prefix Len: 8 bits This field contains the prefix length this router has for the source. If the router is forwarding solely on group state, this field is set to 255 (0xff). @@ -769,21 +794,21 @@ 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Augmented Response Type | Value .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MBZ: 8 bits - This field must be zeroed on transmission and ignored on + This field MUST be zeroed on transmission and ignored on reception. Augmented Response Type: 16 bits This field specifies the type of various responses from a multicast router that might need to communicate back to the Mtrace2 client as well as the multicast routers on the traced path. The Augmented Response Type is defined as follows: @@ -830,21 +855,21 @@ 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MBZ |T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Query Type | Value .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MBZ: 7 bits - This field must be zeroed on transmission and ignored on + This field MUST be zeroed on transmission and ignored on reception. T-bit (Transitive Attribute): 1 bit If the TLV type is unrecognized by the receiving router, then this TLV is either discarded or forwarded along with the Query, depending on the value of this bit. If this bit is set, then the router MUST forward this TLV. If this bit is clear, the router MUST send an Mtrace2 Reply with an UNKNOWN_QUERY error. Extended Query Type: 16 bits @@ -899,157 +924,161 @@ Duplicate Query messages as identified by the tuple (Mtrace2 Client Address, Query ID) SHOULD be ignored. This MAY be implemented using a cache of previously processed queries keyed by the Mtrace2 Client Address and Query ID pair. The duration of the cached entries is implementation specific. Duplicate Request messages MUST NOT be ignored in this manner. 4.1.2. Query Normal Processing When a router receives an Mtrace2 Query and it determines that it is - the proper LHR, it turns the Query to a Request by changing the TLV - type from 0x01 to 0x02, and performs the steps listed in Section 4.2. + the proper LHR/RP, it turns the Query to a Request by changing the + TLV type from 0x01 to 0x02, and performs the steps listed in + Section 4.2. 4.2. Receiving Mtrace2 Request An Mtrace2 Request is an Mtrace2 message that uses TLV type of 0x02. With the exception of the LHR, whose Request was just converted from a Query, each Request received by a router should have at least one Standard Response Block filled in. 4.2.1. Request Packet Verification If the Mtrace2 Request does not come from an adjacent router, or if the Request is not addressed to this router, or if the Request is addressed to a multicast group which is not a link-scoped group (i.e. - 224/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be silently + 224.0.0.0/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be silently ignored. GTSM [12] SHOULD be used by the router to determine whether the router is adjacent or not. If the sum of the number of the Standard Response Blocks in the received Mtrace2 Request and the value of the Augmented Response Type of 0x01, if any, is equal or more than the # Hops in the Mtrace2 Request, it MUST be silently ignored. 4.2.2. Request Normal Processing When a router receives an Mtrace2 Request message, it performs the following steps. Note that it is possible to have multiple situations covered by the Forwarding Codes. The first one encountered is the one that is reported, i.e. all "note Forwarding Code N" should be interpreted as "if Forwarding Code is not already - set, set Forwarding Code to N". + set, set Forwarding Code to N". Note that in the steps described + below the "Outgoing Interface" is the one on which the Mtrace2 + Request message arrives. - 1. Prepare a Standard Response Block to be appended to the packet - and fill in the Query Arrival Time, Outgoing Interface Address - (for IPv4) or Outgoing Interface ID (for IPv6), Output Packet - Count, and Fwd TTL (for IPv4). Note that the Outgoing Interface - is the one on which the Mtrace2 Request message arrives. + 1. Prepare a Standard Response Block to be appended to the packet, + setting all fields to an initial default value of zero. - 2. Attempt to determine the forwarding information for the + 2. If Mtrace2 is administratively prohibited, note the Forwarding + Code of ADMIN_PROHIB and skip to step 4. + + 3. In the Standard Response Block, fill in the Query Arrival Time, + Outgoing Interface Address (for IPv4) or Outgoing Interface ID + (for IPv6), Output Packet Count, and Fwd TTL (for IPv4). + + 4. Attempt to determine the forwarding information for the specified source and group, using the same mechanisms as would be used when a packet is received from the source destined for the group. A state need not be instantiated, it can be a "phantom" state created only for the purpose of the trace, such as "dry-run." If using a shared-tree protocol and there is no source-specific state, or if no source-specific information is desired (i.e., all 1's for IPv4 or unspecified address (::) for IPv6), group state should be used. If there is no group state or no group- specific information is desired, potential source state (i.e., the path that would be followed for a source-specific Join) should be used. - 3. If no forwarding information can be determined, the router notes + 5. If no forwarding information can be determined, the router notes a Forwarding Code of NO_ROUTE, sets the remaining fields that have not yet been filled in to zero, and then sends an Mtrace2 Reply back to the Mtrace2 client. - 4. Fill in the Incoming Interface Address (or Incoming Interface ID - and Local Address for IPv6), Upstream Router Address (or Remote - Address for IPv6), Input Packet Count, Total Number of Packets, - Routing Protocol, S, and Src Mask (or Src Prefix Len for IPv6) - using the forwarding information determined by the step 2. - - 5. If Mtrace2 is administratively prohibited, note the Forwarding - Code of ADMIN_PROHIB. If Mtrace2 is administratively prohibited - and any of the fields as filled in the step 4 are considered - private information, zero out the applicable fields. + 6. If a Forwarding Code of ADMIN_PROHIB has been set, skip to step + 7. Otherwise, fill in the Incoming Interface Address (or + Incoming Interface ID and Local Address for IPv6), Upstream + Router Address (or Remote Address for IPv6), Input Packet Count, + Total Number of Packets, Routing Protocol, S, and Src Mask (or + Src Prefix Len for IPv6) using the forwarding information + determined in step 4. - 6. If the Outgoing interface is not enabled for multicast, note + 7. If the Outgoing interface is not enabled for multicast, note Forwarding Code of NO_MULTICAST. If the Outgoing interface is the interface from which the router would expect data to arrive from the source, note forwarding code RPF_IF. If the Outgoing interface is not one to which the router would forward data from the source or RP to the group, a Forwarding code of WRONG_IF is noted. In the above three cases, the router will return an Mtrace2 Reply and terminate the trace. - 7. If the group is subject to administrative scoping on either the + 8. If the group is subject to administrative scoping on either the Outgoing or Incoming interfaces, a Forwarding Code of SCOPED is noted. - 8. If this router is the RP for the group for a non-source-specific + 9. If this router is the RP for the group for a non-source-specific query, note a Forwarding Code of REACHED_RP. The router will send an Mtrace2 Reply and terminate the trace. - 9. If this router is directly connected to the specified source or + 10. If this router is directly connected to the specified source or source network on the Incoming interface, it sets the Upstream Router Address (for IPv4) or the Remote Address (for IPv6) of the response block to zero. The router will send an Mtrace2 Reply and terminate the trace. - 10. If this router has sent a prune upstream which applies to the - source and group in the Mtrace2 Request, it notes Forwarding + 11. If this router has sent a prune upstream which applies to the + source and group in the Mtrace2 Request, it notes a Forwarding Code of PRUNE_SENT. If the router has stopped forwarding downstream in response to a prune sent by the downstream router, - it notes Forwarding Code of PRUNE_RCVD. If the router should + it notes a Forwarding Code of PRUNE_RCVD. If the router should normally forward traffic downstream for this source and group - but is not, it notes Forwarding Code of NOT_FORWARDING. + but is not, it notes a Forwarding Code of NOT_FORWARDING. - 11. If this router is a gateway (e.g., a NAT or firewall) that hides + 12. If this router is a gateway (e.g., a NAT or firewall) that hides the information between this router and the Mtrace2 client, it - notes Forwarding Code of REACHED_GW. The router continues the + notes a Forwarding Code of REACHED_GW. The router continues the processing as described in Section 4.5. - 12. If the total number of the Standard Response Blocks, including + 13. If the total number of the Standard Response Blocks, including the newly prepared one, and the value of the Augmented Response Type of 0x01, if any, is less than the # Hops in the Request, the packet is then forwarded to the upstream router as described in Section 4.3; otherwise, the packet is sent as an Mtrace2 Reply to the Mtrace2 client as described in Section 4.4. 4.3. Forwarding Mtrace2 Request This section describes how an Mtrace2 Request should be forwarded. 4.3.1. Destination Address If the upstream router for the Mtrace2 Request is known for this request, the Mtrace2 Request is sent to that router. If the Incoming interface is known but the upstream router is not, the Mtrace2 Request is sent to an appropriate multicast address on the Incoming interface. The multicast address SHOULD depend on the multicast routing protocol in use, such as ALL-[protocol]-ROUTERS.MCAST.NET. - It MUST be a link-scoped group (i.e. 224/24 for IPv4, FF02::/16 for - IPv6), and MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 and - All Nodes Address (FF02::1) for IPv6. It MAY also be ALL- + It MUST be a link-scoped group (i.e. 224.0.0.0/24 for IPv4, FF02::/16 + for IPv6), and MUST NOT be ALL-SYSTEMS.MCAST.NET (224.0.0.1) for IPv4 + and All Nodes Address (FF02::1) for IPv6. It MAY also be ALL- ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6 if the routing protocol in use does not define a more appropriate multicast address. 4.3.2. Source Address An Mtrace2 Request should be sent with the address of the Incoming interface. However, if the Incoming interface is unnumbered, the - router can use one of its numbered interface address as the source + router can use one of its numbered interface addresses as the source address. 4.3.3. Appending Standard Response Block An Mtrace2 Request MUST be sent upstream towards the source or the RP after appending a Standard Response Block to the end of the received Mtrace2 Request. The Standard Response Block includes the multicast states and statistics information of the router described in Section 3.2.4. @@ -1077,49 +1106,51 @@ 4.4.1. Destination Address An Mtrace2 Reply MUST be sent to the address specified in the Mtrace2 Client Address field in the Mtrace2 Request. 4.4.2. Source Address An Mtrace2 Reply SHOULD be sent with the address of the router's Outgoing interface. However, if the Outgoing interface address is - unnumbered, the router can use one of its numbered interface address - as the source address. + unnumbered, the router can use one of its numbered interface + addresses as the source address. 4.4.3. Appending Standard Response Block An Mtrace2 Reply MUST be sent with the prepared Standard Response Block appended at the end of the received Mtrace2 Request except in the case of NO_SPACE forwarding code. 4.5. Proxying Mtrace2 Query When a gateway (e.g., a NAT or firewall), which needs to block unicast packets to the Mtrace2 client, or hide information between the gateway and the Mtrace2 client, receives an Mtrace2 Query from an adjacent host or Mtrace2 Request from an adjacent router, it appends - a Standard Response Block with REACHED_GW as the Forwarding Code, and - turns the Query or Request as a Reply, and sends the Reply back to + a Standard Response Block with REACHED_GW as the Forwarding Code. It + turns the Query or Request into a Reply, and sends the Reply back to the client. At the same time, the gateway originates a new Mtrace2 Query message by copying the original Mtrace2 header (the Query or Request without any of the response blocks), and makes the changes as follows: o sets the RPF interface's address as the Mtrace2 Client Address; o uses its own port number as the Client Port #; and, - o decreases # Hops by the number of the Standard Response Block that - was just returned as a Reply. + o decreases # Hops by ((number of the Standard Response Blocks that + were just returned in a Reply) - 1). The "-1" in this expression + accounts for the additional Standard Response Block appended by + the gateway router. The new Mtrace2 Query message is then sent to the upstream router or to an appropriate multicast address on the RPF interface. When the gateway receives an Mtrace2 Reply whose Query ID matches the one in the original Mtrace2 header, it MUST relay the Mtrace2 Reply back to the Mtrace2 client by replacing the Reply's header with the original Mtrace2 header. If the gateway does not receive the corresponding Mtrace2 Reply within the [Mtrace Reply Timeout] period (see Section 5.8.4), then it silently discards the original Mtrace2 @@ -1272,21 +1303,21 @@ router. If desired, each of those neighbors could be probed to determine the remainder of the path. Unfortunately, this heuristic may end up with multiple paths, since there is no way of knowing what the non-responding router's algorithm for choosing an upstream router is. However, if all paths but one flow back towards the non- responding router, it is possible to be sure that this is the correct path. 6. Protocol-Specific Considerations - This section describes the Mtrace2 behavior with the present of + This section describes the Mtrace2 behavior with the presence of different multicast protocols. 6.1. PIM-SM When an Mtrace2 reaches a PIM-SM RP, and the RP does not forward the trace on, it means that the RP has not performed a source-specific join so there is no more state to trace. However, the path that traffic would use if the RP did perform a source-specific join can be traced by setting the trace destination to the RP, the trace source to the traffic source, and the trace group to 0. This Mtrace2 Query @@ -1396,35 +1427,42 @@ 7.5. Time Delay If the routers have synchronized clocks, it is possible to estimate propagation and queuing delay from the differences between the timestamps at successive hops. However, this delay includes control processing overhead, so is not necessarily indicative of the delay that data traffic would experience. 8. IANA Considerations - The following new assignments can only be made via a Standards Action - as specified in [4]. + The following new registries are to be created and maintained under + the "RFC Required" registry policy as specified in [4]. -8.1. Forwarding Codes +8.1. "Mtrace2 Forwarding Codes" Registry - New Forwarding Codes must only be created by an RFC that modifies - this document's Section 3.2.4 and Section 3.2.5, fully describing the - conditions under which the new Forwarding Code is used. The IANA may - act as a central repository so that there is a single place to look - up Forwarding Codes and the document in which they are defined. + This is an integer in the range 0-255. Assignment of a Forwarding + Code requires specification of a value and a name for the Forwarding + Code. Initial values for the forwarding codes are given in the table + at the end of Section 3.2.4. Additional values (specific to IPv6) + may also be specified at the end of Section 3.2.5. Any additions to + this registry are required to fully describe the conditions under + which the new Forwarding Code is used. -8.2. UDP Destination Port +8.2. "Mtrace2 TLV Types" registry - The IANA should allocate UDP destination port for Mtrace2 upon - publication of the first RFC. + Assignment of a TLV Type requires specification of an integer value + "Code" in the range 0-255 and a name ("Type"). Initial values for + the TLV Types are given in the table at the beginning of Section 3.2. + +8.3. UDP Destination Port + + The Mtrace2 UDP destination port is [TBD]. 9. Security Considerations This section addresses some of the security considerations related to Mtrace2. 9.1. Addresses in Mtrace2 Header An Mtrace2 header includes three addresses, source address, multicast address, and Mtrace2 client address. These addresses MUST be @@ -1478,23 +1516,23 @@ mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original multicast traceroute client, mtrace (version 1), has been implemented by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the "S" bit to allow statistics for a source subnet is due to Tom Pusateri. For the Mtrace version 2 specification, the authors would like to give special thanks to Tatsuya Jinmei, Bill Fenner, and Steve Casner. Also, extensive comments were received from David L. Black, Ronald - Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert Kebler, Heidi Ou, - Pekka Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, - Stig Venaas, and Cao Wei. + Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert Kebler, John + Kristoff, Heidi Ou, Pekka Savola, Shinsuke Suzuki, Dave Thaler, + Achmad Husni Thamrin, Stig Venaas, and Cao Wei. 11. References 11.1. Normative References [1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.