RFC 2710
Multicast Listener Discovery (MLD) for IPv6
RFC 2710: Multicast Listener Discovery (MLD) for IPv6 🦋
okay so here's the title block, bestie 💅
- RFC number: 2710
- Title: Multicast Listener Discovery (MLD) for IPv6
- Published by: Network Working Group
- Authors: S. Deering (Cisco Systems), W. Fenner (AT&T Research), B. Haberman (IBM)
- Category: Standards Track
- Date: October 1999
- Obsoletes / Updates: the title block doesn't list any, so nothing gets replaced or updated here 🌸
Status of This Memo ✨
ok so this doc is an Internet standards track protocol for the Internet community 🌈 it's literally asking for discussion and suggestions for improvements 💖 if you want to know where this protocol sits in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📖 and the memo is unlimited in distribution, so it's giving open access 🫶
Copyright Notice 🎀
Copyright (C) The Internet Society (1999). All Rights Reserved. 💜
Abstract 🦋
this doc specifies the protocol an IPv6 router uses to find out if there are multicast listeners (nodes that want to receive multicast packets) on the links it's directly attached to 👀 it also figures out exactly which multicast addresses those neighbouring nodes care about 💅 this protocol is called Multicast Listener Discovery, or MLD for short ✨ MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2 🌸 the big difference is that MLD uses ICMPv6 (IP Protocol 58) message types instead of IGMP (IP Protocol 2) message types 🔥
1. Definitions 🧚
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read the way RFC 2119 [KEYWORDS] describes 📚 those are the real rule words, so pay attention to them 👑
2. Introduction 🌷
okay the whole point of MLD is to let each IPv6 router find out which multicast listeners are on its directly attached links, and which multicast addresses those neighbours want 🫶 that info gets handed to whatever multicast routing protocol the router is running, so multicast packets actually reach every link with interested receivers ✨ it's giving teamwork 💕
MLD is asymmetric, which means the router and the listeners each get their own behaviour 🦋 if a router is listening to a multicast address itself, it does both parts of the protocol for that address, including replying to its own messages 🙈
if a router has more than one interface to the same link, it only needs to do the router part of MLD on one of them 🌈 listeners are different though: they have to do the listener part on every interface where an application or upper-layer protocol asked to receive multicast packets 💅
3. Message Format 💖
MLD is a sub-protocol of ICMPv6, so MLD message types are just a subset of the ICMPv6 messages 🧚 you can spot them in IPv6 packets by the Next Header value of 58 ✨ every MLD message in this doc goes out with a link-local IPv6 Source Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option [RTR-ALERT] inside a Hop-by-Hop Options header 🔥 (the Router Alert option is the thing that makes routers look at MLD messages sent to multicast addresses they have zero interest in, so it's kinda essential 🙈)
here's the MLD message layout 👇
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Response Delay | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.1. Type 🎀
there are three types of MLD messages, and we're serving all three 💅
- Multicast Listener Query (
Type = decimal 130)- there are two subtypes of Query messages:
- General Query: used to learn which multicast addresses have listeners on an attached link 👀
- Multicast-Address-Specific Query: used to learn if one particular multicast address has any listeners on an attached link 🔍
- the two subtypes are told apart by what's in the Multicast Address field, which is covered in section 3.6 🦋
- there are two subtypes of Query messages:
- Multicast Listener Report (
Type = decimal 131) 💜 - Multicast Listener Done (
Type = decimal 132) 🌸
in the rest of the doc, these message types are just called "Query", "Report", and "Done" 🧚
3.2. Code 🍓
set to zero by the sender and ignored by receivers 🙈
3.3. Checksum 🔥
it's the standard ICMPv6 checksum, and it covers the whole MLD message plus a "pseudo-header" of IPv6 header fields [ICMPv6,IPv6] 💖
3.4. Maximum Response Delay ⭐
this field only means something in Query messages 🧚 it tells you the maximum delay allowed before sending a responding Report, measured in milliseconds ⏰ in every other message it's set to zero by the sender and ignored by receivers 💅
tuning this value lets routers adjust the "leave latency" (the gap between the moment the last node on a link stops listening to a multicast address and the moment the routing protocol hears that nobody's listening to it anymore) 😭 check section 7.8 for that 🌈 it also changes how bursty MLD traffic is on a link, which is in section 7.3 ✨
3.5. Reserved 🌷
set to zero by the sender and ignored by receivers 🫶
3.6. Multicast Address 💜
in a Query message, this field is set to zero for a General Query, and set to a specific IPv6 multicast address for a Multicast-Address-Specific Query 🦋
in a Report or Done message, the field holds a specific IPv6 multicast address that the sender is listening to (Report) or has stopped listening to (Done) 🔥
3.7. Other fields 👑
here's how you work out the length of a received MLD message: take the IPv6 Payload Length value and subtract the length of any IPv6 extension headers between the IPv6 header and the MLD message 🧮 if that number is bigger than 24 octets, there are extra fields beyond the ones described above, probably for a future backwards-compatible version of MLD 🔮
an implementation of the MLD version in this document MUST NOT send an MLD message longer than 24 octets, and MUST ignore anything past the first 24 octets of a received MLD message 🚫 also, the MLD checksum MUST be computed over the entire MLD message, not just the first 24 octets 💀
4. Protocol Description ✨
Okay so this is where it gets juicy 🦋 Timer defaults are explained later in this doc, and timer and counter names always show up in [square brackets] 💅
Routers use MLD to figure out which multicast addresses have listeners on each of their attached links 👀 Each router keeps a list for every link, showing which multicast addresses have listeners there, plus a timer for each address. The router only needs to know that listeners exist for an address on a link. It does NOT need to know who the listeners are (like their unicast address) or even how many there are 🙈 literally none of its business, bestie.
For each attached link, a router picks one of its link-local unicast addresses on that link to use as the IPv6 Source Address in every MLD packet it sends on that link 🫶
For each interface where the router runs MLD, the router must set that interface to listen to all link-layer multicast addresses that IPv6 multicasts can generate 🔥 For example, an Ethernet-attached router must set its Ethernet address reception filter to accept all Ethernet multicast addresses that start with the hex value 3333 [IPv6-ETHER]. If an Ethernet interface can't filter that whole range, it must be set to accept ALL Ethernet multicast addresses so it still meets the MLD requirements ✨
A router may take on one of two roles on each attached link: Querier or Non-Querier 🎀 Normally there's only one Querier per link. Every router starts up as a Querier on each of its attached links 🌸 If a router hears a Query message whose IPv6 Source Address is numerically less than its own selected address for that link, it MUST become a Non-Querier on that link 😭 And if [Other Querier Present Interval] passes without that router hearing any Queries on that link from a router with a lower address than its own, it resumes the role of Querier on that link 🧚
A Querier periodically sends a General Query on its link every [Query Interval] 💜 This is how it asks for reports of all multicast addresses of interest on that link. On startup, a router SHOULD send [Startup Query Count] General Queries spaced closely together, [Startup Query Interval] apart, on all attached links. That way it finds out quickly and reliably which multicast listeners are on those links 🚀
General Queries go to the link-scope all-nodes multicast address FF02::1, with a Multicast Address field of 0 and a Maximum Response Delay of [Query Response Interval] 🍓
When a node gets a General Query, it sets a delay timer for each multicast address it's listening to on the interface the Query came in on 💅 This EXCLUDES the link-scope all-nodes address and any multicast addresses of scope 0 (reserved) or 1 (node-local). Each timer gets its own random value, picked from the range [0, Maximum Response Delay] using the highest clock granularity the node has, where Maximum Response Delay is the value in the Query packet 🌈 If a timer for an address is already running, it only gets reset to the new random value if the requested Maximum Response Delay is less than what's left on the running timer. And if the Query packet says the Maximum Response Delay is zero, every timer is effectively set to zero, so the timer-expiry action below happens right away ⭐
When a node gets a Multicast-Address-Specific Query, it checks whether it's listening to the queried Multicast Address on the interface where the Query arrived. If it is, it sets a delay timer for that address to a random value from the range [0, Maximum Response Delay], same as above 🦋 If a timer for that address is already running, the same reset rule applies: the new random value only replaces it if the requested Maximum Response Delay is less than the time left on the running timer. If the Maximum Response Delay in the Query packet is zero, that timer is effectively set to zero and the expiry action happens immediately 🫶
When a node's timer for a particular multicast address on a particular interface expires, the node sends a Report to that address through that interface 📣 The address being reported goes in both the IPv6 Destination Address field and the MLD Multicast Address field of the Report packet. The IPv6 Hop Limit of 1, along with the link-local IPv6 Source Address, keeps the packet from traveling past the link the reporting interface is attached to 🔒
If a node hears another node's Report for a multicast address on an interface while its own timer for that same address is running on that interface, it stops its timer and does NOT send a Report for that address 🤫 This is how duplicate reports get suppressed on the link. Main character energy for the node that stays quiet 🤐
When a router gets a Report from a link, there are two possibilities 💖 If the reported address isn't already in the router's list of multicast addresses with listeners on that link, the address gets added. Its timer is set to [Multicast Listener Interval], and the router's multicast routing component is told about it. If the reported address is already in the list, its timer is reset to [Multicast Listener Interval]. And when an address's timer expires, the router assumes there are no listeners for that address left on the link, so it deletes the address from the list and tells the multicast routing component it's gone 👋
When a node starts listening to a multicast address on an interface, it should immediately send an unsolicited Report for that address on that interface, in case it's the first listener on the link 🎉 To cover the chance that the initial Report gets lost or damaged, it is recommended that it be repeated once or twice after short delays [Unsolicited Report Interval]. (A simple way to do this is to send the initial Report, then act as if a Multicast-Address-Specific Query was received for that address, and set a timer accordingly 🧠)
When a node stops listening to a multicast address on an interface, it SHOULD send one Done message to the link-scope all-routers multicast address FF02::2. The Done message carries, in its Multicast Address field, the address the node is leaving 👋 If the node's most recent Report was suppressed because it heard another Report, it MAY send nothing at all, since there's a very high chance another listener for that address is still on the same link 💅 If this optimization is implemented, it MUST be able to be turned off, but it SHOULD default to on 🌸
When a router in Querier state gets a Done message from a link, it checks whether the Multicast Address in the message is in its list of addresses with listeners on that link. If it is, the Querier sends [Last Listener Query Count] Multicast-Address-Specific Queries to that multicast address, one every [Last Listener Query Interval] 🕵️♀️ These Queries have their Maximum Response Delay set to [Last Listener Query Interval]. If no Reports for the address come in from the link after the response delay of the last query has passed, the routers on the link assume the address has no listeners left there. The address gets deleted from the list and its disappearance is made known to the multicast routing component 💀 This process keeps going until it's resolved, meaning either a Report arrives or the last Multicast-Address-Specific Query goes out with no response, even if the link changes from Querier to Non-Querier along the way 🫠
Routers in Non-Querier state MUST ignore Done messages. No exceptions, bestie 🙅♀️
When a router in Non-Querier state gets a Multicast-Address-Specific Query, it checks its timer for the identified multicast address. If that timer value is greater than [Last Listener Query Count] times the Maximum Response Delay in the message, the router sets the address's timer to that latter value 🧚✨
5. Node State Transition Diagram ✨
okay bestie, let's talk about the state machine 🦋 it's where the node's behavior gets spelled out super formally, so it's giving "rules you can actually follow." for any single IPv6 multicast address on any single interface, a node can be in one of three states:
- "Non-Listener" state 🌸 the node is not listening to the address on the interface. no upper-layer protocol or application has asked to receive packets sent to that multicast address. this is the starting state for every multicast address on every interface, and it needs zero storage in the node. so cozy 🧚
- "Delaying Listener" state 💜 the node is listening to the address on the interface AND has a report delay timer running for that address.
- "Idle Listener" state 🎀 the node is listening to the address on the interface but does NOT have a report delay timer running for that address.
there are five big events that can trigger MLD state transitions 😭
- "start listening" 🍓 happens when the node starts listening to the address on the interface. it can only happen from the Non-Listener state.
- "stop listening" 🙈 happens when the node stops listening to the address on the interface. it can only happen from the Delaying Listener and Idle Listener states.
- "query received" 👀 happens when the node gets either a valid General Query message or a valid Multicast-Address-Specific Query message. to be valid, the Query message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. the Multicast Address field in the MLD message must contain either zero (a General Query) or a valid multicast address (a Multicast-Address-Specific Query). a General Query applies to all multicast addresses on the interface where the Query arrived. a Multicast-Address-Specific Query applies to just one multicast address on that same interface. and queries get ignored for addresses in the Non-Listener state 🙅♀️
- "report received" 📨 happens when the node gets a valid MLD Report message. to be valid, the Report message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. a Report only applies to the address in its Multicast Address field, on the interface where the Report arrived. it gets ignored in the Non-Listener or Idle Listener state.
- "timer expired" ⏰ happens when the report delay timer for the address on the interface runs out. it can only happen in the Delaying Listener state.
all the other events, like invalid MLD messages or MLD message types that aren't Query or Report, get ignored in every state. not the vibe 💀
there are seven possible actions the node can take in response to those events 💅
- "send report" 📣 for the address on the interface. the Report message gets sent to the address being reported.
- "send done" 👋 for the address on the interface. if the flag saying we were the last node to report is cleared, this action MAY be skipped. the Done message goes to the link-scope all-routers address (
FF02::2). - "set flag" 🚩 saying we were the last node to send a report for this address.
- "clear flag" 🧹 because we were NOT the last node to send a report for this address.
- "start timer" ⏱️ for the address on the interface, using a delay value picked uniformly from the interval
[0, Maximum Response Delay], where Maximum Response Delay is specified in the Query. if this is an unsolicited Report, the timer gets set to a delay value picked uniformly from the interval[0, [Unsolicited Report Interval] ]. - "reset timer" 🔄 for the address on the interface to a new value, using a delay value picked uniformly from the interval
[0, Maximum Response Delay], same as described in "start timer". - "stop timer" 🛑 for the address on the interface.
in all of the state diagrams below, every transition arc is labeled with the event that causes it, plus any actions taken during the transition in parentheses. the event is always what triggers the transition. even if the action is conditional, the transition still happens 🫶
________________
| |
| |
| |
| |
--------->| Non-Listener |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| stop listening | start listening | stop listening
| (stop timer, |(send report, | (send done if
| send done if | set flag, | flag set)
| flag set) | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying | (start timer) | Idle |
---->| Listener |------------------->| Listener |
| | | report received | |
| | | (stop timer, | |
| | | clear flag) | |
| |_________________|------------------->|_________________|
| query received | timer expired
| (reset timer if | (send report,
| Max Resp Delay | set flag)
| < current timer) |
-------------------the link-scope all-nodes address (FF02::1) is a special case 🌈 the node starts in Idle Listener state for that address on every interface, never moves to another state, and never sends a Report or Done for it. that one's just vibes 🧘♀️
MLD messages are never sent for multicast addresses whose scope is 0 (reserved) or 1 (node-local). no MLD for those, periodt 🚫
MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR-ARCH], except for the link-scope, all-nodes address (FF02::1). the one exception is the all-nodes address, which we already covered 💜
6. Router State Transition Diagram ✨
okay so router behavior gets the formal treatment here, with state transition diagrams 💅 A router may be in one of two states on any single attached link:
- "Querier", when this router is the one designated to send MLD Queries on this link 📢
- "Non-Querier", when some other router is designated to send MLD Queries on this link 🫶
Three events can make the router switch states 🔄:
- "query timer expired" happens when the timer for query transmission runs out. This event only matters when the router is in the Querier state ⏰
- "query received from a router with a lower IP address" happens when a valid MLD Query shows up from another router on the same link, with a lower IPv6 Source Address. To be valid, the Query MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum 🔍
- "other querier present timer expired" happens when the timer that tracks another querier with a lower IP address on the link runs out. This event only matters when the router is in the Non-Querier state 🌸
There are three actions the router can take in response to those events 🎀:
- "start general query timer" on the attached link, set to [Query Interval] ⏱️
- "start other querier present timer" on the attached link, set to [Other Querier Present Interval] 🕰️
- "send general query" on the attached link. The General Query goes to the link-scope all-nodes address
FF02::1, and has a Maximum Response Delay of [Query Response Interval] 📣
--------------------------------
_______|________ gen. query timer |
--------- | | expired |
| Initial |---------------->| | (send general query, |
--------- (send gen. q., | | start gen. q. timer) |
start initial gen. q. | |<----------------------
timer) | Querier |
| |
-----| |<---
| | | |
| |________________| |
query received from a | | other querier
router with a lower | | present timer
IP address | | expired
(start other querier | ________________ | (send gen. query,
present timer) | | | | start gen. q. timer)
| | | |
| | | |
---->| Non |----
| Querier |
| |
| |
---->| |----
| |________________| |
| query received from a |
| router with a lower IP |
| address |
| (start other querier |
| present timer) |
---------------------------A router starts in the Initial state on all attached links, and right away moves into the Querier state 🚀
Also, to keep track of which multicast addresses have listeners, a router may be in one of three states for any single IPv6 multicast address on any single attached link 👀:
- "No Listeners Present" state, when no nodes on the link have sent a Report for this multicast address. This is the starting state for all multicast addresses on the router, and it needs no storage in the router 🧹
- "Listeners Present" state, when there's a node on the link that has sent a Report for this multicast address 🙋♀️
- "Checking Listeners" state, when the router has received a Done message but hasn't heard a Report for that address yet 🤔
There are five significant events that can trigger router state transitions 💥:
- "report received" happens when the router gets a Report for the address from the link. To be valid, the Report MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum ✅
- "done received" happens when the router gets a Done message for the address from the link. To be valid, the Done message MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. This event only matters in the "Listeners Present" state and when the router is a Querier 👋
- "multicast-address-specific query received" happens when a router gets a Multicast-Address-Specific Query for the address from the link. To be valid, the Query MUST come from a link-local IPv6 Source Address, be at least 24 octets long, and have a correct MLD checksum. This event only matters in the "Listeners Present" state and when the router is a Non-Querier 🕵️♀️
- "timer expired" happens when the timer for a multicast address runs out. This event only matters in the "Listeners Present" or "Checking Listeners" state ⌛
- "retransmit timer expired" happens when the timer for retransmitting a Multicast-Address-Specific Query runs out. This event only matters in the "Checking Listeners" state 🔁
There are seven possible actions the router can take in response to those events 🛠️:
- "start timer" for the address on the link. This also resets the timer to its initial value of [Multicast Listener Interval] if the timer is already running ⏲️
- "start timer*" for the address on the link. This alternate action sets the timer to the minimum of its current value and either [Last Listener Query Interval] * [Last Listener Query Count], if this router is a Querier, or the Maximum Response Delay in the Query message * [Last Listener Query Count], if this router is a non-Querier 🧮
- "start retransmit timer" for the address on the link, set to [Last Listener Query Interval] 🔄
- "clear retransmit timer" for the address on the link 🧽
- "send multicast-address-specific query" for the address on the link. The Multicast-Address-Specific Query goes to the address being queried, and has a Maximum Response Delay of [Last Listener Query Interval] 📨
- "notify routing +" tells the multicast routing protocol, internally, that there are listeners to this address on this link 🗣️
- "notify routing -" tells the multicast routing protocol, internally, that there are no longer any listeners to this address on this link 🤫
These state diagrams apply per group, per link. There are two of them: one for routers in the Querier state and one for routers in the Non-Querier state. Switching between Querier and Non-Querier on a link is handled specially. Every group on that link that's in "No Listeners Present" or "Listeners Present" switches to the other diagram when the Querier/Non-Querier change happens. But any group in "Checking Listeners" keeps using its current diagram until it leaves "Checking Listeners". E.g., a router that starts as a Querier, gets a Done message for a group, and then gets a Query from a router with a lower address (which moves it to the Non-Querier state) keeps sending multicast-address-specific queries for that group until it either receives a Report or its timer expires. At that point it starts doing the Non-Querier actions for this group 🫧
The state transition diagram for a router in the Querier state looks like this 👑:
________________
| |
| |timer expired
timer expired| |(notify routing -,
(notify routing -)| No Listeners |clear rxmt tmr)
------->| Present |<---------
| | | |
| | | |
| |________________| | ---------------
| | | | rexmt timer |
| report received| | | expired |
| (notify routing +,| | | (send m-a-s |
| start timer)| | | query, |
__________|______ | ________|_|______ st rxmt |
| |<------------ | | tmr) |
| | | |<-------
| | report received | |
| | (start timer, | |
| | clear rxmt tmr) | |
| Listeners |<-------------------| Checking |
| Present | done received | Listeners |
| | (start timer*, | |
| | start rxmt timer, | |
| | send m-a-s query) | |
--->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------The state transition diagram for a router in the Non-Querier state is similar, but non-Queriers don't send any messages. They're only driven by what they receive 👂
________________
| |
| |
timer expired| |timer expired
(notify routing -)| No Listeners |(notify routing -)
--------->| Present |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| |report received |
| |(notify routing +,|
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | report received | |
| | (start timer) | |
| Listeners |<-------------------| Checking |
| Present | m-a-s query rec'd | Listeners |
| | (start timer*) | |
---->| |------------------->| |
| |_________________| |_________________|
| report received |
| (start timer) |
-----------------7. List of timers and default values ⏰🎀
Most of these timers are configurable 🛠️. If you use non-default settings, they MUST be consistent among all routers on a single link 🫶. Also, parentheses are used to group expressions, so the algebra stays clear 🧮.
7.1. Robustness Variable 🎀
okay so the Robustness Variable is basically the knob you turn when you expect a link to be lossy 🌸 if the link is kinda flaky, you can bump it up. MLD is robust to (Robustness Variable - 1) packet losses 🫶 The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2 💖
7.2. Query Interval 🦋
the Query Interval is the gap between General Queries that the Querier sends ✨ Default: 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. it's giving "chill out on the chatter" energy 🧚
7.3. Query Response Interval 💅
this is the Maximum Response Delay inserted into the periodic General Queries 🍓 Default: 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, as node 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]. no cap, this is the one that keeps the replies from all showing up at once 😭
7.4. Multicast Listener Interval 👑
the Multicast Listener Interval is how long has to pass before a router decides there are no more listeners for an address on a link 💀 This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).
7.5. Other Querier Present Interval 🌈
this one is how long a router waits before it decides the other router that was supposed to be the querier is no longer around 🙈 This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query Response Interval). periodt 💜
7.6. Startup Query Interval ⭐
the Startup Query Interval is the gap between General Queries a Querier sends when it first starts up 🎀 Default: 1/4 the Query Interval.
7.7. Startup Query Count 🌸
the Startup Query Count is how many Queries get sent out on startup, spaced apart by the Startup Query Interval 🫶 Default: the Robustness Variable.
7.8. Last Listener Query Interval 🔥
the Last Listener Query Interval is the Maximum Response Delay inserted into Multicast-Address-Specific Queries sent in response to Done messages, and it's also the time between Multicast-Address-Specific Query messages ✨ Default: 1000 (1 second)
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 an address. lowkey the main knob for how fast you notice someone left 👀
7.9. Last Listener Query Count 🦋
the Last Listener Query Count is how many Multicast-Address-Specific Queries get sent before the router assumes there are no remaining listeners for an address on a link 💖 Default: the Robustness Variable.
7.10. Unsolicited Report Interval 🧚
the Unsolicited Report Interval is the time between repeats of a node's first report saying it's interested in a multicast address 💅 Default: 10 seconds.
8. Message Destinations 🍓
this info lives elsewhere in the doc too, but we summarize it here for convenience 🫶
Message Type IPv6 Destination Address
------------ ------------------------
General Query link-scope all-nodes (FF02::1)
Multicast-Address-Specific Query the multicast address being queried
Report the multicast address being reported
Done link-scope all-routers (FF02::2)9. Security Considerations 🔥💀
okay this section is serious, bestie 😭 We consider the ramifications of a forged message of each type. Note that the requirement that nodes verify that the IPv6 Source Address of all received MLD messages is a link-local address defends them from acting on forged MLD messages originated off-link, so we discuss only the effects of on-link forgery.
Query message:
A forged Query message from a machine with a lower IP 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 Done messages, traffic might flow to addresses with no listeners for up to [Multicast Listener Interval]. A forged Query message sent to an address with listeners will cause one or more nodes that are listeners to that address to send a Report. This causes a small amount of extra traffic on the link, but causes no protocol problems.
Report message:
A forged Report message may cause routers to think there are listeners for an address present on a link when there are not. However, since listening to a multicast address is generally an unprivileged operation, a local user may trivially gain the same result without forging any messages.
Done message:
A forged Done message will cause the Querier to send out Multicast-Address-Specific Queries for the address in question. This causes extra processing on each router and on each of the address's listeners, and extra packets on the link, but cannot cause loss of desired traffic.
10. Acknowledgments 🫶
MLD was derived from IGMPv2 [IGMPv2], which was designed by Rosen Sharma and Steve Deering and documented by Bill Fenner. thank you to these legends 👑✨
11. References 📚
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[IGMPv2] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December, 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RTR-ALERT] Partridge, C. and A. Jackson, "IPv6 Router Alert
Option", RFC 2711, October 1999.
[STD-PROC] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.12. Authors' Addresses 🎀
Stephen E. Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 527 8213
EMail: deering@cisco.com
William C. Fenner
AT&T Research
75 Willow Road
Menlo Park, CA 94025
USA
Phone: +1 650 867 6073
EMail: fenner@research.att.com
Brian Haberman
IBM Corporation
800 Park Office Drive
Research Triangle Park, NC 27709
USA
Phone: +1 919 254 2673
EMail: haberman@raleigh.ibm.com13. Full Copyright Statement 🌈
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the
Internet Society.📦 where this page comes from
- ietf: rfc2710 1999-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms