There are three versions of IGMP, as defined by Request for Comments (RFC) documents of the Internet Engineering Task Force
(IETF). IGMPv2 improves over IGMPv1 by adding the ability for a host to signal desire to leave a multicast group and IGMPv3
improves over IGMPv2 mainly by adding the ability to listen to multicast originating from a set of source IP addresses only.
Table 1. IGMP Versions
Provides the basic query-response mechanism that allows the multicast device to determine which multicast groups are active
and other processes that enable hosts to join and leave a multicast group. RFC 1112 defines the IGMPv1 host extensions for
Extends IGMP, allowing such capabilities as the IGMP leave process, group-specific queries, and an explicit maximum response
time field. IGMPv2 also adds the capability for devices to elect the IGMP querier without dependence on the multicast protocol
to perform this task. RFC 2236 defines IGMPv2.
Provides for source filtering, which enables a multicast receiver host to signal to a device which groups it wants to receive
multicast traffic from, and from which sources this traffic is expected. In addition, IGMPv3 supports the link local address
184.108.40.206, which is the destination IP address for IGMPv3 membership reports; all IGMPv3-capable multicast devices must listen
to this address. RFC 3376 defines IGMPv3.
By default, enabling a PIM on an interface enables IGMPv2 on that device. IGMPv2 was designed to be as backward compatible
with IGMPv1 as possible. To accomplish this backward compatibility, RFC 2236 defined special interoperability rules. If your
network contains legacy IGMPv1 hosts, you should be familiar with these operability rules. For more information about IGMPv1
and IGMPv2 interoperability, see RFC 2236, Internet Group Management Protocol, Version 2 .
Devices That Run IGMPv1
IGMPv1 devices send IGMP queries to the “all-hosts” multicast address of 220.127.116.11 to solicit multicast groups with active
multicast receivers. The multicast receivers also can send IGMP reports to the device to notify it that they are interested
in receiving a particular multicast stream. Hosts can send the report asynchronously or in response to the IGMP queries sent
by the device. If more than one multicast receiver exists for the same multicast group, only one of these hosts sends an IGMP
report message; the other hosts suppress their report messages.
In IGMPv1, there is no election of an IGMP querier. If more than one device on the segment exists, all the devices send periodic
IGMP queries. IGMPv1 has no special mechanism by which the hosts can leave the group. If the hosts are no longer interested
in receiving multicast packets for a particular group, they simply do not reply to the IGMP query packets sent from the device.
The device continues sending query packets. If the device does not hear a response in three IGMP queries, the group times
out and the device stops sending multicast packets on the segment for the group. If the host later wants to receive multicast
packets after the timeout period, the host simply sends a new IGMP join to the device, and the device begins to forward the
multicast packet again.
If there are multiple devices on a LAN, a designated router (DR) must be elected to avoid duplicating multicast traffic for
connected hosts. PIM devices follow an election process to select a DR. The PIM device with the highest IP address becomes
The DR is responsible for the following tasks:
Sending PIM register and PIM Join and Prune messages toward the rendezvous point (RP) to inform it about host group membership.
Sending IGMP host-query messages.
Sending host-query messages by default every 60 seconds in order to keep the IGMP overhead on hosts and networks very low.
Devices That Run IGMPv2
IGMPv2 improves the query messaging capabilities of IGMPv1.
The query and membership report messages in IGMPv2 are identical to the IGMPv1 messages with two exceptions:
IGMPv2 query messages are broken into two categories: general queries (identical to IGMPv1 queries) and group-specific queries.
IGMPv1 membership reports and IGMPv2 membership reports have different IGMP type codes.
IGMPv2 also enhances IGMP by providing support for the following capabilities:
Querier election process--Provides the capability for IGMPv2 devices to elect the IGMP querier without having to rely on
the multicast routing protocol to perform the process.
Maximum Response Time field--A new field in query messages permits the IGMP querier to specify the maximum query-response
time. This field permits the tuning of the query-response process to control response burstiness and to fine-tune leave latencies.
Group-Specific Query messages--Permits the IGMP querier to perform the query operation on a specific group instead of all
Leave-Group messages--Provides hosts with a method of notifying devices on the network that they wish to leave the group.
Unlike IGMPv1, in which the DR and the IGMP querier are typically the same device, in IGMPv2 the two functions are decoupled.
The DR and the IGMP querier are selected based on different criteria and may be different devices on the same subnet. The
DR is the device with the highest IP address on the subnet, whereas the IGMP querier is the device with the lowest IP address.
Query messages are used to elect the IGMP querier as follows:
When IGMPv2 devices start, they each multicast a general query message to the all-systems group address of 18.104.22.168 with
their interface address in the source IP address field of the message.
When an IGMPv2 device receives a general query message, the device compares the source IP address in the message with its
own interface address. The device with the lowest IP address on the subnet is elected the IGMP querier.
All devices (excluding the querier) start the query timer, which is reset whenever a general query message is received from
the IGMP querier. If the query timer expires, it is assumed that the IGMP querier has gone down, and the election process
is performed again to elect a new IGMP querier.
By default, the timer is two times the query interval.
Devices Running IGMPv3
IGMPv3 adds support for source filtering, which enables a multicast receiver host to signal to a device which groups it wants
to receive multicast traffic from, and from which sources this traffic is expected. This membership information enables the
software to forward traffic only from those sources from which receivers requested the traffic.
IGMPv3 supports applications that explicitly signal sources from which they want to receive traffic. With IGMPv3, receivers
signal membership to a multicast group in the following two modes:
INCLUDE mode--In this mode, the receiver announces membership to a group and provides a list of IP addresses (the INCLUDE
list) from which it wants to receive traffic.
EXCLUDE mode--In this mode, the receiver announces membership to a group and provides a list of IP addresses (the EXCLUDE
list) from which it does not want to receive traffic. In other words, the host wants to receive traffic only from sources
whose IP addresses are not listed in the EXCLUDE list. To receive traffic from all sources, like in the case of the Internet
Standard Multicast (ISM) service model, a host expresses EXCLUDE mode membership with an empty EXCLUDE list.
IGMPv3 is the industry-designated standard protocol for hosts to signal channel subscriptions in an SSM network environment.
For SSM to rely on IGMPv3, IGMPv3 must be available in the network stack portion of the operating systems running on the last
hop devices and hosts and be used by the applications running on those hosts.
In IGMPv3, hosts send their membership reports to 22.214.171.124; all IGMPv3 devices, therefore, must listen to this address.
Hosts, however, do not listen or respond to 126.96.36.199; they only send their reports to that address. In addition, in IGMPv3,
there is no membership report suppression because IGMPv3 hosts do not listen to the reports sent by other hosts. Therefore,
when a general query is sent out, all hosts on the wire respond.