Zusammenfassung

  • RFC 3019 stellte MLD-Interface- und Cache-Zustand bereit, gab dem Management jedoch zugleich Kontrolle: MLD ein- oder ausschalten, Zeilen anlegen oder löschen, lokale Mitgliedschaft setzen, Timer verändern und ein Proxy-Interface bestimmen.
  • Eine Zeile, die letzte Reporter-Adresse oder ein erfolgreicher SET belegten deshalb nur den vom Agenten dargestellten Zustand — nicht einen aktuellen entfernten Listener, Weiterleitung, Paketzustellung oder Anwendungsempfang.

Eine Cache-Tabelle wirkt wie die Chronik dessen, was das Protokoll gesehen hat. Bei RFC 3019 war sie mehr als das: Sie war zugleich ein Bedienpult.

Der Manager konnte eine Zeile erzeugen und später wieder auslesen. Er konnte den lokalen Rechner als Mitglied markieren. Er konnte MLD auf einem Interface deaktivieren oder die Zeit verändern, nach der Mitgliedschaft geprüft und entfernt wurde.

Die Tabelle blieb damit nützlich. Nur die Beweisfrage änderte sich. Eine korrekt gelesene Zeile sagte, welchen Zustand der Agent darstellte. Sie sagte nicht automatisch, wodurch dieser Zustand entstanden war.

In einer Zeile lagen Historie, Gegenwart und Policy

RFC 3019 definierte zwei Tabellen. Die MLD Interface Table enthielt pro Interface mit aktiviertem MLD eine Zeile. Die MLD Cache Table enthielt pro IPv6-Multicast-Adresse und Interface eine Mitgliedschaftszeile. Hosts und Router sollten beide Tabellen implementieren; einzelne Objekte galten nur für Router.

Die Interface-Zeile umfasste Query-Intervall, maximale Antwortzeit, MLD-Version, Querier-Adresse, kumulative Joins, aktuelle Gruppenzahl, Robustness Variable, Last-Listener-Intervall, Proxy-Interface und Querier-Timer.

Diese Werte teilten keinen gemeinsamen Evidenztyp. Der Join-Zähler blickte zurück. Die Gruppenzahl beschrieb aktuelle Cache-Zeilen. Die Ablaufzeit sagte, wann unter gleichbleibenden Bedingungen eine Zustandsänderung bevorstand. Schreibbare Intervalle waren Konfiguration.

Die Cache-Zeile enthielt lokale Mitgliedschaft, letzten Reporter, Alter, Ablaufzeit und RowStatus. Eine Oberfläche durfte sie zusammen anzeigen. Eine Untersuchung musste ihre unterschiedlichen Ursprünge erhalten.

Der letzte Reporter konnte längst gegangen sein

mldCacheLastReporter bezeichnete die IPv6-Quelladresse des zuletzt empfangenen Membership Reports für die Gruppe auf dem Interface. Ohne empfangenen Report lautete der Wert 0::0.

Das Objekt war keine Teilnehmerliste. „Zuletzt“ war eine Reihenfolge der Beobachtung, keine Aussage über fortdauernde Anwesenheit.

MLD aus RFC 2710 musste dem Router nur mitteilen, ob mindestens ein Listener auf dem Link existierte. Hörte ein Host bereits den Report eines anderen, konnte er seinen eigenen unterdrücken. Eine sichtbare Adresse konnte daher mehrere stumme Mitglieder vertreten. Der Reporter konnte später austreten, während ein anderer Host oder das lokale System die Zeile erhielt.

Auch mldCacheExpiryTime war kein Lebenszeichen. Es gab die minimale Restzeit bis zum Altern der Zeile an. Null konnte bedeuten, dass allein mldCacheSelf die Zeile hielt und ein lokaler Austritt sie sofort entfernte. Eine Implementierung durfte lokale Reports aber wie fremde behandeln, weshalb Null nicht zwingend war.

Für die Behauptung eines aktuellen entfernten Listeners brauchte man Report-Zeit, lokale Mitgliedschaft, Timer-Epoche und Agentenkontinuität. Für Zustellung kamen Forwarding- und Empfängerbelege hinzu.

Das Management konnte die später gelesene Tatsache erzeugen

mldCacheStatus war read-create. Ein Manager konnte neue Einträge erzeugen und vorhandene löschen. Die Beschreibung der Basis-Konformitätsgruppe sagte ausdrücklich, dass sie die Erzeugung und Löschung von MLD-Cache-Einträgen durch den Manager erlauben sollte.

mldCacheSelf war ebenfalls read-create und standardmäßig wahr.

Eine Zeile konnte aus einem Report auf dem Link, einem lokalen Join, einem Managementvorgang oder einem noch nicht abgelaufenen alten Zustand stammen. Der aktuelle Wert musste diese Abstammung nicht mitführen.

Legte eine Automation eine Zeile für einen Test an und las sie anschließend zurück, bestätigte die Antwort den Agentenzustand. Sie war kein unabhängiger Beleg dafür, dass ein entfernter Host berichtet hatte. Schreiben und Prüfen verwendeten dasselbe Register.

Programmierbare Kontrolle ist nicht das Problem. Problematisch wird es, wenn ihre Herkunft verloren geht und die resultierende Zeile als externe Beobachtung gilt.

Das Löschen einer Interface-Zeile schaltete MLD ab

mldInterfaceStatus beschrieb nicht nur einen Datensatz. Aktivieren der Zeile aktivierte MLD; Zerstören der Zeile deaktivierte MLD auf dem Interface.

Schreibbare Parameter veränderten Query-Häufigkeit, maximale Antwortzeit, Verlusttoleranz und die Wartezeit zur Prüfung des letzten Mitglieds. Ein kleinerer Wert reduzierte Leave-Latenz und verkürzte zugleich das Zeitfenster für eine Antwort.

mldInterfaceProxyIfIndex verband Interfaces. Auf einem Interface gelernte Mitgliedschaft konnte Reports auf einem anderen auslösen. Null bedeutete kein Proxying; ein anderer Wert machte lokalen Cache-Zustand zur Ursache einer Upstream-Aktion.

Ein akzeptierter SET konnte also Protokollverhalten ändern. Er bewies trotzdem nicht, dass die nächste Query gesendet, vom Nachbarn empfangen, in Forwarding umgesetzt oder von einer Anwendung als Nutzdaten erlebt wurde.

read-create war kein Inventar aller Implementierungen

Die maximale Zugriffsdeklaration bedeutete nicht, dass jeder konforme Agent Schreibzugriff bieten musste.

Host- und Router-Konformität erlaubten für mldInterfaceStatus als Mindestzugriff read-only. Schreiben war nicht erforderlich. Schema-Fähigkeit, implementierte Fähigkeit, VACM-View, Autorisierung und beobachteter Effekt blieben getrennt.

RFC 2579 definierte den allgemeinen RowStatus-Lebenszyklus. Eine active-Zeile blieb dennoch Managementzustand. Sie bewies weder Persistenz nach Neustart noch Synchronität mit dem MLD-Prozess oder dem Datenpfad.

Die Fragen lauten nacheinander: War Schreiben standardisiert? War es implementiert? War dieser Principal berechtigt? Wurde die operative Wirkung beobachtet? Die Objektdeklaration beantwortete nur die erste.

Lesen konnte verraten, Schreiben konnte stören

Die Security Considerations von RFC 3019 unterschieden beide Risiken. Lesbare Objekte konnten Informationen über Multicast-Sitzungen offenlegen. mldCacheSelf und mldCacheLastReporter konnten Maschinen identifizierbar machen, die mit einer Gruppe verbunden waren. Die historische Einschätzung „relatively innocuous“ ist keine allgemeine Datenschutzregel.

Unberechtigter Schreibzugriff konnte Denial of Service verursachen. SET ohne angemessenen Schutz gefährdete den Netzbetrieb.

SNMPv1 allein galt als unsichere Umgebung. Selbst IPsec beantwortete nicht, wer innerhalb des geschützten Netzes welche Objekte verändern durfte. Daher empfahl der RFC USM aus RFC 2574 und VACM aus RFC 2575.

Kanal, Identität, View, SET-Annahme, Protokollzustand, Forwarding und Empfängerergebnis benötigen getrennte Belege.

RFC 5519 ergänzte Struktur, nicht rückwirkende Wahrheit

RFC 5519 löste RFC 3019 im Jahr 2009 ab. Es vereinte IGMP- und MLD-Management, trennte Host- und Router-Tabellen und ergänzte Source-Filter-Zustand für IGMPv3 und MLDv2.

Der Nachfolger zeigte Grenzen des früheren Modells. Seine Spalten dürfen nicht rückwirkend in eine Zeile von 2001 gelesen werden. Ebenso belegt die RFC-Linie keine konkrete Implementierung, Verbreitung oder Migration.

Lu Hengs Arbeiten werden hier als offengelegte Analysebrille genutzt. Running-Code Primacy trennt Modul und laufenden Agenten. Reality Layers trennt Zeile, Report, Policy, Forwarding und Empfang. Minimum Initial Specification erklärt den Nutzen einer kleinen frühen Oberfläche, ohne spätere Fähigkeiten hineinzulesen.

Lu Heng war weder Autor noch Unterstützer von RFC 3019.

Die Tabelle war keine schlechte Zeugenaussage. Sie war eine genaue Aussage zu einem kleineren Gegenstand: dem Zustand, den der Agent verwaltete.

Sources