Summary

  • RFC 2375 ließ dieselbe dauerhafte Dienstbedeutung in mehreren IPv6-Geltungsbereichen erscheinen, erklärte aber Adressen, die sich nur im Scope unterscheiden, zu getrennten Gruppen mit getrenntem Beitritt.
  • Eine Zuteilung belegte Namenskoordination und Kollisionsschutz, nicht das Vorhandensein von Hörern, Weiterleitungszustand, zugelassenen Quellen oder Anwendungszustellung.

Eine anfängliche, bewusst begrenzte Liste

IPv6 besaß 1998 bereits ein Multicast-Adressformat. Implementierungen brauchten zusätzlich gemeinsame Werte für alle Knoten, alle Router, Routingprotokolle, Zeitdienste und Konferenzsysteme aus der IPv4-Erfahrung.

RFC 2375 veröffentlichte eine Auswahl. Relevante IPv4-Zuteilungen wurden übernommen, unpassende nicht, Rückmeldungen zur Übertragung waren ausdrücklich erwünscht, und alle übrigen IPv6-Multicast-Adressen blieben reserviert. Das Dokument öffnete einen Teil des Namensraums; es beanspruchte nicht, dessen Zukunft abschließend zu beschreiben.

Die Tabelle verhinderte widersprüchliche Bedeutungen derselben Zahl. Sie sagte nicht, dass der benannte Dienst irgendwo lief oder Hörer hatte.

Das X bedeutete nicht „überall dieselbe Gruppe“

Fest zugeordnete Adressen galten nur in ihrem genannten Scope. Bei variablen Adressen stand X im Scope-Feld, sodass dieselbe dauerhafte Gruppennummer mit jedem zulässigen Scope verbunden werden konnte.

RFC 2375 zog die entscheidende Grenze: Unterschieden sich zwei Adressen nur im Scope, bezeichneten sie verschiedene Gruppen. Ein Knoten musste jeder Gruppe einzeln beitreten.

Im NTP-Beispiel von RFC 2373 konnte dieselbe Kennung Server auf derselben Schnittstelle, demselben Link, demselben Standort oder im globalen Bereich meinen. Die Dienstbedeutung blieb. Die vollständige Zieladresse und ihre Teilnehmermenge blieben nicht gleich. Die Nummer reiste; die Mitgliedschaft nicht.

Der Scope bildete das Ziel mit

Der Geltungsbereich war keine Anzeigeoption. Er begrenzte die topologische Region der Gruppe, und Router durften Pakete nicht darüber hinaus weiterleiten. „Alle Router“ auf einer Schnittstelle, auf einem Link und an einem Standort waren drei verschiedene Adressatenkreise.

Bei temporären Gruppen war die Trennung noch schärfer. Derselbe Wert an einem anderen Standort hatte keine notwendige Beziehung zur ersten Gruppe. Gleiches galt für dieselbe ID in einem anderen Scope oder für eine dauerhafte Gruppe mit gleicher Nummer.

Ähnliche Bits begründeten keine operative Identität. Erst vollständige Adresse, Scope und laufender Zustand bestimmten, um welche Gruppe es ging.

Im Register saßen keine Hörer

Eine dauerhafte Zuteilung lieferte den ersten Beleg: Dieser Wert hatte nach dieser Regel jene Bedeutung. Sie ließ keine Anwendung Empfang anfordern, wählte keine Schnittstelle und meldete keinem benachbarten Router einen Hörer.

RFC 2710 machte die nächste Ebene mit Multicast Listener Discovery sichtbar. Router konnten ermitteln, welche Adressen auf direkt angeschlossenen Links von Interesse waren. Hosts führten Zustand je Adresse und Schnittstelle, antworteten auf Abfragen und meldeten Änderungen der Mitgliedschaft.

IANA-Eintrag und Listener Report waren verschiedene Nachweise. Der erste stabilisierte Bedeutung, der zweite belegte Interesse an Ort und Zeit. Danach mussten immer noch Multicast-Route, Quellrichtlinie, Paketankunft und Anwendungsergebnis folgen.

Dauerhaftigkeit hatte mehrere Gegenstände

RFC 3307 unterschied später dauerhafte Multicast-Adressen, dauerhafte Gruppenkennungen und dynamische Adressen. IANA konnte eine vollständige Adresse reservieren. Eine dauerhafte Gruppen-ID konnte denselben Dienst über mehrere Server und Scopes kennzeichnen. Eine dynamische Zuteilung diente einem vorübergehenden Bedarf.

Alle drei ordneten Kollision und Bedeutung; keine erzeugte Mitglieder. Für einen laufenden Dienst musste eine Kennung mit einem Scope verbunden, als vollständige Adresse gebildet, von einer Anwendung angefordert, auf einer Schnittstelle beigetreten und durch Weiterleitungszustand getragen werden.

RFC 3306 band bestimmte Multicast-Adressen an Unicast-Präfixe. Der Multicast-Scope durfte deren Reichweite nicht überschreiten, und die Adresse sollte nicht länger leben als das Präfix. Auch wiederverwendbare Identität blieb räumlich und zeitlich gebunden.

Ein lebendes Register ist keine Verkehrsmessung

RFC 4291 behielt das Scope-Modell bei. RFC 7346 definierte später Wert 3 als Realm-Local und präzisierte die Begriffe. Das heutige IANA-Register trennt weiterhin Scope-Werte, feste und variable Adressen, unicastbasierte Gruppen-IDs und dynamische IDs.

Diese Entwicklung belegt fortlaufende Koordination, nicht aktuellen Verkehr für jede Zeile von 1998. Ein Name kann reserviert bleiben, nachdem seine Implementierung verschwunden ist; ein neuer Dienst kann Jahrzehnte später hinzukommen.

Das Register sagt, was kollisionsfrei benannt werden kann. Nur das laufende Netz zeigt, wer tatsächlich zuhört.

Begrenzte Autorität war die Stärke

Lu Hengs Prinzip der minimalen Anfangsspezifikation passt hier: RFC 2375 öffnete gerade genug gemeinsamen Raum, reservierte den Rest und erlaubte Korrektur durch Erfahrung. Running-Code-Primat verlegt die nächste Autorität in Beitritte, Berichte, Weiterleitungstabellen und beobachtete Pakete.

Die Realitätsebenen bleiben getrennt: Dienstbedeutung, Gruppen-ID, Scope, vollständige Adresse, Schnittstellenmitgliedschaft, vom Router gelernter Listener-Zustand, Multicast-Route, zugelassene Quelle, empfangenes Paket und Anwendungsergebnis.

RFC 2375 gab den frühen Gruppen Namen. Sie versprach nicht, dass ein stabiler Name seine Hörer mitbringt.