Zusammenfassung
- IGMPv1 und v2 verteilten Antworten mit Zufallstimern. Hörte ein wartender Host einen gültigen Report für dieselbe Gruppe, stoppte er seinen Timer; gewöhnlich erhielt der Router nur den Nachweis, dass mindestens ein Mitglied am Link vorhanden war.
- Ein v2-Leave löste lediglich eine beschleunigte Prüfung aus. V3 entfernte die Unterdrückung zwischen Hosts, weil Quelllisten, Zustandsänderungen und portbezogenes Forwarding die Reports nicht mehr austauschbar machten.
Die Architektur begann mit einer kleineren Frage
Ein Multicast-Router muss entscheiden, ob er Daten der Gruppe G auf ein direkt angeschlossenes Netz weiterleitet. Dafür braucht er zunächst weder Namen noch Anzahl der Empfänger. Ein einziges verbleibendes Mitglied genügt, damit die richtige Entscheidung „weiterleiten“ lautet.
RFC 1112 vom August 1989 beschrieb die später als erste breit eingesetzte IGMP-Version bezeichnete Lösung. Mitgliedschaft war dynamisch und an eine Schnittstelle gebunden. Ein Sender musste der Gruppe nicht angehören. Der Router erhielt kein Verzeichnis von Personen, Prozessen oder dauerhaften Gruppeneigentümern.
Er erhielt einen eng begrenzten Fakt: Auf diesem Link existiert mindestens ein Interessent. Solange alle positiven Reports genau diese Frage beantworteten, konnte einer für die übrigen stehen.
Ein Zufallstimer bestimmte den vorläufigen Zeugen
Der Router schickte eine Host Membership Query mit TTL eins an 224.0.0.1. Jeder Host setzte für jede betroffene Gruppe auf der Empfangsschnittstelle einen eigenen zufälligen Timer zwischen null und zehn Sekunden.
Der erste abgelaufene Timer führte zu einem Membership Report an die Adresse der gemeldeten Gruppe, ebenfalls mit TTL eins. Andere Mitglieder am selben Link konnten ihn hören. Wartete ein Host noch auf seinen eigenen Timer, stoppte er ihn nach einem gültigen Report für G und sendete nichts.
Der Zufall entzerrte den Zeitpunkt; das Mithören verringerte die Menge. Im Normalfall entstand ein Report pro Gruppe statt einer Antwort pro Host. Der Gewinner erhielt kein Mandat. Bei der nächsten Query konnte ein anderer Timer zuerst ablaufen.
„Report Suppression“ bezeichnet daher keine ausgelöschte Mitgliedschaft. Unterdrückt wurde eine noch nicht gesendete, für die konkrete Routerentscheidung redundante Meldung. Für den Zustand G auf Schnittstelle I vorhanden hatte das zweite Ja keinen zusätzlichen Wert.
Anwesenheit musste erneuert werden
Periodische Queries hielten den Routerzustand frisch. Blieben Reports im vorgeschriebenen Ablauf aus, durfte der Router annehmen, dass keine lokalen Mitglieder mehr vorhanden waren, und von außen eintreffenden Verkehr für G nicht mehr auf den Link geben.
Die Mitgliedschaft war Soft State. Ein abgestürzter Host musste keine unmögliche Abmeldung nachholen; ohne erneuerte Evidenz lief sein Einfluss aus. Daraus folgt die bewusste Asymmetrie: Anwesenheit lässt sich schnell durch einen Zeugen belegen, die Abwesenheit aller erst nach einer erfolglosen Aufforderung an alle.
Ein neu beigetretener Host sendete deshalb sofort einen unaufgeforderten Report und wiederholte ihn nach kurzen zufälligen Wartezeiten. Als möglicherweise erstes Mitglied konnte er nicht auf die nächste periodische Query warten, ohne Daten zu verlieren.
Dieses Zeitmodell war kein Lieferbeleg. Es regelte lediglich, wann ein Router genügend lokale Empfangsevidenz besaß.
Leave bedeutete: bitte jetzt nachfragen
Mit RFC 2236 erschien IGMPv2 im November 1997. Max Response Time, Querier-Wahl, gruppenspezifische Queries und Leave Group sollten vor allem die Zeit verkürzen, in der Verkehr nach dem Weggang des letzten Hörers weiterfloss.
Ein Host, der sich als letzten Reporter der Gruppe erinnerte, sollte beim Austritt Leave an 224.0.0.2 senden. War er nicht der letzte Reporter gewesen, durfte er schweigen, weil kürzlich ein anderer Host Anwesenheit belegt hatte.
Letzter Reporter hieß aber nicht letztes Mitglied. Der Querier löschte G nach Leave nicht sofort. Er stellte in kurzen Abständen mehrere Group-Specific Queries. Jeder verbleibende Host konnte antworten und den Zustand erhalten. Erst wenn auch das letzte Antwortfenster leer blieb, galt die Gruppe lokal als verlassen.
Leave war ein Prüfimpuls, kein Urteil. Ein einzelner Host erhielt nicht die Macht, den Empfang anderer zu beenden. Befand sich ein v1-Mitglied in der Gruppe, musste ein v2-Router Leave sogar ignorieren, weil der ältere Host am neuen Austrittsverfahren nicht teilnehmen konnte.
Quellpräferenzen machten Reports unverwechselbar
IGMPv3 änderte den Gegenstand der Meldung. RFC 3376 spezifizierte v3 im Jahr 2002; RFC 9776 löste den Text 2025 mit kompatiblen Klarstellungen und Errata-Korrekturen als heutiger Standard ab.
Im Modus INCLUDE möchte ein System G nur von aufgelisteten Quellen empfangen. In EXCLUDE akzeptiert es alle Quellen außer einer Liste. Wünsche einzelner Sockets werden zum Schnittstellenzustand zusammengeführt. Group Records beschreiben aktuellen Zustand, Filtermoduswechsel, neu erlaubte oder künftig blockierte Quellen.
Zwei Mitglieder derselben Gruppe können dadurch verschiedene legitime Aussagen machen. Der eine Host verlangt S1, der andere S2. Source-Specific Multicast nach RFC 4607 bezeichnet den Kanal ausdrücklich als (S,G). Ein Report über S1 ersetzt keinen Report über S2.
Die v3-Entwurfsbegründung zieht daraus eine seltene Konsequenz: Sie entfernt die alte Host-Unterdrückung. Ein v3-Host bricht seinen Report nicht mehr ab, weil er einen anderen gehört hat. Router könnten hostbezogene Beobachtungen für Fast Leave oder Abrechnung benötigen; IGMP-snooping Bridges vertragen die Unterdrückung schlecht; Hosts erhalten eine einfachere Zustandsmaschine. Mehrere Group Records lassen sich außerdem in einem v3-Paket bündeln, sodass Effizienz ohne Informationsverlust möglich bleibt.
Die Zufallsverteilung blieb erhalten. Antworten auf eine General Query müssen innerhalb der Max Response Time gestreut werden und dürfen nicht alle sofort starten. V3 trennte den Schutz vor einer Antwortlawine von der Frage, ob fremde Evidenz die eigene ersetzen darf.
Ein Switch hörte keine gemeinsame Runde mehr
Die ursprüngliche Regel stellte sich den LAN-Link als gemeinsamen akustischen Raum vor. Ein Switch mit IGMP Snooping betrachtet dagegen einzelne Ports.
Eine normale Bridge flutet Multicast. Ein Snooping-Switch liest IGMP und baut eine portbezogene Weiterleitungstabelle. RFC 4541, ein informatives Dokument, empfiehlt Reports typischerweise nur zu Ports mit Multicast-Routern und nicht zu reinen Host-Ports weiterzugeben.
Wird ein v1/v2-Report doch zu einem anderen Host geflutet, kann dieser seinen eigenen Report unterdrücken. Der Router weiß nun, dass G irgendwo am Link existiert. Der Switch hat womöglich nie gelernt, dass auch der Port des schweigenden Hosts G benötigt, und schneidet den tatsächlichen Empfänger ab.
Dasselbe Paket stützte zwei Karten. Für den Router hieß es G auf diesem Link; für den Switch musste es G an diesem Port heißen. Die für die erste Entscheidung austauschbaren Zeugen waren es für die zweite nicht.
V3-Reports gehen an 224.0.0.22 und können mehrere Einträge tragen. Die Kompression verschwand nicht. Sie wanderte von der Auslassung eigenständiger Aussagen zur Bündelung, die ihre Unterschiede erhält.
Kompatibilität kann den Wortschatz zurücksetzen
Auf realen Netzen leben Versionen nebeneinander. Hört ein v3-Host eine ältere Query, startet er einen Kompatibilitätstimer und antwortet vorübergehend im alten Format. Router merken sich alte Mitglieder, weil deren Existenz die sichere Behandlung von Leave und Quellzustand verändert.
Ein einziges Altgerät kann damit eine Gruppe für eine Zeit auf gröbere Semantik zurückführen. Die Kompatibilität schützt laufenden Dienst, überlässt aber dem am wenigsten ausdrucksfähigen Teilnehmer die Grenze dessen, was der Link beweisen kann.
Für SSM verlangt RFC 9776 deshalb, dass ein SSM-fähiger Host seinen v3 Membership Record nicht durch einen v1- oder v2-Report unterdrücken lässt. Ein Dashboard mit der bloßen Anzeige „IGMP aktiv“ verbirgt diese semantische Herabstufung.
Empfangsinteresse war nie Berechtigung
IGMP meldet lokales IPv4-Multicast-Interesse an benachbarte Router. Es baut keinen weiträumigen Verteilbaum, authentifiziert keinen Abonnenten, erteilt kein Senderecht und garantiert keine Zustellung.
RFC 9776 stellt fest, dass IGMP keine Vertraulichkeit bietet. Geräte am Link können potenziell sensible Gruppeninteressen beobachten. Gefälschte Reports können Verkehr ohne echten Empfänger aufrechterhalten; gefälschte alte Reports können Kompatibilitätszustände verlängern und Fast Leave oder Quellfilter schwächen. TTL eins, Router Alert und On-Link-Adressprüfungen begrenzen manche Wege, sind aber kein kryptografischer Nachweis.
Die schmale Bedeutung ist die Stärke des Protokolls. Es gibt der Weiterleitung genügend Evidenz, ohne Nutzeridentität oder Anspruch zu behaupten. Wer daraus ein Zugangs- oder Abrechnungsregister macht, verleiht dem Signal nachträglich eine Autorität, die seine Grammatik nie trug.
Quellen und Grenzen
RFC 1112 definiert Zufallstimer und Unterdrückung, RFC 2236 Leave und Last-Member-Prüfung. RFC 3376 hält die historische v3-Begründung fest; RFC 9776 ist die aktuelle Spezifikation. RFC 4541 behandelt Snooping-Switches, RFC 4607 das (S,G)-Modell.
Die Dokumente belegen keine weltweite Verbreitung, Produktkonformität oder reale Identität eines Hörers. Die Deutung als Wandel der Beweisaustauschbarkeit folgt aus den Zustandsmodellen und ausdrücklich dokumentierten Entwurfsgründen.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
