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.
The Internet Group Management Protocol is a TCP/IP family communication protocol developed at Stanford University and first specified in 1989 in RFC 1112. The first protocol version IGMPv1 was followed by the revised versions IGMPv2 (RFC 2236) and IGMPv3 (RFC 3376; RFC 4604). 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.
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.
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.
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.
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 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:
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).
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:
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, 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:
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:
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.
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.
Unlike its predecessor, IGMPv3 allows a host to join one group and leave another in a single transaction – IGMPv2 still requires two separate messages.
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.
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, which is also made possible by the Internet Group Management Protocol.
If a system in IP networks is to send data packets to different target hosts as efficiently as possible, an IP multicasting connection is the perfect solution. When it comes to multipoint transmission, the data packets are able to reach all interested parties thanks to various protocols such as GMP, for example. Switches and internet routers can also use the communication protocol for IGMP...
DHCP snooping makes a network more secure. There are no two ways about it: DHCP makes network configuration so much easier. This is especially the case in large networks, where devices are constantly changing and the manual assignment of IP addresses is a never-ending task. Yet by using DHCP to simplify the process, you do relinquish controls, and criminals can take advantage of this. By using...
Provide powerful and reliable service to your clients with a web hosting package from IONOS.
View packages
