IGMP: Das steckt hinter dem Internet Group Management Protocol

Spätestens seit dem großen Erfolg von Streaming-Diensten wie Netflix oder Spotify ist IP-Multicasting als Übertragungsmethode für das Internet und Heimnetzwerke kaum mehr wegzudenken. Dies technische Verfahren ermöglicht es dem Sender von Daten nämlich, Datenströme gezielt an ganze Empfängergruppen zu schicken, wodurch dieser Transport- und Routingkapazitäten optimal nutzen kann. Ohne diese Übertragungsmethode müsste er separate Datenpakete an jedes Empfängergerät verschicken, was eine enorme Bandbreite erfordern und so schnell zu einer Überlastung führen würde. Damit wäre es praktisch unmöglich, den angebotenen Dienst dauerhaft verfügbar zu halten.

Ein Protokoll, das bei der Organisation der genannten Multicast-Empfängergruppen in IPv4-Netzwerken eine wichtige Rolle spielt, ist das Internet Group Management Protocol (IGMP).

Das Internet Group Management Protocol ist ein Kommunikationsprotokoll der TCP/IP-Familie, das an der Stanford University entwickelt und 1989 in RFC 1112 erstmals spezifiziert wurde. Auf diese erste Protokollversion IGMPv1 folgten die Überarbeitungen IGMPv2 (RFC 2236) und IGMPv3 (RFC 3376; RFC 4604). Die Versionen sind dabei immer rückwärtskompatibel, wodurch ein IGMPv3-Gerät automatisch auch Version 1 und 2 unterstützt. Das Internet Group Management Protocol ist ausschließlich für IPv4-Netzwerke zuständig – in IPv6-Netzen übernimmt das ähnlich Multicast Listener Discovery (MLD) seine Funktion.

Die grundlegende Aufgabe von IGMP ist es, dynamische Gruppen für IP-Multicast-Übertragungen zu verwalten, wobei diese Verwaltung nicht über das Sendegerät selbst, sondern über die eingebundenen Router läuft. Diese nehmen einerseits von den Empfängergeräten (oder auch von den jeweiligen untergeordneten Routern) Anfragen zur Aufnahme in eine bestimmte Multicast-Gruppe entgegen. Andererseits leiten sie IGMP-Nachrichten an die entsprechenden übergeordneten Router weiter, wenn sie passende Multicast-Datenpakete erhalten. Die Sendestation erhält dabei keinerlei Informationen, welche und wie viele Endstationen ein verschicktes Paket erreicht, da sie lediglich ein einziges Datenpaket an ihren übergeordneten Router weiterleitet.

Es ist bereits zur Sprache gekommen, dass die Gruppen-Verwaltung via IGMP nicht im Verantwortungsbereich des Paketsenders liegt. Dieser Ausgangshosts muss aber – wie im Übrigen alle anderen involvierten Stationen des Netzwerks (inklusive des Empfängers) – Multicast-Verbindungen unterstützen. Die Entgegennahme von Client-Anfragen zur Aufnahme in eine bestimmte Multicast-Gruppe sowie die Benachrichtigung der Clients im Falle eingehender Multicast-Datenströme wird von den einzelnen Netzwerk-Routern übernommen, die auf dem Weg zwischen Sender und Empfänger liegen.

Zu diesem Zweck bietet das Internet Group Management Protocol einerseits Funktionen, über die eine Station dem ihr zugeordneten Router mitteilen kann, dass die Aufnahme in eine Multicast-Gruppe erfolgen soll. Andererseits befähigt es die Router dazu, sich ausgehende Schnittstellen derjenigen Empfängergeräte zu merken, die bestimmte IP-Multicast-Datenströme erhalten sollen, um dann gezielt Benachrichtigungen (Reports) schicken zu können, sobald entsprechende Daten empfangen werden. Multicast-Gruppen zeichnen sich dabei durch ihre spezifischen Adressen aus dem Bereich 224.0.0.x aus. In den meisten Fällen ist die erste Anlaufstelle eines Geräts der heimische Internet-Router, der das Beitrittsgesuch empfängt und an den nächsten Netzwerkknoten, typischerweise den Router des Internetdienstanbieters, weiterleitet. Diese Kommunikationskette endet bei dem Router des Datenstromsenders, der das IP-Paket seinerseits bei Bedarf dupliziert, wenn er mehrere ausgehende Schnittstellen zu bedienen hat.

Die drei veröffentlichten Versionen des Internet Group Management Protocols zeichnen sich zahlreiche Gemeinsamkeiten aus. IGMPv2 und IGMPv3 haben den Vorgänger nämlich in erster Linie um Funktionen erweitert, während die grundsätzlichen Merkmale wie die Gruppenadresse für generelle Anfragen (0.0.0.0) unverändert übernommen wurden. Doch wie sehen die jeweiligen Erweiterungen im Detail aus?

Der IGMP-Header hat also eine Gesamtlänge von 64 Bit. Die ersten 8 Bits geben dabei immer zunächst die Protokollversion IGMPv1 sowie den Typ der Nachricht an. Für dieses Feld (Type) gibt es die beiden Möglichkeiten „1“ (für Beitrittsanfragen) und „2“ (für Benachrichtigungen über Multicast-Datenströme). Es folgen die Bits 8 bis 15, die keinerlei Funktion haben und lediglich aus Nullen bestehen. Den Abschluss des ersten 32-Bit-Blocks bildet eine Prüfsumme. Handelt es sich um ein IGMP-Benachrichtigungspaket, schließt sich nun die 32 Bit lange Gruppenadresse an. Beitrittsanfragen hängt hingegen ein Abschnitt an, der ausschließlich Nullen enthält (Gruppenadresse 0.0.0.0).

Die Originalversion der Protokoll-Linie gibt selbst nicht vor, welcher Router für die Multicast-Abfragen genutzt werden soll (wird durch das Multicast Routing Protocol geregelt).

Die Kopfzeile beginnt ähnlich wie in der ersten Protokollfassung, ohne allerdings die Versionsnummer anzugeben. Die möglichen Type-Codes sind „0x11“ (für Anfragen), „0x16“ (für Benachrichtigungen) und „0x17“ (für Leave-Messages). Im Rahmen der Rückwärtskompatibilität gibt es zudem den Code „0x12“ für IGMPv1-Benachrichtigungen. Die Bits 8 bis 15 erhalten in IGMPv2 eine konkrete Funktion – zumindest bei Beitrittsanfragen – und definieren die maximal erlaubte Antwortzeit. Es folgen Prüfsumme (16 Bit) und die Gruppenadresse (32 Bit), die bei generellen Anfragen wiederum die protokolltypische Form 0.0.0.0 hat.

IGMPv2 gibt die Regel vor, dass der Router mit der niedrigsten IP-Adresse im Subnetz für die Multicast-Abfragen eingesetzt wird.

Die ersten zwei 32-Bit-Sequenzen sind identisch mit denen des IGMPv2-Headers – Type, maximale Antwortzeit, Prüfsumme und Gruppenadresse. Auch IGMPv3 bietet an dieser Stelle die Möglichkeit des Austauschs mit älteren Protokollversionen: Hierfür stehen den Hosts die Codes „0x12“ für Version 1 und „0x16“ für Version 2 zur Verfügung. Im Anschluss an die Gruppenadresse beginnt der IGMPv3-Query-spezifische Header-Teil, dessen erste 32 Bit sich folgendermaßen zusammensetzen:

• Res.: reserviertes 4-Bit-Feld, das keinerlei Funktionen hat und nur Nullen enthält.
• S (Suppress Router-Side Processing): S-Flag, das den Routern auf Wert „1“ gesetzt. signalisiert, dass sie normale Updates beim Empfangen einer Anfrage unterdrücken sollen. Ist der Wert „0“, ist das Feld inaktiv.
• QRV (Querier’s Robustness Variable): 3 Bit, die den Wert „Robustheitsvariable“ enthalten können, der von anfragenden Hosts genutzt wird.
• QQIC (Querier’s Query Interval Code): 8-Bit-Feld, über das sich das Intervall für IGMPV3-Anfragen spezifizieren lässt.
• Anzahl der Quelladressen: Anzahl der Quelladressen, die nachfolgend aufgeführt werden.

Nach diesen sehr spezifischen Angaben folgt die Quelladresse bzw. eine Auflistung der einzelnen Quelladressen (jeweils 32 Bit), sofern mehrere Quellen definiert werden sollen.

Im Gegensatz zu seinem Vorgänger ermöglicht es IGMPv3 einem Host, in einer einzigen Transaktion einer Gruppe beizutreten und eine andere zu verlassen – IGMPv2 benötigt hierfür noch zwei separate Nachrichten.

Die Rolle von IGMP ist klar definiert: Das Kommunikationsprotokoll kommt immer dort zur Anwendung, wo Multicast-Übertragungen in IPv4-Netzwerken wie dem Internet benötigt werden. Klassische Einsatzszenarien sind also Echtzeitapplikationen, die über Mehrpunktverbindungen laufen – also beispielsweise Webkonferenz-Tools oder Live-Streaming-Dienste. Dabei soll nicht jeder Client einzeln mit dem benötigten Datenstrom versorgt werden müssen, da dies schnell zu einer Überlastung des Ausgangsservers und der involvierten Netzwerkknoten führen würde.