Internet group management protocol

The Internet Group Management Protocol is a communications protocol used to manage the membership of Internet Protocol multicast groups. IGMP is used by IP hosts and adjacent multicast routers to establish multicast group memberships. It is an integral part of the IP multicast specification, like ICMP for unicast connections.

Table of contents

1 IGMP version 0.

1.1 RFC 966, page 16:
1.2 RFC 988, pages 1, 2 and 3:
1.3 RFC 988, page 10:
1.4 RFC 988, page 13:

2 IGMP version 1.

2.5 RFC 1054, pages 10 through 13:
2.6 RFC 1054, pages 16 and 17:

2.6.1 HOST GROUP ADDRESS ISSUES: Group Address Binding.
2.6.2 CHANGES FROM RFC-988.

2.7 RFC 1112, page 3:

2.7.3 HOST GROUP ADDRESSES.

2.8 RFC 1112, page 11:
2.9 RFC 1122, page 47:
2.10 RFC 1122, pages 67 and 68:
2.11 RFC 1812, page 84:

2.11.4 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP.

3 IGMP version 2.

3.12 RFC 2236, pages 1 and 2:
3.13 RFC 2113, page 2:
3.14 RFC 2236, pages 4 and 5:

4 IGMP version 3

4.15 RFC 3376

5 External links

IGMP version 0.

RFC 966, page 16:

The Internet Group Management Protocol (IGMP(v0)) is used between IP hosts and their immediate neighbour multicast agents to support the allocation of temporary group addresses and the addition and deletion of members of a group.

RFC 988, pages 1, 2 and 3:

IP multicasting is defined as the transmission of an IP datagram to a "host group", a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams, i.e. the datagram is not guaranteed to arrive at all members of the destination group or in the same order relative to other datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group, but membership in a group may be restricted to only those hosts possessing a private access key. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it. A host group may be permanent or transient. A permanent group has a well-known, administratively assigned IP address. It is the address, not the membership of the group, that is permanent; at any time a permanent group may have any number of members, even zero. A transient group, on the other hand, is assigned an address dynamically when the group is created, at the request of a host. A transient group ceases to exist, and its address becomes eligible for reassignment, when its membership drops to zero.

The creation of transient groups and the maintenance of group membership information is the responsibility of "multicast agents", entities that reside in internet gateways or other special-purpose hosts. There is at least one multicast agent directly attached to every IP network or subnetwork that supports IP multicasting. A host requests the creation of new groups, and joins or leaves existing groups, by exchanging messages with a neighboring agent. Multicast agents are also responsible for internetwork delivery of multicast IP datagrams. When sending a multicast IP datagram, a host transmits it to a local network multicast address which identifies all neighboring members of the destination host group. If the group has members on other networks, a multicast agent becomes an additional recipient of the local multicast and relays the datagram to agents on each of those other networks, via the internet gateway system. Finally, the agents on the other networks each transmit the datagram as a local multicast to their own neighboring members of the destination group. Level 2: full support for IP multicasting, allows a host to create, join and leave host groups, as well as send IP datagrams to host groups. It requires implementation of the Internet Group Management Protocol (IGMP) and extension of the IP and local network service interfaces within the host. All of the following sections of this memo are applicable to level 2 implementations.

RFC 988, page 10:

Within the IP module, the membership management operations are supported by the Internet Group Management Protocol (IGMP), specified in Appendix I. As well as having messages corresponding to each of the operations specified above, IGMP also specifies a "deadman timer" procedure whereby hosts periodically confirm their memberships with the multicast agents.

The IP module must maintain a data structure listing the IP addresses of all host groups to which the host currently belongs, along with each group's loopback policy, access key, and timer variables. This data structure is used by the IP multicast transmission service to know which outgoing datagrams to loop back, and by the reception service to know which incoming datagrams to accept. The purpose of IGMP and the management interface operations is to maintain this data structure.

RFC 988, page 13:

The Internet Group Management Protocol (IGMP) is used between IP hosts and their immediate neighbor multicast agents to support the creation of transient groups, the addition and deletion of members of a group, and the periodic confirmation of group membership. IGMP is an asymmetric protocol and is specified here from the point of view of a host, rather than a multicast agent.

Like ICMP, IGMP is a integral part of IP. It is required to be implemented in full by all hosts conforming to level 2 of the IP multicasting specification. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. All IGMP messages have the following format:

MAC header IP-Header IGMP packet IGMP version 0, packet format: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Type Code IGMP Checksum Identifier Group Address Access Key::: Type. 8 bits. Type Description 1 Create Group Request. 2 Create Group Reply. 3 Join Group Request. 4 Join Group Reply. 5 Leave Group Request. 6 Leave Group Reply. 7 Confirm Group Request. 8 Confirm Group Reply.

Code. 8 bits.

In a Create Group Request message, this field indicates if the new host group is to be public or private. In all other Request messages, this field is set to zero.

Code	Description
0	Public.
1	Private.

In a Reply message, the Code field specifies the outcome of the request. Code Description

0 Request granted. 1 Request denied, no resources. 2 Request denied, invalid code. 3 Request denied, invalid group address. 4 Request denied, invalid access key. 5-255 Request pending, retry in this many seconds.

IGMP Checksum. 16 bits.

The checksum is the 16-bit one's complement of the one's complement sum of the IGMP message starting with the IGMP Type. For computing the checksum, the checksum field should first be set to 0. When the data packet is transmitted, the checksum is computed and inserted into this field. When the data packet is received, the checksum is again computed and verified against the checksum field. If the two checksums do not match then an error has occurred.

Identifier. 32 bits.

In a Confirm Group Request message, the identifier field contains zero. In all other Request messages, the identifier field contains a value to distinguish the request from other requests by the same host. In a Reply message, the identifier field contains the same value as in the corresponding Request message.

Group Address. 32 bits.

In a Create Group Request message, the group address field contains zero. In all other Request messages, the group address field contains a host group address. In a Create Group Reply message, the group address field contains either a newly allocated host group address (if the request is granted) or zero (if denied). In all other Reply messages, the group address field contains the same host group address as in the corresponding Request message.

Access Key. 64 bits.

In a Create Group Request message, the access key field contains zero. In all other Request messages, the access key field contains the access key assigned to the host group identified in the Group Address field (zero for public groups). In a Create Group Reply message, the access key field contains either a non-zero 64-bit number (if the request for a private group is granted) or zero. In all other Reply messages, the access key field contains the same access key as in the corresponding Request.

IGMP version 1.

RFC 1054, pages 10 through 13:

The Internet Group Management Protocol (IGMP(v0)) is used by IP hosts to report their host group memberships to any immediately-neighboring multicast routers. IGMP is an asymmetric protocol and is specified here from the point of view of a host, rather than a multicast router. (IGMP may also be used, symmetrically or asymmetrically, between multicast routers.)

Like ICMP, IGMP is a integral part of IP. It is required to be implemented by all hosts conforming to level 2 of the IP multicasting specification. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. This memo specifies version 1 of IGMP.

Informal Protocol Description. Multicast routers send Host Membership Query messages (hereinafter called Queries) to discover which host groups have members on their attached local networks. Queries are addressed to the all-hosts group (address 224.0.0.1), and carry an IP time-to-live (TTL) of 1.

Hosts respond to a Query by generating Host Membership Reports (hereinafter called Reports), reporting each host group to which they belong on the network interface from which the Query was received. In order to avoid an "implosion" of concurrent Reports and to reduce the total number of Reports transmitted, two techniques are used:

When a host receives a Query, rather than sending Reports immediately, it starts a report delay timer for each of its group memberships on the network interface of the incoming Query. Each timer is set to a different, randomly-chosen value between zero and D seconds. When a timer expires, a report is generated for the corresponding host group. Thus, Reports are spread out over a D second interval instead of all occurring at once.
A Report is sent with an IP destination address equal to the host group address being reported, and with an IP time-to-live of 1, so that other members of the same group on the same network can overhear the Report. If a host hears a Report for a group to which it belongs on that network, the host stops its own timer for that group and does not generate a Report for that group. Thus, in the normal case, only one Report will be generated for each group present on the network, by the member host whose delay timer expires first. Note that the multicast routers receive all IP multicast datagrams, and therefore need not be addressed explicitly. Further note that the routers need not know which hosts belong to a group, only that at least one host belongs to a group on a particular network.

There are two exceptions to the behavior described above. First, if a report delay timer is already running for a group membership when a Query is received, that timer is not reset to a new random value, but rather allowed to continue running with its current value. Second, a report delay timer is never set for a host's membership in the all- hosts group (224.0.0.1), and that membership is never reported.

If a host uses a pseudo-random number generator to compute the reporting delays, one of the host's own individual IP address should be used as part of the seed for the generator, to reduce the chance of multiple hosts generating the same sequence of delays.

A host should confirm that a received Report has the same IP host group address in its IP destination field and its IGMP group address field, to ensure that the host's own Report is not cancelled by an erroneous received Report. A host should quietly discard any IGMP message of type other than Host Membership Query or Host Membership Report.

Multicast routers send Queries periodically to refresh their knowledge of memberships present on a particular network. If no Reports are received for a particular group after some number of Queries, the routers assume that that group has no local members and that they need not forward remotely-originated multicasts for that group onto the local network. Queries are normally sent infrequently (no more than once a minute) so as to keep the IGMP overhead on hosts and networks very low. However, when a multicast router starts up, it may issue several closely-space Queries in order to quickly build up its knowledge of local memberships.

When a host joins a new group, it should immediately transmit a Report for that group, rather than waiting for a Query, in case it is the first member of that group on the network. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays. (A simple way to accomplish this is to act as if a Query had been received for that group only, setting the group's random report delay timer.

RFC 1054, pages 16 and 17:

HOST GROUP ADDRESS ISSUES: Group Address Binding.

The binding of IP host group addresses to physical hosts may be considered a generalization of the binding of IP unicast addresses. An IP unicast address is statically bound to a single local network interface on a single IP network. An IP host group address is dynamically bound to a set of local network interfaces on a set of IP networks.

It is important to understand that an IP host group address is NOT bound to a set of IP unicast addresses. The multicast routers do not need to maintain a list of individual members of each host group. For example, a multicast router attached to an Ethernet need associate only a single Ethernet multicast address with each host group having local members, rather than a list of the members' individual IP or Ethernet addresses.

CHANGES FROM RFC-988.

The IP multicast extensions specified in this memo are significantly different from those specified in RFC-988. Most of the changes are due to a shift of responsibility away from the multicast routers (called "multicast agents" in RFC-988) and onto the hosts. This new distribution of responsibility is consistent with the lightweight, soft-state gateway architecture of the Internet, and it allows the IP multicast services (in the same way as the IP unicast services) to be used among hosts on a single network when no router is up or present on the network. Thus, current single-network IP broadcast applications may be migrated to the use of IP multicast before multicast routers are widely available.

RFC 1112, page 3:

At this time, implementation of IGMP is OPTIONAL...Without IGMP, a host can still participate in multicasting local to its connected networks.

RFC 1122, pages 67 and 68:

A host SHOULD support local IP multicasting on all connected networks for which a mapping from Class D IP addresses to link-layer addresses has been specified (see below). Support for local IP multicasting includes sending multicast datagrams, joining multicast groups and receiving multicast datagrams, and leaving multicast groups. This implies support for all of [RFC 1112] except the IGMP protocol itself, which is OPTIONAL.

IGMP provides gateways that are capable of multicast routing with the information required to support IP multicasting across multiple networks. At this time, multicast-routing gateways are in the experimental stage and are not widely available. For hosts that are not connected to networks with multicast-routing gateways or that do not need to receive multicast datagrams originating on other networks, IGMP serves no purpose and is therefore optional for now. However, the rest of [RFC 1112] is currently recommended for the purpose of providing IP-layer access to local network multicast addressing, as a preferable alternative to local broadcast addressing. It is expected that IGMP will become recommended at some future date, when multicast-routing gateways have become more widely available.

If IGMP is not implemented, a host SHOULD still join the "all- hosts" group (224.0.0.1) when the IP layer is initialized and remain a member for as long as the IP layer is active.

Joining the "all-hosts" group will support strictly local uses of multicasting, e.g., a gateway discovery protocol, even if IGMP is not implemented.

The mapping of IP Class D addresses to local addresses is currently specified for the following types of networks:

Ethernet/IEEE 802.3.
Any network that supports broadcast but not multicast, addressing: all IP Class D addresses map to the local broadcast address.
Any type of point-to-point link (e.g., SLIP or HDLC links): no mapping required. All IP multicast datagrams are sent as-is, inside the local framing.

Mappings for other types of networks will be specified in the future. A host SHOULD provide a way for higher-layer protocols or applications to determine which of the host's connected network(s) support IP multicast addressing.

RFC 1812, page 84:

INTERNET GROUP MANAGEMENT PROTOCOL - IGMP.

IGMP is a protocol used between hosts and multicast routers on a single physical network to establish hosts' membership in particular multicast groups. Multicast routers use this information, in conjunction with a multicast routing protocol, to support IP multicast forwarding across the Internet. A router SHOULD implement the multicast router part of IGMP.

MAC header IP-Header IGMP packet IGMP version 1, packet format: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Version Type Unused IGMP Checksum Group Address Version. 4 bits. Set to 1. Type. 4 bits. Type Description 1 Host Membership Query. 2 Host Membership Report. 3 DVRMP

Unused. 8 bits.

Set to zero when the IGMP packet is sent and ignored when received.

IGMP Checksum. 16 bits.

The checksum is the 16-bit one's complement of the one's complement sum of the 8-byte IGMP message. When the checksum is computed, the checksum field should first be set to 0. When the data packet is transmitted, the checksum is computed and inserted into this field. When the data packet is received, the checksum is again computed and verified against the checksum field. If the two checksums do not match then an error has occurred.

Group Address. 32 bits.

In a Host Membership Query message, the group address field is zeroed when sent, ignored when received. In a Host Membership Report message, the group address field holds the IP host group address of the group being reported.

IGMP version 2.

RFC 2236, pages 1 and 2:

IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership.

Like ICMP, IGMP is a integral part of IP. It is required to be implemented by all hosts wishing to receive IP multicasts. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. All IGMP messages described in this document are sent with IP TTL 1, and contain the IP Router Alert option in their IP header.

RFC 2113, page 2:

The Router Alert option has the semantic "routers should examine this packet more closely". By including the Router Alert option in the IP header of its protocol message, RSVP (Resource ReSerVation Protocol) can cause the message to be intercepted while causing little or no performance penalty on the forwarding of normal data packets.

RFC 2236, pages 4 and 5:

Multicast routers use IGMP(v2) to learn which groups have members on each of their attached physical networks. A multicast router keeps a list of multicast group memberships for each attached network, and a timer for each membership. "Multicast group memberships" means the presence of at least one member of a multicast group on a given attached network, not a list of all of the members. When a host receives a General Query, it sets delay timers for each group (excluding the all-systems group) of which it is a member on the interface from which it received the query.

When a router receives a Report, it adds the group being reported to the list of multicast group memberships on the network on which it received the Report and sets the timer for the membership to the [Group Membership Interval]. When a host joins a multicast group, it should immediately transmit an unsolicited Version 2 Membership Report for that group, in case it is the first member of that group on the network.

When a host leaves a multicast group, if it was the last host to reply to a Query with a Membership Report for that group, it SHOULD send a Leave Group message to the all-routers multicast group (224.0.0.2).

MAC header IP header IGMP packet IGMP version 2, packet format: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Type Max Response Time IGMP Checksum Group Address Type. 8 bits. Type Description 0x11 Group Membership Query, general or group-specific. General Query is used to learn which groups have members on an attached network. Group-Specific Query is used to learn if a particular group has any members on an attached network. These two messages are differentiated by the Group Address. 0x12 Version 1 - Membership Report. 0x16 Version 2 - Membership Report.

0x17 Leave Group. 0x24 Multicast Router Advertisement. 0x25 Multicast Router Solicitation. 0x26 Multicast Router Termination.

Max Response Time. 8 bits.

The Max Response Time field is used only in Membership Query messages. It specifies the maximum allowed time before sending a responding report in units of 1/10 second. In all other messages, it is set to zero by the sender and ignored by receivers.

Varying this setting allows IGMPv2 routers to tune the "leave latency" (the time between the moment the last host leaves a group and when the routing protocol is notified that there are no more members). It also allows tuning of the burstiness of IGMP traffic on a subnet.

IGMP Checksum. 16 bits.

The 16-bit one's complement of the one's complement sum of the IGMP message, starting with the IGMP Type field. For computing the checksum, the checksum field should first be set to 0. When the data packet is transmitted, the checksum is computed and inserted into this field. When the data packet is received, the checksum is again computed and verified against the checksum field. If the two checksums do not match then an error has occurred.

Group Address. 32 bits.

In a Membership Query message, this field is set to zero when sending a General Query, and set to the group address being queried when sending a Group-Specific Query. In a Membership Report or Leave Group message, this field holds the IP multicast group address of the group being reported or left.

IGMP version 3

RFC 3376

External links

http://www.networksorcery.com/enp/protocol/igmp.htm