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).

Was ist das Internet Group Management Protocol?

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.
Definition IGMP
IGMP (Internet Group Management Protocol) ist ein Kommunikationsprotokoll der Internetprotokollfamilie (TCP/IP). Es wurde erstmals im Jahr 1989 in RFC 1112 spezifiziert und ist auf der Netzwerkschicht des OSI-Modells aktiv. Dort ist IGMP für die Organisation von Multicast-Gruppen zuständig, die den Versand von IP-Datenströmen an mehrere Empfänger ermöglichen. Damit ist das Internet Group Management Protocol automatisch auch auf allen Hosts implementiert, die IP-Multicasting unterstützen.

Wie funktioniert IGMP?

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.
Hinweis
Soll ein zweites bzw. ein weiteres Endgerät in einem privaten Netzwerk der gleichen Multicast-Gruppe beigefügt werden, kann der Internet-Router dem Beitrittsgesuch unverzüglich stattgeben, woraufhin bereits empfangene Datenströme direkt weitergeleitet werden. Die Übertragung der Daten endet erst dann, wenn das letzte dieser Geräte die Gruppe verlassen hat.

Wie unterscheiden sich die einzelnen IGMP-Versionen?

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?

IGMPv1: Die Basis des Internet Group Management Protocols

IGMPv1 zeichnet sich als erste veröffentlichte Version des Kommunikationsprotokolls durch einige grundlegende Merkmale aus, von denen viele auch in aktuelleren Varianten zu finden sind. So sind bei IGMPv1bereits 0.0.0.0 als Gruppenadresse sowie 224.0.0.1 als Zieladresse für generelle IGMP-Anfragen definiert. Das Standard-Intervall für diese automatisch durch den Router gestellten Anfragen liegt dabei bei 60 Sekunden. IGMPv1 ermöglicht allen unterstützenden Hosts den Beitritt in passende Multicast-Gruppen – Beitrittsgesuche werden in Form von Reports an die entsprechenden IP-Multicast-Adressen gesendet. Im Gegensatz zu den Nachfolgeprotokollen fehlt IGMPv1 allerdings noch eine Funktion, die es den Hosts ermöglicht, Gruppen auf eigene Faust zu verlassen – erst ein Timeout entfernt den jeweiligen Host aus betretenen Gruppen.
Alle IGMP-Nachrichten werden in einfachen IP-Paketen mit der IP-Protokollnummer 2 (Hex: 0x02) transportiert. Der IGMP-Header der ersten Protokollversion sieht dabei folgendermaßen 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).

IGMPv2: Einführung der Leave-Message und eines gruppenspezifischen Nachrichtentyps

Die IGMPv2-Spezifikation stammt aus dem Jahr 1997, womit die erste Überarbeitung des Standards rund 8 Jahre nach der Erstveröffentlichung des Protokolls erschienen ist. Während Gruppen- (0.0.0.0) und Zieladresse (224.0.0.1) für die automatischen Anfragen unverändert blieben, ist die Dauer des Standard-Intervalls auf 125 Sekunden erhöht worden. Die wichtigste Neuerung von IGMPv2 ist allerdings die Beschleunigung des Abmeldeprozesses: Der in der ersten Protokollvariante vorausgesetzte Timeout wird durch einen vom Host initiierten Abmeldeprozesses via „Leave“-Message ersetzt. Als Zieladresse für diesen Nachrichtentyp ist die Adresse 224.0.0.2 definiert.
Eine weitere Neuheit der zweiten Version des Kommunikationsprotokolls: Man kann den Empfangsstatus für eine bestimmte Multicast-Adresse über gruppenspezifische Nachrichten ermitteln.
Auch für IGMPv2-Nachrichten gilt, dass sie in einfachen IP-Paketen mit der IP-Protokollnummer 2 gekapselt versendet werden. Am IGMP-Header wurden jedoch kleinere Anpassungen vorgenommen:
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.

IGMPv3: Erhöhte Sicherheit dank gezielt auswählbarer Multicast-Quellen

IGMPv3, die dritte Version des Internet Group Management Protocols, gibt es seit Oktober 2002. Auch in dieser überarbeitenden Ausführung des Protokolls sind 0.0.0.0 als Gruppen- und 224.0.0.1 als Zieladresse für generelle Anfragen vorgesehen. Hinsichtlich des Standard-Intervalls orientiert sich die Protokollversion mit 125 Sekunden an dem direkten Vorgänger. Eine Neuerung ist die Option, die Quelle des Multicast-Streams gezielt auszuwählen. Dieses sogenannte quellenspezifische Multicasting (source-specific multicast) senkt die Anforderungen an das Netzwerk enorm und sorgt zudem auch für mehr Sicherheit bei der Übertragung, da nicht einfach beliebige und/oder unbekannte Quellen zum Einsatz kommen.
Der IGMP-Header ist auch in IGMPv3 in IP-Pakete (Protokollnummer 2) eingebunden, fällt allerdings wesentlich komplexer aus als bei den beiden Vorgängerprotokollen, was insbesondere auf die mögliche Angabe der Quelladresse zurückzuführen ist. Zudem gibt es konkrete Unterschiede zwischen Anfragen und Benachrichtigungen. Die Kopfzeile für IGMPv3-Gruppenanfragen sieht dabei folgendermaßen aus:
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.
Tipp
Inwiefern sich der Header des zweiten Nachrichtentyps (IGMPv3-Benachrichtigungen) von der hier präsentierten Kopfzeile der IGMPv3-Anfragen unterscheidet, ist in Kapitel 4.2 des RFCs 3376 nachzulesen.
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.

Wo kommt das Internet Group Management Protocol zur Anwendung?

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.
Hinweis
Viele Switches und Internet-Router bieten die Möglichkeit, den Multicast-Datenverkehr in Netzwerken zu filtern, um die Netzwerkleistung zu optimieren. Hierfür greifen die Geräte auf das sogenannte IGMP-Snooping zurück, das ebenfalls durch das Internet Group Management Protocol ermöglicht wird.
War dieser Artikel hilfreich?
Page top