RFC 8487
Mtrace Version 2: Traceroute Facility for IP Multicast
Mtrace Version 2: Traceroute Facility for IP Multicast 🦋
okay bestie, here's the title block 💅
- Request for Comments: 8487
- Series: Internet Engineering Task Force (IETF)
- Authors: H. Asaeda (NICT), K. Meyer (Dell EMC), W. Lee, Ed. (editor) 🫶
- Category: Standards Track ✨
- ISSN: 2070-1721
- Date: October 2018 🍓
Abstract
so this doc is about Mtrace version 2 (we call it Mtrace2 🧚), which is a multicast traceroute tool. Regular unicast traceroute just works on normal routers, but Mtrace2 is different: routers need special implementations to play along 😭 This spec covers what the required functionality looks like in multicast routers, and how an Mtrace2 client sends a Query and gets a Reply back. It's giving full protocol main character energy 👑
Status of This Memo
this is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the whole IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 💜
for the current status, any errata, or how to send feedback, go to https://www.rfc-editor.org/info/rfc8487 🌸
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read those, bestie, because they spell out what you're allowed to do and what you're not 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.
this document might also include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright on some of that older material may not have given the IETF Trust permission to allow changes outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌈
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Mtrace2 TLV Format . . . . . . . . . . . . . . . . . . . 9
3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 12
3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 12
3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 13
3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 18
3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 20
3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 21
4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Receiving an Mtrace2 Query . . . . . . . . . . . . . . . 22
4.1.1. Query Packet Verification . . . . . . . . . . . . . . 22
4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 23
4.2. Receiving an Mtrace2 Request . . . . . . . . . . . . . . 23
4.2.1. Request Packet Verification . . . . . . . . . . . . . 24
4.2.2. Request Normal Processing . . . . . . . . . . . . . . 24
4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 26
4.3.1. Destination Address . . . . . . . . . . . . . . . . . 26
4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 26
4.3.3. Appending Standard Response Block . . . . . . . . . . 26
4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 27
4.4.1. Destination Address . . . . . . . . . . . . . . . . . 27
4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 27
4.4.3. Appending Standard Response Block . . . . . . . . . . 27
4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 28
4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 28
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 29
5.1.1. Destination Address . . . . . . . . . . . . . . . . . 29
5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 29
5.2. Determining the Path . . . . . . . . . . . . . . . . . . 29
5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 29
5.4. Last-Hop Router (LHR) . . . . . . . . . . . . . . . . . . 30
5.5. First-Hop Router (FHR) . . . . . . . . . . . . . . . . . 30
5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 30
5.7. Non-supported Router . . . . . . . . . . . . . . . . . . 30
5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 31
5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 31
5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 31
5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 31
5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 31
5.9. Continuing after an Error . . . . . . . . . . . . . . . . 31
6. Protocol-Specific Considerations . . . . . . . . . . . . . . 32
6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.2. Bidirectional PIM . . . . . . . . . . . . . . . . . . . . 32
6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 33
7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 33
7.2. TTL or Hop-Limit Problems . . . . . . . . . . . . . . . . 33
7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 33
7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 34
7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 35
8.2. "Mtrace2 TLV Types" Registry . . . . . . . . . . . . . . 35
8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 35
9.2. Verification of Clients and Peers . . . . . . . . . . . . 35
9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 36
9.4. Characteristics of Multicast Channel . . . . . . . . . . 36
9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 37
9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 37
9.7. Specific Security Concerns . . . . . . . . . . . . . . . 37
9.7.1. Request and Response Bombardment . . . . . . . . . . 37
9.7.2. Amplification Attack . . . . . . . . . . . . . . . . 37
9.7.3. Leaking of Confidential Topology Details . . . . . . 38
9.7.4. Delivery of False Information (Forged Reply Messages) 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 40
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 411. Introduction ✨
Okay so, picture a multicast distribution tree 🌳. Tracing downstream from a multicast source to a receiver is genuinely hard, because there's no efficient, deterministic way to figure out which branch of the multicast routing tree that receiver is sitting on 😭. Going the other way, up the tree from a receiver to a source, is so much easier, because most existing multicast routing protocols already know the upstream router for each source 💅. So tracing from receiver to source only has to touch the routers on the direct path. Iconic, honestly.
This document specifies the multicast traceroute facility called Mtrace version 2, or Mtrace2 🦋, which lets you trace an IP multicast routing path. Mtrace2 is usually kicked off by an Mtrace2 client sending an Mtrace2 Query to a Last-Hop Router (LHR) or a Rendezvous Point (RP) 🎀. The RP is the special router where sources and receivers meet up in Protocol Independent Multicast - Sparse Mode (PIM-SM) [5]. When the LHR/RP gets the Query, the tracing heads toward a specified source if one is given and the router actually has source-specific state for it. If there's no source address, or no source-specific state on the receiving LHR, the tracing heads toward the RP for the specified group address instead 🧚. Mtrace2 also gives you extra info like packet rates and losses, plus other diagnostic goodies 📊. It's mainly meant for these purposes:
- To trace the path that a packet would take from a source to a receiver.
- To isolate packet-loss problems (e.g., congestion).
- To isolate configuration problems (e.g., Time to live (TTL) threshold).
The figure below shows a typical Mtrace2 setup 👀. FHR is the first-hop router, LHR is the last-hop router, and the arrows are the Mtrace2 messages zipping from one node to another. The numbers in front of the Mtrace2 messages show the order they happen in. The source, the receiver, and the Mtrace2 client are typically hosts 💖.
2. Request 2. Request
+----+ +----+
| | | |
v | v |
+--------+ +-----+ +-----+ +----------+
| Source |----| FHR |----- The Internet -----| LHR |----| Receiver |
+--------+ +-----+ | +-----+ +----------+
\ | ^
\ | /
\ | /
\ | /
3. Reply \ | / 1. Query
\ | /
\ | /
\ +---------+ /
v | Mtrace2 |/
| Client |
+---------+So here's the flow: when an Mtrace2 client starts a multicast trace, it sends an Mtrace2 Query packet to an LHR or RP for a multicast group and, optionally, a source address 🌸. The LHR/RP turns that Query into a Request. The Request message type is the glow-up that lets each upstream router handle the message with different packet and message validation rules than a Query would get 🔥. Then the LHR/RP tacks a Standard Response Block onto the Request, with its interface addresses and packet statistics, and forwards it toward the source/RP 🚀. The Request gets unicasted to its upstream router toward the source/RP, or multicasted to the group if that upstream router's IP address isn't known. Same energy at every hop: each router along the path to the source/RP adds its own Standard Response Block to the end of the Request before passing it upstream 🪜. When the FHR gets the Request, it appends its own Standard Response Block, turns the Request into a Reply, and unicasts that Reply back to the Mtrace2 client 🎉.
Sometimes the Mtrace2 Reply comes back before it reaches the FHR 🙈. That can happen if a Request lands at an RP or gateway, or if one of several error or exception conditions shows up that stops a Request from being sent to the next upstream router 💀.
The Mtrace2 client waits for the Mtrace2 Reply and then displays the results 💅. If no Reply comes back because of network congestion, a broken router (see Section 5.6), or a non-responding router (see Section 5.7), the Mtrace2 client may resend another Mtrace2 Query with a lower hop count (see Section 3.2.1) and repeat the whole process until a Reply finally shows up 🔁. The specifics are up to the Mtrace2 client and are outside the scope of this document 🤷♀️.
One little warning, bestie 🚨: when a router's control plane and forwarding plane are out of sync, the Mtrace2 Requests might get forwarded based on the control states instead. In that case, the traced path might not match the real path the data packets would take 😭.
Mtrace2 supports both IPv4 and IPv6 🌈. The previous version of Mtrace implemented its query and response as Internet Group Management Protocol (IGMP) messages [10], but all Mtrace2 messages are UDP based instead 🦋. The IPv4 and IPv6 packet formats differ because of the address families, but the syntax between them is pretty similar ✨.
This document describes the base specification of Mtrace2, which can serve as a foundation for future proposals like Mtrace2 for Automatic Multicast Tunneling (AMT) [16] and Mtrace2 for Multicast in MPLS/BGP IP VPNs (known as Multicast VPN (MVPN)) [15]. Those are, therefore, out of the scope of this document 🧸.
2. Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [1] [7] when, and only when, they appear in all capitals, as shown here. The key words indicate requirement levels for compliant Mtrace2 implementations 🫶.
2.1. Definitions 🎀
Since Mtrace2 Queries and Requests flow in the opposite direction to the data flow, we refer to "upstream" and "downstream" with respect to data, unless explicitly specified 🔄.
Incoming Interface: The interface on which data is expected to arrive from the specified source and group.
Outgoing Interface: This is one of the interfaces to which data from the source or RP is expected to be transmitted for the specified source and group. It is also the interface on which the Mtrace2 Request was received.
Upstream router: The router, connecting to the Incoming Interface of the current router, which is responsible for forwarding data for the specified source and group to the current router.
First-Hop Router (FHR): The router that is directly connected to the source the Mtrace2 Query specifies.
Last-Hop Router (LHR): A router that is directly connected to a receiver. It is also the router that receives the Mtrace2 Query from an Mtrace2 client.
Group state: The state a shared-tree protocol, such as Protocol Independent Multicast - Sparse Mode (PIM-SM) [5], uses to choose the upstream router towards the RP for the specified group. In this state, source-specific state is not available for the corresponding group address on the router.
Source-specific state: The state that is used to choose the path towards the source for the specified source and group.
ALL-[protocol]-ROUTERS group: Link-local multicast address for multicast routers to communicate with their adjacent routers that are running the same routing protocol. For instance, the IPv4 ALL-PIM-ROUTERS group is 224.0.0.13, and the IPv6 ALL-PIM-ROUTERS group is ff02::d [5].
3. Packet Formats 📦
This section describes the details of the packet formats for Mtrace2 messages 💌.
All Mtrace2 messages are encoded in the Type/Length/Value (TLV) format (see Section 3.1) 🧩. The first TLV of a message is a message header TLV, which specifies the type of message and the extra context needed to process it and to parse the TLVs that follow. Subsequent TLVs in a message, called Blocks, get appended after the header TLV to add more info about the message 🎁. If an implementation receives an unknown TLV Type for any TLV in a message, it SHOULD ignore and silently discard the entire packet 🙅♀️. If the length of a TLV exceeds the 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/Request/Reply messages MUST NOT be fragmented. Therefore, Mtrace2 clients and LHRs/RPs MUST set the IP header do-not-fragment (DF) bit for all Mtrace2 messages 🙅♀️. For IPv6, the packet size for the Mtrace2 messages MUST NOT exceed 1280 bytes, which is the smallest Maximum Transmission Unit (MTU) for an IPv6 interface [8] 📏. The source port is uniquely selected by the local host operating system 🔢. The destination port is the IANA-reserved Mtrace2 port number (see Section 8) 🪪. All Mtrace2 messages MUST have a valid UDP checksum ✅.
Mtrace2 supports both IPv4 and IPv6, but not when they're mixed 🙅♀️. For example, if an Mtrace2 Query or Request message arrives as an IPv4 packet, all addresses specified in the Mtrace2 messages MUST be IPv4 as well. The same rule applies to IPv6 Mtrace2 messages 💜.
3.1. Mtrace2 TLV Format 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type: 8 bits 🏷️
Describes the format of the Value field. For all the available types, please see Section 3.2.
Length: 16 bits 📏
Length of Type, Length, and Value fields in octets. Minimum length required is 4 octets. The length MUST be a multiple of 4 octets. The maximum TLV length is not defined; however, the entire Mtrace2 packet length MUST NOT exceed the available MTU 🧮.
Value: variable length 💎
The format is based on the Type value. The length of the Value field is the Length field minus 3. All reserved fields in the Value field MUST be transmitted as zeros and ignored on receipt 🧸.
3.2. Defined TLVs ✨
okay so bestie, here's the TLV type roster 💅 the first TLV in every Mtrace2 message tells you what kind of message it is, and these are the official types:
Code Type
==== ================================
0x00 Reserved
0x01 Mtrace2 Query
0x02 Mtrace2 Request
0x03 Mtrace2 Reply
0x04 Mtrace2 Standard Response Block
0x05 Mtrace2 Augmented Response Block
0x06 Mtrace2 Extended Query Blockso every Mtrace2 message MUST begin with either a Query, a Request, or a Reply TLV 🎀 that first TLV is the boss and decides what type the whole message is. after the Query, you can have a bunch of optional Extended Query Blocks 🦋 if it's a Request or a Reply, it's followed by a sequence of Standard Response Blocks, one from each multicast router on the path toward the source or the RP 🌸 and when more info is needed, a Standard Response Block can be followed by one or multiple Augmented Response Blocks 💜
we're about to go through each message type in detail in the next few sections 🧚
3.2.1. Mtrace2 Query 🍓
an Mtrace2 Query starts with an Mtrace2 client, which sends it to the LHR 💖 the LHR only changes the Type field of the Query TLV (turning it into a "Request") and then appends a Standard Response Block and forwards it upstream ✨ the LHR and the intermediate routers handling the Mtrace2 message while tracing upstream MUST NOT modify any other fields in the Query/Request TLV 🔥 and intermediate routers that get the message after the LHR made it a Request MUST NOT modify the Type field either 🙈 if the client doesn't know how many hops there are, it could send a first Query with a big # Hops (like 0xff) to try and trace the full path 🌈
here's what a Mtrace2 Query looks like:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | # Hops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Multicast Address |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| Source Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Mtrace2 Client Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query ID | Client Port # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the field rundown, bestie 💅
- Length: 16 bits 📏 the Length field MUST be either 20 (that's 8 + 3 * 4 for IPv4 addresses) or 56 (that's 8 + 3 * 16 for IPv6 addresses) 💜 if the length is 20, IPv4 addresses MUST be assumed, and if it's 56, IPv6 addresses MUST be assumed 🫶
- # Hops: 8 bits 🦋 this is the max number of hops the client wants to trace ✨ if some error in the middle of the path stops the client from getting an Mtrace2 Reply, the client MAY send another Query with a lower number of hops until it gets a Reply 🌸
- Multicast Address: 32 bits or 128 bits 🎀 this is an IPv4 or IPv6 address, and it's either:
- m-1: a multicast group address to be traced, or
- m-2: all ones for IPv4, or the unspecified address (::) for IPv6, if you don't want any group-specific info 🌈
- Source Address: 32 bits or 128 bits 💖 this is an IPv4 or IPv6 address, and it's either:
- s-1: a unicast address of the source to be traced, or
- s-2: all ones for IPv4, or the unspecified address (::) for IPv6, if you don't want any source-specific info 🧚 for example, the client is tracing a (*,g) group state ✨
ngl this one's a warning 😭 it is invalid to have a source-group combination of (s-2, m-2) 💀 if a router gets that combo in an Mtrace2 Query, it MUST silently discard the Query 🙈
- Mtrace2 Client Address: 32 bits or 128 bits 🫶 this is the Mtrace2 client's IPv4 address or IPv6 global address 💅 this address MUST be a valid unicast address, so it MUST NOT be all ones or an unspecified address 🔥 the Mtrace2 Reply gets sent to this address 🦋
- Query ID: 16 bits 🔖 this is a unique identifier for this Mtrace2 Query, so duplicate or delayed Reply messages can be detected 💜
- Client Port #: 16 bits 🌸 this is the destination UDP port number for receiving the Mtrace2 Reply packet 🍓
3.2.2. Mtrace2 Request 🌈
the Mtrace2 Request TLV is exactly the same as an Mtrace2 Query, except its Type field is 0x02 💖
when an LHR gets an Mtrace2 Query, it turns the Query into a Request by changing the Type field from 0x01 to 0x02 ✨ then it appends its own Mtrace2 Standard Response Block (see Section 3.2.4) before sending it upstream 🧚 the upstream routers do the same thing without changing the Type field, until one of them is ready to send a Reply 🎀
3.2.3. Mtrace2 Reply 👑
the Mtrace2 Reply TLV is exactly the same as an Mtrace2 Query, except its Type field is 0x03 🦋
when an FHR or an RP gets an Mtrace2 Request that's destined to itself, it appends its own Mtrace2 Standard Response Block (see Section 3.2.4) to the Request 🌸 then it turns the Request into a Reply by changing the Type field from 0x02 to 0x03 💅 and it changes the UDP destination port to the port number in the Client Port Number field of the Request ✨ finally, it unicasts the Reply to the Mtrace2 client listed in the Mtrace2 Client Address field 💜
ngl there are a bunch of cases where an intermediate router might send back a Reply before the Request reaches the FHR or the RP 😭 check out Sections 4.1.1, 4.2.2, 4.3.3, and 4.5 for the details 🙈
3.2.4. IPv4 Mtrace2 Standard Response Block ✨
Okay bestie, this section is all about the IPv4 Mtrace2 Standard Response Block 🦋 and its message format. The Type field is 0x04 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Arrival Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upstream Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Input packet count on Incoming Interface .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Output packet count on Outgoing Interface .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Total number of packets for this source-group pair .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtg Protocol | Multicast Rtg Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fwd TTL | MBZ |S| Src Mask |Forwarding Code|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+MBZ: 8 bits 🌸 This field MUST be zeroed on transmission and ignored on reception.
Query Arrival Time: 32 bits ⏰ The Query Arrival Time is a 32-bit Network Time Protocol (NTP) timestamp specifying the arrival time of the Mtrace2 Query or Request packet at this router. The 32-bit form of an NTP timestamp consists of the middle 32 bits of the full 64-bit form, so that's the low 16 bits of the integer part and the high 16 bits of the fractional part 🧚
Here's the formula that converts a timespec (fractional part in nanoseconds) into a 32-bit NTP timestamp:
query_arrival_time
= ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125)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) is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" denotes a logical left shift. Math that's giving main character energy 🧮💖
Note that synchronized clocks are required on the traced routers to estimate propagation and queuing 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. Literally so clever 😭
Additionally, Query Arrival Time is useful for measuring the packet rate. For example, suppose that a client issues two 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 packet rate on router X by using the packet-count information stored in the R1 and R2 and using the time T1 and T2. Rate math, iconic 📈✨
Incoming Interface Address: 32 bits 🚪 This field specifies the address of the interface on which packets from the source or the RP are expected to arrive, or 0 if unknown or unnumbered.
Outgoing Interface Address: 32 bits 🚀 This field specifies the address of the interface on which packets from the source or the RP are expected to transmit towards the receiver, or 0 if unknown or unnumbered. This is also the address of the interface on which the Mtrace2 Query or Request arrives. Two jobs, one field, no cap 💅
Upstream Router Address: 32 bits 🛰️ This field specifies the address of the upstream router from which this router expects packets from this source. This MAY be a multicast group (e.g., ALL-[protocol]-ROUTERS group) if the upstream router is not known because of the workings of the multicast routing protocol. However, it MUST be 0 if the Incoming Interface address is unknown or unnumbered. Bestie, the vibes here are very specific 🙈
Input packet count on Incoming Interface: 64 bits 🔢 This field contains the number of multicast packets received for all groups and sources on the Incoming Interface, or all ones if no count can be reported. This counter may have the same value as ifHCInMulticastPkts from the Interfaces Group MIB (IF-MIB) [9] for this interface.
Output packet count on Outgoing Interface: 64 bits 🔢 This field contains the number of multicast packets that have been transmitted or queued for transmission for all groups and sources on the Outgoing Interface, or all ones if no count can be reported. This counter may have the same value as ifHCOutMulticastPkts from the IF-MIB [9] for this interface.
Total number of packets for this source-group pair: 64 bits 🧾 This field counts the number of packets from the specified source forwarded by the router to the specified group, or all ones if no 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 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 sending to this group. This counter should have the same value as ipMcastRoutePkts from the IP Multicast MIB [14] for this forwarding entry. 🎯
Rtg Protocol: 16 bits 🗺️ This field describes the unicast routing protocol running between this router and the upstream router, and it is used to determine the Reverse Path Forwarding (RPF) interface for the specified source or RP. This value should have the same value as ipMcastRouteRtProtocol from the IP Multicast MIB [14] for this entry. If the router is not able to obtain this value, all 0's must be specified.
Multicast Rtg Protocol: 16 bits 🧭 This field describes the multicast routing protocol in use between the router and the upstream router. This value should have the same value as ipMcastRouteProtocol from the IP Multicast MIB [14] for this entry. If the router cannot obtain this value, all 0's must be specified.
Fwd TTL: 8 bits ⏳ This field contains the configured multicast TTL threshold, if any, of the Outgoing Interface.
S: 1 bit 🎀 If this bit is set, it indicates that the packet count for the source-group pair is for the source network, as determined by masking the source address with the Src Mask field.
Src Mask: 7 bits 🎭 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 0xffffff00). If the router is forwarding solely on group state, this field is set to 127 (0x7f).
Forwarding Code: 8 bits 🚦 This field contains a forwarding information/error code. Values with the high-order bit set (0x80-0xff) are intended for use with conditions that are transitory or automatically recovered. Other Forwarding Code values indicate a need to fix a problem in the Query or a need to redirect the Query. Sections 4.1 and 4.2 explain how and when the Forwarding Code is filled. Defined values are as follows:
Value Name Description
----- -------------- ----------------------------------------------
0x00 NO_ERROR No error.
0x01 WRONG_IF Mtrace2 Request arrived on an interface
for which this router does not perform
forwarding for the specified group to the
source or RP.
0x02 PRUNE_SENT This router has sent a prune upstream that
applies to the source and group in the
Mtrace2 Request.
0x03 PRUNE_RCVD This router has stopped forwarding for this
source and group in response to a Request
from the downstream router.
0x04 SCOPED The group is subject to administrative
scoping at this router.
0x05 NO_ROUTE This router has no route for the source or
group and no way to determine a potential
route.
0x06 WRONG_LAST_HOP This router is not the proper LHR.
0x07 NOT_FORWARDING This router is not forwarding this source and
group out the Outgoing Interface for an
unspecified reason.
0x08 REACHED_RP Reached the Rendezvous Point.
0x09 RPF_IF Mtrace2 Request arrived on the expected
RPF interface for this source and group.
0x0A NO_MULTICAST Mtrace2 Request arrived on an interface
that is not enabled for multicast.
0x0B INFO_HIDDEN One or more hops have been hidden from this
trace.
0x0C REACHED_GW Mtrace2 Request arrived on a gateway (e.g.,
a NAT or firewall) that hides the
information between this router and the
Mtrace2 client.
0x0D UNKNOWN_QUERY A non-transitive Extended Query Type was
received by a router that does not support
the type.
0x80 FATAL_ERROR A fatal error is one where the router may
know the upstream router but cannot forward
the message to it.
0x81 NO_SPACE There was not enough room to insert another
Standard Response Block in the packet.
0x83 ADMIN_PROHIB Mtrace2 is administratively prohibited.3.2.5. IPv6 Mtrace2 Standard Response Block
okay so this section is where we talk about the IPv6 version of the Standard Response Block 🦋 bestie, the Type field is also 0x04, same as the IPv4 one, so it's giving consistency 💅
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Arrival Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Local Address *
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Remote Address *
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Input packet count on Incoming Interface .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Output packet count on Outgoing Interface .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Total number of packets for this source-group pair .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtg Protocol | Multicast Rtg Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ 2 | S | Src Prefix Len | Forwarding Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ: 8 bits This field MUST be zeroed on transmission and ignored on reception.
Query Arrival Time: 32 bits Same definition as in IPv4.
Incoming Interface ID: 32 bits This field specifies the interface ID on which packets from the source or RP are expected to arrive, or 0 if unknown. This ID should be the value taken from InterfaceIndex of the IF-MIB [9] for this interface.
Outgoing Interface ID: 32 bits This field specifies the interface ID to which packets from the source or RP are expected to transmit, or 0 if unknown. This ID should be the value taken from InterfaceIndex of the IF-MIB [9] for this interface.
Local Address: 128 bits This field specifies a global IPv6 address that uniquely identifies the router. A unique local unicast address [12] SHOULD NOT be used unless the router is only assigned link-local and unique local addresses. If the router is only assigned link-local addresses, its link-local address can be specified in this field.
Remote Address: 128 bits This field specifies the address of the upstream router, which, in most cases, is a link-local unicast address for the upstream router.
Although a link-local address does not have enough information to identify a node, it is possible to detect the upstream router with the assistance of the Incoming Interface ID and the current router address (i.e., Local Address).
Note that this may be a multicast group (e.g., ALL-[protocol]- ROUTERS group) if the upstream router is not known because of the workings of a multicast routing protocol. However, it should be the unspecified address (::) if the Incoming Interface address is unknown.
Input packet count on Incoming Interface: 64 bits Same definition as in IPv4.
Output packet count on Outgoing Interface: 64 bits Same definition as in IPv4.
Total number of packets for this source-group pair: 64 bits Same definition as in IPv4, except if the S bit is set (see below), the count is for the source network, as specified by the 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 for all sources sending to this group. This counter should have the same value as ipMcastRoutePkts from the IP Multicast MIB [14] for this forwarding entry.
Rtg Protocol: 16 bits Same definition as in IPv4.
Multicast Rtg Protocol: 16 bits Same definition as in IPv4.
MBZ 2: 15 bits This field MUST be zeroed on transmission and ignored on reception.
S: 1 bit Same definition as in IPv4, except the Src Prefix Len field is used to mask the source address.
Src Prefix Len: 8 bits This field contains the prefix length this router has for the source. If the router is forwarding solely on group state, this field is set to 255 (0xff).
Forwarding Code: 8 bits Same definition as in IPv4.
3.2.6. Mtrace2 Augmented Response Block
In addition to the Standard Response Block, a multicast router on the traced path can optionally add one or multiple Augmented Response Blocks before sending the Request to its upstream router.
The Augmented Response Block is flexible for various purposes such as providing diagnosis information (see Section 7) and protocol verification. Its Type field is 0x05, and its format is as follows:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Augmented Response Type | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ: 8 bits This field MUST be zeroed on transmission and ignored on reception.
Augmented Response Type: 16 bits This field specifies the type of various responses from a multicast router that might need to communicate back to the Mtrace2 client as well as the multicast routers on the traced path.
The Augmented Response Type is defined as follows:
Code Type ====== ============================================== 0x0001 # of the returned Standard Response Blocks
When the NO_SPACE error occurs on a router, the router should send the original Mtrace2 Request received from the downstream router as a Reply back to the Mtrace2 client and continue with a new Mtrace2 Request. In the new Request, the router adds a Standard Response Block followed by an Augmented Response Block with 0x01 as the Augmented Response Type, and the number of the returned Mtrace2 Standard Response Blocks as the Value.
Each upstream router recognizes the total number of hops the Request has traced so far by adding this number and the number of the Standard Response Block in the current Request message.
This document only defines one Augmented Response Type in the Augmented Response Block. The description on how to provide diagnosis information using the Augmented Response Block is out of the scope of this document and will be addressed in separate documents.
Value: variable length The format is based on the Augmented Response Type value. The length of the Value field is Length field minus 6.
3.2.7. Mtrace2 Extended Query Block
There may be a sequence of optional Extended Query Blocks that follow an Mtrace2 Query to further specify any information needed for the Query. For example, an Mtrace2 client might be interested in tracing the path the specified source and group would take based on a certain topology. In this case, the client can pass in the multi-topology ID as the value for an Extended Query Type (see below). The Extended Query Type is extensible, and the behavior of the new types will be addressed by separate documents.
The Mtrace2 Extended Query Block's Type field is 0x06 and is formatted as follows:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ | T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Query Type | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ: 7 bits This field MUST be zeroed on transmission and ignored on reception.
T-bit (Transitive Attribute): 1 bit If the TLV Type is unrecognized by the receiving router, then this TLV is either discarded or forwarded along with the Query, depending on the value of this bit. If this bit is set, then the router MUST forward this TLV. If this bit is clear, the router MUST send an Mtrace2 Reply with an UNKNOWN_QUERY error.
Extended Query Type: 16 bits This field specifies the type of the Extended Query Block.
Value: 16 bits This field specifies the value of this Extended Query.
- Router Behavior
This section describes the router behavior in the context of Mtrace2 in detail.
4.1. Receiving an Mtrace2 Query
An Mtrace2 Query message is an Mtrace2 message with no response blocks filled in and uses a TLV Type of 0x01.
4.1.1. Query Packet Verification 🛂✨
Okay bestie, the first thing a router does when an Mtrace2 Query shows up is play bouncer 💅. It MUST check whether the Multicast Address and the Source Address are a valid combo (see Section 3.2.1), and whether the Mtrace2 Client Address is a valid IP unicast address. If either one is invalid, the Query MUST be silently ignored 🙈.
Mtrace2 totally supports a non-local client reaching the LHR/RP 🌍. BUT (plot twist) a router MUST support a mechanism to drop Queries from clients beyond a specified administrative boundary 🚧. The possible approaches are covered in Section 9.2.
If a local LHR client is required, the router has to check whether it's the proper LHR/RP for the destination address in the packet 👑. It's the proper local LHR if it has a multicast-capable interface on the same subnet as the Mtrace2 Client Address, AND it's the router that would forward traffic from the given (S,G) or (*,G) onto that subnet. It's the proper RP if the multicast group address in the Query is 0 and the IP header destination address is a valid RP address on this router.
If the router decides it is NOT the proper LHR/RP, or it just can't tell, it does one of two things depending on whether the Query came in by multicast or unicast 🦋. If it came in by multicast, it MUST be silently discarded 🗑️. If it came in by unicast, the router turns the Query into a Reply by changing the TLV Type to 0x03 and appending a Standard Response Block with a Forwarding Code of WRONG_LAST_HOP. The rest of the fields in that Standard Response Block MUST be zeroed. Then the router sends the Reply to the Mtrace2 Client Address on the Client Port # specified in the Mtrace2 Query 💌.
Duplicate Query messages, identified by the tuple (Mtrace2 Client Address, Query ID), SHOULD be ignored. This MAY be implemented using a cache of previously processed Queries keyed by the Mtrace2 Client Address and Query ID pair. How long the cached entries last is implementation specific. Duplicate Request messages MUST NOT be ignored in this manner.
Heads up, bestie: duplicate Requests are NOT the same as duplicate Queries, so don't go ignoring them with this cache trick 🙃
4.1.2. Query Normal Processing 🧠
When a router gets an Mtrace2 Query and decides it IS the proper LHR/RP, it turns the Query into a Request by changing the TLV Type from 0x01 to 0x02. Then it performs the steps listed in Section 4.2 🚀.
4.2. Receiving an Mtrace2 Request 📨
An Mtrace2 Request is an Mtrace2 message that uses the TLV Type of 0x02. The one exception is the LHR, whose Request was just converted from a Query. Every other Request a router receives should have at least one Standard Response Block filled in 💕.
4.2.1. Request Packet Verification 🔍
If the Mtrace2 Request doesn't come from an adjacent router, OR it isn't addressed to this router, OR it's addressed to a multicast group that isn't a link-scoped group (i.e., 224.0.0.0/24 for IPv4 and FFx2::/16 for IPv6 [2]), it MUST be silently ignored 🙅♀️. The router SHOULD use the Generalized TTL Security Mechanism (GTSM) [13] to figure out whether it's adjacent or not. Source verification specified in Section 9.2 is also considered 🛡️.
If the sum of the number of the Standard Response Blocks in the received Mtrace2 Request and the value of the Augmented Response Type of 0x01, if any, is equal or more than the # Hops in the Mtrace2 Request, it MUST be silently ignored 💀.
4.2.2. Request Normal Processing 🧩
When a router receives an Mtrace2 Request message, it performs the following steps. Note that more than one situation can be covered by the Forwarding Codes 🤯. The first one encountered is the one that gets reported. So all "note Forwarding Code N" should be interpreted as "if Forwarding Code is not already set, set Forwarding Code to N". Also, in the steps below, the "Outgoing Interface" is the one the Mtrace2 Request arrives on 🎀.
- Prepare a Standard Response Block to be appended to the packet, setting all fields to an initial default value of zero 🧸.
- If Mtrace2 is administratively prohibited, note the Forwarding Code of
ADMIN_PROHIBand skip to step 4 🚫. - In the Standard Response Block, fill in the
Query Arrival Time,Outgoing Interface Address(for IPv4) orOutgoing Interface ID(for IPv6),Output Packet Count, andFwd TTL(for IPv4) 📝. - Attempt to determine the forwarding information for the specified source and group, using the same mechanisms that would be used when a packet is received from the source destined for the group 🔎. A state need not be instantiated. It can be a "phantom" state created only for the purpose of the trace, such as "dry-run" 👻.
If using a shared-tree protocol and there is no source-specific state, or if no source-specific information is desired (i.e., all ones for IPv4 or an unspecified address (::) for IPv6), group state should be used. If there is no group state or no group-specific information is desired, potential source state (i.e., the path that would be followed for a source-specific "join") should be used 🌳.
- If no forwarding information can be determined, the router notes a Forwarding Code of
NO_ROUTE, sets the remaining fields that haven't been filled in yet to zero, and then sends an Mtrace2 Reply back to the Mtrace2 client 😭. - If a Forwarding Code of
ADMIN_PROHIBhas been set, skip to step 7. Otherwise, fill in theIncoming Interface Address(orIncoming Interface IDandLocal Addressfor IPv6),Upstream Router Address(orRemote Addressfor IPv6),Input Packet Count,Total Number of Packets,Routing Protocol,S, andSrc Mask(orSrc Prefix Lenfor IPv6), using the forwarding information determined in step 4 🧁. - If the Outgoing Interface is not enabled for multicast, note a Forwarding Code of
NO_MULTICAST. If the Outgoing Interface is the interface the router would expect data to arrive from the source on, note Forwarding CodeRPF_IF. If the Outgoing Interface is not one the router would forward data from the source or RP to the group on, a Forwarding Code ofWRONG_IFis noted. In those three cases, the router will return an Mtrace2 Reply and terminate the trace 🛑. - If the group is subject to administrative scoping on either the Outgoing or Incoming Interfaces, a Forwarding Code of
SCOPEDis noted 🔒. - If this router is the RP for the group for a non-source-specific Query, note a Forwarding Code of
REACHED_RP👑. The router will send an Mtrace2 Reply and terminate the trace. - If this router is directly connected to the specified source or source network on the Incoming Interface, it sets the Upstream Router Address (for IPv4) or the Remote Address (for IPv6) of the response block to zero 🏁. The router will send an Mtrace2 Reply and terminate the trace.
- If this router has sent a prune upstream that applies to the source and group in the Mtrace2 Request, it notes a Forwarding Code of
PRUNE_SENT✂️. If the router has stopped forwarding downstream in response to a prune sent by the downstream router, it notes a Forwarding Code ofPRUNE_RCVD. If the router should normally forward traffic downstream for this source and group but isn't, it notes a Forwarding Code ofNOT_FORWARDING🙈. - If this router is a gateway (e.g., a NAT or firewall) that hides the information between this router and the Mtrace2 client, it notes a Forwarding Code of
REACHED_GW🌐. The router continues the processing as described in Section 4.5. - If the total number of the Standard Response Blocks, including the newly prepared one, plus the value of the Augmented Response Type of
0x01, if any, is less than the# Hopsin the Request, the packet is forwarded to the upstream router as described in Section 4.3. Otherwise, the packet is sent as an Mtrace2 Reply to the Mtrace2 client as described in Section 4.4 💖.
4.3. Forwarding Mtrace2 Request 🦋
This section describes how an Mtrace2 Request should be forwarded 🕊️.
4.3.1. Destination Address 🎯
If the upstream router is known for this Request, the Mtrace2 Request is sent to that router. If the Incoming Interface is known but the upstream router isn't, the Mtrace2 Request is sent to an appropriate multicast address on the Incoming Interface. The multicast address SHOULD depend on the multicast routing protocol in use, such as the ALL-[protocol]-ROUTERS group 📡. It MUST be a link-scoped group (i.e., 224.0.0.0/24 for IPv4 and FF02::/16 for IPv6), and it MUST NOT be the all-systems multicast group (224.0.0.1) for IPv4 or the All Nodes Address (FF02::1) for IPv6. It MAY also be the all-routers multicast group (224.0.0.2) for IPv4 or the All Routers Address (FF02::2) for IPv6, if the routing protocol in use does not define a more appropriate multicast address 🧭.
4.3.2. Source Address 🏷️
An Mtrace2 Request should be sent with the address of the Incoming Interface. However, if the Incoming Interface is unnumbered, the router can use one of its numbered interface addresses as the source address ✨.
4.3.3. Appending Standard Response Block 🧱
An Mtrace2 Request MUST be sent upstream towards the source or the RP, after appending a Standard Response Block to the end of the received Mtrace2 Request. The Standard Response Block includes the multicast states and statistics information of the router, as described in Section 3.2.4 📊.
If appending the Standard Response Block would make the Mtrace2 Request packet longer than the MTU of the Incoming Interface, or, in the case of IPv6, longer than 1280 bytes, the router MUST change the Forwarding Code in the last Standard Response Block of the received Mtrace2 Request into NO_SPACE 😱. The router then turns the Request into a Reply and sends the Reply as described in Section 4.4.
The router will continue with a new Request by copying the old Request, excluding all the response blocks, followed by the previously prepared Standard Response Block and an Augmented Response Block with 0x01 as the Augmented Response Type, and the number of the returned Standard Response Blocks as the Value 🧃.
4.4. Sending Mtrace2 Reply 📬
An Mtrace2 Reply MUST be returned to the client by a router if any of the following conditions occur 🌸:
- The total number of the traced routers are equal to the
# Hopsin the Request (including the one just added) plus the number of the returned blocks, if any. - 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
1280bytes; see Section 4.3.3 for additional details on the handling of this case.) - 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 💌
An Mtrace2 Reply MUST be sent to the address specified in the Mtrace2 Client Address field in the Mtrace2 Request 💖.
4.4.2. Source Address 🦋
okay bestie, so an Mtrace2 Reply SHOULD go out with the address of the router's Outgoing Interface 💅 but if that Outgoing Interface address is unnumbered, the router can just grab one of its numbered interface addresses and use that as the source address instead. no stress 🫶
4.4.3. Appending Standard Response Block 🎀
an Mtrace2 Reply MUST be sent with the prepared Standard Response Block appended at the end of the received Mtrace2 Request, except in the case of the NO_SPACE Forwarding Code 🙈 that one's the exception, periodt.
4.5. Proxying Mtrace2 Query 🌸
this one's giving middleman energy 😭 when a gateway (like a NAT or a firewall) needs to block unicast packets to the Mtrace2 client, or hide information between itself and the client, and it gets an Mtrace2 Query from an adjacent host or an Mtrace2 Request from an adjacent router, it appends a Standard Response Block with REACHED_GW as the Forwarding Code. then it turns the Query or Request into a Reply and sends that Reply back to the client ✨
at the same time, the gateway makes a brand new Mtrace2 Query by copying the original Mtrace2 header (the Query or Request without any of the response blocks) and changing a few things:
- setting the RPF interface's address as the Mtrace2 Client Address;
- using its own port number as the
Client Port #; and, - decreasing
# Hopsby ((number of the Standard Response Blocks that were just returned in a Reply) - 1). The "- 1" in this expression accounts for the additional Standard Response Block appended by the gateway router.
that new Mtrace2 Query then gets sent to the upstream router or to an appropriate multicast address on the RPF interface 🦋
when the gateway gets an Mtrace2 Reply whose Query ID matches the one in the original Mtrace2 header, it MUST relay that Reply back to the Mtrace2 client by replacing the Reply's header with the original Mtrace2 header 💖 if the gateway doesn't get the matching Mtrace2 Reply within the [Mtrace Reply Timeout] period (see Section 5.8.4), then it silently discards the original Mtrace2 Query or Request and terminates the trace. ghosted, bestie 👻
4.6. Hiding Information 🧚
information about a domain's topology and connectivity may be hidden from Mtrace2 Requests 🤫 the Forwarding Code of INFO_HIDDEN can be used to note that. for example, the Incoming Interface address and packet count on the ingress router of a domain, and the Outgoing Interface address and packet count on the egress router of that domain, can be specified as all ones. also, the source-group packet count (see Sections 3.2.4 and 3.2.5) within the domain may be all ones if it's hidden 🌈
5. Client Behavior 💜
this section breaks down how an Mtrace2 client behaves, in detail 🔍
5.1. Sending Mtrace2 Query 🦋
an Mtrace2 client starts an Mtrace2 Query by sending it to the LHR of interest 🎯
5.1.1. Destination Address 🌷
if an Mtrace2 client knows the proper LHR, it unicasts an Mtrace2 Query packet to that router. otherwise, it MAY send the Mtrace2 Query packet to the all-routers multicast group (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6. this makes sure the packet gets received by the LHR on the subnet ✨
see also Section 5.4 on determining the LHR 💅
5.1.2. Source Address 🫶
an Mtrace2 Query MUST be sent with the client's interface address, which is the Mtrace2 Client Address 🎀
5.2. Determining the Path 🗺️
an Mtrace2 client could send an initial Query with a big # Hops value, to try tracing the full path 👑 if that attempt fails, one strategy is a linear search (just like the classic unicast traceroute program): set the # Hops field to 1 and try for a Reply, then 2, and so on. if no Reply shows up at a certain hop, that hop is marked as the probable cause of forwarding failures on the path 💀 the sender can still try to keep tracing past the non-responding hop by bumping the hop count higher, in hopes that further hops respond. but each of these attempts MUST NOT be started before the previous attempt has ended, either because a Reply came back successfully or because the [Mtrace Reply Timeout] timeout has happened 🙅♀️
see also Section 5.6 on receiving the results of a trace 🧚
5.3. Collecting Statistics 📊
once a client decides it has traced the whole path, or as much as it can expect to (see Section 5.8), it might collect statistics by waiting a bit and running a second trace 🍓 if the path is the same in both traces, the statistics can be displayed as described in Sections 7.3 and 7.4 💖
5.4. Last-Hop Router (LHR) 🎯
the Mtrace2 client might not know which router is the last hop, or that router might sit behind a firewall that blocks unicast packets but lets multicast packets through 🧱 in those cases, the Mtrace2 Request should be multicasted to the all-routers multicast group (224.0.0.2) for IPv4 or All Routers Address (FF02::2) for IPv6. all routers except the correct last-hop router SHOULD ignore any Mtrace2 Request that came in via multicast 🙈
5.5. First-Hop Router (FHR) 🌅
the IANA assigned 224.0.1.32 as the default multicast group for old IPv4 mtrace (v1) responses, so mtrace clients that can't reach the first-hop router with unicast still get their answers 🫶 Mtrace2, however, doesn't need any IPv4/IPv6 multicast addresses for its Mtrace2 Replies 🙌 every Mtrace2 Reply goes to the unicast address listed in the Mtrace2 Client Address field of that Reply 💜
5.6. Broken Intermediate Router 💔
a broken intermediate router might just not understand Mtrace2 packets and drop them 🗑️ so the Mtrace2 client gets no Reply at all. it should then do a hop-by-hop search by setting the # Hops field until it finally gets an Mtrace2 Reply 🔎 the client may use a linear or a binary search, but the binary one is likely to be slower, since every failure means waiting out the [Mtrace Reply Timeout] period 🐢
5.7. Non-supported Router 🚫
when a non-supported router gets an Mtrace2 Query or Request whose destination address is a multicast address, the router will silently discard the message 🤐
when the router gets an Mtrace2 Query destined to itself, it returns an Internet Control Message Protocol (ICMP) port unreachable to the Mtrace2 client. but when it gets an Mtrace2 Request destined to itself, it returns an ICMP port unreachable to its adjacent router, the one the Request came from 🔙 so the Mtrace2 client has to end the trace once the [Mtrace Reply Timeout] timeout has happened, and then it can issue another Query with a lower number of # Hops 🔁
5.8. Mtrace2 Termination 🛑
when you're doing an expanding hop-by-hop trace, you need to know when to stop expanding 🧐
5.8.1. Arriving at Source 🏁
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 the upstream router is zero 🥳
5.8.2. Fatal Error 🚨
a trace has hit a fatal error if the last Forwarding Error in the trace has the 0x80 bit set 😱
5.8.3. No Upstream Router 🙅
a trace cannot continue if the last upstream router in the trace is set to 0 🧱
5.8.4. Reply Timeout ⏰
this document defines the [Mtrace Reply Timeout] value, which is used to time out an Mtrace2 Reply as seen in Sections 4.5, 5.2, and 5.7 ⏳ the default [Mtrace Reply Timeout] value is 10 (seconds), and it can be changed manually on the Mtrace2 client and routers 🛠️
5.9. Continuing after an Error 🩹
when the NO_SPACE error happens, as described in Section 4.2, a router sends an Mtrace2 Reply back to the Mtrace2 client and continues with a new Request (see Section 4.3.3) 📨 so the Mtrace2 client may end up receiving multiple Mtrace2 Replies from different routers along the path. when that happens, the client MUST treat them as one single Mtrace2 Reply message by collating the Augmented Response Blocks of the subsequent Replies that share the same Query ID, sequencing each cluster of Augmented Response Blocks based on the order they were received 🧩
if a trace times out, it's very likely that a router in the middle of the path doesn't support Mtrace2 🕵️♀️ that router's address will be in the Upstream Router field of the last Standard Response Block in the last received Reply. a client may be able to work out a list of neighbors of the non-responding router (e.g., by using the Simple Network Management Protocol (SNMP) [12] [14]). those neighbors could then be probed (via the multicast MIB [14]) to figure out which one is the upstream neighbor (i.e., an RPF neighbor) of the non-responding router 🔍 this algorithm works because, even though there may be several neighbors, the non-responding router should only have sent a "join" to the one neighbor on its selected RPF path. so only the RPF neighbor should list the non-responding router as a multicast next hop in its MIB output list for the affected multicast route 🎯✨
6. Protocol-Specific Considerations 🔥
this section describes how Mtrace2 behaves when different multicast protocols are involved 💫
6.1. PIM-SM 🌊
when an Mtrace2 reaches a PIM-SM RP, and the RP doesn't forward the trace on, that means the RP hasn't done a source-specific join, so there's no more state to trace 🫠 but the path that traffic would take if the RP did do a source-specific join can still be traced 🧭 just set the trace destination to the RP, the trace source to the traffic source, and the trace group to 0. this Mtrace2 Query may be unicasted to the RP, and the RP takes the same actions as an LHR 💅
6.2. Bidirectional PIM 🔄
Bidirectional PIM [4] is a variant of PIM-SM that builds bidirectional shared trees connecting multicast sources and receivers 🌳 along those trees, multicast data is natively forwarded from the sources up to the Rendezvous Point Link (RPL), and from there down to receivers, without needing any source-specific state 🦋 unlike PIM-SM, Bidirectional PIM always has state to trace 🙌
a Designated Forwarder (DF) for a given Rendezvous Point Address (RPA) is in charge of forwarding downstream traffic onto its link, and of forwarding upstream traffic from its link towards the RPL that the RPA belongs to 🫶 so the Mtrace2 Reply reports DF addresses or RPA along the path 📍
6.3. PIM-DM 🌪️
routers running PIM - Dense Mode (PIM-DM) [11] don't know which path packets will take unless traffic is actually flowing 😵💫 without some extra protocol mechanism, that means in an environment with multiple possible paths and branch points on shared media, Mtrace2 can only trace existing paths, not potential ones 🙈 when there are multiple possible paths but the branch points aren't on shared media, the upstream router is known, but the LHR might not know it's the appropriate last hop 🤷♀️
when traffic is flowing, PIM-DM routers know whether or not they're the LHR for the link (because they won or lost an Assert battle), and they know who the upstream router is (because it won an Assert battle). so Mtrace2 is always able to follow the proper path when traffic is flowing 👑🌈
6.4. IGMP/MLD Proxy ✨
okay so an IGMP or Multicast Listener Discovery (MLD) Proxy [3] is basically the middle-man router, and when it gets an Mtrace2 Query on an Incoming Interface 🦋, it writes a WRONG_IF into the Forwarding Code of the last Standard Response Block (see Section 3.2.4) and sends the Mtrace2 Reply straight back to the Mtrace2 client. 💅 but if the Query shows up on an Outgoing Interface of the IGMP/MLD proxy instead, it gets forwarded out of its Incoming Interface toward the upstream router. no cap, the direction it arrives from decides everything 🫶
7. Problem Diagnosis 🔍
this section is all about the different situations where Mtrace2 can help you debug multicast problems. it's giving detective era 🕵️♀️✨
7.1. Forwarding Inconsistencies
the Forwarding Error code can tell you if a group is unexpectedly pruned 🌸 or administratively scoped. so if something's getting dropped and you can't figure out why, check this code first bestie 💖
7.2. TTL or Hop-Limit Problems
ngl this one is so clever 🧚. if you take the maximum number of hops from the source and forward the TTL threshold over all of those hops, you can figure out the TTL or hop limit the source needs in order to reach the destination. main character energy for TTL math 👑
7.3. Packet Loss
okay packet loss is the drama 😭. if you take multiple traces, you can track the packet-loss situation by watching the gap between the output packet count for the specified source-group address pair at a given upstream router and the input packet count on the next-hop downstream router. on a point-to-point link, any steadily increasing gap in those counts means packets are getting lost 💀. the counts won't match exactly because of Mtrace2 Request propagation delay, but the gap should basically stay the same (with a bit of jitter from differences in propagation time between the trace iterations). the gap only keeps climbing when loss is actually happening 📈
on a shared link, though, the input count can be bigger than the output count at the previous hop, since other routers or hosts on the link might be injecting packets too 🙈. that shows up as "negative loss", and it can hide real packet loss, so don't get fooled by it!!
also, in addition to the input and output packet counts for all multicast traffic on the interfaces, the Standard Response Block includes a count of the packets a node forwarded for the specified source-group pair 🍓. if you take the difference in that count between two traces and then compare those differences between two hops, you get a measure of packet loss for just the traffic going from the specified source to the specified receiver via the specified group. this measure isn't affected by shared links, which is so iconic 🫶
on a point-to-point link that's a multicast tunnel, packet loss usually comes from congestion in the unicast routers along that tunnel's path 🌈. on native multicast links, loss is more likely in the output queue of one hop (maybe because of priority dropping) or in the input queue at the next hop 🔥. the counters in the Standard Response Block can't tell these cases apart, and differences in packet counts between the Incoming and Outgoing Interfaces on one node generally can't be used to measure queue overflow in that node. so don't try to make the numbers say more than they do, periodt 🙅♀️
7.4. Link Utilization
again, with two traces you can divide the difference in the input or output packet counts at some hop by the difference in timestamps from that same hop to get the packet rate over the link 🦋. if you know the average packet size, you can also estimate the link utilization and see whether the packet loss might be from a rate limit or from the physical capacity of a particular link being exceeded ⭐
7.5. Time Delay
if the routers have synchronized clocks, you can estimate propagation and queuing delay from the differences between the timestamps at successive hops 🧚. BUT this delay also includes control processing overhead, so it isn't necessarily a good picture of the delay that data traffic would actually experience 🙈
8. IANA Considerations 🎀
the following registries have been created and are maintained under the "Specification Required" registry policy as specified in [6] 📋
8.1. "Mtrace2 Forwarding Codes" Registry
this registry holds integers in the range 0-255 🍓. assigning a Forwarding Code means you need to give it a value and a name. the initial values for the Forwarding Codes are in the table at the end of Section 3.2.4, and additional values (specific to IPv6) 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 which the new Forwarding Code is used, so no mystery codes allowed 💅
8.2. "Mtrace2 TLV Types" Registry
assigning a TLV Type means giving it an integer value "Code" in the range 0-255 and a name ("Type") 🫶. the initial values for the TLV Types are in the table at the beginning of Section 3.2 ✨
8.3. UDP Destination Port
IANA has assigned UDP user port 33435 (mtrace) for use by this protocol as the Mtrace2 UDP destination port 🦋
9. Security Considerations 🔐
okay this is the serious part, bestie 😤 this section covers some of the security considerations related to Mtrace2.
9.1. Addresses in Mtrace2 Header
an Mtrace2 header includes three addresses: a source address, a multicast address, and an Mtrace2 Client Address 🎀. these addresses MUST be congruent with the definition in Section 3.2.1, and forwarding Mtrace2 messages that have invalid addresses MUST be prohibited 🚫. for example, if the Mtrace2 Client Address in a header is a multicast address, then a router that receives that Mtrace2 message MUST silently discard it 🤫 not me being dramatic, this is literally a rule 💀
9.2. Verification of Clients and Peers
a router providing Mtrace2 functionality MUST support a source-verification mechanism that drops Queries from clients and Requests from peer router or client addresses that are unauthorized or that are beyond a specified administrative boundary 🛡️. this verification could, for example, be specified with a list of allowed or disallowed clients and peer addresses or subnets for a given Mtrace2 message type sent to the Mtrace2 protocol port 📋. if a Query or Request comes from an unauthorized address or from one beyond the specified administrative boundary, the Query/Request MUST NOT be processed 🙅♀️. the router MAY, however, perform rate-limited logging of such events 📝
the required use of source verification on the participating routers cuts down on the ways spoofed Query/Request packets could get in and cause DoS amplification attacks against an authorized "query" host 😭. the source verification mechanisms protect against this by letting Query messages from an authorized host address be received only by the router(s) connected to that host, and only on the interface that host is attached to 🔒. for protection against spoofed Request messages, the mechanisms only allow Request messages from a directly connected routing peer, and only on the interface that peer is attached to 🫶
note that the following vulnerabilities can't be covered by the source verification methods described here. still, these methods can prevent attacks launched from outside the boundaries of a given network, as well as from any hosts inside the network that aren't on the same LAN as an intended authorized query client 🌈
- a server/router "B" other than the server/router "A" that actually "owns" a given IP address could, if it's connected to the same LAN, send an Mtrace2 Query or Request with the source address set to the address for server/router "A". this isn't a significant threat, though, if only trusted servers and routers are connected to that LAN 🤝
- a malicious application running on a trusted server or router could send packets that might cause an amplification problem. it's beyond the scope of this document to protect against a DoS attack launched from the same host that's the target of the attack, or from another "on path" host, but this isn't a likely threat scenario 👀. also, routers on the path MAY rate-limit the packets as specified in Sections 9.5 and 9.6 🚦
9.3. Topology Discovery
Mtrace2 can be used to discover any actively used topology 🗺️. if your network topology is a secret, Mtrace2 may be restricted at the border of your domain using the ADMIN_PROHIB Forwarding Code 🤐
9.4. Characteristics of Multicast Channel
Mtrace2 can be used to discover what sources are sending to what groups and at what rates 📊. if this information is a secret, Mtrace2 may be restricted at the border of your domain using the ADMIN_PROHIB Forwarding Code 🤫
9.5. Limiting Query/Request Rates
a router may limit Mtrace2 Queries and Requests by ignoring some of the consecutive messages 🚧. the router MAY randomly ignore the received messages to minimize processing overhead, i.e., to keep fairness in processing Queries or to prevent traffic amplification ⚖️. the rate limit is left up to the router's implementation 💁♀️
9.6. Limiting Reply Rates
the proxying and NO_SPACE behaviors may result in one Query returning multiple Reply messages 😳. to prevent abuse, the routers in the traced path MAY need to rate-limit the Replies 🚦. the rate-limit 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 with forged or multicast client/source addresses in Mtrace2 Query or Request messages 😤. the recommended protections against this kind of attack are described in Sections 9.1, 9.2, 9.5, and 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, there's a potential 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 🔐
also, for a router running a PIM protocol (PIM-SM, PIM-DM, PIM - Source-Specific Multicast (PIM-SSM), or Bidirectional PIM), the router SHOULD drop any Mtrace2 Request or Reply message received from an IP address that doesn't correspond to an authenticated PIM neighbor on the interface the packet came in on 🚫. the point of this text is to stop non-router endpoints from injecting Request messages 🙅♀️. implementations of non-PIM protocols SHOULD employ some other mechanism to prevent this attack 🛡️
9.7.3. Leaking of Confidential Topology Details
Mtrace2 Queries are a potential way to get confidential topology information about a targeted network 🕵️♀️. Sections 9.2 and 9.4 describe required and optional methods for making sure information delivered with Mtrace2 messages doesn't get spread to unauthorized hosts 🔒💖
9.7.4. Delivery of False Information (Forged Reply Messages) 💀
Okay bestie, forged Reply messages are lowkey the scary one 😭 They could hand a host invalid or incorrect topology info. They could also mess with multicast traffic statistics, the propagation delay between hops, which multicast and unicast protocols are in use between hops, and any other info people use to analyze multicast traffic patterns and troubleshoot problems. The threat is real, but a few things mitigate it 🛡️
- The source verification of permissible source addresses that Section 9.2 requires 🔒 stops forged Replies from addresses that haven't been authorized to send Mtrace2 messages to routers on a given network. It can block forged Reply messages from any "off path" source, so random outsiders are out ✨
- To forge a Reply, the sender would need to somehow know (or guess) the 2-byte Query ID for an extant Query AND the dynamically allocated source port number 👀 Since source verification can block "off path" sources, this threat is basically limited to "on path" attackers.
- Source verification is required (Section 9.2), and PIM neighbor authentication is recommended (Section 9.7.2) for messages that only count when they come from a multicast routing peer (Request and Reply messages). Together, that kills the possibility of a forged Reply from an authorized host address that doesn't belong to a multicast peer router 🙅♀️
- Encryption between the source of a Query and the endpoint of the trace would protect the Query ID and the dynamically allocated client (source) port (see Section 3.2.1) 🔐 These are the values you'd need to build a forged Reply that passes the querying client's validity checks. It isn't practical, though, because the whole reason you run an Mtrace2 is that the querying client doesn't know the destination endpoint (or the path to it) 😅 Encrypting between the client and the Mtrace2 endpoints isn't practical, but it may be possible to stop forged responses from "off path" nodes on any Mtrace2 transit LAN by devising a scheme that encrypts the critical parts of an Mtrace2 message between each valid sender/receiver pair at each hop used for multicast/Mtrace2 transit. Encryption protection between nodes is, however, totally out of scope for this document 🙈
10. References 📚
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.
[2] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, https://www.rfc-editor.org/info/rfc4291.
[3] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, August 2006, https://www.rfc-editor.org/info/rfc4605.
[4] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, https://www.rfc-editor.org/info/rfc5015.
[5] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, https://www.rfc-editor.org/info/rfc7761.
[6] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, https://www.rfc-editor.org/info/rfc8126.
[7] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, https://www.rfc-editor.org/info/rfc8200.
10.2. Informative References
[9] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, https://www.rfc-editor.org/info/rfc2863.
[10] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, https://www.rfc-editor.org/info/rfc3376.
[11] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, January 2005, https://www.rfc-editor.org/info/rfc3973.
[12] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, https://www.rfc-editor.org/info/rfc4191.
[13] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, https://www.rfc-editor.org/info/rfc5082.
[14] McWalter, D., Thaler, D., and A. Kessler, "IP Multicast MIB", RFC 5132, DOI 10.17487/RFC5132, December 2007, https://www.rfc-editor.org/info/rfc5132.
[15] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, https://www.rfc-editor.org/info/rfc6513.
[16] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, https://www.rfc-editor.org/info/rfc7450.
Acknowledgements 🫶
This spec started out mostly as a transcription of Van Jacobson's slides from the 30th IETF meeting, plus the implementation in mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve Casner, Steve Deering, Dino Farinacci, and Deb Agrawal. The original multicast traceroute client, mtrace (version 1), was implemented 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 Pusateri. 👑
For the Mtrace version 2 specification, the authors want to give super special thanks to Tatsuya Jinmei, Bill Fenner, and Steve Casner 💜 Extensive comments also came in from David L. Black, Ronald Bonica, Yiqun Cai, Liu Hui, Bharat Joshi, Robert Kebler, John Kristoff, Mankamana Mishra, Heidi Ou, Eric Rescorla, Pekka Savola, Shinsuke Suzuki, Dave Thaler, Achmad Husni Thamrin, Stig Venaas, Cao Wei, and the MBONED Working Group members 🌸
Authors' Addresses 🎀
Hitoshi Asaeda
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
Japan
Email: asaeda@nict.go.jp
Kerry Meyer
Dell EMC
176 South Street
Hopkinton, MA 01748
United States
Email: kerry.meyer@me.com
WeeSan Lee (editor)
Email: weesan@weesan.com📦 where this page comes from
- ietf: rfc8487 2018-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms