Let's talk about MLD for a minute.
The purpose of MLD is identical to IGMP.
It's a communications protocol between multicast clients and
routers for receiving IPv6 multicast traffic.
In terms of versions, MLDv1 is operationally equivalent to IGMPv2,
and MLDv2 is operationally equivalent to IGMPv3.
Keep this in mind, since it'll save a lot of time when learning MLD.
Last, MLD operates exclusively using link local unicast addresses,
or link local scoped multicast addresses.
I'll be using simple and short addresses in this demonstration.
Let's jump right into a basic MLDv1 flow diagram.
The multicast router sends an MLDv1 general query to the all
hosts link local multicast address of FF02::1.
The max response time is increased from 2.5 seconds
in IGMPv2 to 10 seconds in MLDv1,
but that's a minor detail we'll explore in the packet capture.
Remember, the general query asks the question, who wants multicast?
The client, in this case, wants to receive traffic on two groups.
I felt like a scope of 8, which is organization local scope,
made sense for this scenario.
Multicast is flowing between multiple sites and
thus is local to the organization, but not globally accessible.
The groups are FF08::1 and FF08::2.
So far, no new concepts.
How does the leave process work?
It's identical to IGMPv2 with some minor naming changes.
First, the client says I don't want multicast on group FF08::1 anymore.
It sends a done group message to FF02::2,
the all multicast routers link local address,
and carries the group in question within the message body.
The router sends back a group-specific query asking
who still wants traffic on FF08::1.
Those who want multicast must send another MLD report.
If no client does,
the router stops sending multicast onto the LAN after waiting only 1 second. Just like IGMPv2, right?