First, a little background: My understanding is that the purpose of IGMP (and its IPv6 cousin, MLD) is to avoid wasted bandwidth by ensuring that multicast packets only get transmitted to destinations that are actually interested in those packets. This logic is a refinement of an older/simpler switch behavior, which was to broadcast incoming multicast packets to all other ports no matter what, and leave it up to the connected devices to drop multicast packets that they weren't interested in.
IGMP and MLD do this by having the switch maintain a table that tracks which connected devices are currently joined to which multicast groups, and when a multicast packet comes in, the switch forwards it only to the ports that are joined to the group indicated by the packet's destination address. So far, so good.
But according to my co-worker, there is an odd special case: If no devices have joined a particular multicast group, then the switch must forward any incoming multicast packets to all ports (well, technically to all ports with an IGMP router attached, but he says it amounts to the same thing, since most switches don't know which ports have an IGMP router attached and so will fall back to flooding to all ports).
This seems very counterintuitive to me — why would an algorithm whose entire purpose is to avoid multicast flooding deliberately flood to all ports in the a scenario where nobody is interested in receiving the multicast data? Is this done to ensure backwards compatibility with broken multicast implementations that expect to receive multicast packets they never requested? If not, what is the motivation for this? It seems like it significantly reduces the usefulness of the algorithm.
For reference, the guidelines my co-worker points to are in section 2.1.2 of RFC 4541:
3) An unregistered packet is defined as an IPv4 multicast packet with
a destination address which does not match any of the groups
announced in earlier IGMP Membership Reports.
If a switch receives an unregistered packet, it must forward that
packet on all ports to which an IGMP router is attached. A switch
may default to forwarding unregistered packets on all ports.
Switches that do not forward unregistered packets to all ports
must include a configuration option to force the flooding of
unregistered packets on specified ports.
I think the following paragraph may explain the motivation, but I don't understand it:
In an environment where IGMPv3 hosts are mixed with snooping
switches that do not yet support IGMPv3, the switch's failure to
flood unregistered streams could prevent v3 hosts from receiving
their traffic. Alternatively, in environments where the snooping
switch supports all of the IGMP versions that are present,
flooding unregistered streams may cause IGMP hosts to be
overwhelmed by multicast traffic, even to the point of not
receiving Queries and failing to issue new membership reports for
their own groups.
i.e. why would failure to flood unregistered streams prevent v3 hosts from receiving their traffic? (wouldn't v3 hosts know to join any groups they want to receive traffic on?) And in the alternative scenario, wouldn't traffic lossage due to flooding be just as bad a problem as traffic loss due not flooding?
Best Answer
The problem is described in the meeting report which is referenced as [IETF56] in RFC4541:
Flooding unregistered streams works around the problem in the case 1 (when the old switch does not forward IGMPv3 reports), and should not make a difference in cases 2 and 3 (when IGMPv3 reports will be passed through the old switch).
As for which problem (dropped traffic or excessive flood) is worse, this highly depends on a particular situation. In some cases flooding may be worse because, unlike dropped traffic, it might not be noticed immediately during testing, and when at some later time the traffic volume increases enough to make flooding a problem, the broken configuration may be widely deployed, needing a lot of work to fix it.