Let's jump into our final flavor of host to router
multicast signaling with MLDv2.
We will begin with the MLDv2 general query,
which is equivalent to an IGMPv3 general query in the IPv4 world.
The source address is still the router link local address,
and the destination is still the all hosts link local multicast group.
Nothing new there.
The packet uses type 130 code 0, just like the MLDv1 query,
indicating that the query message has been recycled.
Because this is a general query, the multicast address is still ::,
the unspecified address representing all 0's,
as no specific group is being targeted.
Towards the bottom of the packet,
we see the same minor option present in IGMPv3 queries.
I don't want to bore you reciting the exact same
thing I said while describing IGMPv3,
so I suggest referencing that module for a refresher.
The number of sources represents the number of IP
addresses for a given multicast group.
In general queries, this will always be 0.
Let's explore the MLDv2 report message.
We can immediately see some differences without digging too deep.
First, note that the source link local address is FE80::4,
the Globomantics client.
That's not new, but the destination address is.
This is quite different than MLDv1,
as it is a new link local multicast group of FF02::16.
Much like 224.0 .0 .22 for IGMPv3,
this specific IPv6 address is used to carry a group of multicast
records in a single packet with a common destination.
The designers of MLDv2 even retained the value of the last byte in the address,
since 16 in hex is the same as 22 in decimal.
Similar to the change between IGMPv2 and IGMPv3 reports,
this new MLDv2 report uses a new packet type of 143.
The old MLDv1 report of type 131 cannot be recycled,
since the entire format must change to accommodate a
variable length list of group records.
The router needs to know how many group records are included,
so this field is provided explicitly.
Here we see that four group records are included,
which seems odd, since only three separate groups were joined.
What explains the discrepancy?
Let's make our way down the list.
The first item answers our question.
We see that pesky link local solicited node multicast
address here as a group record.
Although not always technically necessary,
it does provide an explicit notification that this node
does want multicast on that group, despite it being link local.
Let's move onto one of the organization local scoped groups.
The type of this record is exclude,
which is commonly done for any source multicast joins.
Remember,
exclude mode means that any sources listed in the record are sources from
which the client does not want to receive multicast.
An empty source list in an exclude type of record implies that
the client wants traffic from any source.
I won't expand the record for FF08::2,
since it's virtually identical to the previous ASM record with the exception
of a different multicast group that we can already see.
The final record is interesting,
since it represents a source-specific multicast record.
The IPv6 multicast group of FF38::3 is SSM,
given its membership in the FF3x block.
The record type of include means that any sources listed in
the record should be identified as sources the client wants
to receive multicast from.
This record shows two sources.
We expect to see these sources explicitly listed later in the record.
Moving down, there are two unique local addresses,
which represent the Wired Brain Coffee video sources.
If any other source, for example, FC00:10:2:5::7,
were to send traffic to group FF38::3,
the Globomantics client would not receive it, as it did not express interest in traffic from that source.