# IGMP (Internet Group Management Protocol)

Since the great success of streaming services such as Netflix and Spotify, IP multicasting has become an indispensable transmission method for the internet. This technical procedure enables the sender to send data streams to entire receiver groups, enabling them to make **optimum use of transport and routing capacities**. Without this transmission method, the sender would have to send separate data packets to each receiving device, which would require enormous bandwidth and would quickly lead to an overload. This would make it practically impossible to keep the service permanently available.

The Internet Group Management Protocol (IGMP) is a protocol that plays an important role in the **organization** of these **multicast receiver groups in IPv4 networks**.

## What is the Internet Group Management Protocol?

The Internet Group Management Protocol is a **TCP/IP family communication protocol** developed at Stanford University and first specified in 1989 in [RFC 1112](https://tools.ietf.org/html/rfc1112 "RFC 1112 – Host extensions for IP multicasting"). The first protocol version IGMPv1 was followed by the **revised versions** IGMPv2 ([RFC 2236](https://tools.ietf.org/html/rfc2236 "RFC 2236 – Internet Group Management Protocol, Version 2")) and IGMPv3 ([RFC 3376](https://tools.ietf.org/html/rfc3376 "Internet Group Management Protocol, Version 3"); [RFC 4604](https://tools.ietf.org/html/rfc4604 "IGMPv3 und MLDv2")). The versions are always backward compatible, which means that an IGMPv3 device automatically supports versions 1 and 2. The Internet Group Management Protocol is exclusively responsible for IPv4 networks – in **IPv6** networks, the similar **Multicast Listener Discovery (MLD)** takes over its function.

The basic task of IGMP is to manage **dynamic groups for IP multicast transmissions**, whereby this management doesn’t run via the sending device itself, but via the integrated routers. On the one hand, these receive **requests for inclusion in a specific multicast group** from the receiver devices (or from the respective subordinate router). On the other hand, they forward IGMP messages **to the appropriate parent router** when they receive appropriate multicast data packets. The sending station doesn’t receive any information about which end stations and how many a sent packet reaches, since it only forwards a **single data packet** to its superordinate router.

Definition IGMP IGMP (Internet Group Management Protocol) is a **communication protocol of the internet protocol family (TCP/IP)**. It was first specified in RFC 1112 in 1989 and is active on the network layer of the OSI model. IGMP is responsible for organizing multicast groups that **allow IP data streams to be sent to multiple recipients**. This means that the Internet Group Management Protocol is automatically implemented on all hosts that support IP multicasting.

## How does IGMP work?

It has already been mentioned that group administration via IGMP is not the responsibility of the package sender. However, as with all other stations on the network (including the receiver) involved, this output host must **support multicast connections**. Receiving client requests for inclusion in a specific multicast group and notifying clients in the event of incoming multicast data streams is handled by the individual network routers on the path between the sender and receiver.

For this purpose, the Internet Group Management Protocol offers functions that a station can use to inform the router assigned to it that it is to be included in a multicast group. On the other hand, it enables the routers to remember outgoing **interfaces** of those receiver devices that are to receive certain IP multicast data streams to be able to send specific reports as soon as corresponding data is received. Multicast groups are characterized by their specific addresses from the **224.0.0x range**. In most cases, the **first point of contact for a device is the home internet router**, which receives the membership application and forwards it to the next network node, typically the internet service provider’s router. This **communication chain ends with the router of the data stream** transmitter, which in turn duplicates the IP packet if required, if it has several outgoing interfaces to serve.

Note If a **second or additional terminal** in a private network is to be added to the same multicast group, the internet router can immediately grant the application for access, whereas **data streams that have already been received are forwarded directly**. The data transmission only ends when the last of these devices has left the group.

## How do the individual IGMP versions differ?

The three published versions of the Internet Group Management Protocols have a lot in common. IGMPv2 and IGMPv3 extended the predecessor primarily by functions, while the basic features like the group address for general requests (0.0.0.0) were kept unchanged. But what do the respective extensions look like in detail?

### IGMPv1: the basis of the Internet Group Management Protocol

IGMPv1 is the first published version of the communication protocol to include some basic features, many of which can also be found in more recent versions. **0.0.0.0 is already defined for IGMPv1 as the group address** as well as **224.0.0.1 as the destination address** for general IGMP requests. The default interval for these requests automatically sent out by the router is **60 seconds**. IGMPv1 allows all supporting hosts to join suitable multicast groups – membership requests are sent in the form of reports to the corresponding IP multicast addresses. In contrast to the successor protocols, IGMPv1 still lacks a function that allows hosts to leave groups on their own – only a timeout removes the respective host from groups they’re in.

All IGMP messages are transported in simple IP packets with the IP protocol number 2 (Hex: 0x02). The **IGMP header of the first protocol version** looks like this:

[![Image: IMGPv1 Header](https://www.ionos.com/digitalguide/fileadmin/_processed_/e/6/csm_EN-IGMP_20c43810c2.webp "IMGPv1 Header")](https://www.ionos.com/digitalguide/fileadmin/DigitalGuide/Screenshots_2018/EN-IGMP.png) IMGPv1 Header The IGMP header has a **total length of 64 bits**. The first 8 bits always specify the protocol version IGMPv1 and the type of message. There are two options for the field (type): “1” (for membership requests) and “2” (for notifications about multicast data streams). Bits 8 to 15 follow, but they have no function and only consist of zeros. The first 32-bit block ends with a **checksum**. If it is an IGMP notification package, the **32 bit-long group address** will follow.

The original version of the protocol line itself does not specify **which router should be used for multicast queries** (regulated by the Multicast Routing Protocol).

### IGMPv2: introduction of the leave message and a group-specific message type

The IGMPv2 specification dates from 1997, which means that the first revision of the standard appeared around 8 years after the first publication of the protocol. While group (0.0.0.0) and the destination (224.0.0.1) address for automatic requests remained unchanged, the **default internal duration has been increased to 125 seconds**. However, the most important new feature of IGMPv2 is that the logoff process has sped up: the timeout required in the first protocol variant is replaced by a logoff process initiated by the host via a **“leave” message**. The destination address for this message type is **224.0.0.2**.

Another new feature of the second version of the communication protocol: you can determine the reception status for a specific multicast address using group-specific messages.

**IGMPv2 messages** are also encapsulated in simple **IP packets with IP protocol number 2**. However, minor changes have been made to the **IGMP header**:

[![Image: IMGPv2 Header](https://www.ionos.com/digitalguide/fileadmin/_processed_/5/b/csm_EN-IGMP2_0fbff92ff1.webp "IMGPv2 Header")](https://www.ionos.com/digitalguide/fileadmin/DigitalGuide/Screenshots_2018/EN-IGMP2.png) IMGPv2 Header The header line starts similarly to the first log version, but without specifying the version number. The possible **type codes** are “0x11” (for requests), “0x16” (for notifications), and “0x17” (for leave messages). For **backwards compatibility**, there is also the code “0x12” for IGMPv1 notifications. Bits 8 to 15 receive a concrete function in IGMPv2 – at least for membership requests – and define the **maximum response time allowed**. This is followed by the checksum (16 bits) and the group address (32 bits), which in turn has the protocol-typical form 0.0.0.0 for general requests.

IGMPv2 specifies the rule that the **router with the lowest IP address in the subnet** is used for multicast queries.

### IGMPv3: increased security thanks to selectable multicast sources

IGMPv3, the third version of the Internet Group Management Protocol, was released in October 2002. 0.0.0.0 is the group address and 224.0.0.1 is the destination address for general requests. With regard to the **standard interval**, the protocol version is based on its direct predecessor with **125 seconds**. A new feature is the option to **select the source of the multicast stream**. This so-called source-specific multicasting reduces the demands on the network enormously and also ensures **greater security during transmission**, since not just any and/or unknown sources are used.

The IGMP header is also integrated in IGMPv3 in IP packets (protocol number 2), but is much more complex than with the two predecessor protocols, which is mainly due to the possibility of specifying the source address. There are also specific differences between requests and notifications. The **header for IGMPv3 group requests** looks like this:

[![Image: IMGPv3 Header](https://www.ionos.com/digitalguide/fileadmin/_processed_/a/4/csm_EN-IGMP3_e5d65a608c.webp "IMGPv3 Header")](https://www.ionos.com/digitalguide/fileadmin/DigitalGuide/Screenshots_2018/EN-IGMP3.png) IMGPv3 Header The first two 32-bit sequences are identical to those of the IGMPv2 header – type, maximum response time, checksum, and group address. IGMPv3 also offers the **possibility of exchanging with older protocol versions**: the codes “0x12” for version 1 and “0x16” for version 2 are available to the hosts for this purpose. After the group address, the **IGMPv3 query-specific header part** starts, the first 32 bits of which are composed as follows:

- **Res.**: reserved 4-bit field that has no functions and contains only zeros
- **S (suppress router-side processing)**: S flag that sets the routers to “1” indicating that they should suppress normal updates when receiving a request (if the value is “0” the field is inactive)
- **QRV (Querier’s Robustness Variable)**: 3 bit, which can contain the “robustness variable” value used by requesting hosts
- **QQIC (Querier’s Query Interval Code)**: 8-bit field used to specify the interval for IGMPV3 queries
- **Number of source addresses**: the amount of source addresses listed below

This very specific information is followed by the **source address** or a **list of the individual source addresses** (32 bits each), if several sources are to be defined.

Tip The extent to which the header of the second message type (**IGMPv3 notifications**) differs from the header of the IGMPv3 requests (presented here) can be read in [chapter 4.2 of the RFCs 3376](https://tools.ietf.org/html/rfc3376 "RFC 3376 – Internet Group Management Protocol, Version 3").

Unlike its predecessor, IGMPv3 allows a host to join one group and leave another in a single transaction – IGMPv2 still requires two separate messages.

## When is the Internet Group Management Protocol used?

The role of IGMP is clearly defined: The communication protocol is always used where **multicast transmissions are required in IPv4 networks** such as the internet. Classic deployment scenarios are **real-time applications** that run over multipoint connections – such as **web conferencing tools** or **live streaming services**. Not every client should have to be supplied with the required data stream individually, as this would quickly lead the output server and network nodes to overload.

Note Many switches and internet routers provide the ability to filter **multicast data traffic** in networks to optimize network performance. For this purpose, the devices use so-called [IGMP snooping](https://www.ionos.com/digitalguide/server/know-how/igmp-snooping/), which is also made possible by the Internet Group Management Protocol.


This is a markdown version of: [https://www.ionos.com/digitalguide/server/know-how/igmp-internet-group-management-protocol/](https://www.ionos.com/digitalguide/server/know-how/igmp-internet-group-management-protocol/) for AI/LLM consumption.