Mtrace Version 2: Traceroute Facility for IP Multicast
Extracted elements (29)
Mtrace2 traces from receiver to source (upstream) rather than source to receiver (downstream) because walking up the tree is easy — most multicast routing protocols know the upstream router for each source — while tracing downstream is difficult due to the lack of an efficient, deterministic way to identify which branch a receiver lies on.
Unlike Mtrace version 1, which used IGMP messages, all Mtrace2 messages are UDP-based. This change was made to support both IPv4 and IPv6 under a single protocol with similar syntax, and to avoid IGMP's IPv4-only scope.
Mtrace2 does not require any IPv4/IPv6 multicast addresses for Replies (unlike Mtrace v1, which used 224.0.1.32 for IPv4 responses). Every Mtrace2 Reply is unicasted to the address in the Mtrace2 Client Address field.
When an IGMP/MLD Proxy receives an Mtrace2 Query on its Incoming Interface, it notes WRONG_IF in the Forwarding Code and sends a Reply back to the client. When the Query arrives on the Outgoing Interface, it is forwarded onto the Incoming Interface toward the upstream router.
An Mtrace2 Reply MUST be sent to the address specified in the Mtrace2 Client Address field, and MUST be sent with the prepared Standard Response Block appended (except in the NO_SPACE case).
For IPv4, all Mtrace2 Query/Request/Reply messages MUST NOT be fragmented; clients and LHRs/RPs MUST set the IP header DF bit. For IPv6, packet size MUST NOT exceed 1280 bytes. All Mtrace2 messages MUST have a valid UDP checksum.
If an implementation receives an unknown TLV Type, it SHOULD ignore and silently discard the entire packet. If a TLV's length exceeds the available packet space, the implementation MUST ignore and silently discard the TLV and any remaining packet portion.
If appending a Standard Response Block would exceed the Incoming Interface MTU (or 1280 bytes for IPv6), the router MUST set the last Standard Response Block's Forwarding Code to NO_SPACE, send the current Request as a Reply, and continue with a new Request carrying an Augmented Response Block indicating the count of returned blocks.
Mtrace2 must not mix IPv4 and IPv6: if a Query or Request arrives as an IPv4 packet, all addresses in the message MUST be IPv4; the same rule applies to IPv6 Mtrace2 messages.
The Mtrace2 Client Address MUST be a valid unicast address and MUST NOT be all ones or an unspecified address. It is invalid to have a source-group combination of (all-ones/unspecified, all-ones/unspecified); a router receiving such a combination MUST silently discard the Query.
Upon receiving a Request, if the sum of Standard Response Blocks already in the packet plus any Augmented Response Type 0x01 value is equal to or exceeds the # Hops field, the router MUST silently ignore the message.
When a client receives multiple Mtrace2 Replies sharing the same Query ID (due to NO_SPACE splitting), it MUST treat them as a single Reply by collating the Augmented Response Blocks in order of receipt.
When forwarding a Request upstream, if the upstream router is unknown, the Request MUST be sent to a link-scoped multicast address (224.0.0.0/24 for IPv4, FF02::/16 for IPv6) and MUST NOT be sent to the all-systems group (224.0.0.1) or All Nodes Address (FF02::1).
Six TLV types are defined: 0x01 (Mtrace2 Query), 0x02 (Mtrace2 Request), 0x03 (Mtrace2 Reply), 0x04 (Mtrace2 Standard Response Block), 0x05 (Mtrace2 Augmented Response Block), and 0x06 (Mtrace2 Extended Query Block). Each Mtrace2 message MUST begin with a Query, Request, or Reply TLV.
The default [Mtrace Reply Timeout] is 10 seconds and is used to time out an Mtrace2 Reply in multiple contexts: proxy relay (Section 4.5), client hop-by-hop search (Section 5.2), and non-supported router detection (Section 5.7). The value can be manually changed on both clients and routers.
The Forwarding Code field in the Standard Response Block carries per-hop status: values 0x00–0x0D indicate informational or redirect conditions (e.g., NO_ERROR, WRONG_IF, NO_ROUTE, REACHED_RP, INFO_HIDDEN), while values 0x80–0xFF (high bit set) indicate transitory or auto-recovered fatal errors (e.g., FATAL_ERROR 0x80, NO_SPACE 0x81, ADMIN_PROHIB 0x83).
IANA has assigned UDP port 33435 (mtrace) as the Mtrace2 UDP destination port.
This document creates the 'Mtrace2 Forwarding Codes' IANA registry (integers 0–255, policy: Specification Required), with initial values defined in Section 3.2.4. Additions must fully describe the conditions under which the new code is used.
This document creates the 'Mtrace2 TLV Types' IANA registry (integers 0–255 with a Code and Type name, policy: Specification Required), with initial values defined in Section 3.2.
A router providing Mtrace2 MUST support a source-verification mechanism to drop Queries from unauthorized clients and Requests from unauthorized peer routers or addresses beyond a specified administrative boundary. Unauthorized Query/Requests MUST NOT be processed; the router MAY perform rate-limited logging.
Forged Reply messages can provide invalid topology or traffic statistics. Mitigations include required source verification (Section 9.2), the need for an attacker to guess a 2-byte Query ID and dynamic source port, and recommended PIM neighbor authentication (Section 9.7.2) to block forged Replies from authorized but non-peer hosts.
Mtrace2 can expose confidential network topology and multicast channel characteristics (sources, groups, rates). Operators can restrict this at domain borders using the ADMIN_PROHIB Forwarding Code or the INFO_HIDDEN mechanism.
Mtrace2 is susceptible to amplification attacks because a single Query produces larger Request and Reply messages. Mitigation requires restricting permitted source addresses (Section 9.2) and, for PIM routers, dropping any Request or Reply from an IP address that does not correspond to an authenticated PIM neighbor.
Message type transitions: Query (0x01) → Request (0x02) when LHR receives a Query and begins forwarding upstream; Request (0x02) → Reply (0x03) when FHR or RP receives a Request destined to itself, or when an intermediate router encounters a terminal condition (NO_ROUTE, WRONG_IF, REACHED_RP, hop limit reached, NO_SPACE).
The IPv4 Mtrace2 Standard Response Block (Type 0x04) includes: 32-bit Query Arrival Time (NTP middle-32 format), 32-bit Incoming Interface Address, 32-bit Outgoing Interface Address, 32-bit Upstream Router Address, three 64-bit packet counters (input, output, source-group), 16-bit Rtg Protocol, 16-bit Multicast Rtg Protocol, 8-bit Fwd TTL, 1-bit S flag, 7-bit Src Mask, and 8-bit Forwarding Code.
The IPv6 Mtrace2 Standard Response Block (Type 0x04) replaces interface addresses with 32-bit Interface IDs, adds a 128-bit Local Address and 128-bit Remote Address, and uses an 8-bit Src Prefix Len instead of the 7-bit Src Mask used in IPv4.
The Mtrace2 Extended Query Block (Type 0x06) carries a 7-bit MBZ field, a 1-bit T-bit (Transitive Attribute), a 16-bit Extended Query Type, and a 16-bit Value. If the T-bit is set and the type is unrecognized, the router MUST forward the TLV; if clear, the router MUST send a Reply with UNKNOWN_QUERY error.
The Mtrace2 Query TLV carries: 8-bit # Hops, a 32-bit or 128-bit Multicast Address, a 32-bit or 128-bit Source Address, a 32-bit or 128-bit Mtrace2 Client Address, a 16-bit Query ID, and a 16-bit Client Port #. The Length field MUST be 20 (IPv4) or 56 (IPv6).
The Mtrace2 TLV format consists of an 8-bit Type field, a 16-bit Length field (minimum 4 octets, must be a multiple of 4 octets), and a variable-length Value field whose length equals Length minus 3.