draft-ietf-mboned-mtrace-v2-17.txt   draft-ietf-mboned-mtrace-v2-18.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: September 13, 2017 Cisco Expires: March 1, 2018 Cisco
W. Lee, Ed. W. Lee, Ed.
March 12, 2017 August 28, 2017
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-17 draft-ietf-mboned-mtrace-v2-18
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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 http://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 September 13, 2017. This Internet-Draft will expire on March 1, 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 (http://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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 7
3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 10 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 10
3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 10
3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 11 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 11
3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 14 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 15
3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 17 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 18
3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 18 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 19
4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 19 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 20
4.1.1. Query Packet Verification . . . . . . . . . . . . . . 19 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 20
4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 20 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 21
4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 20 4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 21
4.2.1. Request Packet Verification . . . . . . . . . . . . . 20 4.2.1. Request Packet Verification . . . . . . . . . . . . . 21
4.2.2. Request Normal Processing . . . . . . . . . . . . . . 21 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 22
4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 22 4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 23
4.3.1. Destination Address . . . . . . . . . . . . . . . . . 23 4.3.1. Destination Address . . . . . . . . . . . . . . . . . 24
4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 23 4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 24
4.3.3. Appending Standard Response Block . . . . . . . . . . 23 4.3.3. Appending Standard Response Block . . . . . . . . . . 24
4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 24 4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 25
4.4.1. Destination Address . . . . . . . . . . . . . . . . . 24 4.4.1. Destination Address . . . . . . . . . . . . . . . . . 25
4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 24 4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 25
4.4.3. Appending Standard Response Block . . . . . . . . . . 24 4.4.3. Appending Standard Response Block . . . . . . . . . . 25
4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 24 4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 25
4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 25 4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 26
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 25 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 25 5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 26
5.1.1. Destination Address . . . . . . . . . . . . . . . . . 25 5.1.1. Destination Address . . . . . . . . . . . . . . . . . 27
5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 25 5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 27
5.2. Determining the Path . . . . . . . . . . . . . . . . . . 26 5.2. Determining the Path . . . . . . . . . . . . . . . . . . 27
5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 26 5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 27
5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 26 5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 27
5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 26 5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 28
5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 26 5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 28
5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 27 5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 28
5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 27 5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 28
5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 27 5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 28
5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 27 5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 29
5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 27 5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 29
5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 27 5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 29
5.9. Continuing after an Error . . . . . . . . . . . . . . . . 28 5.9. Continuing after an Error . . . . . . . . . . . . . . . . 29
6. Protocol-Specific Considerations . . . . . . . . . . . . . . 28 6. Protocol-Specific Considerations . . . . . . . . . . . . . . 29
6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 28 6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 30
6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 29 6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 30
7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 29 7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 31
7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 29 7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 31
7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 29 7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 31
7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 30 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31
7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 30 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 32
7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 30 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 31 8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 32
8.2. "Mtrace2 TLV Types" registry . . . . . . . . . . . . . . 31 8.2. "Mtrace2 TLV Types" registry . . . . . . . . . . . . . . 32
8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 31 8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 31 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 33
9.2. Filtering of Clients . . . . . . . . . . . . . . . . . . 31 9.2. Filtering of Clients . . . . . . . . . . . . . . . . . . 33
9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 32 9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 33
9.4. Characteristics of Multicast Channel . . . . . . . . . . 32 9.4. Characteristics of Multicast Channel . . . . . . . . . . 33
9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 32 9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 33
9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 32 9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 34
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.1. Normative References . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . 34
11.2. Informative References . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Given a multicast distribution tree, tracing from a multicast source Given a multicast distribution tree, tracing from a multicast source
to a receiver is difficult, since we do not know which branch of the 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 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 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, other hand, walking up the tree from a receiver to a source is easy,
as most existing multicast routing protocols know the upstream router as most existing multicast routing protocols know the upstream router
for each source. Tracing from a receiver to a source can involve for each source. Tracing from a receiver to a source can involve
skipping to change at page 5, line 45 skipping to change at page 5, line 45
of sync, the Mtrace2 Requests might be forwarded based on the control of sync, the Mtrace2 Requests might be forwarded based on the control
states instead. In which case, the traced path might not represent states instead. In which case, the traced path might not represent
the real path the data packets would follow. the real path the data packets would follow.
Mtrace2 supports both IPv4 and IPv6. Unlike the previous version of Mtrace2 supports both IPv4 and IPv6. Unlike the previous version of
Mtrace, which implements its query and response as IGMP messages [8], Mtrace, which implements its query and response as IGMP messages [8],
all Mtrace2 messages are UDP-based. Although the packet formats of all Mtrace2 messages are UDP-based. Although the packet formats of
IPv4 and IPv6 Mtrace2 are different because of the address families, IPv4 and IPv6 Mtrace2 are different because of the address families,
the syntax between them is similar. the syntax between them is similar.
This document describes the base specification of Mtrace2 that can
serve as a basis for future proposals such as Mtrace2 for AMT [9] and
Mtrace2 for MVPN [10]. They are therefore out of the scope of this
document.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], and "OPTIONAL" are to be interpreted as described in RFC 2119 [1],
and indicate requirement levels for compliant Mtrace2 and indicate requirement levels for compliant Mtrace2
implementations. implementations.
2.1. Definitions 2.1. Definitions
skipping to change at page 8, line 48 skipping to change at page 9, line 10
followed by one or multiple Augmented Response Blocks. followed by one or multiple Augmented Response Blocks.
We will describe each message type in detail in the next few We will describe each message type in detail in the next few
sections. sections.
3.2.1. Mtrace2 Query 3.2.1. Mtrace2 Query
An Mtrace2 Query is usually originated by an Mtrace2 client which An Mtrace2 Query is usually originated by an Mtrace2 client which
sends an Mtrace2 Query message to the LHR. When tracing towards the sends an Mtrace2 Query message to the LHR. When tracing towards the
source or the RP, the intermediate routers MUST NOT modify the Query source or the RP, the intermediate routers MUST NOT modify the Query
message except the Type field. message except the Type field. If the actual number of hops is not
known, an Mtrace2 client could send an initial Query message with a
large # Hops (e.g., 0xffffffff), in order to try to trace the full
path.
An Mtrace2 Query message is shown as follows: An Mtrace2 Query message is shown as follows:
0 1 2 3 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 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 | # Hops | | Type | Length | # Hops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Multicast Address | | Multicast Address |
skipping to change at page 12, line 45 skipping to change at page 13, line 5
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.MCAST.NET) 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 [10] for this interface. ifHCInMulticastPkts from the IF-MIB [12] for this interface.
Output packet count on outgoing interface: 64 bit Output packet count on outgoing interface: 64 bit
This field contains the number of multicast packets that have been This field contains the number of multicast packets that have been
transmitted or queued for transmission for all groups and sources transmitted or queued for transmission for all groups and sources
on the outgoing interface, or all 1's if no count can be reported. on the outgoing interface, or all 1's if no count can be reported.
This counter may have the same value as ifHCOutMulticastPkts from This counter may have the same value as ifHCOutMulticastPkts from
the IF-MIB [10] for this interface. the IF-MIB [12] for this interface.
Total number of packets for this source-group pair: 64 bits Total number of packets for this source-group pair: 64 bits
This field counts the number of packets from the specified source This field counts the number of packets from the specified source
forwarded by the router to the specified group, or all 1's if no forwarded by the router to the specified group, or all 1's if no
count can be reported. If the S bit is set (see below), the count count can be reported. If the S bit is set (see below), the count
is for the source network, as specified by the Src Mask field (see is for the source network, as specified by the Src Mask field (see
below). If the S bit is set and the Src Mask field is 127, below). If the S bit is set and the Src Mask field is 127,
indicating no source-specific state, the count is for all sources indicating no source-specific state, the count is for all sources
sending to this group. This counter should have the same value as sending to this group. This counter should have the same value as
ipMcastRoutePkts from the IPMROUTE-STD-MIB [11] for this ipMcastRoutePkts from the IPMROUTE-STD-MIB [13] for this
forwarding entry. forwarding entry.
Rtg Protocol: 16 bits Rtg Protocol: 16 bits
This field describes the unicast routing protocol running between This field describes the unicast routing protocol running between
this router and the upstream router, and it is used to determine this router and the upstream router, and it is used to determine
the RPF interface for the specified source or RP. This value the RPF interface for the specified source or RP. This value
should have the same value as ipMcastRouteRtProtocol from the should have the same value as ipMcastRouteRtProtocol from the
IPMROUTE-STD-MIB [11] for this entry. If the router is not able IPMROUTE-STD-MIB [13] for this entry. If the router is not able
to obtain this value, all 0's must be specified. to obtain this value, all 0's must be specified.
Multicast Rtg Protocol: 16 bits Multicast Rtg Protocol: 16 bits
This field describes the multicast routing protocol in use between This field describes the multicast routing protocol in use between
the router and the upstream router. This value should have the the router and the upstream router. This value should have the
same value as ipMcastRouteProtocol from the IPMROUTE-STD-MIB [11] same value as ipMcastRouteProtocol from the IPMROUTE-STD-MIB [13]
for this entry. If the router cannot obtain this value, all 0's for this entry. If the router cannot obtain this value, all 0's
must be specified. must be specified.
Fwd TTL: 8 bits Fwd TTL: 8 bits
This field contains the configured multicast TTL threshold, if This field contains the configured multicast TTL threshold, if
any, of the outgoing interface. any, of the outgoing interface.
S: 1 bit S: 1 bit
If this bit is set, it indicates that the packet count for the If this bit is set, it indicates that the packet count for the
source-group pair is for the source network, as determined by source-group pair is for the source network, as determined by
skipping to change at page 15, line 51 skipping to change at page 16, line 51
MBZ: 8 bits MBZ: 8 bits
This field MUST be zeroed on transmission and ignored on This field MUST be zeroed on transmission and ignored on
reception. reception.
Query Arrival Time: 32 bits Query Arrival Time: 32 bits
Same definition as in IPv4. Same definition as in IPv4.
Incoming Interface ID: 32 bits Incoming Interface ID: 32 bits
This field specifies the interface ID on which packets from the This field specifies the interface ID on which packets from the
source or RP are expected to arrive, or 0 if unknown. This ID 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] should be the value taken from InterfaceIndex of the IF-MIB [12]
for this interface. for this interface.
Outgoing Interface ID: 32 bits Outgoing Interface ID: 32 bits
This field specifies the interface ID to which packets from the This field specifies the interface ID to which packets from the
source or RP are expected to transmit, or 0 if unknown. This ID source or RP are expected to transmit, or 0 if unknown. This ID
should be the value taken from InterfaceIndex of the IF-MIB [10] should be the value taken from InterfaceIndex of the IF-MIB [12]
for this interface for this interface
Local Address: 128 bits Local Address: 128 bits
This field specifies a global IPv6 address that uniquely This field specifies a global IPv6 address that uniquely
identifies the router. An unique local unicast address [9] SHOULD identifies the router. An unique local unicast address [11]
NOT be used unless the router is only assigned link-local and SHOULD NOT be used unless the router is only assigned link-local
unique local addresses. If the router is only assigned link-local and unique local addresses. If the router is only assigned link-
addresses, its link-local address can be specified in this field. local addresses, its link-local address can be specified in this
field.
Remote Address: 128 bits Remote Address: 128 bits
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).
skipping to change at page 16, line 46 skipping to change at page 17, line 47
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
Src Prefix Len field. If the S bit is set and the Src Prefix Len Src Prefix Len field. If the S bit is set and the Src Prefix Len
field is 255, indicating no source-specific state, the count is field is 255, indicating no source-specific state, the count is
for all sources sending to this group. This counter should have for all sources sending to this group. This counter should have
the same value as ipMcastRoutePkts from the IPMROUTE-STD-MIB [11] the same value as ipMcastRoutePkts from the IPMROUTE-STD-MIB [13]
for this forwarding entry. for this forwarding entry.
Rtg Protocol: 16 bits Rtg Protocol: 16 bits
Same definition as in IPv4. Same definition as in IPv4.
Multicast Rtg Protocol: 16 bits Multicast Rtg Protocol: 16 bits
Same definition as in IPv4. Same definition as in IPv4.
MBZ 2: 15 bits MBZ 2: 15 bits
This field MUST be zeroed on transmission and ignored on This field MUST be zeroed on transmission and ignored on
skipping to change at page 20, line 43 skipping to change at page 21, line 43
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 (i.e.
224.0.0.0/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 ignored. GTSM [14] SHOULD be used by the router to determine whether
the router is adjacent or not. 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
skipping to change at page 24, line 7 skipping to change at page 25, line 7
The router will continue with a new Request by copying from the old The router will continue with a new Request by copying from the old
Request excluding all the response blocks, followed by the previously Request excluding all the response blocks, followed by the previously
prepared Standard Response Block, and an Augmented Response Block prepared Standard Response Block, and an Augmented Response Block
with Augmented Response Type of 0x01 and the number of the returned with Augmented Response Type of 0x01 and the number of the returned
Standard Response Blocks as the value. The new Request is then Standard Response Blocks as the value. The new Request is then
forwarded upstream. forwarded upstream.
4.4. Sending Mtrace2 Reply 4.4. Sending Mtrace2 Reply
An Mtrace2 Reply MUST be returned to the client by a router if the An Mtrace2 Reply MUST be returned to the client by a router if any of
total number of the traced routers is equal to the # Hops in the the following conditions occur:
Request. The total number of the traced routers is the sum of the
Standard Response Blocks in the Request (including the one just 1. The total number of the traced routers are equal to the # of hops
added) and the number of the returned blocks, if any. in the request (including the one just added) plus the number of
the returned blocks, if any.
2. Appending the Standard Response Block would make the Mtrace2
Request packet longer than the MTU of the Incoming interface.
(In case of IPv6 not more than 1280 bytes; see Section 4.3.3 for
additional details on handling of this case.)
3. The request has reached the RP for a non source specific query or
has reached the first hop router for a source specific query (see
Section 4.2.2, items 9 and 10 for additional details).
4.4.1. Destination Address 4.4.1. Destination Address
An Mtrace2 Reply MUST be sent to the address specified in the Mtrace2 An Mtrace2 Reply MUST be sent to the address specified in the Mtrace2
Client Address field in the Mtrace2 Request. Client Address field in the Mtrace2 Request.
4.4.2. Source Address 4.4.2. Source Address
An Mtrace2 Reply SHOULD be sent with the address of the router's An Mtrace2 Reply SHOULD be sent with the address of the router's
Outgoing interface. However, if the Outgoing interface address is Outgoing interface. However, if the Outgoing interface address is
skipping to change at page 28, line 18 skipping to change at page 29, line 36
will send back an Mtrace2 Reply to the Mtrace2 client, and continue will send back an Mtrace2 Reply to the Mtrace2 client, and continue
with a new Request (see Section 4.3.3). In which case, the Mtrace2 with a new Request (see Section 4.3.3). In which case, the Mtrace2
client may receive multiple Mtrace2 Replies from different routers client may receive multiple Mtrace2 Replies from different routers
along the path. When this happens, the client MUST treat them as a along the path. When this happens, the client MUST treat them as a
single Mtrace2 Reply message. single Mtrace2 Reply message.
If a trace times out, it is very likely that a router in the middle If a trace times out, it is very likely that a router in the middle
of the path does not support Mtrace2. That router's address will be of the path does not support Mtrace2. That router's address will be
in the Upstream Router field of the last Standard Response Block in in the Upstream Router field of the last Standard Response Block in
the last received Reply. A client may be able to determine (via the last received Reply. A client may be able to determine (via
mrinfo or SNMP [9][11]) a list of neighbors of the non-responding mrinfo or SNMP [11][13]) a list of neighbors of the non-responding
router. If desired, each of those neighbors could be probed to router. If desired, each of those neighbors could be probed to
determine the remainder of the path. Unfortunately, this heuristic determine the remainder of the path. Unfortunately, this heuristic
may end up with multiple paths, since there is no way of knowing what 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 the non-responding router's algorithm for choosing an upstream router
is. However, if all paths but one flow back towards the non- 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 responding router, it is possible to be sure that this is the correct
path. path.
6. Protocol-Specific Considerations 6. Protocol-Specific Considerations
skipping to change at page 29, line 13 skipping to change at page 30, line 33
contrast to PIM-SM, Bi-directional PIM always has the state to trace. contrast to PIM-SM, Bi-directional PIM always has the state to trace.
A Designated Forwarder (DF) for a given Rendezvous Point Address A Designated Forwarder (DF) for a given Rendezvous Point Address
(RPA) is in charge of forwarding downstream traffic onto its link, (RPA) is in charge of forwarding downstream traffic onto its link,
and forwarding upstream traffic from its link towards the RPL that and forwarding upstream traffic from its link towards the RPL that
the RPA belongs to. Hence Mtrace2 Reply reports DF addresses or RPA the RPA belongs to. Hence Mtrace2 Reply reports DF addresses or RPA
along the path. along the path.
6.3. PIM-DM 6.3. PIM-DM
Routers running PIM Dense Mode [13] do not know the path packets Routers running PIM Dense Mode [15] do not know the path packets
would take unless traffic is flowing. Without some extra protocol would take unless traffic is flowing. Without some extra protocol
mechanism, this means that in an environment with multiple possible mechanism, this means that in an environment with multiple possible
paths with branch points on shared media, Mtrace2 can only trace paths with branch points on shared media, Mtrace2 can only trace
existing paths, not potential paths. When there are multiple existing paths, not potential paths. When there are multiple
possible paths but the branch points are not on shared media, the possible paths but the branch points are not on shared media, the
upstream router is known, but the LHR may not know that it is the upstream router is known, but the LHR may not know that it is the
appropriate last hop. appropriate last hop.
When traffic is flowing, PIM Dense Mode routers know whether or not When traffic is flowing, PIM Dense Mode routers know whether or not
they are the LHR for the link (because they won or lost an Assert they are the LHR for the link (because they won or lost an Assert
skipping to change at page 33, line 4 skipping to change at page 34, line 27
Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original
multicast traceroute client, mtrace (version 1), has been implemented multicast traceroute client, mtrace (version 1), has been implemented
by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the 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 "S" bit to allow statistics for a source subnet is due to Tom
Pusateri. Pusateri.
For the Mtrace version 2 specification, the authors would like to For the Mtrace version 2 specification, the authors would like to
give special thanks to Tatsuya Jinmei, Bill Fenner, and Steve Casner. give special thanks to Tatsuya Jinmei, Bill Fenner, and Steve Casner.
Also, extensive comments were received from David L. Black, Ronald Also, extensive comments were received from David L. Black, Ronald
Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert Kebler, John Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert Kebler, John
Kristoff, Heidi Ou, Pekka Savola, Shinsuke Suzuki, Dave Thaler, Kristoff, Mankamana Mishra, Heidi Ou, Pekka Savola, Shinsuke Suzuki,
Achmad Husni Thamrin, Stig Venaas, and Cao Wei. Dave Thaler, Achmad Husni Thamrin, Stig Venaas, and Cao Wei.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, May 2008. IANA Considerations Section in RFCs", RFC 5226, May 2008.
[5] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [5] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Protocol Specification (Revised)", RFC 4601, August 2006. Multicast - Sparse Mode (PIM-SM): Protocol Specification
(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.
[7] Fenner, B., He, H., Haberman, B., and H. Sandick, [7] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
11.2. Informative References 11.2. Informative References
[8] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [8] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[9] Draves, R. and D. Thaler, "Default Router Preferences and [9] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
February 2015.
[10] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[11] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [12] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000. MIB", RFC 2863, June 2000.
[11] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast [13] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast
MIB", RFC 5132, December 2007. MIB", RFC 5132, December 2007.
[12] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. [14] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
[13] Adams, A., Nicholas, J., and W. Siadak, "Protocol [15] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005. Specification (Revised)", RFC 3973, January 2005.
Authors' Addresses Authors' Addresses
Hitoshi Asaeda Hitoshi Asaeda
National Institute of Information and Communications Technology National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795 Koganei, Tokyo 184-8795
Japan Japan
 End of changes. 29 change blocks. 
100 lines changed or deleted 126 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/