draft-ietf-mboned-mtrace-v2-22.txt   draft-ietf-mboned-mtrace-v2-23.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: June 23, 2018 Expires: October 4, 2018
W. Lee, Ed. W. Lee, Ed.
December 20, 2017 April 2, 2018
Mtrace Version 2: Traceroute Facility for IP Multicast Mtrace Version 2: Traceroute Facility for IP Multicast
draft-ietf-mboned-mtrace-v2-22 draft-ietf-mboned-mtrace-v2-23
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 https://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 June 23, 2018. This Internet-Draft will expire on October 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 11 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 11
3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 11
3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 12 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 12
3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 16 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 16
3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 18 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 19
3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 19 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 20
4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 20 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 20 4.1. Receiving Mtrace2 Query . . . . . . . . . . . . . . . . . 21
4.1.1. Query Packet Verification . . . . . . . . . . . . . . 20 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 21
4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 21 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 22
4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 21 4.2. Receiving Mtrace2 Request . . . . . . . . . . . . . . . . 22
4.2.1. Request Packet Verification . . . . . . . . . . . . . 21 4.2.1. Request Packet Verification . . . . . . . . . . . . . 22
4.2.2. Request Normal Processing . . . . . . . . . . . . . . 22 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 23
4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 24 4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 24
4.3.1. Destination Address . . . . . . . . . . . . . . . . . 24 4.3.1. Destination Address . . . . . . . . . . . . . . . . . 25
4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 24 4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 25
4.3.3. Appending Standard Response Block . . . . . . . . . . 24 4.3.3. Appending Standard Response Block . . . . . . . . . . 25
4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 25 4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 26
4.4.1. Destination Address . . . . . . . . . . . . . . . . . 25 4.4.1. Destination Address . . . . . . . . . . . . . . . . . 26
4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 25 4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 26
4.4.3. Appending Standard Response Block . . . . . . . . . . 25 4.4.3. Appending Standard Response Block . . . . . . . . . . 26
4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 25 4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 26
4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 26 4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 27
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 26 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 27
5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 26 5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 27
5.1.1. Destination Address . . . . . . . . . . . . . . . . . 27 5.1.1. Destination Address . . . . . . . . . . . . . . . . . 28
5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 27 5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 28
5.2. Determining the Path . . . . . . . . . . . . . . . . . . 27 5.2. Determining the Path . . . . . . . . . . . . . . . . . . 28
5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 27 5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 28
5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 27 5.4. Last Hop Router (LHR) . . . . . . . . . . . . . . . . . . 28
5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 28 5.5. First Hop Router (FHR) . . . . . . . . . . . . . . . . . 29
5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 28 5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 29
5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 28 5.7. Non-Supported Router . . . . . . . . . . . . . . . . . . 29
5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 28 5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 29
5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 28 5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 29
5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 29 5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 30
5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 29 5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 30
5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 29 5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 30
5.9. Continuing after an Error . . . . . . . . . . . . . . . . 29 5.9. Continuing after an Error . . . . . . . . . . . . . . . . 30
6. Protocol-Specific Considerations . . . . . . . . . . . . . . 29 6. Protocol-Specific Considerations . . . . . . . . . . . . . . 31
6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 30 6.2. Bi-Directional PIM . . . . . . . . . . . . . . . . . . . 31
6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 30 6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 32
7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 31 7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 31 7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 32
7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 31 7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 32
7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 32
7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 32 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 33
7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 32 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 32 8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 33
8.2. "Mtrace2 TLV Types" registry . . . . . . . . . . . . . . 32 8.2. "Mtrace2 TLV Types" registry . . . . . . . . . . . . . . 34
8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 33 8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 33 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 34
9.2. Filtering of Clients . . . . . . . . . . . . . . . . . . 33 9.2. Filtering of Clients and Peers . . . . . . . . . . . . . 34
9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 33 9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 34
9.4. Characteristics of Multicast Channel . . . . . . . . . . 33 9.4. Characteristics of Multicast Channel . . . . . . . . . . 35
9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 33 9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 35
9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 34 9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 9.7. Specific Security Concerns . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.7.1. Request and Response Bombardment . . . . . . . . . . 35
11.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.7.2. Amplification Attack . . . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . 35 9.7.3. Leaking of Confidential Topology Details . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 9.7.4. Delivery of False Information . . . . . . . . . . . . 36
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.1. Normative References . . . . . . . . . . . . . . . . . . 36
11.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Given a multicast distribution tree, tracing from a multicast source Given a multicast distribution tree, tracing hop-by-hop downstream
to a receiver is difficult, since we do not know on which branch of from a multicast source to a given multicast receiver is difficult
the multicast tree the receiver lies. This means that we have to because there is no efficient and deterministic way to determine the
flood the whole tree to find the path from a source to a receiver. branch of the multicast routing tree on which that receiver lies. On
On the other hand, walking up the tree from a receiver to a source is the other hand, walking up the tree from a receiver to a source is
easy, as most existing multicast routing protocols know the upstream easy, as most existing multicast routing protocols know the upstream
router for each source. Tracing from a receiver to a source can router for each source. Tracing from a receiver to a source can
involve only the routers on the direct path. involve only the routers on the direct path.
This document specifies the multicast traceroute facility named This document specifies the multicast traceroute facility named
Mtrace version 2 or Mtrace2 which allows the tracing of an IP Mtrace version 2 or Mtrace2 which allows the tracing of an IP
multicast routing path. Mtrace2 is usually initiated from an Mtrace2 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 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 Rendezvous Point (RP). The RP is a special router where sources and
receivers meet in Protocol Independent Multicast - Sparse Mode (PIM- receivers meet in Protocol Independent Multicast - Sparse Mode (PIM-
skipping to change at page 5, line 27 skipping to change at page 5, line 27
\ | / \ | /
\ | / \ | /
\ +---------+ / \ +---------+ /
v | Mtrace2 |/ v | Mtrace2 |/
| client | | client |
+---------+ +---------+
Figure 1 Figure 1
When an Mtrace2 client initiates a multicast trace, it sends an When an Mtrace2 client initiates a multicast trace, it sends an
Mtrace2 Query packet to the LHR or RP for a multicast group and, Mtrace2 Query packet to an LHR or RP for a multicast group and,
optionally, a source address. The LHR/RP turns the Query packet into optionally, a source address. The LHR/RP turns the Query packet into
a Request. The Request message type enables each of the upstream a Request. The Request message type enables each of the upstream
routers processing the message to apply different packet and message routers processing the message to apply different packet and message
validation rules than those required for handling of a Query message. validation rules than those required for handling of a Query message.
The LHR/RP then appends a standard response block containing its The LHR/RP then appends a standard response block containing its
interface addresses and packet statistics to the Request packet, then interface addresses and packet statistics to the Request packet, then
forwards the packet towards the source/RP. The Request packet is forwards the packet towards the source/RP. The Request packet is
either unicasted to its upstream router towards the source/RP, or either unicasted to its upstream router towards the source/RP, or
multicasted to the group if the upstream router's IP address is not 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 known. In a similar fashion, each router along the path to the
skipping to change at page 7, line 19 skipping to change at page 7, line 19
First-hop router (FHR) First-hop router (FHR)
The router that is directly connected to the source the Mtrace2 The router that is directly connected to the source the Mtrace2
Query specifies. Query specifies.
Last-hop router (LHR) Last-hop router (LHR)
A router that is directly connected to a receiver. It is also the A router that is directly connected to a receiver. It is also the
router that receives the Mtrace2 Query from an Mtrace2 client. router that receives the Mtrace2 Query from an Mtrace2 client.
Group state Group state
It is the state a shared-tree protocol, such as PIM-SM [5], uses The state a shared-tree protocol, such as PIM-SM [5], uses to
to choose the upstream router towards the RP for the specified choose the upstream router towards the RP for the specified group.
group. In this state, source-specific state is not available for In this state, source-specific state is not available for the
the corresponding group address on the router. 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 The state that is used to choose the path towards the source for
for the specified source and group. the specified source and group.
ALL-[protocol]-ROUTERS group ALL-[protocol]-ROUTERS group
It is a link-local multicast address for multicast routers to Link-local multicast address for multicast routers to communicate
communicate with their adjacent routers that are running the same with their adjacent routers that are running the same routing
routing protocol. For instance, the IPv4 'ALL-PIM-ROUTERS' group protocol. For instance, the IPv4 'ALL-PIM-ROUTERS' group is
is '224.0.0.13', and the IPv6 'ALL-PIM-ROUTERS' group is 'ff02::d' '224.0.0.13', and the IPv6 'ALL-PIM-ROUTERS' group is 'ff02::d'
[5]. [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 the Type/Length/Value (TLV) All Mtrace2 messages are encoded in the Type/Length/Value (TLV)
format (see Section 3.1). The first TLV of a message is a message format (see Section 3.1). The first TLV of a message is a message
header TLV specifying the type of message and additional context header TLV specifying the type of message and additional context
information required for processing of the message and for parsing of information required for processing of the message and for parsing of
subsequent TLVs in the message. Subsequent TLVs in a message, subsequent TLVs in the message. Subsequent TLVs in a message,
referred to as Blocks, are appended after the header TLV to provide referred to as Blocks, are appended after the header TLV to provide
additional information associated with the message. If an additional information associated with the message. If an
implementation receives an unknown TLV type for the first TLV in a implementation receives an unknown TLV type for any TLV in a message,
message (i.e., the header TLV), it SHOULD ignore and silently discard it SHOULD ignore and silently discard the entire packet. If the
the entire packet. If an implementation receives an unknown TLV type length of a TLV exceeds the available space in the containing packet,
for a subsequent TLV within a message, it SHOULD ignore and silently the implementation MUST ignore and silently discard the TLV and any
discard the entire packet. If the length of a TLV exceeds the remaining portion of the containing packet.
available space in the containing packet, the implementation MUST
ignore and silently discard the TLV and any remaining portion of the
containing packet.
All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 Query and All Mtrace2 messages are UDP packets. For IPv4, Mtrace2
Request messages MUST NOT be fragmented. For IPv6, the packet size Query/Request/Reply messages MUST NOT be fragmented. Therefore,
for the Mtrace2 messages MUST NOT exceed 1280 bytes, which is the Mtrace2 clients and LHRs/RPs MUST set the IP header do-not-fragment
smallest Maximum Transmission Unit (MTU) for an IPv6 interface [2]. (DF) bit for all Mtrace2 messages. For IPv6, the packet size for the
The source port is uniquely selected by the local host operating Mtrace2 messages MUST NOT exceed 1280 bytes, which is the smallest
system. The destination port is the IANA reserved Mtrace2 port Maximum Transmission Unit (MTU) for an IPv6 interface [2]. The
number (see Section 8). All Mtrace2 messages MUST have a valid UDP source port is uniquely selected by the local host operating system.
checksum. 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. Additionally, Mtrace2 supports both IPv4 and IPv6, but not mixed.
For example, if an Mtrace2 Query or Request message arrives in as an For example, if an Mtrace2 Query or Request message arrives in as an
IPv4 packet, all addresses specified in the Mtrace2 messages MUST be IPv4 packet, all addresses specified in the Mtrace2 messages MUST be
IPv4 as well. Same rule applies to IPv6 Mtrace2 messages. IPv4 as well. Same rule applies to IPv6 Mtrace2 messages.
3.1. Mtrace2 TLV format 3.1. Mtrace2 TLV format
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
skipping to change at page 8, line 37 skipping to change at page 8, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 8 bits Type: 8 bits
Describes the format of the Value field. For all the available Describes the format of the Value field. For all the available
types, please see Section 3.2 types, please see Section 3.2
Length: 16 bits Length: 16 bits
Length of Type, Length, and Value fields in octets. Minimum Length of Type, Length, and Value fields in octets. Minimum
length required is 3 octets. The maximum TLV length is not length required is 4 octets. The length MUST be a multiple of 4
defined; however the entire Mtrace2 packet length SHOULD NOT octets. The maximum TLV length is not defined; however the entire
exceed the available MTU. Mtrace2 packet length MUST NOT exceed the available MTU.
Value: variable length Value: variable length
The format is based on the Type value. The length of the value 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 is Length field minus 3. All reserved fields in the Value
field MUST be transmitted as zeros and ignored on receipt. field MUST be transmitted as zeros and ignored on receipt.
3.2. Defined TLVs 3.2. Defined TLVs
The following TLV Types are defined: The following TLV Types are defined:
skipping to change at page 9, line 28 skipping to change at page 9, line 28
followed by a sequence of Standard Response Blocks, each from a followed by a sequence of Standard Response Blocks, each from a
multicast router on the path towards the source or the RP. In the multicast router on the path towards the source or the RP. In the
case more information is needed, a Standard Response Block can be case more information is needed, a Standard Response Block can be
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 originated by an Mtrace2 client which sends an
sends an Mtrace2 Query message to the LHR. When tracing towards the Mtrace2 Query message to the LHR. The LHR modifies only the Type
source or the RP, the intermediate routers MUST NOT modify the Query field of the Query TLV (to turn it into a "Request") before appending
message except the Type field. If the actual number of hops is not a Standard Response Block and forwarding it upstream. The LHR and
intermediate routers handling the Mtrace2 message when tracing
upstream MUST NOT modify any other fields within the Query/Request
TLV. Additionally, intermediate routers handling the message after
the LHR has converted the Query into a Request MUST NOT modify the
type field of the Request TLV. If the actual number of hops is not
known, an Mtrace2 client could send an initial Query message with a 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 large # Hops (e.g., 0xff), in order to try to trace the full path.
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 10, line 27 skipping to change at page 10, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Mtrace2 Client Address | | Mtrace2 Client Address |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query ID | Client Port # | | Query ID | Client Port # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2
Length: 16 bits
The length field MUST be either 20 (i.e., 8 plus 3 * 4 (IPv4
addresses)) or 56 (i.e., 8 + 3 * 16 (IPv6 addresses)); if the
length is 20, then IPv4 addresses MUST be assumed and if the
length is 56, then IPv6 addresses MUST be assumed.
# Hops: 8 bits # Hops: 8 bits
This field specifies the maximum number of hops that the Mtrace2 This field specifies the maximum number of hops that the Mtrace2
client wants to trace. If there are some error conditions in the client wants to trace. If there are some error conditions in the
middle of the path that prevent an Mtrace2 Reply from being middle of the path that prevent an Mtrace2 Reply from being
received by the client, the client MAY issue another Mtrace2 Query received by the client, the client MAY issue another Mtrace2 Query
with a lower number of hops until it receives a Reply. with a lower number of hops until it receives a Reply.
Multicast Address: 32 bits or 128 bits Multicast Address: 32 bits or 128 bits
This field specifies an IPv4 or IPv6 address, which can be either: This field specifies an IPv4 or IPv6 address, which can be either:
skipping to change at page 11, line 25 skipping to change at page 11, line 28
Query ID: 16 bits Query ID: 16 bits
This field is used as a unique identifier for this Mtrace2 Query This field is used as a unique identifier for this Mtrace2 Query
so that duplicate or delayed Reply messages may be detected. so that duplicate or delayed Reply messages may be detected.
Client Port #: 16 bits Client Port #: 16 bits
This field specifies the destination UDP port number for receiving This field specifies the destination UDP port number for receiving
the Mtrace2 Reply packet. the Mtrace2 Reply packet.
3.2.2. Mtrace2 Request 3.2.2. Mtrace2 Request
The format of an Mtrace2 Request message is similar to an Mtrace2 The Mtrace2 Request TLV is exactly the same as an Mtrace2 Query
Query except the Type field is 0x02. except for identifying the Type field of 0x02.
When a LHR receives an Mtrace2 Query message, it would turn the Query When a LHR receives an Mtrace2 Query message, it turns the Query into
into a Request by changing the Type field of the Query from 0x01 to a Request by changing the Type field of the Query from 0x01 to 0x02.
0x02. The LHR would then append an Mtrace2 Standard Response Block The LHR then appends an Mtrace2 Standard Response Block (see
(see Section 3.2.4) of its own to the Request message before sending Section 3.2.4) of its own to the Request message before sending it
it upstream. The upstream routers would do the same without changing upstream. The upstream routers do the same without changing the Type
the Type field until one of them is ready to send a Reply. field until one of them is ready to send a Reply.
3.2.3. Mtrace2 Reply 3.2.3. Mtrace2 Reply
The format of an Mtrace2 Reply message is similar to an Mtrace2 Query The Mtrace2 Reply TLV is exactly the same as an Mtrace2 Query except
except the Type field is 0x03. for identifying the Type field of 0x03.
When a FHR or a RP receives an Mtrace2 Request message which is When a FHR or an RP receives an Mtrace2 Request message which is
destined to itself, it would append an Mtrace2 Standard Response destined to itself, it appends an Mtrace2 Standard Response Block
Block (see Section 3.2.4) of its own to the Request message. Next, (see Section 3.2.4) of its own to the Request message. Next, it
it would turn the Request message into a Reply by changing the Type turns the Request message into a Reply by changing the Type field of
field of the Request from 0x02 to 0x03. The Reply message would then the Request from 0x02 to 0x03 and by changing the UDP destination
be unicasted to the Mtrace2 client specified in the Mtrace2 Client port to the port number specified in the Client Port number field in
Address field. the Request. It then unicasts the Reply message to the Mtrace2
client specified in the Mtrace2 Client Address field.
There are a number of cases in which an intermediate router might There are a number of cases in which an intermediate router might
return a Reply before a Request reaches the FHR or the RP. See return a Reply before a Request reaches the FHR or the RP. See
Section 4.1.1, Section 4.2.2, Section 4.3.3, and Section 4.5 for more Section 4.1.1, Section 4.2.2, Section 4.3.3, and Section 4.5 for more
details. details.
3.2.4. IPv4 Mtrace2 Standard Response Block 3.2.4. IPv4 Mtrace2 Standard Response Block
This section describes the message format of an IPv4 Mtrace2 Standard This section describes the message format of an IPv4 Mtrace2 Standard
Response Block. The Type field is 0x04. Response Block. The Type field is 0x04.
skipping to change at page 13, line 15 skipping to change at page 13, line 18
The following formula converts from a timespec (fractional part in The following formula converts from a timespec (fractional part in
nanoseconds) to a 32-bit NTP timestamp: nanoseconds) to a 32-bit NTP timestamp:
query_arrival_time query_arrival_time
= ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125) = ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125)
The constant 32384 is the number of seconds from Jan 1, 1900 to The constant 32384 is the number of seconds from Jan 1, 1900 to
Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125)
is a reduction of ((tv.tv_nsec / 1000000000) << 16). is a reduction of ((tv.tv_nsec / 1000000000) << 16).
Note that Mtrace2 does not require all the routers on the path to Note that synchronized clocks are required on the traced routers
have synchronized clocks in order to measure one-way latency. to estimate propagation and queueing delays between successive
hops. Nevertheless, even without this synchronization, an
application can still estimate an upper bound on cumulative one
way latency by measuring the time between sending a Query and
receiving a Reply.
Additionally, Query Arrival Time is useful for measuring the Additionally, Query Arrival Time is useful for measuring the
packet rate. For example, suppose that a client issues two packet rate. For example, suppose that a client issues two
queries, and the corresponding requests R1 and R2 arrive at router queries, and the corresponding requests R1 and R2 arrive at router
X at time T1 and T2, then the client would be able to compute the X at time T1 and T2, then the client would be able to compute the
packet rate on router X by using the packet count information packet rate on router X by using the packet count information
stored in the R1 and R2, and the time T1 and T2. stored in the R1 and R2, and the time T1 and T2.
Incoming Interface Address: 32 bits Incoming 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
skipping to change at page 13, line 38 skipping to change at page 13, line 45
or unnumbered. or unnumbered.
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 group) 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 MUST be 0 if the incoming
incoming interface address is unknown or unnumbered. 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 Interfaces Group MIB (IF-MIB) [12] ifHCInMulticastPkts from the Interfaces Group MIB (IF-MIB) [12]
for this interface. 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
skipping to change at page 15, line 5 skipping to change at page 15, line 13
masking the source address with the Src Mask field. masking the source address with the Src Mask field.
Src Mask: 7 bits Src Mask: 7 bits
This field contains the number of 1's in the netmask the router 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 has for the source (i.e. a value of 24 means the netmask is
0xffffff00). If the router is forwarding solely on group state, 0xffffff00). If the router is forwarding solely on group state,
this field is set to 127 (0x7f). this field is set to 127 (0x7f).
Forwarding Code: 8 bits Forwarding Code: 8 bits
This field contains a forwarding information/error code. Values This field contains a forwarding information/error code. Values
with the high order bit set (0x80-0xff) are intended for use as with the high order bit set (0x80-0xff) are intended for use with
error or exception codes. Section 4.1 and Section 4.2 explain how conditions that are transitory or automatically recovered. Other
and when the Forwarding Code is filled. Defined values are as forwarding code values indicate a need to fix a problem in the
follows: Query or a need to redirect the Query. Section 4.1 and
Section 4.2 explain how and when the Forwarding Code is filled.
Defined values are as follows:
Value Name Description Value Name Description
----- -------------- ---------------------------------------------- ----- -------------- ----------------------------------------------
0x00 NO_ERROR No error 0x00 NO_ERROR No error
0x01 WRONG_IF Mtrace2 Request arrived on an interface 0x01 WRONG_IF Mtrace2 Request arrived on an interface
to which this router would not forward for to which this router would not forward for
the specified group towards the source or RP. the specified group towards the source or RP.
0x02 PRUNE_SENT This router has sent a prune upstream which 0x02 PRUNE_SENT This router has sent a prune upstream which
applies to the source and group in the applies to the source and group in the
Mtrace2 Request. Mtrace2 Request.
skipping to change at page 19, line 11 skipping to change at page 20, line 5
reception. reception.
Augmented Response Type: 16 bits Augmented Response Type: 16 bits
This field specifies the type of various responses from a This field specifies the type of various responses from a
multicast router that might need to communicate back to the multicast router that might need to communicate back to the
Mtrace2 client as well as the multicast routers on the traced Mtrace2 client as well as the multicast routers on the traced
path. path.
The Augmented Response Type is defined as follows: The Augmented Response Type is defined as follows:
Code Type Code Type
==== =============================================== ====== ==============================================
0x01 # of the returned Standard Response Blocks 0x0001 # of the returned Standard Response Blocks
When the NO_SPACE error occurs on a router, the router should send When the NO_SPACE error occurs on a router, the router should send
the original Mtrace2 Request received from the downstream router the original Mtrace2 Request received from the downstream router
as a Reply back to the Mtrace2 client and continue with a new as a Reply back to the Mtrace2 client and continue with a new
Mtrace2 Request. In the new Request, the router would add a Mtrace2 Request. In the new Request, the router adds a Standard
Standard Response Block followed by an Augmented Response Block Response Block followed by an Augmented Response Block with 0x01
with 0x01 as the Augmented Response Type, and the number of the as the Augmented Response Type, and the number of the returned
returned Mtrace2 Standard Response Blocks as the Value. Mtrace2 Standard Response Blocks as the Value.
Each upstream router would recognize the total number of hops the Each upstream router recognizes the total number of hops the
Request has been traced so far by adding this number and the Request has been traced so far by adding this number and the
number of the Standard Response Block in the current Request number of the Standard Response Block in the current Request
message. message.
This document only defines one Augmented Response Type in the This document only defines one Augmented Response Type in the
Augmented Response Block. The description on how to provide Augmented Response Block. The description on how to provide
diagnosis information using the Augmented Response Block is out of diagnosis information using the Augmented Response Block is out of
the scope of this document, and will be addressed in separate the scope of this document, and will be addressed in separate
documents. documents.
skipping to change at page 27, line 18 skipping to change at page 28, line 18
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 multicast group (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 is the Mtrace2 Client Address.
5.2. Determining the Path 5.2. Determining the Path
An Mtrace2 client could send an initial Query messages with a large # An Mtrace2 client could send an initial Query messages with a large #
Hops, in order to try to trace the full path. If this attempt fails, Hops, in order to try to trace the full path. If this attempt fails,
one strategy is to perform a linear search (as the traditional one strategy is to perform a linear search (as the traditional
unicast traceroute program does); set the # Hops field to 1 and try unicast traceroute program does); set the # Hops field to 1 and try
to get a Reply, then 2, and so on. If no Reply is received at a to get a Reply, then 2, and so on. If no Reply is received at a
certain hop, the hop count can continue past the non-responding hop, certain hop, this hop is identified as the probable cause of
in the hopes that further hops may respond. These attempts should forwarding failures on the path. Nevertheless, the sender may
continue until the [Mtrace Reply Timeout] timeout has occurred. attempt to continue tracing past the non-responding hop by further
increasing the hop count in the hopes that further hops may respond.
Each of these attempts should be initiated only after the previous
attempt has terminated either because of successful reception of a
Reply or because the [Mtrace Reply Timeout] timeout has occurred.
See also Section 5.6 on receiving the results of a trace. See also Section 5.6 on receiving the results of a trace.
5.3. Collecting Statistics 5.3. Collecting Statistics
After a client has determined that it has traced the whole path or as After a client has determined that it has traced the whole path or as
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.
skipping to change at page 28, line 31 skipping to change at page 29, line 33
because a failure requires waiting for the [Mtrace Reply Timeout] because a failure requires waiting for the [Mtrace Reply Timeout]
period. period.
5.7. Non-Supported Router 5.7. Non-Supported Router
When a non-supported router receives an Mtrace2 Query or Request When a non-supported router receives an Mtrace2 Query or Request
message whose destination address is a multicast address, the router message whose destination address is a multicast address, the router
will silently discard the message. will silently discard the message.
When the router receives an Mtrace2 Query which is destined to When the router receives an Mtrace2 Query which is destined to
itself, the router would return an Internet Control Message Protocol itself, the router returns an Internet Control Message Protocol
(ICMP) port unreachable to the Mtrace2 client. On the other hand, (ICMP) port unreachable to the Mtrace2 client. On the other hand,
when the router receives an Mtrace2 Request which is destined to when the router receives an Mtrace2 Request which is destined to
itself, the router would return an ICMP port unreachable to its itself, the router returns an ICMP port unreachable to its adjacent
adjacent router from which the Request receives. Therefore, the router from which the Request receives. Therefore, the Mtrace2
Mtrace2 client needs to terminate the trace when the [Mtrace Reply client needs to terminate the trace when the [Mtrace Reply Timeout]
Timeout] timeout has occurred, and may then issue another Query with timeout has occurred, and may then issue another Query with a lower
a lower number of # Hops. number of # Hops.
5.8. Mtrace2 Termination 5.8. Mtrace2 Termination
When performing an expanding hop-by-hop trace, it is necessary to When performing an expanding hop-by-hop trace, it is necessary to
determine when to stop expanding. determine when to stop expanding.
5.8.1. Arriving at Source 5.8.1. Arriving at Source
A trace can be determined to have arrived at the source if the A trace can be determined to have arrived at the source if the
Incoming Interface of the last router in the trace is non-zero, but Incoming Interface of the last router in the trace is non-zero, but
skipping to change at page 29, line 30 skipping to change at page 30, line 30
(seconds), and can be manually changed on the Mtrace2 client and (seconds), and can be manually changed on the Mtrace2 client and
routers. routers.
5.9. Continuing after an Error 5.9. Continuing after an Error
When the NO_SPACE error occurs, as described in Section 4.2, a router When the NO_SPACE error occurs, as described in Section 4.2, a router
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 this case, the Mtrace2 with a new Request (see Section 4.3.3). In this 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 by collating the augmented response
blocks of subsequent Replies sharing the same query ID, sequencing
each cluster of augmented response blocks based on the order in which
they are received.
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 the Simple Network Management Protocol (SNMP) [11][13]) a mrinfo or the Simple Network Management Protocol (SNMP) [11][13]) a
list of neighbors of the non-responding router. The neighbors list of neighbors of the non-responding router. The neighbors
obtained in this way could then be probed (via the multicast MIB obtained in this way could then be probed (via the multicast MIB
[13]) to determine which one is the upstream neighbor (i.e., Reverse [13]) to determine which one is the upstream neighbor (i.e., Reverse
Path Forwarding (RPF) neighbor) of the non-responding router. This Path Forwarding (RPF) neighbor) of the non-responding router. This
skipping to change at page 32, line 34 skipping to change at page 33, line 37
If the routers have synchronized clocks, it is possible to estimate If the routers have synchronized clocks, it is possible to estimate
propagation and queuing delay from the differences between the propagation and queuing delay from the differences between the
timestamps at successive hops. However, this delay includes control timestamps at successive hops. However, this delay includes control
processing overhead, so is not necessarily indicative of the delay processing overhead, so is not necessarily indicative of the delay
that data traffic would experience. that data traffic would experience.
8. IANA Considerations 8. IANA Considerations
The following new registries are to be created and maintained under The following new registries are to be created and maintained under
the "RFC Required" registry policy as specified in [4]. the "Specification Required" registry policy as specified in [4].
8.1. "Mtrace2 Forwarding Codes" Registry 8.1. "Mtrace2 Forwarding Codes" Registry
This is an integer in the range 0-255. Assignment of a Forwarding 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 requires specification of a value and a name for the Forwarding
Code. Initial values for the forwarding codes are given in the table 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) 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 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 this registry are required to fully describe the conditions under
which the new Forwarding Code is used. which the new Forwarding Code is used.
skipping to change at page 33, line 25 skipping to change at page 34, line 31
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
congruent with the definition defined in Section 3.2.1 and forwarding congruent with the definition defined in Section 3.2.1 and forwarding
Mtrace2 messages having invalid addresses MUST be prohibited. For Mtrace2 messages having invalid addresses MUST be prohibited. For
instance, if Mtrace2 Client Address specified in an Mtrace2 header is instance, if Mtrace2 Client Address specified in an Mtrace2 header is
a multicast address, then a router that receives the Mtrace2 message a multicast address, then a router that receives the Mtrace2 message
MUST silently discard it. MUST silently discard it.
9.2. Filtering of Clients 9.2. Filtering of Clients and Peers
A router SHOULD support a mechanism to filter out queries from A router MUST support a mechanism to filter out Queries from clients
clients beyond a specified administrative boundary. Such a boundary and Requests from peer router addresses that are unauthorized or that
are beyond a specified administrative boundary. This filtering
could, for example, be specified via a list of allowed/disallowed could, for example, be specified via a list of allowed/disallowed
client addresses or subnets. If a query is received from beyond the client and peer addresses or subnets for the Mtrace2 protocol port.
specified administrative boundary, the Query MUST NOT be processed. If a Query or Request is received from an unauthorized address or one
The router MAY, however, perform rate limited logging of such events. beyond the specified administrative boundary, the Query/Request MUST
NOT be processed. The router MAY, however, perform rate limited
logging of such events.
9.3. Topology Discovery 9.3. Topology Discovery
Mtrace2 can be used to discover any actively-used topology. If your Mtrace2 can be used to discover any actively-used topology. If your
network topology is a secret, Mtrace2 may be restricted at the border network topology is a secret, Mtrace2 may be restricted at the border
of your domain, using the ADMIN_PROHIB forwarding code. of your domain, using the ADMIN_PROHIB forwarding code.
9.4. Characteristics of Multicast Channel 9.4. Characteristics of Multicast Channel
Mtrace2 can be used to discover what sources are sending to what Mtrace2 can be used to discover what sources are sending to what
skipping to change at page 34, line 14 skipping to change at page 35, line 27
fairness in processing queries, or prevent traffic amplification. fairness in processing queries, or prevent traffic amplification.
The rate limit is left to the router's implementation. The rate limit is left to the router's implementation.
9.6. Limiting Reply Rates 9.6. Limiting Reply Rates
The proxying and NO_SPACE behaviors may result in one Query returning The proxying and NO_SPACE behaviors may result in one Query returning
multiple Reply messages. In order to prevent abuse, the routers in multiple Reply messages. In order to prevent abuse, the routers in
the traced path MAY need to rate-limit the Replies. The rate limit the traced path MAY need to rate-limit the Replies. The rate limit
function is left to the router's implementation. function is left to the router's implementation.
9.7. Specific Security Concerns
9.7.1. Request and Response Bombardment
A malicious sender could generate invalid and undesirable Mtrace2
traffic to hosts and/or routers on a network by eliciting responses
to spoofed or multicast client addresses. This could be done via
forged or multicast client/source addresses in Mtrace2 Query or
Request messages. The recommended protections against this type of
attack are described in Section 9.1, Section 9.2, Section 9.5, and
Section 9.6.
9.7.2. Amplification Attack
Because an Mtrace2 Query results in Mtrace2 Request and Mtrace2 Reply
messages that are larger than the original message, the potential
exists for an amplification attack from a malicious sender. This
threat is minimized by restricting the set of addresses from which
Mtrace2 messages can be received on a given router as specified in
Section 9.2.
9.7.3. Leaking of Confidential Topology Details
Mtrace2 Queries are a potential mechanism for obtaining confidential
topology information for a targeted network. Section 9.2 and
Section 9.4 describe required and optional methods for ensuring that
information delivered with Mtrace2 messages is not disseminated to
unauthorized hosts.
9.7.4. Delivery of False Information
Forged Reply messages could potentially provide a host with invalid
or incorrect topology information. This threat is mitigated by the
following factors:
o The required filtering of permissible source addresses specified
in Section 9.2 eliminates the origination of forged Replies from
addresses that have not been authorized to send Mtrace2 messages
to routers on a given network.
o To forge a Reply, the sender would need to somehow know the
associated two byte query ID for an extant Query and the
dynamically allocated source port number.
10. Acknowledgements 10. Acknowledgements
This specification started largely as a transcription of Van This specification started largely as a transcription of Van
Jacobson's slides from the 30th IETF, and the implementation in Jacobson's slides from the 30th IETF, and the implementation in
mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve
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, Mankamana Mishra, Heidi Ou, Pekka Savola, Shinsuke Suzuki, Kristoff, Mankamana Mishra, Heidi Ou, Eric Rescorla, Pekka Savola,
Dave Thaler, Achmad Husni Thamrin, Stig Venaas, and Cao Wei. Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, Stig Venaas, Cao
Wei, and the Mboned working group members.
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 8200, July 2017. (IPv6) Specification", RFC 8200, July 2017.
 End of changes. 41 change blocks. 
161 lines changed or deleted 236 lines changed or added

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