draft-ietf-mboned-mtrace-v2-18.txt   draft-ietf-mboned-mtrace-v2-19.txt 
MBONED Working Group H. Asaeda MBONED Working Group H. Asaeda
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track K. Meyer Intended status: Standards Track K. Meyer
Expires: March 1, 2018 Cisco Expires: April 10, 2018 Cisco
W. Lee, Ed. W. Lee, Ed.
August 28, 2017 October 7, 2017
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-18 draft-ietf-mboned-mtrace-v2-19
Abstract Abstract
This document describes the IP multicast traceroute facility, named This document describes the IP multicast traceroute facility, named
Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2
requires special implementations on the part of routers. This requires special implementations on the part of routers. This
specification describes the required functionality in multicast specification describes the required functionality in multicast
routers, as well as how an Mtrace2 client invokes a query and routers, as well as how an Mtrace2 client invokes a query and
receives a reply. receives a reply.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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 publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . 7 3.1. Mtrace2 TLV format . . . . . . . . . . . . . . . . . . . 8
3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 10 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 11
3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 11
3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 11 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 12
3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 15 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 15
3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 18 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 18
3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 19 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 19
4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 20 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 20
4.1.1. Query Packet Verification . . . . . . . . . . . . . . 20 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 20
4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 21 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 21
4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 21 4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 21
4.2.1. Request Packet Verification . . . . . . . . . . . . . 21 4.2.1. Request Packet Verification . . . . . . . . . . . . . 21
4.2.2. Request Normal Processing . . . . . . . . . . . . . . 22 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 22
skipping to change at page 6, line 52 skipping to change at page 7, line 26
Group state Group state
It is the state a shared-tree protocol, such as PIM-SM [5], uses 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 to choose the upstream router towards the RP for the specified
group. In this state, source-specific state is not available for group. In this state, source-specific state is not available for
the corresponding group address on the router. the corresponding group address on the router.
Source-specific state Source-specific state
It is the state that is used to choose the path towards the source It is the state that is used to choose the path towards the source
for the specified source and group. 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 It is a link-local multicast address for multicast routers to
communicate with their adjacent routers that are running the same communicate with their adjacent routers that are running the same
routing protocol. For instance, the address of ALL-PIM- routing protocol. For instance, the IPv4 'ALL-PIM-ROUTERS' group
ROUTERS.MCAST.NET [5] is '224.0.0.13' for IPv4 and 'ff02::d' for is '224.0.0.13', and the IPv6 'ALL-PIM-ROUTERS' group is 'ff02::d'
IPv6. [5].
3. Packet Formats 3. Packet Formats
This section describes the details of the packet formats for Mtrace2 This section describes the details of the packet formats for Mtrace2
messages. messages.
All Mtrace2 messages are encoded in TLV format (see Section 3.1). 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 The first TLV of a message is a message header TLV specifying the
type of message and additional context information required for type of message and additional context information required for
processing of the message and for parsing of subsequent TLVs in the processing of the message and for parsing of subsequent TLVs in the
skipping to change at page 12, line 44 skipping to change at page 13, line 36
Outgoing Interface Address: 32 bits Outgoing Interface Address: 32 bits
This field specifies the address of the interface on which packets This field specifies the address of the interface on which packets
from the source or the RP are expected to transmit towards the from the source or the RP are expected to transmit towards the
receiver, or 0 if unknown or unnumbered. This is also the address receiver, or 0 if unknown or unnumbered. This is also the address
of the interface on which the Mtrace2 Query or Request arrives. of the interface on which the Mtrace2 Query or Request arrives.
Upstream Router Address: 32 bits Upstream Router Address: 32 bits
This field specifies the address of the upstream router from which This field specifies the address of the upstream router from which
this router expects packets from this source. This may be a 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 upstream router is not known because of the workings of the
multicast routing protocol. However, it should be 0 if the multicast routing protocol. However, it should be 0 if the
incoming interface address is unknown or unnumbered. incoming interface address is unknown or unnumbered.
Input packet count on incoming interface: 64 bits Input packet count on incoming interface: 64 bits
This field contains the number of multicast packets received for This field contains the number of multicast packets received for
all groups and sources on the incoming interface, or all 1's if no 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 count can be reported. This counter may have the same value as
ifHCInMulticastPkts from the IF-MIB [12] for this interface. ifHCInMulticastPkts from the IF-MIB [12] for this interface.
skipping to change at page 17, line 30 skipping to change at page 17, line 30
This field specifies the address of the upstream router, which, in This field specifies the address of the upstream router, which, in
most cases, is a link-local unicast address for the upstream most cases, is a link-local unicast address for the upstream
router. router.
Although a link-local address does not have enough information to Although a link-local address does not have enough information to
identify a node, it is possible to detect the upstream router with identify a node, it is possible to detect the upstream router with
the assistance of Incoming Interface ID and the current router the assistance of Incoming Interface ID and the current router
address (i.e., Local Address). address (i.e., Local Address).
Note that this may be a multicast group (e.g., ALL-[protocol]- Note that this may be a multicast group (e.g., ALL-[protocol]-
ROUTERS.MCAST.NET) if the upstream router is not known because of ROUTERS group) if the upstream router is not known because of the
the workings of a multicast routing protocol. However, it should workings of a multicast routing protocol. However, it should be
be the unspecified address (::) if the incoming interface address the unspecified address (::) if the incoming interface address is
is unknown. unknown.
Input packet count on incoming interface: 64 bits Input packet count on incoming interface: 64 bits
Same definition as in IPv4. Same definition as in IPv4.
Output packet count on outgoing interface: 64 bits Output packet count on outgoing interface: 64 bits
Same definition as in IPv4. Same definition as in IPv4.
Total number of packets for this source-group pair: 64 bits Total number of packets for this source-group pair: 64 bits
Same definition as in IPv4, except if the S bit is set (see 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 below), the count is for the source network, as specified by the
skipping to change at page 21, line 41 skipping to change at page 21, line 41
An Mtrace2 Request is an Mtrace2 message that uses TLV type of 0x02. 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 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 a Query, each Request received by a router should have at least one
Standard Response Block filled in. Standard Response Block filled in.
4.2.1. Request Packet Verification 4.2.1. Request Packet Verification
If the Mtrace2 Request does not come from an adjacent router, or if 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 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. addressed to a multicast group which is not a link-scoped group
224.0.0.0/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be silently (i.e., 224.0.0.0/24 for IPv4, FFx2::/16 [3] for IPv6), it MUST be
ignored. GTSM [14] SHOULD be used by the router to determine whether silently ignored. GTSM [14] SHOULD be used by the router to
the router is adjacent or not. determine whether the router is adjacent or not.
If the sum of the number of the Standard Response Blocks in the If the sum of the number of the Standard Response Blocks in the
received Mtrace2 Request and the value of the Augmented Response Type 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 of 0x01, if any, is equal or more than the # Hops in the Mtrace2
Request, it MUST be silently ignored. Request, it MUST be silently ignored.
4.2.2. Request Normal Processing 4.2.2. Request Normal Processing
When a router receives an Mtrace2 Request message, it performs the When a router receives an Mtrace2 Request message, it performs the
following steps. Note that it is possible to have multiple following steps. Note that it is possible to have multiple
skipping to change at page 24, line 12 skipping to change at page 24, line 12
This section describes how an Mtrace2 Request should be forwarded. This section describes how an Mtrace2 Request should be forwarded.
4.3.1. Destination Address 4.3.1. Destination Address
If the upstream router for the Mtrace2 Request is known for this If the upstream router for the Mtrace2 Request is known for this
request, the Mtrace2 Request is sent to that router. If the Incoming request, the Mtrace2 Request is sent to that router. If the Incoming
interface is known but the upstream router is not, the Mtrace2 interface is known but the upstream router is not, the Mtrace2
Request is sent to an appropriate multicast address on the Incoming Request is sent to an appropriate multicast address on the Incoming
interface. The multicast address SHOULD depend on the multicast interface. The multicast address SHOULD depend on the multicast
routing protocol in use, such as ALL-[protocol]-ROUTERS.MCAST.NET. routing protocol in use, such as ALL-[protocol]-ROUTERS group. It
It MUST be a link-scoped group (i.e. 224.0.0.0/24 for IPv4, FF02::/16 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 for IPv6), and MUST NOT be the all-systems multicast group
and All Nodes Address (FF02::1) for IPv6. It MAY also be ALL- (224.0.0.1) for IPv4 and All Nodes Address (FF02::1) for IPv6. It
ROUTERS.MCAST.NET (224.0.0.2) for IPv4 or All Routers Address MAY also be the all-routers multicast group (224.0.0.2) for IPv4 or
(FF02::2) for IPv6 if the routing protocol in use does not define a All Routers Address (FF02::2) for IPv6 if the routing protocol in use
more appropriate multicast address. does not define a more appropriate multicast address.
4.3.2. Source Address 4.3.2. Source Address
An Mtrace2 Request should be sent with the address of the Incoming An Mtrace2 Request should be sent with the address of the Incoming
interface. However, if the Incoming interface is unnumbered, the interface. However, if the Incoming interface is unnumbered, the
router can use one of its numbered interface addresses as the source router can use one of its numbered interface addresses as the source
address. address.
4.3.3. Appending Standard Response Block 4.3.3. Appending Standard Response Block
skipping to change at page 27, line 9 skipping to change at page 27, line 9
5.1. Sending Mtrace2 Query 5.1. Sending Mtrace2 Query
An Mtrace2 client initiates an Mtrace2 Query by sending the Query to An Mtrace2 client initiates an Mtrace2 Query by sending the Query to
the LHR of interest. the LHR of interest.
5.1.1. Destination Address 5.1.1. Destination Address
If an Mtrace2 client knows the proper LHR, it unicasts an Mtrace2 If an Mtrace2 client knows the proper LHR, it unicasts an Mtrace2
Query packet to that router; otherwise, it MAY send the Mtrace2 Query 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 Routers Address (FF02::2) for IPv6. This will ensure that the packet
is received by the LHR on the subnet. is received by the LHR on the subnet.
See also Section 5.4 on determining the LHR. See also Section 5.4 on determining the LHR.
5.1.2. Source Address 5.1.2. Source Address
An Mtrace2 Query MUST be sent with the client's interface address, An Mtrace2 Query MUST be sent with the client's interface address,
which would be the Mtrace2 Client Address. which would be the Mtrace2 Client Address.
skipping to change at page 27, line 46 skipping to change at page 27, line 46
much as it can expect to (see Section 5.8), it might collect 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 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 the path is the same in the two traces, statistics can be displayed
as described in Section 7.3 and Section 7.4. as described in Section 7.3 and Section 7.4.
5.4. Last Hop Router (LHR) 5.4. Last Hop Router (LHR)
The Mtrace2 client may not know which is the last-hop router, or that 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 router may be behind a firewall that blocks unicast packets but
passes multicast packets. In these cases, the Mtrace2 Request should 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 be multicasted to the all-routers multicast group (224.0.0.2) for
Routers Address (FF02::2) for IPv6. All routers except the correct IPv4 or All Routers Address (FF02::2) for IPv6. All routers except
last-hop router SHOULD ignore any Mtrace2 Request received via the correct last-hop router SHOULD ignore any Mtrace2 Request
multicast. received via multicast.
5.5. First Hop Router (FHR) 5.5. First Hop Router (FHR)
The IANA assigned 224.0.1.32, MTRACE.MCAST.NET as the default The IANA assigned 224.0.1.32 as the default multicast group for old
multicast group for old IPv4 mtrace (v1) responses, in order to IPv4 mtrace (v1) responses, in order to support mtrace clients that
support mtrace clients that are not unicast reachable from the first- are not unicast reachable from the first-hop router. Mtrace2,
hop router. Mtrace2, however, does not require any IPv4/IPv6 however, does not require any IPv4/IPv6 multicast addresses for the
multicast addresses for the Mtrace2 Replies. Every Mtrace2 Reply is Mtrace2 Replies. Every Mtrace2 Reply is sent to the unicast address
sent to the unicast address specified in the Mtrace2 Client Address specified in the Mtrace2 Client Address field of the Mtrace2 Reply.
field of the Mtrace2 Reply.
5.6. Broken Intermediate Router 5.6. Broken Intermediate Router
A broken intermediate router might simply not understand Mtrace2 A broken intermediate router might simply not understand Mtrace2
packets, and drop them. The Mtrace2 client will get no Reply at all 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 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 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 linear or binary search; however, the latter is likely to be slower
because a failure requires waiting for the [Mtrace Reply Timeout] because a failure requires waiting for the [Mtrace Reply Timeout]
period. period.
skipping to change at page 33, line 7 skipping to change at page 33, line 7
which the new Forwarding Code is used. which the new Forwarding Code is used.
8.2. "Mtrace2 TLV Types" registry 8.2. "Mtrace2 TLV Types" registry
Assignment of a TLV Type requires specification of an integer value Assignment of a TLV Type requires specification of an integer value
"Code" in the range 0-255 and a name ("Type"). Initial values for "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. the TLV Types are given in the table at the beginning of Section 3.2.
8.3. UDP Destination Port 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 9. Security Considerations
This section addresses some of the security considerations related to This section addresses some of the security considerations related to
Mtrace2. Mtrace2.
9.1. Addresses in Mtrace2 Header 9.1. Addresses in Mtrace2 Header
An Mtrace2 header includes three addresses, source address, multicast An Mtrace2 header includes three addresses, source address, multicast
address, and Mtrace2 client address. These addresses MUST be address, and Mtrace2 client address. These addresses MUST be
skipping to change at page 34, line 43 skipping to change at page 34, line 45
[1] Bradner, S., "Key words for use in RFCs to indicate [1] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997. requirement levels", RFC 2119, March 1997.
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an [4] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
IANA Considerations Section in RFCs", RFC 5226, May 2008. Writing an IANA Considerations Section in RFCs", RFC 8126,
June 2017.
[5] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [5] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", RFC 7761, March 2016. (Revised)", RFC 7761, March 2016.
[6] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [6] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
 End of changes. 21 change blocks. 
46 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/