Being equivalent to IGMPv3, MLD supports some key improvements.
I'll briefly review each.
MLDv2 allows a single membership report to carry multiple multicast groups.
Each group record represents a multicast group of interest.
SSM is a key improvement that solves the interdomain multicast problem,
plus other less critical design issues in the IPv6 multicast world.
MLDv2 carries over include and exclude modes from IGMPv3,
plus a few more, making it tunable for any environment.
Next, I'll provide an overview of the basic MLDv2 query and join operation.
Our router issues an MLDv2 general query,
which is conceptually identical to MLDv1.
Like IGMPv3, the message has some extra information we'll explore soon.
The client sends a single MLDv2 membership report,
carrying group records for several multicast groups of interest.
The destination address becomes FF02::16,
a new link local address specific to MLDv2 and the source
remains the client's link local unicast address.
Some of these groups could be SSM, which helps solve our big multicast problem.
Speaking of SSM,
I'll quickly review how it works to solve inter-domain multicast in IPv6.
Assuming the client knows the multicast source ahead of time,
it can notify its connected router via MLDv2 that it only wants
multicast from the orange server across the network.
If the client doesn't know the exact IPv6 source address,
it can use DNS resolution,
a service available in almost all organizations to resolve a host name,
something like video.wiredbrain .net, or whatever it happens to be.
Once the multicast routing is built between receiver and source,
traffic flows along the shortest path without any
arduous regionally-aligned scopes.
Conventionally, the SSM range for IPv6 multicast is FF3x::/32, where x is the scope value.