We've already discussed the various IGMPv3 improvements,
but let's explore how it works behind the scenes.
First, the general membership query.
Source and destination addresses remain unchanged from both IGMPv1 and IGMPv2,
so let's move past that.
Continuing to recycle the packet type,
IGMPv3 uses 11 in hex or 17 in decimal as the query type.
The maximum response time serves the same purpose as IGMPv2 and
also uses the same default value of 2.5 seconds.
The multicast address remains 0.0 .0 .0 as is true for all
versions of general membership queries.
This intuitively makes sense,
since the general question does not specify any multicast groups.
The next few rows contain some extra information added by IGMPv3.
I'll quickly cover each one.
The S bit signals whether or not other routers on the segment
receiving this query should surprise the actions they'd
normally take when receiving a query.
Typically the reception of a query means lowering the state
timers to the Less Member Query Time, or LQMT.
Setting this flag omits that update.
This is a minor technical detail and is a small optimization.
The QRV represents the Querier Robustness Variable.
Although the robustness variable was introduced in IGMPv2,
it was used behind the scenes to measure the reliability of the transport.
If the network is lossy,
the robustness variable can be increased to
overcome it with extra IGMP messaging.
In IGMPv3, this variable is signaled explicitly and 2 is the default value.
The QQIC represents the Querier's Query Interval Code.
If less than 128, it represents the router's query interval in seconds.
If 128 or greater,
it's a complex mathematical formula that breaks the 8-bit field into many
fields which can represent intervals larger than 256.
In this case, the query interval is 60 seconds.
The number of sources represents the number of IP address
multicast sources for a given multicast group.
In general queries, this will always be 0.
Let's explore the IGMPv3 membership report.
This one is very different than IGMPv1 and IGMPv2.
Immediately we see the destination IP address is a new link
local multicast group of 224.0 .0 .22.
This is specific to IGMPv3 and is used to target any IGMPv3 speaking routers.
The membership report itself uses a new type of 22 in hex or 34 in decimal.
Since the concept of max response time is meaningless in a membership report,
IGMPv3 just zeros out the code.
At last, that third capability.
A single IGMPv3 report can contain multiple group records.
Each group record contains the mode, typically either exclude or include.
Exclude means I don't want multicast from these sources.
In other words, the group record is excluding any specified sources.
When the number of sources is 0,
that means I do not want multicast from no sources on this group,
a tricky double negative which implies I do want
multicast from any sources on this group.
This particular group record for 239.2 .2 .2 is an Any Source Multicast,
or ASM record.
The next group record is quite different.
Its mode is include, which means I only want multicast from these sources.
Given a nonzero value for the number of sources,
we should see a list of source addresses.
This particular record is specifically asking for
multicast on group 232.3 .3 .3,
but only coming from sources 10.2 .5 .5 and 10.2 .5 .6.
To save time, I won't dig into the third group record,
since it's a basic ASM record using exclude mode for group 239.1 .1 .1. It is similar to the ASM record for 239.2 .2 .2.