RFC 3376 - Internet Group Management Protocol, Version 3 (Internet Group Management Protocol, Version 3)

• Veröffentlicht: October 2002
• Errata: Keine Errata

---

Status of this Memo (Status dieses Memos)

Dieses Dokument spezifiziert ein Internet-Standards-Track-Protokoll für die Internet-Community und bittet um Diskussion und Verbesserungsvorschläge. Bitte beziehen Sie sich auf die aktuelle Ausgabe der "Internet Official Protocol Standards" (STD 1) für den Standardisierungsstatus und Status dieses Protokolls. Die Verteilung dieses Memos ist unbegrenzt.

Copyright Notice (Urheberrechtshinweis)

Abstract (Zusammenfassung)

Dieses Dokument spezifiziert Version 3 des Internet Group Management Protocol, IGMPv3. IGMP ist das Protokoll, das von IPv4-Systemen verwendet wird, um ihre IP-Multicast-Gruppenmitgliedschaften an benachbarte Multicast-Router zu melden. Version 3 von IGMP fügt Unterstützung für "Quellfilterung" (source filtering) hinzu, d. h. die Fähigkeit eines Systems, Interesse am Empfang von Paketen nur von bestimmten Quelladressen oder von allen außer bestimmten Quelladressen zu melden, die an eine bestimmte Multicast-Adresse gesendet werden. Diese Informationen können von Multicast-Routing-Protokollen verwendet werden, um die Zustellung von Multicast-Paketen von bestimmten Quellen an Netzwerke zu vermeiden, in denen es keine interessierten Empfänger gibt.

Contents (Inhalt)

• 1. Introduction (Einführung)
• 2. The Service Interface for Requesting IP Multicast Reception (Die Serviceschnittstelle zum Anfordern des IP-Multicast-Empfangs)
• 3. Multicast Reception State Maintained by Systems (Von Systemen verwalteter Multicast-Empfangsstatus)
• 4. Message Formats (Nachrichtenformate)
• 5. Description of the Protocol for Group Members (Beschreibung des Protokolls für Gruppenmitglieder)
• 6. Description of the Protocol for Multicast Routers (Beschreibung des Protokolls für Multicast-Router)
• 7. Interoperation With Older Versions of IGMP (Zusammenarbeit mit älteren Versionen von IGMP)
• 8. List of Timers, Counters and Their Default Values (Liste der Timer, Zähler und ihrer Standardwerte)
• 9. Security Considerations (Sicherheitsüberlegungen)
• 10. IANA Considerations (IANA-Überlegungen)
• 11. Acknowledgments (Danksagung)
• 12. References (Referenzen)
• Appendix A. Design Rationale (Anhang A. Entwurfsbegründung)
• Appendix B. Summary of Changes from IGMPv2 (Anhang B. Zusammenfassung der Änderungen gegenüber IGMPv2)
• Author's Address (Adresse des Autors)

---

1. Introduction (Einführung)

Das Internet Group Management Protocol (IGMP) wird von IPv4-Systemen (Hosts und Routern) verwendet, um ihre IP-Multicast-Gruppenmitgliedschaften an benachbarte Multicast-Router zu melden. Beachten Sie, dass ein IP-Multicast-Router selbst Mitglied einer oder mehrerer Multicast-Gruppen sein kann. In diesem Fall führt er sowohl den „Multicast-Router-Teil“ des Protokolls aus (um die von seinem Multicast-Routing-Protokoll benötigten Mitgliedschaftsinformationen zu sammeln) als auch den „Gruppenmitglied-Teil“ des Protokolls (um sich selbst und andere benachbarte Multicast-Router über seine Mitgliedschaften zu informieren).

IGMP wird auch für andere IP-Multicast-Verwaltungsfunktionen verwendet, wobei andere Nachrichtentypen als die für die Meldung der Gruppenmitgliedschaft verwendeten verwendet werden. Dieses Dokument spezifiziert nur die Funktionen und Nachrichten zur Meldung der Gruppenmitgliedschaft.

Dieses Dokument spezifiziert Version 3 von IGMP. Version 1, spezifiziert in [RFC-1112], war die erste weit verbreitete Version und die erste Version, die zu einem Internetstandard wurde. Version 2, spezifiziert in [RFC-2236], fügte Unterstützung für „geringe Austrittslatenz“ (low leave latency) hinzu, d. h. eine Verkürzung der Zeit, die ein Multicast-Router benötigt, um zu erfahren, dass in einem angeschlossenen Netzwerk keine Mitglieder einer bestimmten Gruppe mehr vorhanden sind. Version 3 fügt Unterstützung für „Quellfilterung“ (source filtering) hinzu, d. h. die Fähigkeit eines Systems, Interesse am Empfang von Paketen nur von bestimmten Quelladressen (wie zur Unterstützung von Quellenspezifischem Multicast [SSM] erforderlich) oder von allen außer bestimmten Quelladressen zu melden, die an eine bestimmte Multicast-Adresse gesendet werden. Version 3 ist so konzipiert, dass sie mit den Versionen 1 und 2 interoperabel ist.

Multicast Listener Discovery (MLD) wird von IPv6-Systemen auf ähnliche Weise verwendet. MLD Version 1 [MLD] implementiert die Funktionalität von IGMP Version 2; MLD Version 2 [MLDv2] implementiert die Funktionalität von IGMP Version 3.

Die großgeschriebenen Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC-2119] beschrieben zu interpretieren. Aufgrund des Fehlens von Kursivschrift wird die Betonung hier durch das Einklammern eines Wortes oder einer Phrase in "*"-Zeichen angezeigt.

---

2. The Service Interface for Requesting IP Multicast Reception (Die Serviceschnittstelle zum Anfordern des IP-Multicast-Empfangs)

Innerhalb eines IP-Systems gibt es (zumindest konzeptionell) eine Serviceschnittstelle, die von Protokollen der oberen Schicht oder Anwendungsprogrammen verwendet wird, um die IP-Schicht aufzufordern, den Empfang von Paketen zu aktivieren und zu deaktivieren, die an bestimmte IP-Multicast-Adressen gesendet werden. Um die Fähigkeiten von IGMPv3 voll auszuschöpfen, muss die IP-Serviceschnittstelle eines Systems die folgende Operation unterstützen:

IPMulticastListen ( socket, interface, multicast-address,
                    filter-mode, source-list )

• "socket" ist ein implementierungsspezifischer Parameter, der verwendet wird, um zwischen verschiedenen anfordernden Entitäten (z. B. Programmen oder Prozessen) innerhalb des Systems zu unterscheiden; der Socket-Parameter von BSD Unix-Systemaufrufen ist ein spezifisches Beispiel.

• "interface" ist ein lokaler Bezeichner der Netzwerkschnittstelle, auf der der Empfang der angegebenen Multicast-Adresse aktiviert oder deaktiviert werden soll. Schnittstellen können physisch (z. B. eine Ethernet-Schnittstelle) oder virtuell (z. B. der Endpunkt einer Frame Relay-Verbindung oder der Endpunkt eines IP-in-IP-"Tunnels") sein. Eine Implementierung kann zulassen, dass ein spezieller "unspezifizierter" Wert als Schnittstellenparameter übergeben wird; in diesem Fall würde die Anforderung für die "primäre" oder "Standard"-Schnittstelle des Systems gelten (möglicherweise durch Systemkonfiguration festgelegt). Wenn der Empfang derselben Multicast-Adresse auf mehr als einer Schnittstelle gewünscht wird, wird IPMulticastListen für jede gewünschte Schnittstelle separat aufgerufen.

• "multicast-address" ist die IP-Multicast-Adresse oder Gruppe, auf die sich die Anforderung bezieht. Wenn der Empfang von mehr als einer Multicast-Adresse auf einer bestimmten Schnittstelle gewünscht wird, wird IPMulticastListen für jede gewünschte Multicast-Adresse separat aufgerufen.

• "filter-mode" kann entweder INCLUDE oder EXCLUDE sein. Im INCLUDE-Modus wird der Empfang von Paketen, die an die angegebene Multicast-Adresse gesendet werden, nur von den im source-list-Parameter aufgeführten IP-Quelladressen angefordert. Im EXCLUDE-Modus wird der Empfang von Paketen, die an die angegebene Multicast-Adresse gesendet werden, von allen IP-Quelladressen angefordert, außer denen, die im source-list-Parameter aufgeführt sind.

• "source-list" ist eine ungeordnete Liste von null oder mehr IP-Unicast-Adressen, von denen der Multicast-Empfang je nach Filtermodus gewünscht oder nicht gewünscht wird. Eine Implementierung DARF eine Begrenzung für die Größe von Quelllisten festlegen, aber diese Begrenzung DARF NICHT weniger als 64 Adressen pro Liste betragen. Wenn eine Operation dazu führt, dass die Größenbeschränkung der Quellliste überschritten wird, MUSS die Serviceschnittstelle einen Fehler zurückgeben.

Für eine gegebene Kombination von Socket, Schnittstelle und Multicast-Adresse kann zu jeder Zeit nur ein einziger Filtermodus und eine einzige Quellliste wirksam sein. Entweder der Filtermodus oder die Quellliste oder beides können jedoch durch nachfolgende IPMulticastListen-Anforderungen geändert werden, die denselben Socket, dieselbe Schnittstelle und dieselbe Multicast-Adresse angeben. Jede nachfolgende Anforderung ersetzt jede frühere Anforderung für den angegebenen Socket, die Schnittstelle und die Multicast-Adresse vollständig.

Frühere Versionen von IGMP unterstützten keine Quellfilter und verfügten über eine einfachere Serviceschnittstelle, die aus Join- und Leave-Operationen bestand, um den Empfang einer bestimmten Multicast-Adresse (von allen Quellen) auf einer bestimmten Schnittstelle zu aktivieren und zu deaktivieren. Die entsprechenden Operationen in der neuen Serviceschnittstelle folgen:

The Join operation is equivalent to

Die Join-Operation entspricht

IPMulticastListen ( socket, interface, multicast-address,
                    EXCLUDE, {} )

und die Leave-Operation entspricht:

IPMulticastListen ( socket, interface, multicast-address,
                    INCLUDE, {} )

wobei {} eine leere Quellliste ist.

Ein Beispiel für eine API, die die in dieser Serviceschnittstelle beschriebenen Funktionen bereitstellt, findet sich in [FILTER-API].

---

3. Multicast Reception State Maintained by Systems (Von Systemen verwalteter Multicast-Empfangsstatus)

3.1. Socket State (Socket-Status)

Für jeden Socket, auf dem IPMulticastListen aufgerufen wurde, zeichnet das System den gewünschten Multicast-Empfangsstatus für diesen Socket auf. Dieser Status besteht konzeptionell aus einer Reihe von Datensätzen der Form:

(interface, multicast-address, filter-mode, source-list)

Der Socket-Status entwickelt sich als Reaktion auf jeden Aufruf von IPMulticastListen auf dem Socket wie folgt:

• Wenn der angeforderte Filtermodus INCLUDE ist und die angeforderte Quellliste leer ist, wird der Eintrag, der der angeforderten Schnittstelle und Multicast-Adresse entspricht, gelöscht, falls vorhanden. Wenn kein solcher Eintrag vorhanden ist, wird die Anforderung ignoriert.

• Wenn der angeforderte Filtermodus EXCLUDE ist oder die angeforderte Quellliste nicht leer ist, wird der Eintrag, der der angeforderten Schnittstelle und Multicast-Adresse entspricht, falls vorhanden, so geändert, dass er den angeforderten Filtermodus und die Quellliste enthält. Wenn kein solcher Eintrag vorhanden ist, wird unter Verwendung der in der Anforderung angegebenen Parameter ein neuer Eintrag erstellt.

3.2. Interface State (Schnittstellenstatus)

Zusätzlich zum Multicast-Empfangsstatus pro Socket muss ein System auch den Multicast-Empfangsstatus für jede seiner Schnittstellen verwalten oder berechnen. Dieser Status besteht konzeptionell aus einer Reihe von Datensätzen der Form:

(multicast-address, filter-mode, source-list)

Für eine bestimmte Schnittstelle existiert höchstens ein Datensatz pro Multicast-Adresse. Dieser Status pro Schnittstelle wird vom Status pro Socket abgeleitet, kann sich jedoch vom Status pro Socket unterscheiden, wenn verschiedene Sockets unterschiedliche Filtermodi und/oder Quelllisten für dieselbe Multicast-Adresse und Schnittstelle haben. Nehmen wir beispielsweise an, eine Anwendung oder ein Prozess ruft die folgende Operation auf Socket s1 auf:

IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )

und fordert den Empfang von Paketen auf Schnittstelle i an, die an die Multicast-Adresse m gesendet werden, nur wenn sie von Quelle a, b oder c stammen. Nehmen wir an, eine andere Anwendung oder ein anderer Prozess ruft die folgende Operation auf Socket s2 auf:

IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )

und fordert den Empfang von Paketen auf derselben Schnittstelle i an, die an dieselbe Multicast-Adresse m gesendet werden, nur wenn sie von den Quellen b, c oder d stammen. Um die Empfangsanforderungen beider Sockets zu erfüllen, ist es notwendig, dass Schnittstelle i Pakete empfängt, die von einer der Quellen a, b, c oder d an m gesendet werden. Daher hat in diesem Beispiel der Empfangsstatus der Schnittstelle i für die Multicast-Adresse m den Filtermodus INCLUDE und die Quellliste {a, b, c, d}.

Nachdem ein Multicast-Paket von der IP-Schicht von einer Schnittstelle akzeptiert wurde, hängt seine anschließende Zustellung an die Anwendung oder den Prozess, die/der auf einem bestimmten Socket lauscht, vom Multicast-Empfangsstatus dieses Sockets ab [und möglicherweise auch von anderen Bedingungen, z. B. an welchen Transport-Layer-Port der Socket gebunden ist]. Im obigen Beispiel wird also ein Paket, das auf Schnittstelle i ankommt, für die Multicast-Adresse m bestimmt ist und die Quelladresse a hat, an Socket s1, aber nicht an Socket s2 zugestellt. Beachten Sie, dass IGMP-Abfragen und -Berichte keiner Quellfilterung unterliegen und immer von Hosts und Routern verarbeitet werden müssen.

Das Filtern von Paketen basierend auf dem Multicast-Empfangsstatus eines Sockets ist eine neue Funktion dieser Serviceschnittstelle. Die vorherige Serviceschnittstelle [RFC1112] beschrieb keine Filterung basierend auf dem Multicast-Join-Status; vielmehr bewirkte ein Join auf einem Socket einfach, dass der Host einer Gruppe auf der angegebenen Schnittstelle beitrat, und Pakete, die für diese Gruppe bestimmt waren, konnten an alle Sockets zugestellt werden, unabhängig davon, ob sie beigetreten waren oder nicht.

Die allgemeinen Regeln zum Ableiten des Status pro Schnittstelle aus dem Status pro Socket lauten wie folgt: Für jedes eindeutige Paar (Schnittstelle, Multicast-Adresse), das in einem Socket-Status vorkommt, wird ein Datensatz pro Schnittstelle für diese Multicast-Adresse auf dieser Schnittstelle erstellt. Unter Berücksichtigung aller Socket-Datensätze, die dasselbe Paar (Schnittstelle, Multicast-Adresse) enthalten,

• wenn irgendein solcher Datensatz einen Filtermodus von EXCLUDE hat, dann ist der Filtermodus des Schnittstellendatensatzes EXCLUDE, und die Quellliste des Schnittstellendatensatzes ist die Schnittmenge der Quelllisten aller Socket-Datensätze im EXCLUDE-Modus, abzüglich der Quelladressen, die in einem Socket-Datensatz im INCLUDE-Modus vorkommen. Wenn beispielsweise die Socket-Datensätze für die Multicast-Adresse m auf der Schnittstelle i wie folgt lauten:

from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
from socket s3:  ( i, m, INCLUDE, {d, e, f} )

( m, EXCLUDE, {b, c} )

Wenn ein vierter Socket hinzugefügt wird, wie z. B.:

from socket s4:  ( i, m, EXCLUDE, {} )

dann wird der Schnittstellendatensatz zu:

( m, EXCLUDE, {} )

• wenn alle solchen Datensätze einen Filtermodus von INCLUDE haben, dann ist der Filtermodus des Schnittstellendatensatzes INCLUDE, und die Quellliste des Schnittstellendatensatzes ist die Vereinigung der Quelllisten aller Socket-Datensätze. Wenn beispielsweise die Socket-Datensätze für die Multicast-Adresse m auf der Schnittstelle i wie folgt lauten:

from socket s1:  ( i, m, INCLUDE, {a, b, c} )
from socket s2:  ( i, m, INCLUDE, {b, c, d} )
from socket s3:  ( i, m, INCLUDE, {e, f} )

( m, INCLUDE, {a, b, c, d, e, f} )

Eine Implementierung DARF KEINEN EXCLUDE-Schnittstellendatensatz verwenden, um eine Gruppe darzustellen, wenn sich alle Sockets für diese Gruppe im INCLUDE-Status befinden. Wenn beim Berechnen einer Schnittstellenstatus-Quellliste Systemressourcengrenzen erreicht werden, MUSS ein Fehler an die Anwendung zurückgegeben werden, die die Operation angefordert hat.

Die oben genannten Regeln zum Ableiten des Schnittstellenstatus werden (neu) bewertet, wann immer ein IPMulticastListen-Aufruf den Socket-Status durch Hinzufügen, Löschen oder Ändern eines Datensatzes pro Socket ändert. Beachten Sie, dass eine Änderung des Socket-Status nicht unbedingt zu einer Änderung des Schnittstellenstatus führt.

---

4. Nachrichtenformate

IGMP-Nachrichten werden in IPv4-Datagrammen eingekapselt, mit einer IP-Protokollnummer von 2. Jede in diesem Dokument beschriebene IGMP-Nachricht wird mit einer IP Time-to-Live von 1, IP Precedence von Internetwork Control (z.B. Type of Service 0xc0) gesendet und trägt eine IP Router Alert-Option [RFC-2113] in ihrem IP-Header. IGMP-Nachrichtentypen werden von der IANA [IANA-REG] wie in [RFC-3228] beschrieben registriert.

Es gibt zwei IGMP-Nachrichtentypen, die für das in diesem Dokument beschriebene IGMPv3-Protokoll relevant sind:

Type Number (hex)	Message Name
0x11	Membership Query
0x22	Version 3 Membership Report

Eine Implementierung von IGMPv3 MUSS auch die folgenden drei Nachrichtentypen unterstützen, für die Interoperation mit früheren Versionen von IGMP (siehe Abschnitt 7):

Type Number (hex)	Message Name	Reference
0x12	Version 1 Membership Report	[RFC-1112]
0x16	Version 2 Membership Report	[RFC-2236]
0x17	Version 2 Leave Group	[RFC-2236]

Nicht erkannte Nachrichtentypen MÜSSEN stillschweigend ignoriert werden. Andere Nachrichtentypen können von neueren Versionen oder Erweiterungen von IGMP, von Multicast-Routing-Protokollen oder für andere Verwendungen genutzt werden.

In diesem Dokument beziehen sich die großgeschriebenen Wörter "Query" und "Report", sofern nicht anders angegeben, auf IGMP Membership Queries bzw. IGMP Version 3 Membership Reports.

4.1. Membership Query-Nachricht

Membership Queries werden von IP-Multicast-Routern gesendet, um den Multicast-Empfangsstatus benachbarter Schnittstellen abzufragen. Queries haben das folgende Format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x11  | Max Resp Code |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                              .                              -+
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1. Max Resp Code

Das Feld Max Resp Code spezifiziert die maximale Zeit, die vor dem Senden eines antwortenden Reports erlaubt ist. Die tatsächlich erlaubte Zeit, genannt Max Resp Time, wird in Einheiten von 1/10 Sekunde dargestellt und aus dem Max Resp Code wie folgt abgeleitet:

Wenn Max Resp Code < 128, Max Resp Time = Max Resp Code

Wenn Max Resp Code >= 128, repräsentiert Max Resp Code einen Gleitkommawert wie folgt:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |1| exp | mant  |
   +-+-+-+-+-+-+-+-+

Max Resp Time = (mant | 0x10) << (exp + 3)

Kleine Werte von Max Resp Time ermöglichen es IGMPv3-Routern, die "Leave Latency" (die Zeit zwischen dem Moment, in dem der letzte Host eine Gruppe verlässt, und dem Moment, in dem das Routing-Protokoll benachrichtigt wird, dass es keine Mitglieder mehr gibt) zu optimieren. Größere Werte, insbesondere im exponentiellen Bereich, ermöglichen die Optimierung der Burstiness des IGMP-Verkehrs in einem Netzwerk.

4.1.2. Checksum

Die Checksum ist das 16-Bit-Einerkomplement der Einerkomplementsumme der gesamten IGMP-Nachricht (die gesamte IP-Nutzlast). Für die Berechnung der Checksum wird das Checksum-Feld auf Null gesetzt. Beim Empfang von Paketen MUSS die Checksum überprüft werden, bevor ein Paket verarbeitet wird. [RFC-1071]

4.1.3. Group Address

Das Feld Group Address wird beim Senden einer General Query auf Null gesetzt und beim Senden einer Group-Specific Query oder Group-and-Source-Specific Query auf die abgefragte IP-Multicast-Adresse gesetzt (siehe Abschnitt 4.1.9 unten).

4.1.4. Resv (Reserved)

Das Feld Resv wird beim Senden auf Null gesetzt und beim Empfang ignoriert.

4.1.5. S Flag (Suppress Router-Side Processing)

Wenn auf eins gesetzt, zeigt das S Flag allen empfangenden Multicast-Routern an, dass sie die normalen Timer-Updates unterdrücken sollen, die sie beim Hören einer Query durchführen. Es unterdrückt jedoch nicht die Querier-Wahl oder die normale "Host-seitige" Verarbeitung einer Query, die ein Router möglicherweise als Folge davon durchführen muss, dass er selbst ein Gruppenmitglied ist.

4.1.6. QRV (Querier's Robustness Variable)

Wenn ungleich Null, enthält das QRV-Feld den [Robustness Variable]-Wert, der vom Querier verwendet wird, d.h. dem Absender der Query. Wenn die [Robustness Variable] des Queriers 7 überschreitet, den Maximalwert des QRV-Felds, wird QRV auf Null gesetzt. Router übernehmen den QRV-Wert aus der zuletzt empfangenen Query als ihren eigenen [Robustness Variable]-Wert, es sei denn, dieser zuletzt empfangene QRV war Null, in diesem Fall verwenden die Empfänger den in Abschnitt 8.1 angegebenen Standard-[Robustness Variable]-Wert oder einen statisch konfigurierten Wert.

4.1.7. QQIC (Querier's Query Interval Code)

Das Feld Querier's Query Interval Code spezifiziert das [Query Interval], das vom Querier verwendet wird. Das tatsächliche Intervall, genannt Querier's Query Interval (QQI), wird in Einheiten von Sekunden dargestellt und aus dem Querier's Query Interval Code wie folgt abgeleitet:

Wenn QQIC < 128, QQI = QQIC

Wenn QQIC >= 128, repräsentiert QQIC einen Gleitkommawert wie folgt:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |1| exp | mant  |
   +-+-+-+-+-+-+-+-+

QQI = (mant | 0x10) << (exp + 3)

Multicast-Router, die nicht der aktuelle Querier sind, übernehmen den QQI-Wert aus der zuletzt empfangenen Query als ihren eigenen [Query Interval]-Wert, es sei denn, dieser zuletzt empfangene QQI war Null, in diesem Fall verwenden die empfangenden Router den in Abschnitt 8.2 angegebenen Standard-[Query Interval]-Wert.

4.1.8. Number of Sources (N)

Das Feld Number of Sources (N) gibt an, wie viele Quelladressen in der Query vorhanden sind. Diese Zahl ist Null in einer General Query oder einer Group-Specific Query und ungleich Null in einer Group-and-Source-Specific Query. Diese Zahl wird durch die MTU des Netzwerks begrenzt, über das die Query übertragen wird. Zum Beispiel verbraucht bei einem Ethernet mit einer MTU von 1500 Oktetten der IP-Header einschließlich der Router Alert-Option 24 Oktette, und die IGMP-Felder bis einschließlich des Felds Number of Sources (N) verbrauchen 12 Oktette, wodurch 1464 Oktette für Quelladressen verbleiben, was die Anzahl der Quelladressen auf 366 (1464/4) begrenzt.

4.1.9. Source Address [i]

Die Felder Source Address [i] sind ein Vektor von n IP-Unicast-Adressen, wobei n der Wert im Feld Number of Sources (N) ist.

4.1.10. Additional Data

Wenn das Packet Length-Feld im IP-Header einer empfangenen Query anzeigt, dass zusätzliche Daten-Oktette über die hier beschriebenen Felder hinaus vorhanden sind, MÜSSEN IGMPv3-Implementierungen diese Oktette in die Berechnung zur Überprüfung der empfangenen IGMP-Checksum einbeziehen, aber diese zusätzlichen Oktette ansonsten ignorieren. Beim Senden einer Query DARF eine IGMPv3-Implementierung KEINE zusätzlichen Oktette über die hier beschriebenen Felder hinaus einschließen.

4.1.11. Query-Varianten

Es gibt drei Varianten der Query-Nachricht:

1. Eine "General Query" wird von einem Multicast-Router gesendet, um den vollständigen Multicast-Empfangsstatus der benachbarten Schnittstellen zu erfahren (d.h. die Schnittstellen, die an das Netzwerk angeschlossen sind, auf dem die Query übertragen wird). In einer General Query sind sowohl das Feld Group Address als auch das Feld Number of Sources (N) Null.

2. Eine "Group-Specific Query" wird von einem Multicast-Router gesendet, um den Empfangsstatus in Bezug auf eine einzelne Multicast-Adresse der benachbarten Schnittstellen zu erfahren. In einer Group-Specific Query enthält das Feld Group Address die interessierende Multicast-Adresse, und das Feld Number of Sources (N) enthält Null.

3. Eine "Group-and-Source-Specific Query" wird von einem Multicast-Router gesendet, um zu erfahren, ob eine benachbarte Schnittstelle den Empfang von Paketen wünscht, die an eine bestimmte Multicast-Adresse von einer bestimmten Liste von Quellen gesendet werden. In einer Group-and-Source-Specific Query enthält das Feld Group Address die interessierende Multicast-Adresse, und die Felder Source Address [i] enthalten die interessierenden Quelladresse(n).

4.1.12. IP-Zieladressen für Queries

In IGMPv3 werden General Queries mit einer IP-Zieladresse von 224.0.0.1, der All-Systems-Multicast-Adresse, gesendet. Group-Specific und Group-and-Source-Specific Queries werden mit einer IP-Zieladresse gesendet, die der interessierenden Multicast-Adresse entspricht. Jedoch MUSS ein System jede Query akzeptieren und verarbeiten, deren IP Destination Address-Feld eine der Adressen (Unicast oder Multicast) enthält, die der Schnittstelle zugewiesen sind, auf der die Query ankommt.

4.2. Version 3 Membership Report-Nachricht

Version 3 Membership Reports werden von IP-Systemen gesendet, um (an benachbarte Router) den aktuellen Multicast-Empfangsstatus oder Änderungen im Multicast-Empfangsstatus ihrer Schnittstellen zu melden. Reports haben das folgende Format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x22  |    Reserved   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |  Number of Group Records (M)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [1]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [2]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   .                               .                               .
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [M]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

wobei jeder Group Record das folgende interne Format hat:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Multicast Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                                                             -+
   .                               .                               .
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                         Auxiliary Data                        .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.1. Reserved

Die Reserved-Felder werden beim Senden auf Null gesetzt und beim Empfang ignoriert.

4.2.2. Checksum

Die Checksum ist das 16-Bit-Einerkomplement der Einerkomplementsumme der gesamten IGMP-Nachricht (die gesamte IP-Nutzlast). Für die Berechnung der Checksum wird das Checksum-Feld auf Null gesetzt. Beim Empfang von Paketen MUSS die Checksum überprüft werden, bevor eine Nachricht verarbeitet wird.

4.2.3. Number of Group Records (M)

Das Feld Number of Group Records (M) gibt an, wie viele Group Records in diesem Report vorhanden sind.

4.2.4. Group Record

Jeder Group Record ist ein Block von Feldern, der Informationen über die Mitgliedschaft des Absenders in einer einzelnen Multicast-Gruppe auf der Schnittstelle enthält, von der der Report gesendet wird.

4.2.5. Record Type

4.2.6. Aux Data Len

Das Feld Aux Data Len enthält die Länge des Auxiliary Data-Felds in diesem Group Record in Einheiten von 32-Bit-Wörtern. Es kann Null enthalten, um das Fehlen von Zusatzdaten anzuzeigen.

4.2.7. Number of Sources (N)

Das Feld Number of Sources (N) gibt an, wie viele Quelladressen in diesem Group Record vorhanden sind.

4.2.8. Multicast Address

Das Feld Multicast Address enthält die IP-Multicast-Adresse, auf die sich dieser Group Record bezieht.

4.2.9. Source Address [i]

Die Felder Source Address [i] sind ein Vektor von n IP-Unicast-Adressen, wobei n der Wert im Feld Number of Sources (N) dieses Records ist.

4.2.10. Auxiliary Data

Das Feld Auxiliary Data, falls vorhanden, enthält zusätzliche Informationen zu diesem Group Record. Das in diesem Dokument spezifizierte Protokoll, IGMPv3, definiert keine Zusatzdaten. Daher MÜSSEN Implementierungen von IGMPv3 keine Zusatzdaten einschließen (d.h. MÜSSEN das Feld Aux Data Len auf Null setzen) in jedem übertragenen Group Record und MÜSSEN alle in einem empfangenen Group Record vorhandenen Zusatzdaten ignorieren. Die Semantik und interne Kodierung des Auxiliary Data-Felds sind durch jede zukünftige Version oder Erweiterung von IGMP zu definieren, die dieses Feld verwendet.

4.2.11. Additional Data

Wenn das Packet Length-Feld im IP-Header eines empfangenen Reports anzeigt, dass zusätzliche Daten-Oktette über den letzten Group Record hinaus vorhanden sind, MÜSSEN IGMPv3-Implementierungen diese Oktette in die Berechnung zur Überprüfung der empfangenen IGMP-Checksum einbeziehen, aber diese zusätzlichen Oktette ansonsten ignorieren. Beim Senden eines Reports DARF eine IGMPv3-Implementierung KEINE zusätzlichen Oktette über den letzten Group Record hinaus einschließen.

4.2.12. Group Record Types

Es gibt eine Reihe verschiedener Typen von Group Records, die in einer Report-Nachricht enthalten sein können:

• Ein "Current-State Record" wird von einem System als Antwort auf eine auf einer Schnittstelle empfangene Query gesendet. Er meldet den aktuellen Empfangsstatus dieser Schnittstelle in Bezug auf eine einzelne Multicast-Adresse. Der Record Type eines Current-State Records kann einer der folgenden beiden Werte sein:

  Value	Name and Meaning
  1	MODE_IS_INCLUDE - zeigt an, dass die Schnittstelle einen Filtermodus von INCLUDE für die angegebene Multicast-Adresse hat. Die Felder Source Address [i] in diesem Group Record enthalten die Quellliste der Schnittstelle für die angegebene Multicast-Adresse, falls diese nicht leer ist.
  2	MODE_IS_EXCLUDE - zeigt an, dass die Schnittstelle einen Filtermodus von EXCLUDE für die angegebene Multicast-Adresse hat. Die Felder Source Address [i] in diesem Group Record enthalten die Quellliste der Schnittstelle für die angegebene Multicast-Adresse, falls diese nicht leer ist.

• Ein "Filter-Mode-Change Record" wird von einem System gesendet, wann immer eine lokale Invokation von IPMulticastListen eine Änderung des Filtermodus (d.h. eine Änderung von INCLUDE zu EXCLUDE oder von EXCLUDE zu INCLUDE) des Schnittstellenzustandseintrags für eine bestimmte Multicast-Adresse verursacht. Der Record wird in einem Report aufgenommen, der von der Schnittstelle gesendet wird, auf der die Änderung aufgetreten ist. Der Record Type eines Filter-Mode-Change Records kann einer der folgenden beiden Werte sein:

  Value	Name and Meaning
  3	CHANGE_TO_INCLUDE_MODE - zeigt an, dass die Schnittstelle für die angegebene Multicast-Adresse in den INCLUDE-Filtermodus gewechselt hat. Die Felder Source Address [i] in diesem Group Record enthalten die neue Quellliste der Schnittstelle für die angegebene Multicast-Adresse, falls diese nicht leer ist.
  4	CHANGE_TO_EXCLUDE_MODE - zeigt an, dass die Schnittstelle für die angegebene Multicast-Adresse in den EXCLUDE-Filtermodus gewechselt hat. Die Felder Source Address [i] in diesem Group Record enthalten die neue Quellliste der Schnittstelle für die angegebene Multicast-Adresse, falls diese nicht leer ist.

• Ein "Source-List-Change Record" wird von einem System gesendet, wann immer eine lokale Invokation von IPMulticastListen eine Änderung der Quellliste verursacht, die nicht mit einer Änderung des Filtermodus des Schnittstellenzustandseintrags für eine bestimmte Multicast-Adresse zusammenfällt. Der Record wird in einem Report aufgenommen, der von der Schnittstelle gesendet wird, auf der die Änderung aufgetreten ist. Der Record Type eines Source-List-Change Records kann einer der folgenden beiden Werte sein:

  Value	Name and Meaning
  5	ALLOW_NEW_SOURCES - zeigt an, dass die Felder Source Address [i] in diesem Group Record eine Liste der zusätzlichen Quellen enthalten, von denen das System für Pakete hören möchte, die an die angegebene Multicast-Adresse gesendet werden. Wenn die Änderung an einer INCLUDE-Quellliste erfolgte, sind dies die Adressen, die der Liste hinzugefügt wurden; wenn die Änderung an einer EXCLUDE-Quellliste erfolgte, sind dies die Adressen, die aus der Liste gelöscht wurden.
  6	BLOCK_OLD_SOURCES - zeigt an, dass die Felder Source Address [i] in diesem Group Record eine Liste der Quellen enthalten, von denen das System nicht mehr hören möchte, für Pakete, die an die angegebene Multicast-Adresse gesendet werden. Wenn die Änderung an einer INCLUDE-Quellliste erfolgte, sind dies die Adressen, die aus der Liste gelöscht wurden; wenn die Änderung an einer EXCLUDE-Quellliste erfolgte, sind dies die Adressen, die der Liste hinzugefügt wurden.

Wenn eine Änderung der Quellliste sowohl das Zulassen neuer Quellen als auch das Blockieren alter Quellen zur Folge hat, werden zwei Group Records für dieselbe Multicast-Adresse gesendet, einer vom Typ ALLOW_NEW_SOURCES und einer vom Typ BLOCK_OLD_SOURCES.

Wir verwenden den Begriff "State-Change Record", um entweder einen Filter-Mode-Change Record oder einen Source-List-Change Record zu bezeichnen.

Nicht erkannte Record Type-Werte MÜSSEN stillschweigend ignoriert werden.

4.2.13. IP-Quelladressen für Reports

Ein IGMP-Report wird mit einer gültigen IP-Quelladresse für das Zielnetz gesendet. Die Quelladresse 0.0.0.0 kann von einem System verwendet werden, das noch keine IP-Adresse erworben hat. Beachten Sie, dass die Quelladresse 0.0.0.0 gleichzeitig von mehreren Systemen in einem LAN verwendet werden kann. Router MÜSSEN einen Report mit einer Quelladresse von 0.0.0.0 akzeptieren.

4.2.14. IP-Zieladressen für Reports

Version 3 Reports werden mit einer IP-Zieladresse von 224.0.0.22 gesendet, auf die alle IGMPv3-fähigen Multicast-Router hören. Ein System, das im Version 1- oder Version 2-Kompatibilitätsmodus arbeitet, sendet Version 1- oder Version 2-Reports an die im Feld Group Address des Reports angegebene Multicast-Gruppe. Darüber hinaus MUSS ein System jeden Version 1- oder Version 2-Report akzeptieren und verarbeiten, dessen IP Destination Address-Feld eine der Adressen (Unicast oder Multicast) enthält, die der Schnittstelle zugewiesen sind, auf der der Report ankommt.

4.2.15. Notation für Group Records

Im Rest dieses Dokuments verwenden wir die folgende Notation, um den Inhalt eines Group Records zu beschreiben, der sich auf eine bestimmte Multicast-Adresse bezieht:

   IS_IN ( x )  -  Type MODE_IS_INCLUDE, source addresses x
   IS_EX ( x )  -  Type MODE_IS_EXCLUDE, source addresses x
   TO_IN ( x )  -  Type CHANGE_TO_INCLUDE_MODE, source addresses x
   TO_EX ( x )  -  Type CHANGE_TO_EXCLUDE_MODE, source addresses x
   ALLOW ( x )  -  Type ALLOW_NEW_SOURCES, source addresses x
   BLOCK ( x )  -  Type BLOCK_OLD_SOURCES, source addresses x

wobei x entweder:

• ein Großbuchstabe (z.B. "A") ist, um die Menge der Quelladressen darzustellen, oder

• ein Mengenausdruck (z.B. "A+B"), wobei "A+B" die Vereinigung der Mengen A und B bedeutet, "A*B" die Schnittmenge der Mengen A und B bedeutet und "A-B" das Entfernen aller Elemente der Menge B aus der Menge A bedeutet.

4.2.16. Membership Report Size

Wenn die Menge der in einem Report erforderlichen Group Records nicht in die Größenbeschränkung einer einzelnen Report-Nachricht passt (wie durch die MTU des Netzwerks bestimmt, auf dem sie gesendet wird), werden die Group Records in so vielen Report-Nachrichten gesendet, wie erforderlich sind, um die gesamte Menge zu melden.

Wenn ein einzelner Group Record so viele Quelladressen enthält, dass er nicht in die Größenbeschränkung einer einzelnen Report-Nachricht passt, wird er, wenn sein Type nicht MODE_IS_EXCLUDE oder CHANGE_TO_EXCLUDE_MODE ist, in mehrere Group Records aufgeteilt, die jeweils eine andere Teilmenge der Quelladressen enthalten und jeweils in einer separaten Report-Nachricht gesendet werden. Wenn sein Type MODE_IS_EXCLUDE oder CHANGE_TO_EXCLUDE_MODE ist, wird ein einzelner Group Record gesendet, der so viele Quelladressen enthält, wie passen, und die verbleibenden Quelladressen werden nicht gemeldet; obwohl die Wahl, welche Quellen gemeldet werden sollen, willkürlich ist, ist es vorzuziehen, in jedem nachfolgenden Report dieselbe Menge von Quellen zu melden, anstatt jedes Mal verschiedene Quellen zu melden.

---

5. Beschreibung des Protokolls für Gruppenmitglieder

IGMP ist ein asymmetrisches Protokoll, das unterschiedliche Verhaltensweisen für Gruppenmitglieder (Hosts oder Router, die Multicast-Pakete empfangen möchten) und Multicast-Router (die auf IGMP-Nachrichten hören und Multicast-Weiterleitung koordinieren) spezifiziert. Dieser Abschnitt beschreibt den Teil von IGMPv3, der für Gruppenmitglieder gilt. (Beachten Sie, dass ein Router auch ein Gruppenmitglied sein kann.)

Ein System führt das in diesem Abschnitt beschriebene Protokoll über jede Schnittstelle aus, auf der Multicast-Empfang unterstützt wird. Das Protokoll auf jeder Schnittstelle umfasst die sofortige Verarbeitung von zwei Arten von Ereignissen:

1. Eine Änderung des Multicast-Empfangsstatus auf der Schnittstelle, verursacht durch eine lokale Invokation der IPMulticastListen-Definition.

5.1. Aktion bei Änderung des Schnittstellenstatus

Eine Invokation von IPMulticastListen kann den Multicast-Empfangsstatus einer Schnittstelle gemäß den Regeln in Abschnitt 3.2 ändern. Jede solche Änderung betrifft den Per-Interface-Status für eine einzelne Multicast-Gruppenadresse.

Eine Änderung des Schnittstellenstatus veranlasst das System, sofort einen State Change Report von dieser Schnittstelle zu übertragen. Der Typ und Inhalt des State Change Reports werden wie folgt bestimmt:

1. Wenn die Zustandsänderung nicht signifikant ist, z.B. der Filtermodus für eine Gruppe von INCLUDE zu INCLUDE oder von EXCLUDE zu EXCLUDE wechselt, während die Menge der Quelladressen unverändert bleibt, wird kein Report generiert.

2. Wenn die Zustandsänderung signifikant ist, wird ein State Change Report generiert. Der Report enthält einen einzelnen Group Record für die Gruppe, deren Status sich geändert hat. Der Typ und Inhalt des Group Records werden durch Vergleich des Old State (der Zustand vor der Änderung) mit dem New State (der Zustand nach der Änderung) bestimmt, wie in der folgenden Tabelle angegeben:

   Old State	New State	State Change Record Sent
   INCLUDE (A)	INCLUDE (B)	ALLOW (B-A), BLOCK (A-B)
   EXCLUDE (A)	EXCLUDE (B)	ALLOW (A-B), BLOCK (B-A)
   INCLUDE (A)	EXCLUDE (B)	TO_EX (B)
   EXCLUDE (A)	INCLUDE (B)	TO_IN (B)

   Die Notation "ALLOW (B-A)" bedeutet, dass der State Change Record eine Quellliste trägt, die alle Quelladressen enthält, die in Menge B, aber nicht in Menge A sind. Die Notation "BLOCK (A-B)" bedeutet, dass der State Change Record eine Quellliste trägt, die alle Quelladressen enthält, die in Menge A, aber nicht in Menge B sind.

   Wenn die berechnete Quellliste für einen ALLOW- oder BLOCK-Record leer ist, wird dieser Record vom State Change Report ausgelassen.

Um sicherzustellen, dass der State Change Report von allen Multicast-Routern im Netzwerk empfangen wird, überträgt das System den Report [Robustness Variable] - 1 Mal erneut, in zufälligen Intervallen, die aus dem Bereich (0, [Unsolicited Report Interval]) gewählt werden. Die [Robustness Variable] ist ein einstellbarer Parameter, der standardmäßig auf 2 gesetzt ist. Das [Unsolicited Report Interval] ist ebenfalls ein einstellbarer Parameter, der standardmäßig auf 10 Sekunden gesetzt ist.

Wenn ein State Change Report für die Übertragung geplant ist und eine Query empfangen wird, die einen Current State Report veranlassen würde (siehe Abschnitt 5.2), wird der ausstehende State Change Report verworfen und stattdessen der Current State Report gesendet. Der Current State Report muss alle Informationen enthalten, die im State Change Report gewesen wären.

5.2. Aktion beim Empfang einer Query

Wenn ein System eine Query empfängt, überprüft es zunächst, ob die Query gültig ist. Um gültig zu sein, muss die Query:

2. eine korrekte IP-Checksum haben,
3. eine Ziel-IP-Adresse haben, die der All-Systems-Multicast-Adresse (224.0.0.1) oder der spezifischen abgefragten Gruppenadresse entspricht.

Wenn die Query ungültig ist, wird sie ignoriert. Wenn die Query gültig ist, führt das System die folgenden Aktionen aus:

1. Es aktualisiert seinen Timer für den Querier, falls erforderlich (siehe Abschnitt 6).
2. Es bestimmt, ob es auf die Query antworten muss.

Die folgenden Unterabschnitte beschreiben die Regeln für die Beantwortung verschiedener Arten von Queries.

5.2.1. Aktion beim Empfang einer General Query

Beim Empfang einer General Query überprüft das System jede Schnittstelle, um zu sehen, ob es einen Multicast-Empfangsstatus für eine Gruppe gibt. Für jede Gruppe, für die es einen Status gibt, plant das System das Senden eines Current State Reports.

Der Report enthält einen Group Record für die Gruppe. Der Typ des Group Records ist MODE_IS_INCLUDE, wenn der Filtermodus für die Gruppe INCLUDE ist, und MODE_IS_EXCLUDE, wenn der Filtermodus EXCLUDE ist. Die Quellliste im Group Record enthält die Menge der Quelladressen für die Gruppe.

Der Report wird so geplant, dass er zu einer zufälligen Zeit gesendet wird, die aus dem Bereich (0, [Max Resp Time]) gewählt wird, wobei [Max Resp Time] der im Feld Max Resp Code der Query angegebene Wert ist.

5.2.2. Aktion beim Empfang einer Group-Specific Query

Beim Empfang einer Group-Specific Query überprüft das System, ob es einen Multicast-Empfangsstatus für die in der Query angegebene Gruppenadresse hat. Wenn nicht, ignoriert es die Query.

Wenn es einen Status für die Gruppe gibt, plant das System das Senden eines Current State Reports. Der Report enthält einen Group Record für die Gruppe, konstruiert wie in Abschnitt 5.2.1 beschrieben.

Der Report wird so geplant, dass er zu einer zufälligen Zeit gesendet wird, die aus dem Bereich (0, [Max Resp Time]) gewählt wird.

5.2.3. Aktion beim Empfang einer Group-and-Source-Specific Query

Beim Empfang einer Group-and-Source-Specific Query überprüft das System, ob es einen Multicast-Empfangsstatus für die in der Query angegebene Gruppenadresse hat. Wenn nicht, ignoriert es die Query.

Wenn es einen Status für die Gruppe gibt, bestimmt das System, ob es an einer der in der Query angegebenen Quelladressen interessiert ist. Das System ist an einer Quelladresse interessiert, wenn:

1. Der Filtermodus für die Gruppe EXCLUDE ist, ODER
2. Der Filtermodus für die Gruppe INCLUDE ist und die Quelladresse in der Quellliste ist.

Wenn das System an mindestens einer der Quelladressen interessiert ist, plant es das Senden eines Current State Reports. Der Report enthält einen Group Record für die Gruppe, konstruiert wie in Abschnitt 5.2.1 beschrieben.

Der Report wird so geplant, dass er zu einer zufälligen Zeit gesendet wird, die aus dem Bereich (0, [Max Resp Time]) gewählt wird.

5.2.4. Aktion beim Empfang einer Query mit gesetztem "S"-Flag

Wenn das "S" (Suppress Router-Side Processing) Flag in einer empfangenen Query gesetzt ist, aktualisiert das System seinen Timer für den Querier nicht. Es antwortet jedoch weiterhin auf die Query, wie in den Abschnitten 5.2.1 bis 5.2.3 beschrieben.

---

6. Protokoll für Multicast-Router

Der Zweck von IGMP besteht darin, jedem Multicast-Router zu ermöglichen, für jedes seiner direkt angeschlossenen Netzwerke zu erfahren, welche Multicast-Adressen Listener in diesem Netzwerk haben. IGMPv3 ermöglicht es einem Multicast-Router auch zu erfahren, welche Quellen für die Listener von Interesse sind.

6.1. Bedingungen für die Querier-Wahl

IGMPv3 stimmt mit IGMPv2 darin überein, dass es nur einen Querier pro Netzwerk geben sollte. IGMPv3-Querier und IGMPv2-Querier können jedoch im selben Netzwerk koexistieren. Das Wahlprotokoll ist das gleiche wie in IGMPv2:

1. Zunächst startet jeder Multicast-Router als Querier auf jedem seiner angeschlossenen Netzwerke.
2. Wenn ein Multicast-Router eine Query-Nachricht von einem Router mit einer niedrigeren IP-Adresse hört, muss er ein Non-Querier auf diesem Netzwerk werden.
3. Wenn ein Multicast-Router für [Other Querier Present Interval] keine Query-Nachricht von einem Router mit einer niedrigeren IP-Adresse gehört hat, nimmt er die Rolle des Queriers wieder auf.

6.2. Querier-Aktion beim Empfang einer Query

Wenn ein Querier eine Query-Nachricht empfängt, überprüft er die Quell-IP-Adresse der Query.

1. Wenn die Quell-IP-Adresse niedriger ist als seine eigene IP-Adresse, wird der Router ein Non-Querier.
2. Wenn die Quell-IP-Adresse höher ist als seine eigene IP-Adresse, bleibt der Router der Querier.
3. Wenn die Quell-IP-Adresse gleich seiner eigenen IP-Adresse ist, wird die Query ignoriert (es handelt sich um eine Reflexion oder Loopback).

6.3. Senden von Queries

Der Querier sendet periodisch General Queries, um Mitgliedschaftsinformationen zu erbitten. Er sendet auch Group-Specific oder Group-and-Source-Specific Queries, wenn er bestimmte Arten von State Change Reports empfängt.

6.3.1. General Queries

Der Querier sendet periodisch General Queries an die All-Systems-Multicast-Adresse (224.0.0.1). Das Standard-[Query Interval] beträgt 125 Sekunden.

General Queries werden verwendet, um die Mitgliedschaftsinformationen für alle Gruppen und Quellen zu aktualisieren.

6.3.2. Group-Specific Queries

Wenn der Querier einen State Change Report empfängt, der anzeigt, dass ein System eine Gruppe verlassen hat (z.B. eine Filtermodusänderung von EXCLUDE zu INCLUDE oder eine Quelllistenänderung, die eine Quelle blockiert), sendet er eine Group-Specific Query an die Gruppenadresse.

Diese Query wird verwendet, um festzustellen, ob es noch verbleibende Systeme gibt, die an der Gruppe interessiert sind.

6.3.3. Group-and-Source-Specific Queries

Wenn der Querier einen State Change Report empfängt, der anzeigt, dass ein System nicht mehr an bestimmten Quellen für eine Gruppe interessiert ist (z.B. das Blockieren bestimmter Quellen), sendet er eine Group-and-Source-Specific Query.

Diese Query wird verwendet, um festzustellen, ob es noch verbleibende Systeme gibt, die an diesen bestimmten Quellen interessiert sind.

6.4. Empfang von Reports

Multicast-Router zeichnen den Empfangsstatus für jede Gruppe und Quelle basierend auf den Reports auf, die sie empfangen. Der Status wird pro Schnittstelle beibehalten.

6.4.1. Empfang von Current State Records

Wenn ein Router einen Current State Record empfängt, aktualisiert er seine Gruppen-/Quell-Timer.

• Wenn der Record MODE_IS_INCLUDE ist, aktualisiert der Router die Timer für die aufgeführten Quellen.
• Wenn der Record MODE_IS_EXCLUDE ist, aktualisiert der Router den Gruppentimer und die Timer für die ausgeschlossenen Quellen (falls vorhanden).

6.4.2. Empfang von Filter-Mode-Change Records

Wenn ein Router einen Filter-Mode-Change Record empfängt, aktualisiert er den Filtermodus und die Timer.

• CHANGE_TO_INCLUDE_MODE: Der Router wechselt in den INCLUDE-Modus, falls er es noch nicht war, und aktualisiert die Quell-Timer.
• CHANGE_TO_EXCLUDE_MODE: Der Router wechselt in den EXCLUDE-Modus und aktualisiert den Gruppentimer.

6.4.3. Empfang von Source-List-Change Records

Wenn ein Router einen Source-List-Change Record empfängt, aktualisiert er die Quell-Timer.

• ALLOW_NEW_SOURCES: Der Router fügt die neuen Quellen zu seiner Liste hinzu und startet deren Timer.
• BLOCK_OLD_SOURCES: Der Router kann abfragen, ob andere Systeme diese Quellen noch benötigen, bevor er sie entfernt.

6.5. Wechsel des Router-Filtermodus

Der Filtermodus des Routers für eine Gruppe wechselt zwischen INCLUDE und EXCLUDE basierend auf dem Status des Gruppentimers und der Quell-Timer.

• Wenn der Gruppentimer läuft, ist der Filtermodus EXCLUDE.
• Wenn der Gruppentimer abläuft, wechselt der Filtermodus zu INCLUDE.

6.6. Aktion beim Empfang einer Group Leave-Nachricht (IGMPv2)

Wenn ein Router eine IGMPv2 Leave Group-Nachricht empfängt, verhält er sich so, als hätte er einen State Change Report erhalten, der eine Änderung in den INCLUDE-Modus (effektiv das Verlassen der Gruppe) für die in der Leave-Nachricht angegebene Gruppe anzeigt. Dies ermöglicht es IGMPv3-Routern, mit IGMPv2-Hosts zu interoperieren.

---

7. Interoperation mit IGMPv1 und IGMPv2

IGMPv3-Hosts und -Router interoperieren mit Hosts und Routern, die noch nicht auf IGMPv3 aktualisiert wurden. Diese Kompatibilität wird durch die periodischen Membership Query-Nachrichten aufrechterhalten, die vom Querier multicast werden, und durch die Version 1- und Version 2-Membership Report-Nachrichten, die von älteren Hosts multicast werden.

7.1. IGMPv3-Host-Betrieb

Das Verhalten eines IGMPv3-Hosts hängt davon ab, ob der Querier im Netzwerk IGMPv3, IGMPv2 oder IGMPv1 spricht.

7.1.1. Query-Versionsunterscheidungen

Die IGMP-Version einer Membership Query-Nachricht wird wie folgt bestimmt:

1. IGMPv1 Query: Länge = 8 Oktette, Max Resp Code = 0.
2. IGMPv2 Query: Länge = 8 Oktette, Max Resp Code > 0.
3. IGMPv3 Query: Länge >= 12 Oktette.

7.1.2. Verhalten in Anwesenheit älterer Querier

Ein IGMPv3-Host kann in ein Netzwerk platziert werden, in dem der Querier noch nicht auf IGMPv3 aktualisiert wurde. Der Host muss diese Möglichkeit berücksichtigen.

• IGMPv1 Querier Present: Wenn ein IGMPv3-Host eine IGMPv1 Query empfängt, muss er mit IGMPv1 Reports antworten. Quellfilterung wird nicht unterstützt.
• IGMPv2 Querier Present: Wenn ein IGMPv3-Host eine IGMPv2 Query empfängt, muss er mit IGMPv2 Reports antworten. Quellfilterung wird nicht unterstützt.
• IGMPv3 Querier Present: Wenn ein IGMPv3-Host eine IGMPv3 Query empfängt, antwortet er mit IGMPv3 Reports. Quellfilterung wird unterstützt.

Der Host verwaltet eine Kompatibilitätsmodus-Variable für jede Schnittstelle, die aktualisiert wird, wann immer eine Query empfangen wird. Wenn eine ältere Query empfangen wird, wechselt der Host in den entsprechenden Kompatibilitätsmodus und setzt einen Timer. Wenn der Timer abläuft, wechselt der Host zurück in den IGMPv3-Modus.

7.2. IGMPv3-Router-Betrieb

Das Verhalten eines IGMPv3-Routers hängt davon ab, ob ältere Hosts oder Router im Netzwerk vorhanden sind.

7.2.1. Vorhandensein älterer Hosts

Ein IGMPv3-Router kann IGMPv1- oder IGMPv2-Reports von älteren Hosts empfangen.

• IGMPv1 Report Received: Der Router verhält sich so, als hätte er einen IGMPv3 IS_EX({}) Report für die Gruppe erhalten. Er muss auch alle Leave Group-Nachrichten für diese Gruppe ignorieren (da IGMPv1 keine Leave-Nachrichten hat).
• IGMPv2 Report Received: Der Router verhält sich so, als hätte er einen IGMPv3 IS_EX({}) Report für die Gruppe erhalten.

Wenn ältere Hosts vorhanden sind, muss der Router möglicherweise die IGMPv3-spezifische Verarbeitung (wie quellenspezifische Queries) für die betroffenen Gruppen unterdrücken, um die Kompatibilität sicherzustellen.

7.2.2. Vorhandensein älterer Router

Wenn sich ein IGMPv3-Router in einem Netzwerk mit älteren Routern befindet, bestimmt der Querier-Wahlprozess (Abschnitt 6.1), welcher Router der Querier wird.

• Wenn ein IGMPv1-Router vorhanden ist und der Querier wird, müssen alle Router (einschließlich IGMPv3-Router) als IGMPv1-Router agieren.
• Wenn ein IGMPv2-Router vorhanden ist und der Querier wird, müssen alle Router als IGMPv2-Router agieren.
• Wenn ein IGMPv3-Router der Querier wird, sendet er IGMPv3-Queries. Ältere Router sehen diese als ungültige IGMPv1/v2-Queries (oder handhaben sie, wenn sie teilweise kompatibel sind), aber im Allgemeinen sollten IGMPv3-Router so konfiguriert werden, dass sie im IGMPv1- oder IGMPv2-Modus laufen, wenn sie mit älteren Routern koexistieren müssen, die IGMPv3-Pakete nicht handhaben können.

7.3. Mischung von Version 1-, 2- und 3-Hosts

Es ist möglich, eine Mischung aus IGMPv1-, IGMPv2- und IGMPv3-Hosts im selben Netzwerk zu haben.

• Wenn der Querier IGMPv3 ist, sendet er IGMPv3-Queries.

Der IGMPv3-Router muss alle diese Report-Typen handhaben. Für Gruppen mit IGMPv1- oder IGMPv2-Mitgliedern muss der Router die Gruppe effektiv als im EXCLUDE-Modus mit einer leeren Quellliste behandeln (d.h. "sende mir alles für diese Gruppe"), da ältere Hosts keine Quellfilter angeben können.

---

8. Liste der Timer, Zähler und ihrer Standardwerte

Die meisten dieser Timer und Zähler sind konfigurierbar. Wenn nicht standardmäßige Einstellungen verwendet werden, MÜSSEN sie unter allen Routern auf einem einzelnen Link konsistent sein. Beachten Sie, dass die Klammern den Wert des entsprechenden Felds in der Query-Nachricht angeben.

8.1. Robustness Variable

Die Robustness Variable ermöglicht die Anpassung an den erwarteten Paketverlust in einem Netzwerk. Wenn ein Netzwerk voraussichtlich verlustreich ist, kann die Robustness Variable erhöht werden. IGMP ist robust gegenüber [Robustness Variable] - 1 Paketverlusten.

8.2. Query Interval

Das Query Interval ist das Intervall zwischen General Queries, die vom Querier gesendet werden.

8.3. Query Response Interval

Die Max Resp Time, die in die periodischen General Queries eingefügt wird.

8.4. Group Membership Interval

Das Group Membership Interval ist die Zeitspanne, die vergehen muss, bevor ein Multicast-Router entscheidet, dass es keine Mitglieder einer Gruppe oder einer bestimmten Quelle mehr in einem Netzwerk gibt.

8.5. Other Querier Present Interval

Das Other Querier Present Interval ist die Zeitdauer, die vergehen muss, bevor ein Multicast-Router entscheidet, dass es keinen anderen Multicast-Router mehr gibt, der der Querier sein sollte.

8.6. Startup Query Interval

Das Startup Query Interval ist das Intervall zwischen General Queries, die von einem Querier beim Startup gesendet werden.

8.7. Startup Query Count

Der Startup Query Count ist die Anzahl der Queries, die beim Startup gesendet werden, getrennt durch das [Startup Query Interval].

8.8. Last Member Query Interval

Das Last Member Query Interval ist die Max Resp Time, die in Group-Specific Queries eingefügt wird, die als Antwort auf Leave Group-Nachrichten gesendet werden.

8.9. Last Member Query Count

Der Last Member Query Count ist die Anzahl der Group-Specific Queries, die gesendet werden, bevor der Router annimmt, dass es keine lokalen Mitglieder gibt.

8.10. Unsolicited Report Interval

Das Unsolicited Report Interval ist die Zeit zwischen Wiederholungen des anfänglichen Reports eines Hosts über die Mitgliedschaft in einer Gruppe.

8.11. Older Version Querier Present Timeout

Das Older Version Querier Present Timeout ist das Timeout für den Übergang eines Hosts zurück in den IGMPv3-Modus, nachdem eine Query einer älteren Version gehört wurde.

---

9. Sicherheitsüberlegungen

Wir betrachten die Auswirkungen einer gefälschten Nachricht jedes Typs.

9.1. Query-Nachricht

Eine gefälschte Query-Nachricht von einer Maschine mit einer niedrigeren IP-Adresse als der aktuelle Querier führt dazu, dass eine Querier-Wahl stattfindet. Dies kann dazu führen, dass der aktuelle Querier aufhört, Queries zu senden und auf den neuen Querier wartet. Da der neue Querier ungültig ist, kann der Query-Timer auf den Routern schließlich ablaufen, was dazu führt, dass sie ihre Mitgliedschaftsinformationen verwerfen.

Ein DoS-Angriff ist möglich, indem gefälschte Queries mit einem kleinen Max Resp Code gesendet werden. Dies würde dazu führen, dass alle Hosts im LAN gleichzeitig Reports senden, was möglicherweise das Netzwerk oder den Router überlastet.

9.2. Current State Report-Nachrichten

Eine gefälschte Report-Nachricht kann dazu führen, dass der Router glaubt, dass es Mitglieder einer Gruppe in einem Netzwerk gibt, wenn es keine gibt. Dies kann dazu führen, dass Multicast-Verkehr unnötig an das Netzwerk weitergeleitet wird, wodurch Bandbreite verbraucht wird.

9.3. State Change Report-Nachrichten

Eine gefälschte State Change Report-Nachricht kann dazu führen, dass der Router glaubt, dass ein System einer Gruppe beigetreten ist oder sie verlassen hat. Gefälschte "Join"-Reports (ALLOW oder TO_IN) verursachen unnötigen Verkehr. Gefälschte "Leave"-Reports (BLOCK oder TO_EX) können dazu führen, dass der Router eine Group-Specific Query sendet, und wenn keine gültigen Hosts rechtzeitig antworten, kann der Router aufhören, Verkehr für die Gruppe weiterzuleiten, was zu einem Denial of Service für legitime Mitglieder führt.

9.4. IPsec

Der IPsec Authentication Header (AH) [RFC2402] kann verwendet werden, um IGMP-Nachrichten zu schützen. Wenn AH verwendet wird, wird die Authentifizierung auf das gesamte IP-Paket angewendet, einschließlich der IGMP-Nachricht. Dies kann die Fälschung von IGMP-Nachrichten verhindern. Die Schlüsselverwaltung für Multicast ist jedoch komplex und ein Bereich fortlaufender Forschung.

---

10. IANA-Überlegungen

10.1. IGMP-Nachrichtentypen

IANA hat den IGMP-Nachrichtentyp 0x22 für "Version 3 Membership Report" zugewiesen.

10.2. Gruppendatensatztypen

IANA hat ein neues Register für "IGMPv3 Report Types" (Gruppendatensatztypen) erstellt. Die Werte 0x01 bis 0x06 sind in diesem Dokument definiert. Die Werte 0x00 und 0x07 bis 0xFF stehen zur Zuweisung zur Verfügung.

10.3. Max Resp Code

Das Feld Max Resp Code in der Membership Query-Nachricht ist ein 8-Bit-Feld. Die Werte sind in Abschnitt 4.1.1 definiert. Es ist kein Register erforderlich.

---

11. Danksagungen

Wir möchten den vielen Menschen danken, die zum Design und zur Dokumentation von IGMPv3 beigetragen haben. Insbesondere würdigen wir die Beiträge von:

• Steve Deering, der IP Multicast erfunden und die früheren Versionen von IGMP entworfen hat.
• Van Jacobson, der zum Design der Timer-Mechanismen beigetragen hat.
• Isidor Kouvelas, der Co-Autor früherer Entwürfe war.
• Den Mitgliedern der IDMR-Arbeitsgruppe für ihre Überprüfung und Kommentare.

---

12. Referenzen

12.1. Normative Referenzen

12.2. Informative Referenzen

---

Anhang A. Design-Rationale

A.1. Der "Exclude"-Filtermodus

Der "Exclude"-Filtermodus wurde eingeführt, um "Source-Specific Multicast" (SSM) zu unterstützen, während gleichzeitig die Kompatibilität mit dem bestehenden "Any-Source Multicast" (ASM)-Modell aufrechterhalten wird.

Bei ASM tritt ein Host einer Gruppe G bei und empfängt Verkehr von allen Quellen, die an G senden. Dies entspricht EXCLUDE({}, G). Bei SSM tritt ein Host einem spezifischen Kanal (S, G) bei und empfängt Verkehr nur von Quelle S, der an Gruppe G gesendet wird. Dies entspricht INCLUDE({S}, G).

Der EXCLUDE-Modus ermöglicht es einem Host, bestimmte Quellen aus einer ASM-Gruppe zu blockieren, was zum Filtern unerwünschten Verkehrs nützlich ist.

A.2. Der "Include"-Filtermodus

Der "Include"-Filtermodus ist der primäre Modus für SSM. Er ermöglicht es einem Host, die Menge der Quellen explizit anzugeben, die er empfangen möchte. Dies vereinfacht das Multicast-Routing-Protokoll, da der Router nur einen quellenspezifischen Baum aufbauen muss.

A.3. State Change Reports

State Change Reports werden gesendet, um Zuverlässigkeit zu gewährleisten. Durch Wiederholung der Reports wird die Wahrscheinlichkeit verringert, dass sie verloren gehen. Dies ist wichtig, da IGMP über einen unzuverlässigen Transport (IP) läuft.

---

Anhang B. Zusammenfassung der Änderungen von IGMPv2

Das Folgende ist eine Zusammenfassung der Änderungen von IGMPv2 [RFC2236] zu IGMPv3:

1. Quellfilterung: Die Fähigkeit für Hosts anzugeben, welche Quellen sie empfangen möchten (INCLUDE-Modus) oder welche Quellen sie blockieren möchten (EXCLUDE-Modus).

2. Group Record Types: IGMPv3-Reports enthalten Group Records, die verschiedene Typen sein können (Current State, Filter Mode Change, Source List Change), um verschiedene Arten von Informationen zu übermitteln.

3. Membership Report-Format: Das Report-Format wurde vollständig neu gestaltet, um mehrere Group Records in einer einzelnen Nachricht zu unterstützen und Quelladressen zu tragen.

4. Query-Format: Das Query-Format wurde erweitert, um Group-and-Source-Specific Queries zu unterstützen und die Robustness Variable und Query Interval (QQIC) zu tragen.

5. Max Resp Code: Das Feld Max Resp Code wurde neu definiert, um größere Werte unter Verwendung einer Gleitkommadarstellung zu unterstützen.

6. Querier-Wahl: Der Querier-Wahlmechanismus bleibt derselbe, aber die Regeln für den Umgang mit älteren Versionen wurden geklärt.

7. S Flag: Das "Suppress Router-Side Processing"-Flag in Queries ermöglicht es Routern, Timer-Updates zu unterdrücken, wenn sie Queries empfangen, was für bestimmte Diagnosen oder spezielle Konfigurationen nützlich ist.