--- 1/draft-ietf-mboned-mtrace-v2-18.txt 2017-10-10 05:19:01.562789878 -0700 +++ 2/draft-ietf-mboned-mtrace-v2-19.txt 2017-10-10 05:19:01.754794434 -0700 @@ -1,74 +1,86 @@ MBONED Working Group H. Asaeda Internet-Draft NICT Intended status: Standards Track K. Meyer -Expires: March 1, 2018 Cisco +Expires: April 10, 2018 Cisco W. Lee, Ed. - August 28, 2017 + October 7, 2017 Mtrace Version 2: Traceroute Facility for IP Multicast - draft-ietf-mboned-mtrace-v2-18 + draft-ietf-mboned-mtrace-v2-19 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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/. + Drafts is at https://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 March 1, 2018. + This Internet-Draft will expire on April 10, 2018. Copyright Notice Copyright (c) 2017 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 + (https://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. + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . 7 + 3.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . 8 3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 9 - 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 10 - 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 10 - 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 11 + 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 11 + 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 11 + 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 12 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 15 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 18 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 19 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 20 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 20 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 21 4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 21 4.2.1. Request Packet Verification . . . . . . . . . . . . . 21 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 22 @@ -276,26 +289,26 @@ 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. - ALL-[protocol]-ROUTERS.MCAST.NET + ALL-[protocol]-ROUTERS group It is a link-local multicast address for multicast routers to 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. + routing protocol. For instance, the IPv4 'ALL-PIM-ROUTERS' group + is '224.0.0.13', and the IPv6 'ALL-PIM-ROUTERS' group is 'ff02::d' + [5]. 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). 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 @@ -554,21 +568,21 @@ Outgoing Interface Address: 32 bits This field specifies the address of the interface on which packets from the source or the RP are expected to transmit towards the receiver, or 0 if unknown or unnumbered. This is also the address of the interface on which the Mtrace2 Query or Request arrives. Upstream Router Address: 32 bits This field specifies the address of the upstream router from which this router expects packets from this source. This may be a - multicast group (e.g. ALL-[protocol]-ROUTERS.MCAST.NET) if the + multicast group (e.g., ALL-[protocol]-ROUTERS group) if the upstream router is not known because of the workings of the multicast routing protocol. However, it should be 0 if the incoming interface address is unknown or unnumbered. Input packet count on incoming interface: 64 bits This field contains the number of multicast packets received for all groups and sources on the incoming interface, or all 1's if no count can be reported. This counter may have the same value as ifHCInMulticastPkts from the IF-MIB [12] for this interface. @@ -741,24 +755,24 @@ This field specifies the address of the upstream router, which, in most cases, is a link-local unicast address for the upstream router. Although a link-local address does not have enough information to identify a node, it is possible to detect the upstream router with the assistance of Incoming Interface ID and the current router address (i.e., Local Address). Note that this may be a multicast group (e.g., ALL-[protocol]- - ROUTERS.MCAST.NET) if the upstream router is not known because of - the workings of a multicast routing protocol. However, it should - be the unspecified address (::) if the incoming interface address - is unknown. + ROUTERS group) if the upstream router is not known because of the + workings of a multicast routing protocol. However, it should be + the unspecified address (::) if the incoming interface address is + unknown. Input packet count on incoming interface: 64 bits Same definition as in IPv4. Output packet count on outgoing interface: 64 bits Same definition as in IPv4. Total number of packets for this source-group pair: 64 bits Same definition as in IPv4, except if the S bit is set (see below), the count is for the source network, as specified by the @@ -947,24 +961,24 @@ 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.0.0.0/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be silently - ignored. GTSM [14] SHOULD be used by the router to determine whether - the router is adjacent or not. + addressed to a multicast group which is not a link-scoped group + (i.e., 224.0.0.0/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be + silently ignored. GTSM [14] 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 @@ -1060,27 +1074,27 @@ 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.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. + routing protocol in use, such as ALL-[protocol]-ROUTERS group. It + MUST be a link-scoped group (i.e., 224.0.0.0/24 for IPv4, FF02::/16 + for IPv6), and MUST NOT be the all-systems multicast group + (224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6. It + MAY also be the all-routers multicast group (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 addresses as the source address. 4.3.3. Appending Standard Response Block @@ -1191,21 +1205,21 @@ 5.1. Sending Mtrace2 Query An Mtrace2 client initiates an Mtrace2 Query by sending the Query to the LHR of interest. 5.1.1. Destination Address If an Mtrace2 client knows the proper LHR, it unicasts an Mtrace2 Query packet to that router; otherwise, it MAY send the Mtrace2 Query - packet to the ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All + packet to the all-routers multicast group (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6. This will ensure that the packet is received by the LHR on the subnet. See also Section 5.4 on determining the LHR. 5.1.2. Source Address An Mtrace2 Query MUST be sent with the client's interface address, which would be the Mtrace2 Client Address. @@ -1228,34 +1242,33 @@ much as it can expect to (see Section 5.8), it might collect statistics by waiting a short time and performing a second trace. If the path is the same in the two traces, statistics can be displayed as described in Section 7.3 and Section 7.4. 5.4. Last Hop Router (LHR) The Mtrace2 client may not know which is the last-hop router, or that router may be behind a firewall that blocks unicast packets but passes multicast packets. In these cases, the Mtrace2 Request should - be multicasted to ALL-ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All - Routers Address (FF02::2) for IPv6. All routers except the correct - last-hop router SHOULD ignore any Mtrace2 Request received via - multicast. + be multicasted to the all-routers multicast group (224.0.0.2) for + IPv4 or All Routers Address (FF02::2) for IPv6. All routers except + the correct last-hop router SHOULD ignore any Mtrace2 Request + received via multicast. 5.5. First Hop Router (FHR) - The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default - multicast group for old IPv4 mtrace (v1) responses, in order to - support mtrace clients that are not unicast reachable from the first- - hop router. Mtrace2, however, does not require any IPv4/IPv6 - multicast addresses for the Mtrace2 Replies. Every Mtrace2 Reply is - sent to the unicast address specified in the Mtrace2 Client Address - field of the Mtrace2 Reply. + The IANA assigned 224.0.1.32 as the default multicast group for old + IPv4 mtrace (v1) responses, in order to support mtrace clients that + are not unicast reachable from the first-hop router. Mtrace2, + however, does not require any IPv4/IPv6 multicast addresses for the + Mtrace2 Replies. Every Mtrace2 Reply is sent to the unicast address + specified in the Mtrace2 Client Address field of the Mtrace2 Reply. 5.6. Broken Intermediate Router A broken intermediate router might simply not understand Mtrace2 packets, and drop them. The Mtrace2 client will get no Reply at all as a result. It should then perform a hop-by-hop search by setting the # Hops field until it gets an Mtrace2 Reply. The client may use linear or binary search; however, the latter is likely to be slower because a failure requires waiting for the [Mtrace Reply Timeout] period. @@ -1466,21 +1479,22 @@ which the new Forwarding Code is used. 8.2. "Mtrace2 TLV Types" registry 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]. + The Mtrace2 UDP destination port is assigned when this document is + published as RFC. 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 @@ -1551,22 +1565,23 @@ [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. [3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. - [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 5226, May 2008. + [4] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", RFC 8126, + June 2017. [5] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 7761, March 2016. [6] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007.