RFC 3810
Multicast Listener Discovery Version 2 (MLDv2) for IPv6
Multicast Listener Discovery Version 2 (MLDv2) for IPv6 🎀
Part 1 of 14, bestie! 💖
Okay so this is an RFC (an Internet standard, basically the protocol rulebook 📜). It's the Standards Track one, which means it's an actual official spec and not just a vibe. It was written in June 2004 by R. Vida, Ed. and L. Costa, Ed., both from LIP6. They're the editors (the people who wrangled the whole doc into shape). It updates RFC 2710, the original MLD spec, so it doesn't replace it, it adds to it 🦋. The Request for Comments number is 3810, and the Network Working Group is the team that put it together ✨.
Status of This Memo ✨
Okay, this part is the fine print, but it matters! It says this is an Internet standards track protocol for the Internet community, and the authors want people to discuss it and suggest improvements 💬. If you want to know where it stands officially, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the distribution is unlimited, so share away 🌸.
Copyright Notice 🌈
Copyright (C) The Internet Society (2004). Yep, it's owned by the Internet Society 💅.
Abstract 🦋
So, the big picture. This doc updates RFC 2710 and specifies Version 2 of the Multicast Listener Discovery Protocol (MLDv2) 🎀. MLD is what an IPv6 router uses to figure out which multicast listeners are hanging out on its directly attached links, and which multicast addresses those neighbors actually care about 👀. MLDv2 is built to play nicely with MLDv1 🤝. The big new power is that a node can say "I only want packets to this multicast address from these specific source addresses," or "I want everything except packets from these specific sources." That's source filtering, and it's giving main character energy 👑.
Table of Contents 🧚
Here's the roadmap, copied exactly so the page numbers still match:
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
3. The Service Interface for Requesting IP Multicast Reception . 9
4. Multicast Listening State Maintained by Nodes . . . . . . . . 11
5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13
6. Protocol Description for Multicast Address Listeners. . . . . 27
7. Protocol Description for Multicast Routers. . . . . . . . . . 34
8. Interoperation with MLDv1 . . . . . . . . . . . . . . . . . . 48
9. List of Timers, Counters, and their Default Values. . . . . . 51
10. Security Considerations . . . . . . . . . . . . . . . . . . . 55
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 56
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57
Appendix A. Design Rationale. . . . . . . . . . . . . . . . . . . 58
Appendix B. Summary of Changes from MLDv1 . . . . . . . . . . . . 59
Editors' Contact Information. . . . . . . . . . . . . . . . . . . 61
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 61
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 621. Introduction ✨
Okay bestie, so MLD is used by IPv6 routers to find out which multicast listeners (nodes that want to receive multicast packets) are on their directly attached links 📡. It also figures out which multicast addresses those neighbors are actually into 💖. Here's a fun twist: a multicast router can also be a listener for one or more multicast addresses 🤯. In that case it does both the "multicast router part" and the "multicast address listener part" of the protocol. It collects the listener info its multicast routing protocol needs, and it also tells itself and its neighboring multicast routers what it's listening to. Multitasking queen 👑.
This doc specifies Version 2 of MLD. The old version, MLDv1, is defined in [RFC2710], and we'll just call it MLDv1 from here 🌸. MLDv2 is basically a translation of the IGMPv3 protocol [RFC3376] for IPv6 🦋.
Compared to MLDv1, MLDv2 adds source filtering 🔥. That means a node can say it only wants packets only from specific source addresses. This is needed for Source-Specific Multicast [RFC3569]. Or it can say it wants packets from all but specific source addresses, sent to a particular multicast address. And yes, MLDv2 is still designed to be interoperable with MLDv1 🫶.
Now the formatting notes, because this doc has some rules. The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] 📜. Since there's no italics in plain text, emphasis is shown by wrapping a word or phrase in * characters 💅. Also, square brackets mean "the value of the enclosed variable," not the variable's name written without brackets 🤓.
2. Protocol Overview 🌈
Here's the quick tour before the deep dive. The protocol details come later ✨.
MLD is an asymmetric protocol 🙈. That means it gives multicast address listeners (hosts or routers that listen to multicast packets) and multicast routers separate behaviors. The whole point is to help each multicast router learn, for each of its directly attached links, which multicast addresses and which sources have interested listeners there 🎯. That info goes to whatever multicast routing protocol the router is running, so multicast packets reach every link with someone who wants them 🚀.
Multicast routers only need to know that at least one node on an attached link is listening to packets for a particular multicast address from a particular source 💜. A multicast router doesn't have to individually track what each neighboring node wants 🙃. (Still, check out Appendix A2 item 1 if you want the reasoning behind that.)
A multicast router runs the router part of MLDv2 (detailed in section 7) on each of its directly attached links 🧚. If a router has more than one interface on the same link, it only needs to run the protocol on one of them 💅. How the router behaves depends on whether there are several multicast routers on the same subnet. If there are, a querier election mechanism (described in section 7.6.2) picks a single router to be in Querier state, and that router is called the Querier 👑. All the multicast routers on the subnet listen to the messages from multicast address listeners and keep the same listening information state. That way, if the current Querier fails, someone else can take over 🛟. Still, only the Querier sends periodic or triggered query messages on the subnet, as described in section 7.1 🌸.
A multicast address listener runs the listener part of MLDv2 (detailed in section 6) on all interfaces that support multicast reception 🎀. This is true even if more than one of those interfaces are connected to the same link 🦋.
2.1. Building Multicast Listening State on Multicast Address Listeners 💖
Okay, this is where listeners build their state. Upper-layer protocols and applications running on a multicast address listener node use specific service interface calls (described in section 3) to ask the IP layer to turn reception of packets sent to specific multicast addresses on or off 🔥. The node keeps Multicast Address Listening state for each socket where those service interface calls were made (section 4.1) 🧠. On top of that per-socket state, a node must also maintain or compute multicast listening state for each of its interfaces (section 4.2) 🫶.
Conceptually, that per-interface state is a set of records. Each record has an IPv6 multicast address, a filter mode, and a source list 📋. The filter mode is either INCLUDE or EXCLUDE 🌈.
- In INCLUDE mode, reception of packets sent to the multicast address is enabled only from the source addresses in the source list ✅.
- In EXCLUDE mode, reception is enabled from all source addresses except the ones in the source list 🚫.
Here's the rule of thumb: there's at most one record per multicast address for a given interface 💅. This per-interface state is derived from the per-socket state, but it can differ when different sockets have different filter modes and/or source lists for the same multicast address and interface 🧚.
After the IP layer accepts a multicast packet from an interface, delivering it to an application on a particular socket depends on that socket's multicast listening state. It can also depend on other stuff, like which transport-layer port the socket is bound to 🔌. And the big one: MLDv2 messages are not subject to source filtering and must always be processed by hosts and routers 🙌. No exceptions, periodt 💀.
2.2. Exchanging Messages between the Querier and the Listening Nodes 💌
okay so there are three types of MLDv2 query messages 🫶: General Queries, Multicast Address Specific Queries, and Multicast Address and Source Specific Queries. The Querier sends General Queries periodically to learn about multicast address listener info on an attached link 👀. These queries are how the Multicast Address Listener state inside all multicast routers on the link gets built and refreshed ✨.
When a node gets one of these queries, it responds by reporting its per-interface Multicast Address Listening state in Current State Report messages. Those go to a specific multicast address that all MLDv2 routers on the link listen to 📡. But if a node's listening state changes, it doesn't wait around. It immediately reports the change in a State Change Report 🚨. A State Change Report contains Filter Mode Change records, Source List Change records, or records of both types 💅. A detailed description of the report messages is in section 5.2.12.
Both router and listener state changes are mainly triggered by a specific timer expiring, or by receiving an MLD message. (A listener state change can also be triggered by a service interface call, fr 🧚.) So, to make the protocol robust even when message exchanges are unreliable, messages get retransmitted several times 🔁. Timers are also set to account for possible message losses and to wait for those retransmissions 💖.
Periodical General Queries and Current State Reports don't use this retransmission rule, because we don't want to overload the link 😭. It's assumed these messages don't usually generate state changes. Their main purpose is to refresh existing state, so if one gets lost, the state gets refreshed during the next reporting period 🦋.
As opposed to Current State Reports, State Change Reports are retransmitted several times, so they don't get missed by one or more multicast routers 🙈. The number of retransmissions depends on the so-called Robustness Variable 🎀. This variable lets you tune the protocol for the expected packet loss on a link. If a link is expected to be lossy (like a wireless connection), the value of the Robustness Variable may be increased 📶. MLD is robust to [Robustness Variable]-1 packet losses. This document recommends a default value of 2 for the Robustness Variable (see section 9.1) 👑.
If more changes to the same per-interface state entry happen before all the retransmissions of the State Change Report for the first change are done, each additional change immediately triggers a brand new State Change Report 🌈. Section 6.1 shows how the content of this new report is computed. Retransmissions of the new State Change Report get scheduled as well, so each instance of state change is transmitted at least [Robustness Variable] times ✨.
If a node on a link uses a State Change Report to say it no longer wants to listen to a particular multicast address (or source), the Querier must query for other listeners of that multicast address (or source) before it deletes that address (or source) from its Multicast Address Listener state and stops the corresponding traffic. So the Querier sends a Multicast Address Specific Query to check whether any nodes are still listening to a specified multicast address 🔍. Similarly, the Querier sends a Multicast Address and Source Specific Query to check whether, for a specified multicast address, nodes are still listening to a specific set of sources 🕵️♀️. Section 5.1.13 describes each query in more detail.
Both Multicast Address Specific Queries and Multicast Address and Source Specific Queries are only sent in response to State Change Reports, never in response to Current State Reports. This distinction between the two types of reports is needed so the router doesn't treat all Multicast Listener Reports as potential changes in state 🙅. The fast leave mechanism of MLDv2, described in more detail in section 2.2, might not be effective if a State Change Report is lost and only the following Current State Report is received by the router. Still, it avoids extra processing at the router and reduces MLD traffic on the link ⚖️. More details on why the two report types need to be distinguished are in Appendix A1 📚.
Nodes respond to the above queries through Current State Reports, which contain their per-interface Multicast Address Listening state only for the multicast addresses (or sources) being queried 💬.
As stated earlier, in order to ensure protocol robustness, all the queries, except the periodical General Queries, are retransmitted several times within a given time interval. The number of retransmissions depends on the Robustness Variable. If new queries get scheduled while there are pending queries to be retransmitted for the same multicast address, the new queries and the pending queries have to be merged 🧩. Host reports received for a multicast address with pending queries may also affect the contents of those queries. The process of building and maintaining the state of pending queries is presented in section 7.6.3 📝.
Protocol robustness also gets a boost from the S flag (Suppress Router-Side Processing) 💪. As described above, when a Multicast Address Specific or a Multicast Address and Source Specific Query is sent by the Querier, a number of retransmissions of the query are scheduled. In the original (first) query the S flag is clear. When the Querier sends this query, it lowers the timers for the concerned multicast address (or source) to a given value. Similarly, any non-querier multicast router that receives the query lowers its timers in the same way 🫧. Meanwhile, while waiting for the next scheduled queries to go out, the Querier may receive a report that updates the timers. The scheduled queries still have to be sent, so a non-querier router keeps its state synchronized with the current Querier (the non-querier router might have missed the first query) 🔄. But the timers should not be lowered again, since a valid answer was already received. So in subsequent queries, the Querier sets the S flag ✨.
2.3. Building Multicast Address Listener State on Multicast Routers 🦋
okay so multicast routers that implement MLDv2 (whether they're in Querier state or not) keep state per multicast address per attached link 🧚 This multicast address listener state is made up of a Filter Mode, a Filter Timer, and a Source List, with a timer attached to each source on that list ⏰ The Filter Mode is how the router squishes everyone's listening state down into a minimum set, so that every node's listening state still gets respected ✨ The Filter Mode may change when particular report messages come in, or when certain timer conditions happen.
A router is in INCLUDE mode for a specific multicast address on a given interface if all the listeners on the link interested in that address are in INCLUDE mode 💖 The router state is written as INCLUDE (A), where A is a list of sources called the "Include List". The Include List is the set of sources that one or more listeners on the link have asked to receive 🎀 Every source on the Include List gets forwarded by the router, and any other source that isn't on it gets blocked 🚫
A source can be added to the current Include List if a listener in INCLUDE mode sends a Current State or a State Change Report that includes that source 💅 Each source on the Include List has its own source timer, which gets updated whenever a listener in INCLUDE mode sends a report confirming its interest in that specific source. If the timer of a source on the Include List expires, that source gets deleted from the Include List 😭
Besides this "soft leave" mechanism, MLDv2 also has a "fast leave" scheme, and it's based on source timers too 🏃♀️ When a node in INCLUDE mode says it wants to stop listening to a specific source, all the multicast routers on the link lower their timers for that source to a given value. The Querier then sends a Multicast Address and Source Specific Query to check whether there are other listeners for that source on the link or not 🔍 If a report that includes this source arrives before the timer expires, all the multicast routers on the link update the source timer. If not, the source gets deleted from the Include List. The way the Include List gets handled based on the reports received is detailed in Tables 7.4.1 and 7.4.2 📋
A router is in EXCLUDE mode for a specific multicast address on a given interface if there's at least one listener in EXCLUDE mode for that address on the link 👑 When the first report comes in from a listener like that, the router sets the Filter Timer for that address. This timer gets reset each time an EXCLUDE mode listener confirms its listening state through a Current State Report. The timer also gets updated when a listener that used to be in INCLUDE mode announces its filter mode change through a State Change Report message. If the Filter Timer expires, that means there are no more listeners in EXCLUDE mode on the link, so the router switches back to INCLUDE mode for that multicast address 🌈
When the router is in EXCLUDE mode, its state is written as EXCLUDE (X,Y), where X is called the "Requested List" and Y is called the "Exclude List". All sources except the ones on the Exclude List get forwarded by the router. The Requested List has no effect on forwarding 🙈 Even so, the router still has to keep the Requested List, and there are two reasons why:
- To keep track of sources that listeners in INCLUDE mode are listening to. This is needed so the router can make a seamless transition back to INCLUDE mode once there are no listeners in EXCLUDE mode left. That transition shouldn't interrupt the flow of traffic to INCLUDE mode listeners for that multicast address 🫶 So at the time of the transition, the Requested List should hold the set of sources that INCLUDE mode nodes have explicitly requested.
When the router switches to INCLUDE mode, the sources in the Requested List move to the Include List, and the Exclude List gets deleted 🦋 Before switching, the Requested List can hold an inexact guess of the sources INCLUDE mode listeners are listening to, meaning it might be too big or too small. These inexactitudes happen because the Requested List is also used for fast blocking, which is described below 🤷♀️ If fast blocking is needed, some sources may get deleted from the Requested List (as shown in Tables 7.4.1 and 7.4.2) to shrink the router state. Even then, the Filter Timer is updated too. That means INCLUDE mode listeners get enough time, before any possible switch, to reconfirm their interest in the removed source(s) and rebuild the Requested List to match 💪 The protocol makes sure that when a switch to INCLUDE mode happens, the Requested List will be accurate ✅ The details of the router's transition to INCLUDE mode are in Appendix A3.
- To allow the fast blocking of sources that were previously unblocked. If the router gets a report containing such a request, the concerned sources are added to the Requested List. Their timers are set to a given small value, and the Querier sends a Multicast Address and Source Specific Query to see whether nodes on the link are still interested in those sources 🕵️♀️ If no node announces interest in those specific sources, their timers expire. Then the sources move from the Requested List to the Exclude List, and from then on the router blocks them 🚫💅
The handling of the EXCLUDE mode router state, based on the reports received, is also detailed in Tables 7.4.1 and 7.4.2 📋
Both the MLDv2 router and listener behaviors described in this document were defined to keep backward interoperability with MLDv1 hosts and routers 🫶 Interoperability issues are detailed in section 8 🌸
3. The Service Interface for Requesting IP Multicast Reception ✨
okay so within an IP system there's (at least conceptually) a service interface that upper-layer protocols or application programs use to ask the IP layer to turn reception of packets sent to specific IP multicast addresses on or off 💅 To really take advantage of MLDv2's capabilities, a node's IP service interface must support this operation:
IPv6MulticastListen ( socket, interface, IPv6 multicast address,
filter mode, source list )where:
- "socket" is an implementation-specific parameter used to tell apart different requesting entities (e.g., programs, processes) inside the node. The socket parameter of BSD Unix system calls is a specific example 🧦
- "interface" is a local identifier for the network interface where reception of the specified multicast address gets turned on or off. Interfaces can be physical (e.g., an Ethernet interface) or virtual (e.g., the endpoint of a Frame Relay virtual circuit or an IP-in-IP "tunnel") 🌐 An implementation may allow a special "unspecified" value to be passed as the interface parameter, in which case the request applies to the "primary" or "default" interface of the node (maybe set up by system configuration). If reception of the same multicast address is wanted on more than one interface, IPv6MulticastListen gets invoked separately for each wanted interface 🔁
- "IPv6 multicast address" is the multicast address the request is about. If reception of more than one multicast address on a given interface is wanted, IPv6MulticastListen gets invoked separately for each wanted address 🎯
- "filter mode" can be either INCLUDE or EXCLUDE. In INCLUDE mode, reception of packets sent to the specified multicast address is requested only from the source addresses listed in the source list parameter. In EXCLUDE mode, reception of packets sent to the given multicast address is requested from all source addresses except those listed in the source list parameter 🔀
- "source list" is an unordered list of zero or more unicast addresses that multicast reception is wanted from or not wanted from, depending on the filter mode. An implementation MAY impose a limit on the size of source lists. When an operation causes the source list size limit to be exceeded, the service interface SHOULD return an error 🚨
For a given combination of socket, interface, and IPv6 multicast address, only a single filter mode and source list can be in effect at any one time 💜 Still, either the filter mode or the source list, or both, can be changed by later IPv6MulticastListen requests that specify the same socket, interface, and IPv6 multicast address. Each later request completely replaces any earlier request for that given socket, interface, and multicast address 🔄
The MLDv1 protocol didn't support source filters and had a simpler service interface. It had Start Listening and Stop Listening operations to turn listening to a given multicast address (from all sources) on or off on a given interface 🌸 The equivalent operations in the new service interface look like this:
The Start Listening operation is equivalent to:
IPv6MulticastListen ( socket, interface, IPv6 multicast address,
EXCLUDE, {} )and the Stop Listening operation is equivalent to:
IPv6MulticastListen ( socket, interface, IPv6 multicast address,
INCLUDE, {} )where {} is an empty source list.
An example of an API that provides the capabilities outlined in this service interface is given in [RFC3678] 🎀
4. Multicast Listening State Maintained by Nodes 🌸
4.1. Per-Socket State 🎀
For each socket on which IPv6MulticastListen has been invoked, the node records the desired multicast listening state for that socket 📝 Conceptually, that state is a set of records of this form:
(interface, IPv6 multicast address, filter mode, source list)The per-socket state changes in response to each invocation of IPv6MulticastListen on the socket, like this:
- If the requested filter mode is INCLUDE and the requested source list is empty, then the entry that matches the requested interface and multicast address is deleted, if it's there. If no such entry exists, the request has no effect 🗑️
- If the requested filter mode is EXCLUDE or the requested source list is non-empty, then the entry that matches the requested interface and multicast address, if it's there, gets changed to hold the requested filter mode and source list. If no such entry exists, a new entry gets created using the parameters from the request ✨
4.2. Per-Interface State ✨
okay so, on top of the per-socket multicast listening state, a node also has to keep track of (or work out) multicast listening state for each of its interfaces 🎀. Conceptually that's a bunch of records shaped like this:
(IPv6 multicast address, filter mode, source list)There's at most one record per multicast address for a given interface, bestie 💅. This per-interface state comes from the per-socket state, but it can look different when different sockets have different filter modes and/or source lists for the same multicast address and interface 🦋.
Let's do an example, because it's giving drama 🍓. Say one app calls:
IPv6MulticastListen ( s1, i, m, INCLUDE, {a, b, c} )It wants packets sent to multicast address m on interface i, only if they come from sources a, b, or c. Then another process calls:
IPv6MulticastListen ( s2, i, m, INCLUDE, {b, c, d} )It wants the same interface i and the same multicast address m, only from sources b, c, or d. To make both sockets happy, interface i has to receive packets sent to m from any one of a, b, c, or d. So the listening state of interface i for m ends up with filter mode INCLUDE and source list {a, b, c, d} 🌈.
After the IP layer accepts a multicast packet from an interface, handing it to the app that listens on a particular socket depends on that socket's multicast listening state. It might also depend on other stuff, like which transport-layer port the socket is bound to 🧚. So in the example above, if a packet arrives on interface i, destined to multicast address m, with source address a, it may be delivered on socket s1 but not on socket s2 🙈. Also, MLDv2 messages are not subject to source filtering and must always be processed by hosts and routers 🫶.
Requiring packets to be filtered based on a socket's multicast reception state is a brand new feature of this service interface ✨. The previous service interface had no filtering based on multicast listening state. A Start Listening operation on a socket just made the node start listening to a multicast address on the given interface, and packets sent to that address could be delivered to all sockets, whether they had started listening or not 😭.
The general rules for working out the per-interface state from the per-socket state go like this. For each distinct (interface, IPv6 multicast address) pair that shows up in any per-socket state, a per-interface record gets created for that multicast address on that interface. Then you look at all the socket records that contain the same (interface, IPv6 multicast address) pair:
- if any such record has a filter mode of EXCLUDE, then the filter mode of the interface record is EXCLUDE 🔥. Its source list is the intersection of the source lists of all socket records in EXCLUDE mode, minus those source addresses that appear in any socket record in INCLUDE mode. For example, if the socket records for multicast address m on interface i are:
from socket s1: ( i, m, EXCLUDE, {a, b, c, d} )
from socket s2: ( i, m, EXCLUDE, {b, c, d, e} )
from socket s3: ( i, m, INCLUDE, {d, e, f} )then the corresponding interface record on interface i is:
( m, EXCLUDE, {b, c} )If a fourth socket is added, such as:
From socket s4: ( i, m, EXCLUDE, {} )then the interface record becomes:
( m, EXCLUDE, {} )- if all such records have a filter mode of INCLUDE, then the filter mode of the interface record is INCLUDE 💖, and its source list is the union of the source lists of all the socket records. For example, if the socket records for multicast address m on interface i are:
from socket s1: ( i, m, INCLUDE, {a, b, c} )
from socket s2: ( i, m, INCLUDE, {b, c, d} )
from socket s3: ( i, m, INCLUDE, {e, f} )then the corresponding interface record on interface i is:
( m, INCLUDE, {a, b, c, d, e, f} )An implementation MUST NOT use an EXCLUDE interface record for a multicast address if all sockets for this multicast address are in INCLUDE state. ⚠️ Also, if system resource limits are reached when a per-interface state source list is calculated, an error MUST be returned to the application which requested the operation. Nobody wants that, periodt 💀.
The above rules for deriving the per-interface state are (re)evaluated whenever an IPv6MulticastListen invocation modifies the per-socket state by adding, deleting, or modifying a per-socket state record 🔄. Just know that a change to the per-socket state doesn't necessarily mean the per-interface state changes too 🤷♀️.
5. Message Formats 🎀
okay now the fun bit, the actual message formats 🧚. MLDv2 is a sub-protocol of ICMPv6, which means MLDv2 message types are a subset of ICMPv6 messages 🌸. You can spot MLDv2 messages inside IPv6 packets by a preceding Next Header value of 58 🔍. All MLDv2 messages described in this document MUST be sent with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RFC2711] in a Hop-by-Hop Options header. The Router Alert option is what makes routers examine MLDv2 messages sent to IPv6 multicast addresses they themselves have no interest in 👀. MLDv2 Reports can be sent with the source address set to the unspecified address [RFC3513] if a valid link-local IPv6 source address hasn't been acquired yet for the sending interface. (See section 5.2.13. for details.) 🫶
There are two MLD message types that matter for the MLDv2 protocol described in this document 💅:
- Multicast Listener Query (Type = decimal 130)
- Version 2 Multicast Listener Report (Type = decimal 143). See section 11 for IANA considerations.
To make sure it plays nicely with nodes that implement MLDv1 (see section 8), an implementation of MLDv2 must also support these two message types 🤝:
- Version 1 Multicast Listener Report (Type = decimal 131) [RFC2710]
- Version 1 Multicast Listener Done (Type = decimal 132) [RFC2710]
Unrecognized message types MUST be silently ignored. Other message types may be used by newer versions or extensions of MLD, by multicast routing protocols, or for other uses. 🙃
In this document, unless otherwise qualified, the capitalized words "Query" and "Report" refer to MLD Multicast Listener Queries and MLD Version 2 Multicast Listener Reports, respectively 📣.
5.1. Multicast Listener Query Message 🔮
Multicast Listener Queries are sent by multicast routers in Querier State to query the multicast listening state of neighboring interfaces 🛰️. Queries look like this:
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 = 130 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resv |S| QRV | QQIC | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- . -+
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.1.1. Code 🧸
Initialized to zero by the sender; ignored by receivers 💖.
5.1.2. Checksum 🔐
The standard ICMPv6 checksum. It covers the entire MLDv2 message, plus a "pseudo-header" of IPv6 header fields [RFC2463]. When computing the checksum, the Checksum field is set to zero. When a packet is received, the checksum MUST be verified before processing it 🧐.
5.1.3. Maximum Response Code ⏱️
The Maximum Response Code field specifies the maximum time allowed before sending a responding Report ⏳. The actual time allowed, called the Maximum Response Delay, is represented in units of milliseconds, and it's derived from the Maximum Response Code like this:
If Maximum Response Code < 32768,
Maximum Response Delay = Maximum Response CodeIf Maximum Response Code >=32768, Maximum Response Code represents a floating-point value as follows:
0 1 2 3 4 5 6 7 8 9 A B C D E F
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Maximum Response Delay = (mant | 0x1000) << (exp+3)Small values of Maximum Response Delay let MLDv2 routers tune the "leave latency" (the time between the moment the last node on a link stops listening to a specific multicast address and the moment the routing protocol gets told there are no more listeners for that address) 🎯. Larger values, especially in the exponential range, let you tune the burstiness of MLD traffic on a link 🌊.
5.1.4. Reserved 🌷
Initialized to zero by the sender; ignored by receivers ✨.
5.1.5. Multicast Address 🎀
okay so for a General Query, the Multicast Address field gets set to zero 🫶 For a Multicast Address Specific Query or a Multicast Address and Source Specific Query, it gets set to the multicast address being queried (see section 5.1.10, below) ✨
5.1.7. S Flag (Suppress Router-Side Processing) 🙈
when this is set to one, the S Flag tells any receiving multicast routers that they have to suppress the normal timer updates they do upon hearing a Query 💅 but ngl it does not suppress the querier election, or the normal "host-side" processing of a Query that a router may be required to perform because it's a multicast listener itself 🧚
5.1.8. QRV (Querier's Robustness Variable) 💜
if it's non-zero, the QRV field holds the [Robustness Variable] value the Querier used. if the Querier's [Robustness Variable] is bigger than 7 (the max value of the QRV field), the QRV field gets set to zero 🌸
routers adopt the QRV value from the most recently received Query as their own [Robustness Variable] value. the exception is if that most recent QRV was zero, because then they use the default [Robustness Variable] value from section 9.1, or a statically configured value instead 🫶
5.1.9. QQIC (Querier's Query Interval Code) 🌈
the Querier's Query Interval Code field tells everyone the [Query Interval] the Querier is using. the actual interval, called the Querier's Query Interval (QQI), is in seconds, and you work it out from the Querier's Query Interval Code like this 🧮
if QQIC < 128, then QQI = QQIC 💖
if QQIC is >= 128, the QQIC is a floating-point value laid out like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1| exp | mant |
+-+-+-+-+-+-+-+-+and the formula is:
QQI = (mant | 0x10) << (exp + 3)multicast routers that are not the current Querier adopt the QQI value from the most recently received Query as their own [Query Interval] value. same twist as before: if that most recent QQI was zero, the receiving routers use the default [Query Interval] value from section 9.2 instead 🦋
5.1.10. Number of Sources (N) 🍓
the Number of Sources (N) field tells you how many source addresses are in the Query. it's zero in a General Query or a Multicast Address Specific Query, and non-zero in a Multicast Address and Source Specific Query 💅 this number is limited by the MTU of the link the Query gets sent over, so the math matters bestie 🤓
for example, on an Ethernet link with an MTU of 1500 octets, the IPv6 header (40 octets) together with the Hop-By-Hop Extension Header (8 octets) that includes the Router Alert option eats up 48 octets. the MLD fields up to the Number of Sources (N) field eat 28 octets. so there are 1424 octets left for source addresses, which limits the number of source addresses to 89 (1424/16) 😭✨
5.1.11. Source Address [i] 🌷
the Source Address [i] fields are a vector of n unicast addresses, where n is the value in the Number of Sources (N) field 🫧
5.1.12. Additional Data 🍑
if the Payload Length field in the IPv6 header of a received Query says there are extra octets of data past the fields described here, MLDv2 implementations MUST include those octets in the computation to verify the received MLD Checksum. but they MUST otherwise ignore those additional octets 🙈 when sending a Query, an MLDv2 implementation MUST NOT include additional octets beyond the fields described above 🎀
5.1.13. Query Variants 👑
there are three variants of the Query message, and they're giving very different vibes:
- A "General Query" is sent by the Querier to learn which multicast addresses have listeners on an attached link. In a General Query, both the Multicast Address field and the Number of Sources (N) field are zero.
- A "Multicast Address Specific Query" is sent by the Querier to learn if a particular multicast address has any listeners on an attached link. In a Multicast Address Specific Query, the Multicast Address field contains the multicast address of interest, while the Number of Sources (N) field is set to zero.
- A "Multicast Address and Source Specific Query" is sent by the Querier to learn if any of the sources from the specified list for the particular multicast address has any listeners on an attached link or not. In a Multicast Address and Source Specific Query, the Multicast Address field contains the multicast address of interest, while the Source Address [i] field(s) contain(s) the source address(es) of interest. 🦋
5.1.14. Source Addresses for Queries 🔥
okay this one is serious 🚨 all MLDv2 Queries MUST be sent with a valid IPv6 link-local source address. if a node (router or host) receives a Query message with the IPv6 Source Address set to the unspecified address (::), or any other address that is not a valid IPv6 link-local address, it MUST silently discard the message and SHOULD log a warning 💀
5.1.15. Destination Addresses for Queries 🧚
in MLDv2, General Queries are sent to the link-scope all-nodes multicast address (FF02::1). Multicast Address Specific and Multicast Address and Source Specific Queries are sent with an IP destination address equal to the multicast address of interest 🌸
However, a node MUST accept and process any Query whose IP Destination Address field contains any of the addresses (unicast or multicast) assigned to the interface on which the Query arrives. this might be useful, e.g., for debugging purposes 🔍
5.2. Version 2 Multicast Listener Report Message 💜
Version 2 Multicast Listener Reports are the messages IP nodes send to report (to neighboring routers) the current multicast listening state, or changes in the multicast listening state, of their interfaces. Reports have this 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 = 143 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+each Multicast Address Record has this internal format 🫧
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Type | Aux Data Len | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- -+
. . .
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Auxiliary Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.2.1. Reserved 🎀
the Reserved fields are set to zero on transmission, and ignored on reception 🌸
5.2.2. Checksum 🔐
this is the standard ICMPv6 checksum. it covers the entire MLDv2 message, plus a "pseudo-header" of IPv6 header fields [RFC2460, RFC2463]. to compute the checksum, the Checksum field is set to zero first 🧠 when a packet is received, the checksum MUST be verified before processing it ✅
5.2.3. Nr of Mcast Address Records (M) 💅
the Nr of Mcast Address Records (M) field specifies how many Multicast Address Records are present in this Report 🍓
5.2.4. Multicast Address Record 🦋
each Multicast Address Record is a block of fields that contain information on the sender listening to a single multicast address on the interface from which the Report is sent 🫶
5.2.5. Record Type ✨
okay so this field is literally the "what kind of record is this" tag 💅 It specifies the type of the Multicast Address Record. Go to section 5.2.12 for the full tea on all the possible Record Types 🫶
5.2.6. Aux Data Len 🎀
bestie, the Aux Data Len field tells you how long the Auxiliary Data Field is in this Multicast Address Record, counted in units of 32-bit words 🧚 It can be zero, which just means there's no auxiliary data here ✨
5.2.7. Number of Sources (N) 🌸
the Number of Sources (N) field says how many source addresses are present in this Multicast Address Record. Simple but iconic 💖
5.2.8. Multicast Address 🦋
this one holds the multicast address that this Multicast Address Record is about 💜
5.2.9. Source Address [i] 🍓
the Source Address [i] fields are basically a vector of n unicast addresses, where n is whatever's in this record's Number of Sources (N) field 🔥
5.2.10. Auxiliary Data 🧚
ngl this one's a big deal. If the Auxiliary Data field is there, it holds extra info about this Multicast Address Record. But MLDv2 doesn't define any auxiliary data at all 😭 So MLDv2 implementations MUST NOT include any auxiliary data (i.e., MUST set the Aux Data Len field to zero) in any Multicast Address Record they send, and they MUST ignore any such data in any Multicast Address Record they receive. The meaning and internal encoding of the Auxiliary Data field are up to any future version or extension of MLD that uses this field to decide 🌈
5.2.11. Additional Data 💅
if the Payload Length field in the IPv6 header of a received Report says there are extra octets of data past the last Multicast Address Record, MLDv2 implementations MUST include those octets in the math to verify the received MLD Checksum, but MUST otherwise ignore them. When sending a Report, an MLDv2 implementation MUST NOT include any octets past the last Multicast Address Record. Main character energy, no extras 👑
5.2.12. Multicast Address Record Types 👑
okay this section is where the real drama is 🍿 There are a bunch of different Multicast Address Record types that can show up in a Report message:
- A "Current State Record" is sent by a node in response to a Query received on an interface. It reports the current listening state of that interface, with respect to a single multicast address. The Record Type of a Current State Record may be one of the following two values:
Value Name and Meaning
----- ----------------
1 MODE_IS_INCLUDE - indicates that the interface has a filter
mode of INCLUDE for the specified multicast address. The
Source Address [i] fields in this Multicast Address Record
contain the interface's source list for the specified
multicast address. A MODE_IS_INCLUDE Record is never sent
with an empty source list.
2 MODE_IS_EXCLUDE - indicates that the interface has a filter
mode of EXCLUDE for the specified multicast address. The
Source Address [i] fields in this Multicast Address Record
contain the interface's source list for the specified
multicast address, if it is non-empty.- A "Filter Mode Change Record" is sent by a node whenever a local invocation of
IPv6MulticastListencauses a change of the filter mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to INCLUDE) of the interface-level state entry for a particular multicast address, whether the source list changes at the same time or not. The Record is included in a Report sent from the interface where the change happened. The Record Type of a Filter Mode Change Record may be one of the following two values:
3 CHANGE_TO_INCLUDE_MODE - indicates that the interface has
changed to INCLUDE filter mode for the specified multicast
address. The Source Address [i] fields in this Multicast
Address Record contain the interface's new source list for
the specified multicast address, if it is non-empty.
4 CHANGE_TO_EXCLUDE_MODE - indicates that the interface has
changed to EXCLUDE filter mode for the specified multicast
address. The Source Address [i] fields in this Multicast
Address Record contain the interface's new source list for
the specified multicast address, if it is non-empty.- A "Source List Change Record" is sent by a node whenever a local invocation of
IPv6MulticastListencauses a change of source list that is not coincident with a change of filter mode, of the interface-level state entry for a particular multicast address. The Record is included in a Report sent from the interface where the change happened. The Record Type of a Source List Change Record may be one of the following two values:
5 ALLOW_NEW_SOURCES - indicates that the Source Address [i]
fields in this Multicast Address Record contain a list of
the additional sources that the node wishes to listen to,
for packets sent to the specified multicast address. If
the change was to an INCLUDE source list, these are the
addresses that were added to the list; if the change was to
an EXCLUDE source list, these are the addresses that were
deleted from the list.
6 BLOCK_OLD_SOURCES - indicates that the Source Address [i]
fields in this Multicast Address Record contain a list of
the sources that the node no longer wishes to listen to,
for packets sent to the specified multicast address. If the
change was to an INCLUDE source list, these are the
addresses that were deleted from the list; if the change
was to an EXCLUDE source list, these are the addresses that
were added to the list.If a change of source list results in both allowing new sources and blocking old sources, then two Multicast Address Records are sent for the same multicast address, one of type ALLOW_NEW_SOURCES and one of type BLOCK_OLD_SOURCES.
We use the term "State Change Record" to refer to either a Filter Mode Change Record or a Source List Change Record.
Multicast Address Records with an unrecognized Record Type value MUST be silently ignored, with the rest of the report being processed.
In the rest of this document, we use the following notation to describe the contents of a Multicast Address Record that pertains to a particular multicast address:
IS_IN ( x ) - Type MODE_IS_INCLUDE, source addresses x
IS_EX ( x ) - Type MODE_IS_EXCLUDE, source addresses x
TO_IN ( x ) - Type CHANGE_TO_INCLUDE_MODE, source addresses x
TO_EX ( x ) - Type CHANGE_TO_EXCLUDE_MODE, source addresses x
ALLOW ( x ) - Type ALLOW_NEW_SOURCES, source addresses x
BLOCK ( x ) - Type BLOCK_OLD_SOURCES, source addresses x
where x is either:
o a capital letter (e.g., "A") to represent the set of source
addresses,
or
o a set expression (e.g., "A+B"), where "A+B" means the union of
sets A and B, "A*B" means the intersection of sets A and B, and
"A-B" means the removal of all elements of set B from set A.5.2.13. Source Addresses for Reports 🦋
an MLDv2 Report MUST be sent with a valid IPv6 link-local source address, or the unspecified address (::), if the sending interface has not acquired a valid link-local address yet. Sending reports with the unspecified address is allowed so IP multicast can be used in the Neighbor Discovery Protocol [RFC2461]. For stateless autoconfiguration, as defined in [RFC2462], a node is required to join several IPv6 multicast groups, in order to perform Duplicate Address Detection (DAD). Before DAD, the only address the reporting node has for the sending interface is a tentative one, which cannot be used for communication. Thus, the unspecified address must be used.
On the other hand, routers MUST silently discard a message that is not sent with a valid link-local address, without taking any action on the contents of the packet. So a Report gets discarded if the router can't identify the source address as belonging to a link connected to the interface where the packet arrived. A Report sent with the unspecified address is also discarded by the router. This is a big security win, since unidentified reporting nodes can't influence the state of the MLDv2 router(s) 🔒 Still, the reporting node has changed its listening state for the multicast addresses in the Multicast Address Records of the Report. From then on, it treats packets sent to those multicast addresses according to this new listening state. Once a valid link-local address is available, a node SHOULD generate new MLDv2 Report messages for all multicast addresses joined on the interface.
5.2.14. Destination Addresses for Reports 💖
Version 2 Multicast Listener Reports are sent to the IP destination address FF02:0:0:0:0:0:0:16, which all MLDv2-capable multicast routers listen to (see section 11 for IANA considerations related to this special destination address). A node in version 1 compatibility mode (see details in section 8) sends version 1 Reports to the multicast address in the Multicast Address field of the Report. Also, a node MUST accept and process any version 1 Report whose IP Destination Address field contains any of the IPv6 addresses (unicast or multicast) assigned to the interface where the Report arrives. This might be useful, e.g., for debugging purposes.
5.2.15. Multicast Listener Report Size 🌈
if the set of Multicast Address Records needed in a Report doesn't fit within the size limit of a single Report message (based on the MTU of the link it'll be sent on), the Multicast Address Records get sent in as many Report messages as it takes to report the whole set.
If a single Multicast Address Record has so many source addresses that it doesn't fit within the size limit of a single Report message, then:
- if its Type is not IS_EX or TO_EX, it gets split into multiple Multicast Address Records. Each one contains a different subset of the source addresses, and is sent in a separate Report.
- if its Type is IS_EX or TO_EX, a single Multicast Address Record is sent, with as many source addresses as can fit. The remaining source addresses are not reported. Although the choice of which sources to report is arbitrary, it is preferable to report the same set of sources in each subsequent report, rather than reporting different sources each time 🫶
6. Protocol Description for Multicast Address Listeners ✨
okay so MLD is asymmetric 🦋, which means it has separate behaviours for multicast address listeners (hosts or routers that listen to multicast packets) and for multicast routers. this section covers the part of MLDv2 that applies to all multicast address listeners. (fun fact: a multicast router that is also a listener does both parts 💅 it receives and responds to its own MLD messages, plus the ones from its neighbours.) the multicast router part is in section 7 🌸
a node runs the protocol described here over all interfaces where multicast reception is supported, even if more than one of those interfaces is connected to the same link 🧚
for interoperability with multicast routers running MLDv1, nodes keep a Host Compatibility Mode variable for each interface where multicast reception is supported 🎀 this section describes what listener nodes do on interfaces where Host Compatibility Mode = MLDv2. the algorithm for figuring out Host Compatibility Mode, and what happens if it's set to MLDv1, are in section 8 💜
the link-scope all-nodes multicast address, FF02::1, is a special case 👑 on every node (hosts and routers alike, multicast routers included), listening to packets sent to the all-nodes multicast address from any source is permanently enabled on every interface where multicast listening is supported. no MLD messages are ever sent about FF02::1 or about any multicast address of scope 0 (reserved) or 1 (node-local) 🙈
there are three types of events that trigger MLDv2 protocol actions on an interface:
- a change of the per-interface listening state, caused by a local invocation of
IPv6MulticastListen💖 - the firing of a specific timer ⏰
- the reception of a Query 🔥
(received MLD messages of types other than Query are silently ignored, except where needed for interoperation with nodes that implement MLDv1 🫶)
the subsections below walk through what to do for each case. timer and counter names appear in [square brackets], and their default values are in section 9 ✨
6.1. Action on Change of Per-Interface State
an invocation of IPv6MulticastListen can change the multicast listening state of an interface, following the rules in section 4.2 💅 each change affects the per-interface entry for one single multicast address.
when the per-interface state changes, the node immediately sends a State Change Report from that interface 🚀 the type and contents of the Multicast Address Record(s) in that Report come from comparing the filter mode and source list for the affected multicast address before and after the change, using the table below. if no per-interface state existed for that address before the change (so the change created a new per-interface record), or if no state exists after the change (so the change deleted a per-interface record), then the "non-existent" state is treated as having an INCLUDE filter mode and an empty source list 🌈
Old State New State State Change Record Sent
--------- --------- ------------------------
INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B)
EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A)
INCLUDE (A) EXCLUDE (B) TO_EX (B)
EXCLUDE (A) INCLUDE (B) TO_IN (B)if the computed source list for either an ALLOW or a BLOCK State Change Record is empty, that record gets left out of the Report 🙃
to cover the chance that the State Change Report gets missed by one or more multicast routers, [Robustness Variable] - 1 retransmissions are scheduled through a Retransmission Timer 🔁 they happen at intervals picked at random from the range (0, [Unsolicited Report Interval]). this is the robustness part, bestie 💪
if more changes hit the same per-interface state entry before all the retransmissions of the State Change Report for the first change are done, each extra change triggers an immediate transmission of a new State Change Report 😭
the contents of the new Report are worked out like this:
- just like for the first Report, the per-interface state for the affected multicast address is compared before and after the latest change.
- the records that show the difference are built according to the table above. but these records don't get sent in a separate message! they get merged with the contents of the pending report to make the new State Change Report 🧩 the rules for the merged report are described below.
sending the merged State Change Report ends the retransmissions of the earlier State Change Reports for that same multicast address, and it becomes the first of [Robustness Variable] transmissions of the new State Change Reports 💖 these transmissions are needed so that every instance of a state change gets sent at least [Robustness Variable] times. no skipping, periodt 👑
every time a source is included in the difference report above, the node has to keep retransmission state for that source until [Robustness Variable] State Change Reports have been sent 🫧 this stops a series of back-to-back state changes from breaking the protocol's robustness. sources in retransmission state can live in a per-multicast-address Retransmission List, with a Source Retransmission Counter attached to each source in the list 🗂️ when a source joins the list, its counter is set to [Robustness Variable]. each time a State Change Report is sent, the counter goes down by one. when it hits zero, the source is removed from the Retransmission List for that multicast address 🎀
if the per-interface listening change that triggers the new report is a filter mode change, then the next [Robustness Variable] State Change Reports will include a Filter Mode Change Record 🌸 this holds even if there are any number of source list changes during that stretch. the node has to keep retransmission state for the multicast address until those [Robustness Variable] State Change Reports have gone out, and it can do this with a per-multicast-address Filter Mode Retransmission Counter 🧁 when the filter mode changes, the counter is set to [Robustness Variable]. each time a State Change Report is sent, the counter goes down by one. once it reaches zero, meaning [Robustness Variable] State Change Reports with Filter Mode Change Records have been sent since the last filter mode change, and source list changes have led to extra reports being scheduled, then the next State Change Report includes Source List Change Records 🦋
every time a per-interface listening state change triggers an Immediate transmission of a new State Change Report, its contents are decided like this 🫶 if the report should contain a Filter Mode Change Record (that is, the Filter Mode Retransmission Counter for that multicast address is higher than zero), then: if the interface's current filter mode is INCLUDE, a TO_IN record goes in the report, otherwise a TO_EX record goes in. if the report should contain Source List Change Records instead (the Filter Mode Retransmission Counter for that address is zero), then an ALLOW record and a BLOCK record go in. the contents of these records are built according to the table below 💅
Record Sources included
------ ----------------
TO_IN All in the current per-interface state that must be
forwarded
TO_EX All in the current per-interface state that must be
blocked
ALLOW All with retransmission state (i.e., all sources from the
Retransmission List) that must be forwarded
BLOCK All with retransmission state that must be blockedif the computed source list for either an ALLOW or a BLOCK record is empty, that record gets left out of the State Change Report 🌈
Note: when the first State Change Report is sent, the non-existent pending report to merge with can be treated as a Source Change Report with empty ALLOW and BLOCK records (because no sources have retransmission state yet). ✨
building a scheduled State Change Report, which gets triggered by the firing of a Retransmission Timer instead of a per-interface listening state change, is covered in section 6.3 🧚
6.2. Action on Reception of a Query ✨
okay so when an MLD message carrying a Query shows up, the node does NOT just fire back a reply 🙅♀️ first it checks that the source address is a valid link-local address, that the Hop Limit is set to 1, and that the Router Alert option is present in the Hop-By-Hop Options header of the IPv6 packet 🧐 if any of those checks fail, the packet gets dropped. bye 🗑️
if the MLD message passes, the node starts processing the Query. but it doesn't answer right away. it waits a random amount of time, capped by the Maximum Response Delay that comes from the Maximum Response Code in the Query 🎲 a node can get a bunch of different Queries on different interfaces, and they can be different kinds (General Queries, Multicast Address Specific Queries, and Multicast Address and Source Specific Queries), and each one might need its own delayed response 🦋
before scheduling a response, the node must first consider the responses it already has pending and, in lots of cases, schedule one combined response instead 🫶 so for each interface where it runs the listener part of the MLDv2 protocol, the node must be able to keep track of this state:
- an Interface Timer for scheduling responses to General Queries;
- a Multicast Address Timer for scheduling responses to Multicast Address (and Source) Specific Queries, for each multicast address the node has to report on;
- a per-multicast-address list of sources to be reported in response to a Multicast Address and Source Specific Query.
when a new valid General Query arrives on an interface, the node checks whether it has any per-interface listening state record to report on. 👀 same vibe for a new valid Multicast Address (and Source) Specific Query: the node checks whether it has a per-interface listening state record that matches the queried multicast address (and source). if it does, a delay for the response is randomly picked from the range (0, [Maximum Response Delay]), where Maximum Response Delay is derived from the Maximum Response Code in the received Query message. then these rules decide whether a Report needs to be scheduled and what kind to schedule. (the rules are checked in order, and only the first matching rule gets applied 🎯)
- if there is a pending response to a previous General Query scheduled sooner than the selected delay, no additional response needs to be scheduled. 💅
- if the received Query is a General Query, the Interface Timer is used to schedule a response to the General Query after the selected delay. any previously pending response to a General Query gets canceled. 🚫
- if the received Query is a Multicast Address Specific Query or a Multicast Address and Source Specific Query, and there is no pending response to a previous Query for this multicast address, then the Multicast Address Timer is used to schedule a report. if the received Query is a Multicast Address and Source Specific Query, the list of queried sources is recorded so it can be used when generating a response. 📝
- if there is already a pending response to a previous Query scheduled for this multicast address, and either the new Query is a Multicast Address Specific Query or the recorded source list for the multicast address is empty, then the multicast address source list gets cleared and a single response is scheduled using the Multicast Address Timer. the new response is scheduled to be sent at the earliest of the remaining time for the pending report and the selected delay. ⏰
- if the received Query is a Multicast Address and Source Specific Query, and there is a pending response for this multicast address with a non-empty source list, then the multicast address source list is augmented to contain the list of sources in the new Query, and a single response is scheduled using the Multicast Address Timer. the new response is scheduled to be sent at the earliest of the remaining time for the pending report and the selected delay. 🔥
6.3. Action on Timer Expiration 🎀
there are several timers that, when they expire, trigger protocol actions on an MLDv2 Multicast Address Listener node. 🧚 all of these actions are about pending reports the node scheduled.
- if the expired timer is the Interface Timer (so there's a pending response to a General Query), then one Current State Record gets sent for each multicast address the specified interface has listening state for, as described in section 4.2. each record carries the multicast address, its filter mode (
MODE_IS_INCLUDEorMODE_IS_EXCLUDE), and its Source list. multiple Current State Records get packed into individual Report messages, to the extent possible 📦
this naive algorithm can cause bursts of packets when a node listens to a large number of multicast addresses 😭 so instead of using one single Interface Timer, implementations are recommended to spread the transmission of those Report messages over the interval (0, [Maximum Response Delay]). and note that any such implementation MUST avoid the "ack-implosion" problem, which means it MUST NOT send a Report immediately upon reception of a General Query. no spamming, periodt 🙅♀️
- if the expired timer is a Multicast Address Timer and the list of recorded sources for that multicast address is empty (so there's a pending response to a Multicast Address Specific Query), then, if and only if the interface has listening state for that multicast address, a single Current State Record gets sent for that address. the record carries the multicast address, its filter mode (
MODE_IS_INCLUDEorMODE_IS_EXCLUDE), and the source list, if there is one 🌸 - if the expired timer is a Multicast Address Timer and the list of recorded sources for that multicast address is non-empty (so there's a pending response to a Multicast Address and Source Specific Query), then, if and only if the interface has listening state for that multicast address, the contents of the corresponding Current State Record are worked out from the per-interface state and the pending response record, like this table says 👇
set of sources in the
per-interface state pending response record Current State Record
------------------- ----------------------- --------------------
INCLUDE (A) B IS_IN (A*B)
EXCLUDE (A) B IS_IN (B-A)if the resulting Current State Record has an empty set of source addresses, then no response is sent. after the required Report messages have been generated, the source lists associated with any reported multicast addresses get cleared 🧹
- if the expired timer is a Retransmission Timer for a multicast address (so there's a pending State Change Report for that multicast address), the contents of the report get figured out like this. if the report should contain a Filter Mode Change Record (meaning the Filter Mode Retransmission Counter for that multicast address has a value higher than zero), then, if the current filter mode of the interface is INCLUDE, a
TO_INrecord gets included in the report. otherwise aTO_EXrecord gets included. in both cases, the Filter Mode Retransmission Counter for that multicast address gets decremented by one unit after the report is transmitted 🔁
if the report should contain Source List Change Records instead (meaning the Filter Mode Retransmission Counter for that multicast address is zero), then an ALLOW and a BLOCK record get included. the contents of these records are built according to the table below 💖
Record Sources included
------ ----------------
TO_IN All in the current per-interface state that must be
forwarded
TO_EX All in the current per-interface state that must be
blocked
ALLOW All with retransmission state (i.e., all sources from the
Retransmission List) that must be forwarded. For each
included source, its Source Retransmission Counter is
decreased with one unit after the transmission of the
report. If the counter reaches zero, the source is
deleted from the Retransmission List for that multicast
address.
BLOCK All with retransmission state (i.e., all sources from the
Retransmission List) that must be blocked. For each
included source, its Source Retransmission Counter is
decreased with one unit after the transmission of the
report. If the counter reaches zero, the source is
deleted from the Retransmission List for that multicast
address.if the computed source list for either an ALLOW or a BLOCK record is empty, that record gets left out of the State Change Report 🙈
7. Description of the Protocol for Multicast Routers 🛣️💖
okay so this is where the routers get their moment ✨ The whole point of MLD is that each multicast router figures out, for every link it's directly attached to, which multicast addresses have listeners on that link. MLD version 2 goes one step further, letting a router also learn which sources have listeners among the neighboring nodes, for packets sent to any particular multicast address 👀 All of that info gets handed to whatever multicast routing protocol the router is running, so multicast packets actually reach every link where someone is interested. literally the whole plot 🦋
This section covers the part of MLDv2 that multicast routers do. Routers can also become multicast address listeners themselves, so they perform the listener part too, which is described in section 6. 🎀
A multicast router runs this protocol over each of its directly attached links. If a router has more than one interface to the same link, it only needs to run the protocol over one of them 🙈
For each interface where the router runs MLD, the router must configure that interface to listen to all link-layer multicast addresses that can be generated by IPv6 multicasts. For example, an Ethernet-attached router has to set its Ethernet address reception filter to accept all Ethernet multicast addresses that start with the hexadecimal value 3333 [RFC2464]. If an Ethernet interface can't filter that multicast address range, it has to be set to accept ALL Ethernet multicast addresses so that it still meets the MLD requirements 💅
On each interface where this protocol runs, the router MUST enable reception of the link-scope "all MLDv2-capable routers" multicast address from all sources. It MUST also perform the multicast address listener part of MLDv2 for that address on that interface 🔥
Multicast routers only need to know that at least one node on an attached link listens to packets for a particular multicast address from a particular source. A multicast router is not required to individually keep track of the interests of each neighboring node 🧚 (Nevertheless, see Appendix A2 item 1 for discussion.)
MLDv2 is backward compatible with the MLDv1 protocol. For a detailed description of the compatibility issues, see section 8. 🌈
7.1. Conditions for MLD Queries 🔍
How a router running MLDv2 behaves depends on whether there are several multicast routers on the same subnet 🫶 If there are, a querier election mechanism (described in section 7.6.2) picks a single multicast router to be in Querier state. All the multicast routers on the subnet listen to the messages sent by multicast address listeners and keep the same multicast listening information state, so they can quickly and correctly take over the querier job if the current Querier fails. Still, only the Querier sends periodic or triggered query messages on the subnet 👑
The Querier periodically sends General Queries to request Multicast Address Listener information from an attached link. These queries are how the Multicast Address Listener state of routers on attached links gets built and refreshed 🍓
Nodes answer these queries by reporting their Multicast Address Listening state (and the set of sources they listen to) using Current State Multicast Address Records in MLDv2 Multicast Listener Reports 💜
As a listener of a multicast address, a node can express interest in listening or not listening to traffic from particular sources. When a node's desired listening state changes, it reports the change using Filter Mode Change Records or Source List Change Records. These records indicate an explicit state change for a multicast address at a node, either in the Multicast Address Record's source list or in its filter mode ✨ When Multicast Address Listening stops at a node, or traffic from a particular source is no longer wanted, the Querier must query for other listeners of the multicast address or of the source before it deletes the multicast address (or source) from its Multicast Address Listener state and prunes its traffic. Careful, this step matters 😭
To get every node on a link to respond to changes in multicast address listening, the Querier sends specific queries. A Multicast Address Specific Query checks that no nodes listen to the specified multicast address, or "rebuilds" the listening state for that address. These are sent when the Querier receives a State Change Record saying a node has stopped listening to a multicast address. They're also sent to enable a fast transition of a router from EXCLUDE to INCLUDE mode, in case a received State Change Record calls for it 🦋
A Multicast Address and Source Specific Query checks that no nodes on a link listen to traffic from a specific set of sources. These queries list sources for a particular multicast address that have been asked to stop being forwarded. The Querier sends this query to learn whether any node listens to packets sent to the specified multicast address from the specified source addresses. Multicast Address and Source Specific Queries are only sent in response to State Change Records, and never in response to Current State Records 🙈 Section 5.1.13 describes each query in more detail.
7.2. MLD State Maintained by Multicast Routers 🗂️
Multicast routers that run MLDv2 keep state per multicast address, per attached link. That state covers a filter mode, a list of sources, and various timers. For each attached link where MLD runs, a multicast router records the listening state for that link. Conceptually, that state is a set of records of the form:
(IPv6 multicast address, Filter Timer,
Router Filter Mode, (source records) )Each source record looks like this:
(IPv6 source address, source timer)If all sources for a multicast address are listened to, the router keeps an empty source record list with the Router Filter Mode set to EXCLUDE. This means nodes on this link want all sources for this multicast address to be forwarded. It's the MLDv2 equivalent of an MLDv1 listening state 🎀
7.2.1. Definition of Router Filter Mode 🧠
To keep internal state small, MLDv2 routers keep a filter mode per multicast address, per attached link. The filter mode sums up the total listening state of a multicast address in a minimal set, so that every node's listening state is respected 💅 The filter mode can change when certain types of Multicast Address Records arrive, or when certain timer conditions happen. In the following sections, "Router Filter Mode" means the filter mode of a particular multicast address within a router. Section 7.4 describes how the Router Filter Mode changes for each Multicast Address Record received.
A router is in INCLUDE mode for a specific multicast address on a given interface if all the listeners on the link interested in that address are in INCLUDE mode. The router state is written as INCLUDE (A), where A is called the "Include List". The Include List is the set of sources that one or more listeners on the link have asked to receive. Every source in the Include List will be forwarded by the router, and any other source that isn't in the Include List will be blocked 🌸
A router is in EXCLUDE mode for a specific multicast address on a given interface if at least one listener on the link interested in that address is in EXCLUDE mode. Conceptually, when a Multicast Address Record is received, the Router Filter Mode for that address gets updated to cover all the requested sources using the least amount of state. As a rule, once a Multicast Address Record with a filter mode of EXCLUDE is received, the Router Filter Mode for that address will be set to EXCLUDE. Still, if all nodes with a Multicast Address Record whose filter mode is EXCLUDE stop reporting, it's desirable for the Router Filter Mode for that address to go back to INCLUDE mode. That transition happens when the Filter Timer expires, and section 7.5 explains it in detail ⭐
When the router is in EXCLUDE mode, the router state is written as EXCLUDE (X,Y), where X is called the "Requested List" and Y is called the "Exclude List". All sources, except those in the Exclude List, will be forwarded by the router. The Requested List has no effect on forwarding, but it still has to be maintained for several reasons, as explained in section 7.2.3 🦋
How the INCLUDE and EXCLUDE mode router state is handled, according to the received reports, is spelled out in detail in Tables 7.4.1 and 7.4.2. 💅
7.2.2. Definition of Filter Timers ⏳
The Filter Timer is only used when the router is in EXCLUDE mode for a specific multicast address. It represents the time for the Router Filter Mode of that address to expire and switch to INCLUDE mode. A Filter Timer is a decrementing timer with a lower bound of zero, and there is one Filter Timer per Multicast Address Record. Filter Timers are updated according to the types of Multicast Address Records received 🫶
If a Filter Timer expires while the Router Filter Mode for that multicast address is EXCLUDE, it means there are no more listeners in EXCLUDE mode on the attached link. At that point, the router transitions to INCLUDE filter mode. Section 7.5 describes the actions taken when a Filter Timer expires while in EXCLUDE mode 😭
The table below sums up the role of the Filter Timer. Section 7.4 has the details on how the Filter Timer gets set for each type of Multicast Address Record received.
Router Filter
Filter Mode Timer Value Actions/Comments
----------- ----------------- ----------------
INCLUDE Not Used All listeners in
INCLUDE mode.
EXCLUDE Timer > 0 At least one listener
in EXCLUDE mode.
EXCLUDE Timer == 0 No more listeners in
EXCLUDE mode for the
multicast address.
If the Requested List
is empty, delete
Multicast Address
Record. If not, switch
to INCLUDE filter mode;
the sources in the
Requested List are
moved to the Include
List, and the Exclude
List is deleted.7.2.3. Definition of Source Timers ✨
okay so a Source Timer is a decrementing timer with a lower bound of zero 🦋 each source record gets exactly one of its own. These timers get updated based on the type and filter mode of the Multicast Address Record that comes in, and Section 7.4 spells out how to set them for each record type 💅
a few variables get abbreviated here (they're all explained properly in section 9, so go look if you need the full tea 🍓). MALI is the Multicast Address Listening Interval, meaning how long the multicast address listening state sticks around before it times out. LLQT is the Last Listener Query Time, which is the total time the router should wait for a report after the Querier sends the first query 🔥 during that window, the Querier should send [Last Member Query Count]-1 retransmissions of the query. LLQT also represents the "leave latency," aka the gap between a listener state change being sent and the routing protocol actually getting the updated info 🫶
if the router is in INCLUDE filter mode, a source can get added to the current Include List whenever a listener in INCLUDE mode sends a Current State or State Change Report that includes that source 🌸 every source on the Include List has its own source timer, and it gets refreshed whenever a listener in INCLUDE mode sends a report confirming it still wants that specific source 💜 if that timer runs out, the source gets deleted from the Include List. and if there are no source records left at all, the multicast address record gets deleted from the router 😭
that's the "soft leave" mechanism. MLDv2 also has a "fast leave" scheme, and it's built on source timers too 🧚 when a node in INCLUDE mode says it wants to stop listening to a specific source, all the multicast routers on the link drop that source's timer down to a tiny interval of LLQT milliseconds. then the Querier sends a Multicast Address and Source Specific Query to check whether anyone else on the link is still listening to that source 👀 if a matching report shows up before the timer expires, every multicast router on the link updates that source timer. if nothing shows up, the source gets deleted from the Include List 💀 the way the Include List gets handled based on the reports received is spelled out in Tables 7.4.1 and 7.4.2 ✨
source timers work differently when the Router Filter Mode for a multicast address is EXCLUDE 🌈 sources on the Requested List have running timer values, and the router forwards traffic for them. sources on the Exclude List have their timers set to zero, and the router blocks them. if a timer for a source on the Requested List expires, that source moves to the Exclude List, and then the router tells the routing protocol that no listener on the link wants traffic from that source anymore 🙈
the router has to keep the Requested List around for two big reasons:
- to keep track of the sources that listeners in INCLUDE mode are listening to 🎀 this matters because it makes sure the router can switch cleanly back to INCLUDE mode once there are no listeners left in EXCLUDE mode. that switch shouldn't interrupt traffic to the INCLUDE-mode listeners who still want that multicast address ✨ so at the moment of the switch, the Requested List should be the set of sources that INCLUDE-mode nodes have explicitly asked for. when the router switches to INCLUDE mode, the sources on the Requested List get moved to the Include List, and the Exclude List gets deleted 💖 before that switch happens, the Requested List might be a bit of an inexact guess at what INCLUDE-mode listeners are listening to. it could be too big or too small 🙃 that's because the Requested List also does double duty for fast blocking, which is explained below. if a fast block is needed, some sources might get deleted from the Requested List (as shown in Tables 7.4.1 and 7.4.2) so the router state stays smaller 🍓 but in every one of those cases, the Filter Timer also gets updated. so INCLUDE-mode listeners have plenty of time before any possible switch to reconfirm their interest in the sources that got removed and rebuild the Requested List 🦋 the protocol makes sure the Requested List is accurate by the time a switch to INCLUDE mode happens. the details of the router's transition to INCLUDE mode are in Appendix A3 🧁
- to allow a fast blocking of sources that were previously unblocked 💅 if the router gets a report with that kind of request, the affected sources go onto the Requested List. their timers get set to a tiny interval of LLQT milliseconds, and the Querier sends a Multicast Address and Source Specific Query to check whether any nodes on the link still want those sources 🫶 if no node confirms interest in a given source, its timer runs out, and the source moves from the Requested List to the Exclude List. from that point on, the router blocks that source 🚫
the EXCLUDE mode router state gets handled according to the reports received, and the details are in Tables 7.4.1 and 7.4.2 📋
when the Router Filter Mode for a multicast address is EXCLUDE, source records only get deleted when the Filter Timer expires, or when newly received Multicast Address Records change the router's source record list 💜
7.3. MLDv2 Source Specific Forwarding Rules 🦋
when a multicast router gets a datagram from a source destined to a particular multicast address, it has to decide whether to forward that datagram onto an attached link 🤔 the multicast routing protocol in use is the one making that call, and it should use the MLDv2 info to make sure that every source/multicast address pair with listeners on a link gets forwarded to that link 🌸 MLDv2 info doesn't override multicast routing info, though. for example, if the MLDv2 filter mode for a multicast address is EXCLUDE, the router may still forward packets from excluded sources onto a transit link 🧚
here's the summary: the table below shows the forwarding suggestions MLDv2 gives the routing protocol for traffic from a source going to a multicast address 💖 it also shows what happens when a source timer expires, based on the Router Filter Mode of that multicast address ✨
Router
Filter Mode Source Timer Value Action
----------- ------------------ ------
INCLUDE TIMER > 0 Suggest to forward traffic
from source
INCLUDE TIMER == 0 Suggest to stop forwarding
traffic from source and
remove source record. If
there are no more source
records, delete multicast
address record
EXCLUDE TIMER > 0 Suggest to forward traffic
from source
EXCLUDE TIMER == 0 Suggest to not forward
traffic from source. Move
the source from the
Requested List to the
Exclude List (DO NOT remove
source record)
EXCLUDE No Source Element Suggest to forward traffic
from all sources7.4. Action on Reception of Reports 📨
when an MLD message containing a Report comes in, the router checks a few things 🕵️♀️ it checks whether the message's source address is a valid link-local address, whether the Hop Limit is set to 1, and whether the Router Alert option is present in the Hop-By-Hop Options header of the IPv6 packet. if any of those checks fail, the packet gets dropped 💀 if the MLD message passes validation, the router goes ahead and processes the Report 🎀
7.4.1. Reception of Current State Records 🌈
when the router receives Current State Records, it updates both its Filter Timer and its source timers 💅 in some cases, getting a certain type of multicast address record makes the Router Filter Mode for that multicast address change. the table below lays out the state and timer actions that happen when Current State Records come in ✨
if the router is in INCLUDE filter mode for a multicast address, we write that as INCLUDE (A), where A is the associated Include List 🦋 if the router is in EXCLUDE filter mode for a multicast address, we write it as EXCLUDE (X,Y), where X and Y are the associated Requested List and Exclude List, in that order 🫶
in the "Actions" section of the router state tables, '(A)=J' means that the set A of source records should have their source timers set to value J 🧮 'Delete (A)' means the set A of source records should be deleted 🗑️ and 'Filter Timer = J' means the Filter Timer for the multicast address should be set to value J ⏱️
Router State Report Received New Router State Actions
------------ --------------- ---------------- -------
INCLUDE (A) IS_IN (B) INCLUDE (A+B) (B)=MALI
INCLUDE (A) IS_EX (B) EXCLUDE (A*B, B-A) (B-A)=0
Delete (A-B)
Filter Timer=MALI
EXCLUDE (X,Y) IS_IN (A) EXCLUDE (X+A, Y-A) (A)=MALI
EXCLUDE (X,Y) IS_EX (A) EXCLUDE (A-Y, Y*A) (A-X-Y)=MALI
Delete (X-A)
Delete (Y-A)
Filter Timer=MALI7.4.2. Reception of Filter Mode Change and Source List Change Records ✨
okay so bestie 💖 when a node's global state for a multicast address changes, it sends EITHER a Source List Change Record OR a Filter Mode Change Record for that address. just like Current State Records, routers must act on these and maybe update their own state so it matches the new listening vibe on the link 🦋
The Querier must query sources or multicast addresses that are requested to be no longer forwarded 🫶 When a router queries or receives a query for a specific set of sources, it lowers its source timers for those sources to a small interval of Last Listener Query Time milliseconds ⏳ If multicast address records come back in response to those queries and express interest in listening to the queried sources, the matching timers get updated. it's giving second chances 💅
Multicast Address Specific queries can also help a router go from EXCLUDE to INCLUDE mode quickly 🏃♀️💨 if a received Multicast Address Record motivates that move, the Filter Timer for that address is lowered to a small interval of Last Listener Query Time milliseconds. if any multicast address records that express EXCLUDE mode interest in the address show up within that interval, the Filter Timer gets updated and the suggestion to the routing protocol to forward the address stands without any interruption 🌸 If not, the router will switch to INCLUDE filter mode for that multicast address.
During the query period (aka Last Listener Query Time milliseconds), the MLD component in the router keeps suggesting to the routing protocol to forward traffic from the queried multicast addresses or sources 🧚 It is not until after Last Listener Query Time milliseconds pass without any record expressing interest in the queried multicast address or sources that the router may prune them from the link. no rush, babe 🍓
The following table describes the changes in multicast address state and the action(s) taken when a router receives either a Filter Mode Change or Source List Change Record. it also shows the queries the Querier sends when a particular report comes in 📋
We use the notation Q(MA) to describe a Multicast Address Specific Query to the MA multicast address. We use the notation Q(MA,A) to describe a Multicast Address and Source Specific Query to the MA multicast address with source list A. If source list A is null as a result of the action (e.g. A*B), then no query is sent as a result of the operation 🙈
In order to maintain protocol robustness, the queries defined in the Actions column of the table below need to be transmitted [Last Listener Query Count] times, once every [Last Listener Query Interval] period 💪
If while scheduling new queries there are already pending queries to be retransmitted for the same multicast address, the new and pending queries have to be merged 🔀 Also, received host reports for a multicast address with pending queries may affect the contents of those queries. Section 7.6.3. describes the process of building and maintaining the state of pending queries 📖
Router State Report Received New Router State Actions
------------ --------------- ---------------- -------
INCLUDE (A) ALLOW (B) INCLUDE (A+B) (B)=MALI
INCLUDE (A) BLOCK (B) INCLUDE (A) Send Q(MA,A*B)
INCLUDE (A) TO_EX (B) EXCLUDE (A*B,B-A) (B-A)=0
Delete (A-B)
Send Q(MA,A*B)
Filter Timer=MALI
INCLUDE (A) TO_IN (B) INCLUDE (A+B) (B)=MALI
Send Q(MA,A-B)
EXCLUDE (X,Y) ALLOW (A) EXCLUDE (X+A,Y-A) (A)=MALI
EXCLUDE (X,Y) BLOCK (A) EXCLUDE (X+(A-Y),Y) (A-X-Y) =
Filter Timer
Send Q(MA,A-Y)
EXCLUDE (X,Y) TO_EX (A) EXCLUDE (A-Y,Y*A) (A-X-Y) =
Filter Timer
Delete (X-A)
Delete (Y-A)
Send Q(MA,A-Y)
Filter Timer=MALI
EXCLUDE (X,Y) TO_IN (A) EXCLUDE (X+A,Y-A) (A)=MALI
Send Q(MA,X-A)
Send Q(MA)7.5. Switching Router Filter Modes 🔁
The Filter Timer is the mechanism for moving the Router Filter Mode from EXCLUDE to INCLUDE 🎀
When a Filter Timer expires with a Router Filter Mode of EXCLUDE, a router assumes there are no nodes with a filter mode of EXCLUDE on the attached link. So the router transitions to INCLUDE filter mode for that multicast address. it's a glow-up arc 🌈
A router uses the sources from the Requested List as its state for the switch to a filter mode of INCLUDE. Sources from the Requested List get moved into the Include List, while sources from the Exclude List get deleted 🗑️ For example, if a router's state for a multicast address is EXCLUDE(X,Y) and the Filter Timer expires for that address, the router switches to filter mode of INCLUDE with state INCLUDE(X). If at the moment of the switch the Requested List (X) is empty, the multicast address record gets deleted from the router 💀
7.6. Action on Reception of Queries 👀
When an MLD message containing a Query arrives, the router checks whether the source address of the message is a valid link-local address, whether the Hop Limit is set to 1, and whether the Router Alert option is present in the Hop-By-Hop Options header of the IPv6 packet. If any of these checks fails, the packet is dropped 🚫
If the validity of the MLD message is verified, the router starts processing the Query ✅
7.6.1. Timer Updates ⏰
MLDv2 uses the Suppress Router-Side Processing flag to ensure robustness, as explained in section 2.1. When a router sends or receives a query with a clear Suppress Router-Side Processing flag, it must update its timers so they reflect the correct timeout values for the multicast address or sources being queried. The following table describes the timer actions when sending or receiving a Multicast Address Specific or Multicast Address and Source Specific Query with the Suppress Router-Side Processing flag not set 🧾
Query Action
----- ------
Q(MA,A) Source Timers for sources in A are lowered to LLQT
Q(MA) Filter Timer is lowered to LLQTWhen a router sends or receives a query with the Suppress Router-Side Processing flag set, it will not update its timers 😌
7.6.2. Querier Election 👑
MLDv2 elects a single router per subnet to be in Querier state. all the other routers on the subnet should be in Non-Querier state. MLDv2 uses the same querier election mechanism as MLDv1, namely the IPv6 address. When a router starts operating on a subnet, by default it considers itself the Querier. So it sends several General Queries separated by a small time interval (see sections 9.6 and 9.7 for details) 📣
When a router receives a query with a lower IPv6 address than its own, it sets the Other Querier Present timer to Other Querier Present Timeout. If it was previously in Querier state, it switches to Non-Querier state and stops sending queries on the link. After the Other Querier Present timer expires, it should re-enter the Querier state and begin sending General Queries 🔄
All MLDv2 queries MUST be sent with the FE80::/64 link-local source address prefix. Therefore, for the purpose of MLDv2 querier election, an IPv6 address A is considered lower than an IPv6 address B if the interface ID represented by the last 64 bits of address A, in big-endian bit order, is lower than the interface ID represented by the last 64 bits of address B 🧮
7.6.3. Building and Sending Specific Queries 🛠️
7.6.3.1. Building and Sending Multicast Address Specific Queries 🎯
When a table action Send Q(MA) is encountered, the Filter Timer must be lowered to LLQT. The Querier must then immediately send a Multicast Address Specific query, as well as schedule [Last Listener Query Count - 1] query retransmissions to be sent every [Last Listener Query Interval], over [Last Listener Query Time] ⚡
When transmitting a Multicast Address Specific Query, if the Filter Timer is larger than LLQT, the Suppress Router-Side Processing bit is set in the query message 🙌
7.6.3.2. Building and Sending Multicast Address and Source Specific Queries 🧩
When a table action Send Q(MA,X) is encountered by the Querier in the table in section 7.4.2, the following actions must be performed for each of the sources in X that send to multicast address MA, with source timer larger than LLQT:
- Lower source timer to LLQT;
- Add the sources to the Retransmission List;
- Set the Source Retransmission Counter for each source to [Last Listener Query Count].
The Querier must then immediately send a Multicast Address and Source Specific Query, as well as schedule [Last Listener Query Count -1] query retransmissions to be sent every [Last Listener Query Interval], over [Last Listener Query Time]. The contents of these queries are calculated as follows 🧠
When building a Multicast Address and Source Specific Query for a multicast address MA, two separate query messages are sent for that multicast address. The first one has the Suppress Router-Side Processing bit set and contains all the sources with retransmission state (i.e., sources from the Retransmission List of that multicast address) and timers greater than LLQT. The second has the Suppress Router-Side Processing bit clear and contains all the sources with retransmission state and timers lower or equal to LLQT. If either of the two calculated messages does not contain any sources, then its transmission is suppressed 🫧
Note: If a Multicast Address Specific query is scheduled to be transmitted at the same time as a Multicast Address and Source Specific query for the same multicast address, then transmission of the Multicast Address and Source Specific message with the Suppress Router-Side Processing bit set may be suppressed 🙃
8. Interoperation with MLDv1 🤝
MLD version 2 hosts and routers interoperate with hosts and routers that haven't been upgraded to MLDv2 yet 🌱 This compatibility is maintained by hosts and routers taking appropriate actions depending on which versions of MLD are operating on the hosts and routers within a network 💜
8.1. Query Version Distinctions 🔍
The MLD version of a Multicast Listener Query message is determined as follows:
MLDv1 Query: length = 24 octetsMLDv2 Query: length >= 28 octets
Query messages that do not match any of the above conditions (e.g., a Query of length 26 octets) MUST be silently ignored 🙅♀️
8.2. Multicast Address Listener Behavior 🎧
8.2.1. In the Presence of MLDv1 Routers ✨
okay so, to be compatible with MLDv1 routers, MLDv2 hosts MUST operate in version 1 compatibility mode 💅. They MUST keep state per local interface about the compatibility mode of each attached link 🫶. A host's compatibility mode comes from the Host Compatibility Mode variable, which can be in one of two states: MLDv1 or MLDv2 🦋.
The Host Compatibility Mode of an interface gets set to MLDv1 whenever an MLDv1 Multicast Address Listener Query shows up on that interface. At that same moment, the Older Version Querier Present timer for the interface gets set to Older Version Querier Present Timeout seconds. Every new MLDv1 Query that arrives on that interface re-sets the timer. If the Older Version Querier Present timer expires, the host switches back to Host Compatibility Mode of MLDv2 🔄.
When Host Compatibility Mode is MLDv2, a host acts using the MLDv2 protocol on that interface. When Host Compatibility Mode is MLDv1, a host acts in MLDv1 compatibility mode, using only the MLDv1 protocol, on that interface 🌸.
An MLDv1 Querier sends General Queries with the Maximum Response Code set to the desired Maximum Response Delay. So the full range of this field is linear, and the exponential algorithm described in section 5.1.3. is not used. Lowkey a glow-up for the field 💖.
Whenever a host changes its compatibility mode, it cancels all its pending responses and retransmission timers 🧚.
8.2.2. In the Presence of MLDv1 Multicast Address Listeners 🎀
An MLDv2 host may be placed on a link where there are MLDv1 hosts. A host MAY allow its MLDv2 Multicast Listener Report to be suppressed by a Version 1 Multicast Listener Report 🙈.
8.3. Multicast Router Behavior 👑
8.3.1. In the Presence of MLDv1 Routers 🍓
MLDv2 routers may be placed on a network where there is at least one MLDv1 router. The following requirements apply:
- If an MLDv1 router is present on the link, the Querier MUST use the lowest version of MLD present on the network. This must be administratively assured. Routers that desire to be compatible with MLDv1 MUST have a configuration option to act in MLDv1 mode. If an MLDv1 router is present on the link, the system administrator must explicitly configure all MLDv2 routers to act in MLDv1 mode. When in MLDv1 mode, the Querier MUST send periodic General Queries truncated at the Multicast Address field (i.e., 24 bytes long), and SHOULD also warn about receiving an MLDv2 Query (such warnings must be rate-limited). The Querier MUST also fill in the Maximum Response Delay in the Maximum Response Code field, so the exponential algorithm described in section 5.1.3. is not used 💅.
- If a router is not explicitly configured to use MLDv1 and receives an MLDv1 General Query, it SHOULD log a warning. These warnings MUST be rate-limited 🌈.
8.3.2. In the Presence of MLDv1 Multicast Address Listeners 🦋
MLDv2 routers may be placed on a network where there are hosts that have not yet been upgraded to MLDv2. To be compatible with MLDv1 hosts, MLDv2 routers MUST operate in version 1 compatibility mode. MLDv2 routers keep a compatibility mode per multicast address record. The compatibility mode of a multicast address is determined from the Multicast Address Compatibility Mode variable, which can be in one of the two following states: MLDv1 or MLDv2 ✨.
The Multicast Address Compatibility Mode of a multicast address record gets set to MLDv1 whenever an MLDv1 Multicast Listener Report is received for that multicast address. At the same time, the Older Version Host Present timer for the multicast address gets set to Older Version Host Present Timeout seconds. Every new MLDv1 Report received for that multicast address re-sets the timer. If the Older Version Host Present timer expires, the router switches back to Multicast Address Compatibility Mode of MLDv2 for that multicast address 🔄.
Note that when a router switches back to MLDv2 Multicast Address Compatibility Mode for a multicast address, it takes some time to regain source-specific state information. Source-specific information will be learned during the next General Query, but sources that should be blocked will not be blocked until [Multicast Address Listening Interval] after that 🕰️.
When Multicast Address Compatibility Mode is MLDv2, a router acts using the MLDv2 protocol for that multicast address. When Multicast Address Compatibility Mode is MLDv1, a router internally translates the following MLDv1 messages for that multicast address to their MLDv2 equivalents 🧠:
MLDv1 Message MLDv2 Equivalent
------------- ----------------
Report IS_EX( {} )
Done TO_IN( {} )MLDv2 BLOCK messages are ignored, and so are source-lists in TO_EX() messages. In other words, any TO_EX() message is treated as TO_EX( {} ) 🙃. On the other hand, the Querier keeps sending MLDv2 queries, no matter its Multicast Address Compatibility Mode 🫶.
9. List of Timers, Counters, and their Default Values ⏰
Most of these timers are configurable. If non-default settings are used, they MUST be consistent among all nodes on a single link. Note that parentheses are used to group expressions to make the algebra clear 🧮.
9.1. Robustness Variable 💪
The Robustness Variable allows tuning for the expected packet loss on a link. If a link is expected to be lossy, the value of the Robustness Variable may be increased. MLD is robust to [Robustness Variable] - 1 packet losses. The value of the Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default value: 2 🌟.
9.2. Query Interval ⏳
The Query Interval variable denotes the interval between General Queries sent by the Querier. Default value: 125 seconds.
By varying the [Query Interval], an administrator may tune the number of MLD messages on the link. Larger values cause MLD Queries to be sent less often 🐢.
9.3. Query Response Interval 📣
The Maximum Response Delay used to calculate the Maximum Response Code inserted into the periodic General Queries. Default value: 10000 (10 seconds).
By varying the [Query Response Interval], an administrator may tune the burstiness of MLD messages on the link. Larger values make the traffic less bursty, since host responses are spread out over a larger interval. The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval] 🌊.
9.4. Multicast Address Listening Interval 👂
The Multicast Address Listening Interval (MALI) is the amount of time that must pass before a multicast router decides there are no more listeners of a multicast address or a particular source on a link. This value MUST be ([Robustness Variable] times [Query Interval]) plus [Query Response Interval] 💅.
9.5. Other Querier Present Timeout 🫣
The Other Querier Present Timeout is the length of time that must pass before a multicast router decides that there is no longer another multicast router which should be the Querier. This value MUST be ([Robustness Variable] times ([Query Interval]) plus (one half of [Query Response Interval]). 🧐
9.6. Startup Query Interval 🚀
The Startup Query Interval is the interval between General Queries sent by a Querier on startup. Default value: 1/4 the [Query Interval] 🏁.
9.7. Startup Query Count 🔢
The Startup Query Count is the number of Queries sent out on startup, separated by the Startup Query Interval. Default value: [Robustness Variable] ✌️.
9.8. Last Listener Query Interval 🎧
The Last Listener Query Interval is the Maximum Response Delay used to calculate the Maximum Response Code inserted into Multicast Address Specific Queries sent in response to Version 1 Multicast Listener Done messages. It is also the Maximum Response Delay used to calculate the Maximum Response Code inserted into Multicast Address and Source Specific Query messages. Default value: 1000 (1 second) 🎶.
Note that for values of LLQI greater than 32.768 seconds, a limited set of values can be represented, corresponding to sequential values of Maximum Response Code. When converting a configured time to a Maximum Response Code value, it is recommended to use the exact value if possible, or the next lower value if the requested value is not exactly representable 🧾.
This value may be tuned to modify the "leave latency" of the link. A reduced value results in reduced time to detect the departure of the last listener for a multicast address or source 👋.
9.9. Last Listener Query Count 🔁
The Last Listener Query Count is the number of Multicast Address Specific Queries sent before the router assumes there are no local listeners. The Last Listener Query Count is also the number of Multicast Address and Source Specific Queries sent before the router assumes there are no listeners for a particular source. Default value: [Robustness Variable] 🫶.
9.10. Last Listener Query Time ⌛
The Last Listener Query Time is the time value represented by the Last Listener Query Interval, multiplied by [Last Listener Query Count]. It is not a tunable value, but it may be tuned by changing its components 🧩.
9.11. Unsolicited Report Interval 📨
The Unsolicited Report Interval is the time between repetitions of a node's initial report of interest in a multicast address. Default value: 1 second ☝️.
9.12. Older Version Querier Present Timeout 🕵️
The Older Version Querier Present Timeout is the time-out for transitioning a host back to MLDv2 Host Compatibility Mode. When an MLDv1 query is received, MLDv2 hosts set their Older Version Querier Present Timer to [Older Version Querier Present Timeout].
This value MUST be ([Robustness Variable] times (the [Query Interval] in the last Query received)) plus ([Query Response Interval]) 🎯.
9.13. Older Version Host Present Timeout 🫧
The Older Version Host Present Timeout is the time-out for transitioning a router back to MLDv2 Multicast Address Compatibility Mode for a specific multicast address. When an MLDv1 report is received for that multicast address, routers set their Older Version Host Present Timer to [Older Version Host Present Timeout].
This value MUST be ([Robustness Variable] times [Query Interval]) plus ([Query Response Interval]) 💫.
9.14. Configuring timers 🛠️
This section is meant to provide advice to network administrators on how to tune these settings to their network. Ambitious router implementations might tune these settings dynamically based upon changing characteristics of the network 🧑💻.
9.14.1. Robustness Variable 🧱
The Robustness Variable tunes MLD to expected losses on a link. MLDv2 is robust to [Robustness Variable] - 1 packet losses. For example, if the Robustness Variable is set to the default value of 2, MLDv2 is robust to a single packet loss, but it may operate imperfectly if more losses occur. On lossy links, the value of the Robustness Variable should be increased to allow for the expected level of packet loss. However, increasing the value of the Robustness Variable increases the leave latency of the link (the time between when the last listener stops listening to a source or multicast address and when the traffic stops flowing). It's a bit of a trade-off, bestie 🥹🎀.
9.14.2. Query Interval ⏰
okay so the overall level of periodic MLD traffic is inversely proportional to the Query Interval 💅 A longer Query Interval means less MLD traffic overall, which is lowkey the chill option 🌸 The value of the Query Interval MUST be equal to or greater than the Maximum Response Delay used to calculate the Maximum Response Code inserted in General Query messages 🫶
9.14.3. Maximum Response Delay 🐢
the burstiness of MLD traffic is inversely proportional to the Maximum Response Delay ✨ A longer Maximum Response Delay spreads Report messages over a longer interval 🦋 But here's the tea: a longer Maximum Response Delay in Multicast Address Specific and Multicast Address And Source Specific Queries extends the leave latency (the time between when the last listener stops listening to a source or multicast address and when the traffic stops flowing.) 😭 The expected rate of Report messages can be calculated by dividing the expected number of Reporters by the Maximum Response Delay. The Maximum Response Delay may be dynamically calculated per Query by using the expected number of Reporters for that Query, like this:
Query Type Expected number of Reporters
---------- ----------------------------
General Query All nodes on link
Multicast Address Specific Query All nodes on the link that had
expressed interest in the
multicast address
Multicast Address and Source All nodes on the link that had
Specific Query expressed interest in the source
and multicast addressA router is not required to calculate these populations or tune the Maximum Response Delay dynamically. These are simply guidelines 💜
10. Security Considerations 🔐
this part is seriously important, bestie 💀 We consider the ramifications of a forged message of each type. Before processing an MLD message, nodes verify whether the source address of the message is a valid link-local address (or the unspecified address), whether the Hop Limit is set to 1, and whether the Router Alert option is present in the Hop-By-Hop Options header of the IPv6 packet. If any of these checks fails, the packet is dropped 🚫 This defends MLDv2 nodes from acting on forged MLD messages originated off-link 🛡️ Therefore, in the following we discuss only the effects of on-link forgery.
10.1. Query Message
A forged Query message from a machine with a lower IPv6 address than the current Querier will cause Querier duties to be assigned to the forger 😈 If the forger then sends no more Query messages, other routers' Other Querier Present timer will time out and one will resume the role of Querier. During this time, if the forger ignores Multicast Listener Done Messages, traffic might flow to multicast addresses with no listeners for up to [Multicast Address Listener Interval] 🙈
A forged Version 1 Query message will put MLDv2 listeners on that link in MLDv1 Host Compatibility Mode. This scenario can be avoided by providing MLDv2 hosts with a configuration option to ignore Version 1 messages completely 🧚
A DoS attack on a node could be staged through forged Multicast Address and Source Specific Queries. The attacker can find out about the listening state of a specific node with a general query. After that, it could send a large number of Multicast Address and Source Specific Queries, each with a large source list and/or long Maximum Response Delay. The node will have to store and maintain the sources specified in all of those queries for as long as it takes to send the delayed response. This would consume both memory and CPU cycles in order to augment the recorded sources with the source lists included in the successive queries 💀
To protect against such a DoS attack, a node stack implementation could restrict the number of Multicast Address and Source Specific Queries per multicast address within this interval, and/or record only a limited number of sources 🛡️
10.2. Current State Report messages
A forged Report message may cause multicast routers to think there are listeners of a multicast address on a link when there are not. Nevertheless, since listening to a multicast address on a host is generally an unprivileged operation, a local user may trivially gain the same result without forging any messages 🤷♀️
A forged Version 1 Report Message may put a router into MLDv1 Multicast Address Compatibility Mode for a particular multicast address, meaning that the router will ignore MLDv2 source specific state messages. This can cause traffic to flow from unwanted sources for up to [Multicast Address Listener Interval] 😩 This can be solved by providing routers with a configuration switch to ignore Version 1 messages completely. This breaks automatic compatibility with Version 1 hosts, so it should only be used in situations where source filtering is critical 🔥
10.3. State Change Report messages
A forged State Change Report message will cause the Querier to send out Multicast Address Specific or Multicast Address and Source Specific Queries for the multicast address in question. This causes extra processing on each router and on each listener of the multicast address, but cannot cause loss of desired traffic 🌈
11. IANA Considerations 📚
IANA has assigned the IPv6 link-local multicast address FF02:0:0:0:0:0:0:16, called "all MLDv2-capable routers", as described in section 5.2.14. Version 2 Multicast Listener Reports will be sent to this special address 📮
In addition, IANA has assigned the ICMPv6 message type value of 143 for Version 2 Multicast Listener Report messages, as specified in section 4 🍓
12. References 📖
12.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
- [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
- [RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
- [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option," RFC 2711, October 1999.
- [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture, RFC 3513, April 2003.
12.2. Informative References
- [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
- [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
- [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
- [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source- Specific Multicast (SSM)", RFC 3569, July 2003.
- [RFC3678] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
13. Acknowledgments 🎀
we owe a huge thank you to Hitoshi Asaeda, Randy Bush, Francis Dupont, Ted Hardie, Russ Housley, Konstantin Kabassanov, Erik Nordmark, Shinsuke Suzuki, Margaret Wasserman, Bert Wijnen, and Remi Zara for their valuable comments and suggestions on this document 🫶👑
APPENDIX A. Design Rationale ✨
A.1. The Need for State Change Messages
MLDv2 specifies two types of Multicast Listener Reports: Current State and State Change. This section describes the rationale for needing both of these types of Reports 💖
Routers need to distinguish Multicast Listener Reports that were sent in response to Queries from those that were sent as a result of a change in the per-interface state. Multicast Listener Reports that are sent in response to Multicast Address Listener Queries are used mainly to refresh the existing state at the router; they typically do not cause transitions in state at the router. Multicast Listener Reports that are sent in response to changes in the per-interface state require the router to take some action in response to the received report (see Section 7.4.) 🔍
The inability to distinguish between the two types of reports would force a router to treat all Multicast Listener Reports as potential changes in state. That could result in increased processing at the router, as well as an increase in MLD traffic on the link 😵💫
A.2. Host Suppression
In MLDv1, a host would not send a pending multicast listener report if a similar report was sent by another listener on the link. In MLDv2, the suppression of multicast listener reports has been removed. The following points explain this decision 🧠
- Routers may want to track per-host multicast listener status on an interface. This would allow routers to implement fast leaves (e.g., for layered multicast congestion control schemes), as well as track listener status for possible security or accounting purposes. The present specification does not require routers to implement per-host tracking. Nevertheless, the lack of host suppression in MLDv2 makes it possible to implement either proprietary or future standard behavior of multicast routers that would support per-host tracking, while being fully interoperable with MLDv2 listeners and routers that implement the exact behavior described in this specification 🦋
- Multicast Listener Report suppression does not work well on bridged LANs. Many bridges and Layer2/Layer3 switches that implement MLD snooping do not forward MLD messages across LAN segments in order to prevent multicast listener report suppression 🌉
- By eliminating multicast listener report suppression, hosts have fewer messages to process. This leads to a simpler state machine implementation 🧸
- In MLDv2, a single multicast listener report now bundles multiple multicast address records to decrease the number of packets sent. In comparison, the previous version of MLD required that each multicast address be reported in a separate message 📦
A.3. Switching router filter modes from EXCLUDE to INCLUDE ✨
okay so if a link has nodes in both EXCLUDE and INCLUDE mode for the same multicast address, the router has to be in EXCLUDE mode too (see section 7.2.1) 🎀. In EXCLUDE mode, the router forwards traffic from every source except the ones in the Exclude List. Now if all the EXCLUDE nodes disappear or stop listening, it would be sooo nice for the router to switch back to INCLUDE mode seamlessly, without interrupting traffic for the listeners who are already there 🦋
One way to pull this off is for routers to keep track of every source that the INCLUDE-mode nodes are listening to, even while the router itself stays in EXCLUDE mode 💅. If the Filter Timer for a multicast address expires, that tells the router there are no nodes in EXCLUDE mode left on the link. (Otherwise a multicast listener report from that node would have refreshed the Filter Timer, so it would still be alive 🙈.) At that point the router can switch to INCLUDE mode with zero drama. Sources from the Requested List get moved to the Include List, and sources from the Exclude List get deleted 🧚
APPENDIX B. Summary of Changes from MLDv1 🌈
okay bestie, here's the recap of everything that changed from MLDv1, which is specified in RFC 2710 💜
- MLDv2 introduces source filtering 🔥.
- The IP service interface of MLDv2 nodes is modified to match. It lets you specify a filter mode and a source list 🎀.
- An MLDv2 node keeps per-socket and per-interface multicast listening states. Each one includes a filter mode and a source list for each multicast address. This is what makes packet filtering based on a socket's multicast reception state possible ✨.
- MLDv2 state on routers includes a filter mode, a list of sources, and source timers for each multicast address that has listeners on the link. MLDv1 routers only kept the list of multicast addresses 👑.
- Queries include additional fields (section 5.1) 🍓.
- The S flag (Suppress Router-Side Processing) is included in queries to fix robustness issues 🛠️.
- The Querier's Robustness Variable and Query Interval Code are included in Queries so that all MLDv2 routers connected to the same link stay in sync 🫶.
- A new Query type, the Multicast Address and Source Specific Query, is introduced 🦋.
- The Maximum Response Delay isn't directly included in the Query anymore. Instead, an exponential algorithm works out its value from the Maximum Response Code in the Query. The maximum goes up from 65535 milliseconds to about 140 minutes 🌸.
- Reports include Multicast Address Records, so listening state for several different multicast addresses can ride in the same Report message 💖.
- Reports are sent to the "all MLDv2-capable multicast routers" address, not the multicast address the host listens to like in MLDv1. This makes life easier for layer-2 snooping switches 🧚.
- There is no "host suppression" like in MLDv1. All nodes send Report messages 💅.
- Unsolicited Reports, which announce changes in receiver listening state, are sent [Robustness Variable] times. RFC 2710 is less explicit about this 🙈.
- There are no Done messages 💀.
- Interoperability with MLDv1 systems is achieved through MLDv2 state operations 🫶.
- To keep interoperability working, hosts maintain a Host Compatibility Mode variable and an Older Version Querier Present timer per interface. Routers maintain a Multicast Address Compatibility Mode variable and an Older Version Host Present timer per multicast address 👑.
Editors' Contact Information 💌
Here are the editors, with their details exactly as they were written:
Rolland Vida
LIP6, Universite Pierre et Marie Curie
8, rue du Capitaine Scott
75015 Paris, France
Phone: +33-1.44.27.30.58
EMail: Rolland.Vida@lip6.fr
Luis Henrique Maciel Kosmalski Costa
LIP6, Universite Pierre et Marie Curie
8, rue du Capitaine Scott
75015 Paris, France
Phone: +33-1.44.27.30.58
EMail: Luis.Costa@lip6.frAuthors' Addresses 🧑💻
This document was written by:
Rolland Vida, LIP6
EMail: Rolland.Vida@lip6.fr
Luis Henrique Maciel Kosmalski Costa, LIP6
EMail: Luis.Costa@lip6.fr
Serge Fdida, LIP6
EMail: Serge.Fdida@lip6.fr
Steve Deering, Cisco Systems, Inc.
EMail: deering@cisco.com
Bill Fenner, AT&T Labs - Research
EMail: fenner@research.att.com
Isidor Kouvelas, Cisco Systems, Inc.
EMail: kouvelas@cisco.com
Brian Haberman, Caspian Networks
EMail: brian@innovationslab.netThis document is the translation of [RFC3376] for IPv6 semantics. It was elaborated based on the translation of (RFC 2236) into [RFC2710] 🌸.
Full Copyright Statement ©️
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), AND THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED. That includes, but isn't limited to, any warranty that the use of the information herein won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 😭.
Intellectual Property 💜
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology described in this document. It also doesn't say whether any license under those rights is or isn't available, and it doesn't claim to have made any independent effort to find such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79 📚.
Copies of IPR disclosures made to the IETF Secretariat, along with any assurances of licenses to be made available, or the results of any attempt to get a general license or permission to use these proprietary rights for implementers or users of this specification, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org 💌.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society 🎀✨
📦 where this page comes from
- ietf: rfc3810 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms