Zusammenfassung

  • RFC 3678 ließ bestehende Multicast-Aufrufe aus Gründen der Quelltext- und Binärkompatibilität unverändert und ergänzte Quellenfilter-Optionen und -Funktionen.
  • Ein Delta-Aufruf ändert eine Quelle im aktuellen Filter. Ein Aufruf mit vollständigem Zustand ersetzt Modus und Liste gemeinsam; laut RFC ist das für einen Moduswechsel ohne Verlassen der Gruppe nötig und bei großen Listen wegen der atomaren Änderung sinnvoll.

Der bestehende Aufruf ließ sich nicht einfach erweitern

Die erste Einschränkung war nicht der Router, sondern das Programm, das den Socket bereits verwendete. Vor Quellenfiltern konnte ein Multicast-Empfänger einer Gruppe beitreten und bei Bedarf eine lokale Schnittstelle auswählen. Damit war die Mitgliedschaft festgelegt, nicht aber, welche Absender der Empfänger akzeptieren sollte. Den etablierten Aufruf um diese Information zu erweitern, war keine sichere Lösung: RFC 3678 zufolge hätte eine Änderung der Schnittstelle die Binärkompatibilität gebrochen.

Das Dokument setzte deshalb auf eine additive Erweiterung. Neue APIs sollten sowohl die Quelltextkompatibilität wahren – alter Quelltext lässt sich weiter übersetzen und verhält sich wie zuvor – als auch die Binärkompatibilität: Ein vorhandenes Programm soll auf einem System mit Unterstützung für die Erweiterung weiterlaufen. Außerdem sollten Änderungen klein bleiben und Anwendungen erkennen können, wenn die neuen Optionen fehlen, damit sie angemessen reagieren. Das ist ein Informationsdokument über API-Entwurf, kein Beleg dafür, dass jedes Betriebssystem dieselben Aufrufe implementiert hat. RFC 3678

Eine Quelle nach der anderen

Die Delta-Schnittstelle ändert den Filter schrittweise. Bei einer Mitgliedschaft für alle Quellen akzeptiert der Empfänger zunächst Quellen allgemein; ein Sperr- oder Freigabeaufruf ändert die Behandlung eines einzelnen Absenders. Beim Source-Specific Multicast fügt die Anwendung eine bestimmte Quelle zur gewünschten Menge hinzu oder entfernt sie daraus. Der Zustand vor dem Aufruf ist entscheidend: Der RFC definiert manche Kombinationen aus Option und Mitgliedschaft als ungültig; eine bereits gesperrte oder nicht beigetretene Quelle kann wiederum einen anderen Fehler auslösen.

Für eine kleine Änderung ist diese Grammatik sparsam. Die Anwendung kann „diese Quelle sperren“ oder „dieser Quelle beitreten“ sagen, ohne die übrige Liste erneut zu übermitteln. Die Bedeutung hängt jedoch vom aktuellen Filter- und Mitgliedschaftszustand ab. Ein Delta ist keine vollständige Erklärung des gewünschten Endzustands. Die API umfasst IPv4-spezifische Optionen wie IP_ADD_SOURCE_MEMBERSHIP und protokollunabhängige Optionen wie MCAST_JOIN_SOURCE_GROUP. RFC 3678

Oder den gesamten Zustand ersetzen

Die API für den vollständigen Zustand erfüllt einen anderen Zweck. Die Anwendung übergibt den Filtermodus – MCAST_INCLUDE oder MCAST_EXCLUDE – und die komplette Liste der einzuschließenden oder auszuschließenden Quellen. Der Aufruf ersetzt den bisherigen Filter, statt eine einzelne Mitgliedschaftsänderung darauf anzuwenden.

RFC 3678 nennt zwei Fälle, in denen das wichtig ist. Wer zwischen INCLUDE und EXCLUDE wechseln will, ohne die Gruppe zu verlassen, muss die API für den vollständigen Zustand verwenden. Auch bei einer großen Quellenliste empfiehlt der RFC sie, weil sich die Liste in einem Vorgang atomar ändern lässt. Eine Folge von Deltas kann zwar dieselbe Menge ergeben, beschreibt aber mehrere Zwischenänderungen statt eines einzelnen Austauschs.

Auch das Auslesen des Filters hat einen eigenen Vertrag: Die Anwendung kann die Puffergröße schätzen, die Gesamtzahl der Quellen erhalten und den Aufruf wiederholen, falls der Puffer zu klein war. Begrenzt eine Implementierung die Listenlänge, kann eine zu große Menge mit ENOBUFS scheitern. „Alles ersetzen“ ist somit ein Werkzeug zur Zustandsverwaltung, keine Zusage unbegrenzter Kapazität. RFC 3678

Eine Gruppe, zwei Adressfamilien

Für Anwendungen, die nur kleine Änderungen an IPv4-Quelltext benötigen, behielt das Dokument IPv4-spezifische Strukturen und Optionen bei. Daneben definierte es protokollunabhängige Formen. Sie transportieren Gruppe und Quelle in Socket-Strukturen, die verschiedene Adressfamilien unterstützen, während ein Interface-Index die lokale Schnittstelle separat bezeichnet. RFC 3493 hatte einen großen Teil des IPv6-Socket-Vokabulars bereitgestellt, aber keine protokollunabhängigen Multicast-Beitritts- und -Austrittsaufrufe; RFC 3678 schloss diese Lücke. RFC 3493

In einer Funktionssignatur kann diese Trennung leicht untergehen: Die Gruppenadresse bezeichnet das Multicast-Ziel, die Quelladresse den Absender und der Interface-Index begrenzt den Vorgang auf eine lokale Anbindung. Das geprüfte technische Erratum 2524 korrigierte später die Beschreibung des Arguments von getsourcefilter in Abschnitt 5.2.2: Gemeint ist ein Interface-Index, nicht eine lokale IP-Adresse – so wie bereits beim Setzer im vorherigen Abschnitt. Ein weiteres bestätigtes redaktionelles Erratum reparierte einen fehlerhaften Verweis auf den Fehlercode-Abschnitt. Keines ändert das Filtermodell; beide klären, wofür die Argumente stehen. RFC 3678 errata

Filtern am Host heißt nicht überall filtern

Ein Filter kann auf dem Host wirken, selbst wenn Router IGMPv3 oder MLDv2 nicht unterstützen. Die Anwendung erhält dann womöglich eine lokale Filterung, ohne dass damit gezeigt wäre, dass unerwünschte Pakete den lokalen Link nicht mehr durchqueren. Die Protokolle übermitteln Filterinformationen an einen Router; das ist ein anderer Mechanismus als der Socket-Aufruf und hat eigenen Zustand und einen eigenen Übertragungsweg. RFC 3376, RFC 3810 und RFC 4604 beschreiben Teile dieses netzseitigen Verhaltens. RFC 3376 RFC 3810 RFC 4604

Ein Quellenfilter authentifiziert auch keinen Absender. RFC 3678 warnt, dass eine Filterung allein kein Paket abwehrt, dessen gefälschte Quelladresse einer erlaubten Quelle entspricht. Reverse-Path-Prüfungen können in bestimmten Routing-Konstellationen helfen, sind aber keine Garantie. Ein erfolgreicher Socket-Aufruf belegt einen API-Vorgang – nicht den Routerzustand, geringere Bandbreite, authentifizierten Verkehr, den Empfang eines Pakets oder den Erfolg der Anwendung. RFC 3678

Das Dokument hat den Status Informational und erklärt ausdrücklich, kein Internet Standard zu sein; außerdem verweist es auf die offizielle Socket-Spezifikation. Sein historischer Beitrag ist enger gefasst und gerade deshalb aufschlussreich: Bestehende Mitgliedschaftsaufrufe blieben geschützt, einzelne Quellenänderungen waren weiterhin einfach, und für Moduswechsel oder große Listen stand ein vollständiger Austausch bereit. Lu Hengs später entstandene Notes 64 und 65 dienen hier als analytische Perspektiven auf Kompatibilität und lokale Einführung – nicht als Behauptung von Urheberschaft, Zustimmung oder Einfluss auf das Memo von 2004. RFC 3678 status Note 64 Note 65

Quellen