You might be thinking, hey, what about the third capability, the group mode?
This is best explained via demonstration and packet capture, so let's dive in.
PowerPoint just doesn't do it justice.
Let's revisit the IGMP conversation with version 3.
I'll start on the Globomantics client, since I've added a third group to the mix.
The new group is 232.3 .3 .3, which is a source-specific multicast group,
and the client wants to receive traffic from 2 sources,
10.2 .5 .5 and 10.2 .5 .6.
Note that the latter address is a fictitious server,
but for demonstration purposes showing multiple sources is useful.
When the router issues its IGMPv3 general query,
this client should respond with a single IGMPv3
membership report with 3 group records.
Two are ASM groups and one is an SSM group with two sources.
Let's swing over to the router.
I'll enable IGMP debugging for all groups just to show how
a single message carries so much data.
Let's wait for the query.
Okay, that's a lot.
First, we see the IGMPv3 query sent towards the client LAN segment.
The client sends back a single membership report with three group records.
It contained groups 239.1 .1 .1, 239.2 .2 .2, and 232.3 .3 .3.
The multicast routing table was properly updated for all entries, too.
Let's quickly verify that the router installed these
IGMP groups in its state table.
I'll use a more verbose command so we can see the
different group modes and SSM sources.
Again, lots of output.
The first two groups operate in EXCLUDE mode with 0 sources,
effectively saying I want multicast on these groups from any source.
The final group operates in INCLUDE mode with two sources listed below.
This is the client saying I want multicast on this
group only from these two sources.
Let's test the leave functionality.
I'll jump over to the client and remove 1 of the SSM
sources from the 232.3 .3 .3 group.
This is a unique capability of IGMPv3 since IGMPv2
and earlier don't support SSM.
I'll enable debugging on R1 first so we can track the chatter.
Switching back to R1, we see an IGMPv3 report message with 1 group record.
Maybe you expected a leave message here.
I won't detail the specifics of how IGMPv3 handles leave messages,
as this topic is better discussed during the packet analysis.
Let's continue.
The record mentions group 232.3 .3 .3 and uses mode 6.
The packet capture helps explain, but mode 6 basically means block old sources.
In other words, the client is saying I still want to listen on 232.3 .3 .3,
but not from 10.2 .5 .5 anymore.
Like IGMPv2, the router issues a group-specific query for 232.3 .3 .3,
but extends it to include a source address also.
Thus,
it is a source and group-specific query asking does anyone else
want group 232.3 .3 .3 from source 10.2 .5 .5?
Since no clients reply,
R1 purges this source group state entry from its multicast routing table.
I hope this demonstration illustrates the power of IGMPv3 and the level of granularity network operators can achieve while using it.