Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches
RFC 4541

Document Type RFC - Informational (May 2006; Errata)
Authors Frank Solensky  , Morten Christensen  , Karen Kimball 
Last updated 2020-01-21
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized with errata bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4541 (Informational)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Margaret Cullen
Send notices to (None)
Network Working Group                                     M. Christensen
Request for Comments: 4541                               Thrane & Thrane
Category: Informational                                       K. Kimball
                                                             F. Solensky
                                                                May 2006

      Considerations for Internet Group Management Protocol (IGMP)
       and Multicast Listener Discovery (MLD) Snooping Switches

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This memo describes the recommendations for Internet Group Management
   Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping
   switches.  These are based on best current practices for IGMPv2, with
   further considerations for IGMPv3- and MLDv2-snooping.  Additional
   areas of relevance, such as link layer topology changes and
   Ethernet-specific encapsulation issues, are also considered.

1.  Introduction

   The IEEE bridge standard [BRIDGE] specifies how LAN packets are
   'bridged', or as is more commonly used today, switched between LAN
   segments.  The operation of a switch with respect to multicast
   packets can be summarized as follows.  When processing a packet whose
   destination MAC address is a multicast address, the switch will
   forward a copy of the packet into each of the remaining network
   interfaces that are in the forwarding state in accordance with
   [BRIDGE].  The spanning tree algorithm ensures that the application
   of this rule at every switch in the network will make the packet
   accessible to all nodes connected to the network.

   This behaviour works well for broadcast packets that are intended to
   be seen or processed by all connected nodes.  In the case of
   multicast packets, however, this approach could lead to less
   efficient use of network bandwidth, particularly when the packet is

Christensen, et al.          Informational                      [Page 1]
RFC 4541     IGMP and MLD Snooping Switches Considerations      May 2006

   intended for only a small number of nodes.  Packets will be flooded
   into network segments where no node has any interest in receiving the
   packet.  While nodes will rarely incur any processing overhead to
   filter packets addressed to unrequested group addresses, they are
   unable to transmit new packets onto the shared media for the period
   of time that the multicast packet is flooded.  In general,
   significant bandwidth can be wasted by flooding.

   In recent years, a number of commercial vendors have introduced
   products described as "IGMP snooping switches" to the market.  These
   devices do not adhere to the conceptual model that provides the
   strict separation of functionality between different communications
   layers in the ISO model, and instead utilize information in the upper
   level protocol headers as factors to be considered in processing at
   the lower levels.  This is analogous to the manner in which a router
   can act as a firewall by looking into the transport protocol's header
   before allowing a packet to be forwarded to its destination address.

   In the case of IP multicast traffic, an IGMP snooping switch provides
   the benefit of conserving bandwidth on those segments of the network
   where no node has expressed interest in receiving packets addressed
   to the group address.  This is in contrast to normal switch behavior
   where multicast traffic is typically forwarded on all interfaces.

   Many switch datasheets state support for IGMP snooping, but no
   recommendations for this exist today.  It is the authors' hope that
   the information presented in this document will supply this

   The recommendations presented here are based on the following
   information sources: The IGMP specifications [RFC1112], [RFC2236] and
   [IGMPv3], vendor-supplied technical documents [CISCO], bug reports
   [MSOFT], discussions with people involved in the design of IGMP
   snooping switches, MAGMA mailing list discussions, and on replies by
   switch vendors to an implementation questionnaire.

   Interoperability issues that arise between different versions of IGMP
   are not the focus of this document.  Interested readers are directed
   to [IGMPv3] for a thorough description of problem areas.

   The suggestions in this document are based on IGMP, which applies
   only to IPv4.  For IPv6, Multicast Listener Discovery [MLD] must be
   used instead.  Because MLD is based on IGMP, we do not repeat the
   entire description and recommendations for MLD snooping switches.
Show full document text