First, we'll explore how MLDv1 works at a packet level.
The MLD general query message is a good place to start.
The source address is the link local address of fe80::1,
the Globomantics R1 router.
The destination address of ff02::1 is the all hosts link local multicast group.
This asks who wants multicast?
Quickly note that these packets are ICMPv6 and not a whole new IP protocol,
as was true for IGMP with IPv4.
The MLD query uses type 130 and the code is always set to 0.
In the ICMP protocol deep dive course,
we learned about many other ICMPv6 message types,
several of which had behavior-specific codes.
In MLD, each message uses a different type with a code of 0.
MLD also supports the concept of a max response time,
except to millisecond granularity.
Ten thousand milliseconds is equal to 10 seconds,
4 times larger than the 2.5 seconds offered by IGMPv2 by default.
These timers are tunable, but that's not terribly important right now.
Finally,
the IPv6 multicast address is set to all 0s as represented
by the unspecified address written as ::.
Now let's see how IPv6 multicast clients respond to the
general query using the MLDv1 report.
The source address is the link local IPv6 address of the client and the
destination address is the multicast group being joined.
FF08::2 is 1 of the organization local groups that
the Globomantics client has joined,
presumably because it wants to receive Wired Brain Coffee
video feeds on that specific group.
This report message uses type 131 code 0,
which is different than the type 130 code 0
arrangement seen with the query message.
This differentiates the report from the query,
and as we will soon see, from the done message as well.
The max response time is always set to 0 in MLDv1 report messages,
since the field has no meaning outside of a query.
This is similar to IGMPv2.
For packet formatting consistency between MLD packets, the field is retained.
The MLDv1 report message contains exactly one multicast address
representing the group that the client wants to join.
This address always matches the IPv6 destination multicast address.
It is worth taking a moment to mention that many MLD implementations
will issue MLD report messages for link local groups.
Some IPv4 stacks do with IGMP also, though it is not required.
This particular MLD report message is issued by the
Globomantics client at fe80::4,
but destined to a strange-looking link local multicast group.
This is the solicited node multicast address local to the Globomantics client.
One of its key purposes is handling ICMPv6 duplicate address detection, or DAD.
It also plays a role in other functions of IPv6 neighbor discovery, or ND.
I cover these details in my ICMP deep dive,
but I would be remiss if I didn't at least mention it briefly here.
Quickly looking at the internals of the packet,
we see it's just a regular MLD report message without any fancy settings.
By requesting multicast for this solicited node multicast address,
the Globomantics client is effectively saying send me any
traffic on this group for ND activity.
When we visit MLD version 2, we will see this address again, although I won't dig into exactly how it works.