IGMPv2 didn't have any glaring problems,
but IGMPv3 managed to completely change the multicast landscape.
Let's learn how.
Here's the lineup for this module.
IGMPv2 didn't have any major issues, but everything can be improved.
I'll explain the purpose behind IGMPv3.
IGMPv3 supports an entirely new flavor of multicast
called source-specific multicast, or SSM.
That's a big deal, and I'll explain why.
As I always do,
I'll demonstrate what I teach on the live network with plenty of debugs.
Finally, IGMPv3 introduces even more packet types,
and we will leave no stone unturned.
Unlike IGMPv1, IGMPv2 didn't have any killer problems.
One issue I see is the lack of batching for IGMP membership reports.
Suppose a router sends its IGMPv2 general query as usual.
If a client wants to join 100 multicast groups,
which is quite realistic for a video collection and archival platform,
it would need to issue 100 IGMP membership reports.
This chatter clogs up the network, and with modern carrier Ethernet technologies,
this could be eating up expensive WAN bandwidth.
Just as IGMPv2 introduced the concept of the leave
message to overcome shortfalls with IGMPv1,
IGMPv3 seeks to solve a larger multicast design issue.
In a previous module, I explained the concept of a PIM rendezvous point, or RP.
Its job is to discover sources and link them up with receivers.
What happens when many organizations have their own RPs
and all want to exchange multicast?
Now you've got to connect the RPs somehow.
In IPv4, a protocol known as Multicast Source Discovery Protocol,
or MSDP, can do this.
It's far beyond the scope of this course, though.
This is a complex design that has some serious
technical and operational limitations, not to mention security risks.
Is there some way we can receive multicast in such a manner
that sources are known ahead of time, obviating the need for RPs?
Now that we understand the problems,
I'll focus on the three best IGMPv3 improvements.
To solve IGMPv2's minor problem,
IGMPv3 allows a single membership report to carry multiple multicast groups.
Each item in this packet is called a group record and contains the group
address plus some additional data soon to be discussed.
IGMPv3's biggest improvement, the introduction of SSM,
allows clients to receive multicast directly from sources without the complex
signaling required by rendezvous points for source discovery.
I mentioned group records earlier.
One of the key metadata fields is the group mode,
which determines how to interpret the source list.
What's the source list?
I'll explain shortly,
but just know that group modes give us granular control over how
a multicast group should behave in a network.
First,
I'll explain membership report batching by illustrating
the basic IGMPv3 query and join process.
The IGMPv3 speaking router issues a general query,
which is quite similar to IGMPv1 and IGMPv2.
The message itself contains some extra goodies we will
explain in our upcoming packet analysis.
In response, the client issues a single IGMPv3 membership report.
The destination address becomes 224.0 .0 .22,
a new link local address specific to IGMPv3.
The contents of the packet contain individual group records.
Each record contains the group to join plus any other relevant information.
What is that other information, you ask?
That's a perfect segue to the remaining 2 IGMPv3 enhancements.
How does IGMPv3 solve this ugly mess?
First, the client just has to know the source ahead of time.
Many applications can handle this, and with domain name system,
or DNS, to help with host name resolution,
it's not terribly difficult.
The client just has to say I want video from the orange server.
No more need for an RP to figure out the sources for the client,
since the client already knew.
Multicast can simply flow from source to destination along the
shortest path without a litany of RP interconnections.
I've proposed this exact solution in past designs and
personally seen it implemented with great success. By convention, SSM groups in IPv4 use the range 232.0 .0 .0 /8.