首先，有一点背景：我的理解是，IGMP（和它的IPv6表兄弟，MLD）的目的是通过确保多播数据包仅传输到实际上对这些数据包感兴趣的目的地来避免浪费带宽。 这个逻辑是一个更旧/更简单的交换机行为的改进，即将传入的多播数据包广播到所有其他端口，而不pipe它是什么，并将其留给连接的设备丢弃他们不感兴趣的多播数据包。
IGMP和MLD通过让交换机维护一个表来跟踪哪些连接的设备当前join了哪些组播组，并且当组播组进入时，交换机仅将其转发到join到由数据包的目的地址。 到现在为止还挺好。
但根据我的同事的说法，有一个奇怪的特例：如果没有设备join特定的多播组，那么交换机必须将任何传入的多播数据包转发到所有端口 （从技术上讲，所有端口都连接了IGMP路由器，但他说这是相同的事情，因为大多数交换机不知道哪个端口连接了IGMP路由器，因此会回落到所有端口。
这对我来说似乎是非常违反直觉 – 为什么一个algorithm的目的是为了避免组播泛滥故意在所有没有兴趣接收组播数据的场景中泛滥？ 这样做是为了确保向后兼容那些希望接收从未请求的多播数据包的多播实现？ 如果没有，这是什么动机？ 这似乎显着降低了algorithm的有用性。
作为参考，我的同事指出的准则在RFC 4541的第2.1.2节中：
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. 我觉得下面的段落可以解释动机，但我不明白：
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.
也就是说，为什么洪泛未注册的stream防止v3主机接收他们的stream量？ （不会v3主机知道join他们想要接收stream量的任何组）？而在另一种情况下，不会因洪泛造成的stream量损失与由于stream量不stream失而造成的stream量损失同样严重？
该问题在RFC4541中引用为[IETF56]的会议报告 中进行了描述 ：
问题 – 路由器< – > IGMPv2监听切换< – >具有IGMPv3function的主机
路由器发送IGMPv3查询，告诉主机使用IGMPv3主机发送IGMPv3报告
那么会发生什么？
开关做这3个之一：
- 不转发报告
- 转发报告，但不转发数据
- 转发报告和数据，但没有查询，数据超时
结果 – 将路由器或主机（以较上者为准）升级到IGMPv3时，组播会中断。
在案例1中，未注册的数据stream泛滥成为问题（旧的交换机不转发IGMPv3报告时），情况2和3（当IGMPv3报告将通过旧的交换机时）不应该有所作为。
至于哪个问题（交通量减less或洪水过度）更严重，这很大程度上取决于具体情况。 在某些情况下，洪泛可能会更糟，因为与丢弃的stream量不同，在testing期间可能不会马上注意到洪stream，并且在稍后的时间stream量增加足以使泛滥成为问题，破碎的configuration可能被广泛部署，需要很多的工作来解决它。
首先，有一点背景：我的理解是，IGMP（和它的IPv6表兄弟，MLD）的目的是通过确保多播数据包仅传输到实际上对这些数据包感兴趣的目的地来避免浪费带宽。 这个逻辑是一个更旧/更简单的交换机行为的改进，即将传入的多播数据包广播到所有其他端口，而不pipe它是什么，并将其留给连接的设备丢弃他们不感兴趣的多播数据包。
IGMP / MLD的目的是为了让路由器知道哪个组播组已经被任何本地连接的主机join（他们甚至不关心哪一个组播组被join，因为那个时候是共享的媒体）。 然后，路由器将这些信息提供给一个组播路由algorithm，该路由algorithm将在路由器之间交换这个信息来build立组播路由表 这样，连接到路由器A的机器X可以将组播stream量发送到组G，并且连接到另一路由器B的机器Y将在接入G时接收它。
IGMP是在交换机出现之前发明的，期望主机和路由器之间的媒体可以共享。 IGMP甚至为共享媒体进行了优化，因为它通过让只有一个主机只发送一次成员资格报告（因为所有主机都会从该多播组接收stream量）提供优化，以防万一许多主机对同一组感兴趣。
这对我来说似乎是非常违反直觉 – 为什么一个algorithm的目的是为了避免组播泛滥故意在所有没有兴趣接收组播数据的场景中泛滥？
IGMP / MLD路由器总是对任何组播数据感兴趣。 毕竟这是他们的angular色。 如果主机向组X发送组播数据，则路由器必须将数据包转发到至less有一台主机join组X的所有其他路由器。交换机完全不知道这种情况，所以如果它不转发来自主机的未知stream量到路由器，它只会打破多播路由。
至于为什么转发未注册的数据包到所有的端口应该启用，这可能是技术上的原因，但我个人认为交换机相比集线器是一个优化。 我希望他们在默认configuration下优化事物而不会破坏它们。 如果交换机收到什么是非法或意外的数据包，我希望它转发它，因为那个数据包可能是由于某种原因发送的。 我想要的最后一件事是我的交换机丢弃数据包。
Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host
这里我认为标准解释说，
Igmpv3未注册的数据包发送到监听交换机（IGMPv2），它不应该识别Igmp数据包，然后切换Igmp数据包，然后Igmpv3组播数据包不会stream向Igmpv3主机。