Zusammenfassung

  • RFC 10028 ersetzt den überlappenden dynamischen Bereich aus RFC 3307 durch getrennte Blöcke für MADCAP, hostbasierte SSM-Zuteilung, Private Use, Experimental Use und Solicited-Node.
  • Die Trennung wirkt nur, wenn alle Zuteiler im selben Scope die aktuelle Regel ausführen. Bereichskonformität belegt weder Herkunft und Kollisionsfreiheit noch Mitgliedschaft, Weiterleitung oder den Empfang des erwarteten (S,G)-Stroms.

Ein neuer Host wählt 0xF0000030 für einen SSM-Kanal. Der Wert liegt korrekt im von RFC 10028 vorgesehenen Bereich. Ein älterer MADCAP-Server auf demselben Segment hält dagegen noch 0x80000000 bis 0xFFFFFFFF für seinen dynamischen Pool. Er vergibt denselben Wert an eine andere Anwendung.

Beide lokalen Prüfungen können grün sein. Der Host prüft die neue Aufteilung, der Server seine alte Implementierung. Auf dem Link treffen zwei Regelepochen zusammen.

RFC 10028, im August 2026 als IETF Standards Track veröffentlicht, beseitigt die Ursache in der gemeinsamen Spezifikation. Er installiert jedoch kein Update, prüft keine Standby-Instanz und leert keinen Switch-Eintrag. Deshalb ist seine wichtigste Betriebsfrage nicht nur, wie der Bereich aussieht, sondern wer seine Einführung nachweist.

Die frühere Aufteilung erlaubte die Überschneidung

RFC 3307 bezeichnet die unteren 32 Bit einer IPv6-Multicast-Adresse als Gruppen-ID und bindet sie an die Link-Layer-Abbildung. Server- und Host-Zuteilung nutzten denselben dynamischen Bereich; dessen oberster Teil überschnitt sich zusätzlich mit Solicited-Node.

Zwei unabhängige Verfahren konnten somit regelkonform denselben Wert finden. Aus der fertigen Adresse war ihre Herkunft nicht mehr ableitbar.

RFC 10028 und das aktuelle IANA-Register für IPv6 Multicast Address Space teilen neu:

  • 0x800000000x8FFFFFFF: MADCAP;
  • 0x900000000xEFFFFFFF: nicht zugeteilt;
  • 0xF00000000xFCFFFFFF: Host-Zuteilung für SSM;
  • 0xFD0000000xFDFFFFFF: Private Use;
  • 0xFE0000000xFEFFFFFF: Experimental Use;
  • 0xFF0000000xFFFFFFFF: Solicited-Node.

Künftige Belegungen des freien Blocks verlangen Standards Action. RFC 8126 liefert dafür Register- und Änderungskontrollbegriffe. Das Register koordiniert Klassen. Es weist keiner konkreten Anwendung eine laufende Gruppe zu.

Ein IANA-Eintrag beweist daher die gemeinsame Regel, nicht ihre Implementierung. Der Zahlenbereich sagt, welches Verfahren dort vorgesehen ist; er sagt nicht, welches Programm den beobachteten Wert ausgegeben hat.

Für altes MADCAP gilt: aktualisieren oder trennen

RFC 10028 verkleinert den MADCAP-Bereich. Implementierungen sollen die neue Grenze übernehmen. Vorhandene Installationen sollen entweder aktualisierte Software verwenden oder ohne andere IPv6-Multicast-Zuteilungsprotokolle im selben Umfeld arbeiten.

Der RFC kannte zum Redaktionszeitpunkt eine MADCAP-Implementierung und keine großflächige Installation. Diese zeitgebundene Angabe ist keine aktuelle Markt- oder Bestandsaufnahme. Gerade eingebettete Systeme, Cold-Standbys und langlebige Anlagen bleiben leicht unsichtbar.

RFC 2730 definiert MADCAP als Client-Server-Mechanismus. Clients entdecken Server, stellen Anträge und erhalten OFFER, ACK oder NAK; Administratoren bestimmen lokale Richtlinien. Ein Lease belegt eine Serverentscheidung, aber nicht die aktuelle Poolgrenze.

Der Nachweis braucht Software-Build, Konfigurationshash, wirksame Grenzen, Client, Scope, Lease-ID, Beginn, Erneuerung und Ende. Passive und Wiederherstellungsinstanzen gehören dazu.

Die unteren Bits werden Ethernet-Zustand

RFC 4291 definiert Format, Scope und Gruppen-ID von IPv6 Multicast. Eine temporäre Gruppe hat Bedeutung in ihrem Scope. Werden zuvor getrennte Netze verbunden, ändert sich die Kollisionslage.

RFC 2464 bildet IPv6 Multicast auf Ethernet ab: 33:33 plus die letzten vier Oktette der IPv6-Zieladresse. Die gewählte Gruppen-ID landet in NIC-Filtern und Switch-Tabellen. Korrekte Abbildung bedeutet nicht eindeutige Abbildung.

RFC 10019 beschreibt die Folgen für Zeroconf-Netze: unerwünschte Softwarefilterung, verlorener Snooping-Nutzen, überlastete langsame Links und knappe Hardwaretabellen. Getrennte Netzpartitionen können denselben Wert wählen und den Konflikt erst beim Wiederverbinden entdecken.

Eine künftige dezentrale Lösung soll solche Konflikte erkennen und die Streams umziehen. RFC 10019 stellt Anforderungen, aber keinen fertigen Zuteiler. RFC 10028 schafft dafür einen eigenen Bereich.

SSM begrenzt die Koordination von G, nicht den Beweis

RFC 4607 definiert einen SSM-Kanal als (S,G). Verschiedene Quellen können dasselbe G verwenden. RFC 8815 betont deshalb, dass G im SSM-Bereich nicht global eindeutig sein muss.

Quelle, Anwendung, Mitgliedschaft und Weiterleitung bleiben erforderlich. RFC 10028 hält fest, dass SSM nicht überall unterstützt wird. Manche günstigen Switches speichern nur die Ziel-MAC. RFC 4541 zeigt, wie Snooping bei Versions- oder Fähigkeitsunterschieden notwendige Streams abschneiden oder unregistrierten Verkehr fluten kann.

Eine korrekte SSM-Adresse muss daher mit Quelle, MLD/IGMP-Bericht, Snooping-Eintrag, Route und Anwendungs-Canary verknüpft werden.

Privat und experimentell sind keine Freibriefe

Private Use erlaubt lokale Auswahl in isolierten Umgebungen. Zwei Verwaltungen können denselben Wert wählen. Eine Fusion, temporäre Verbindung oder wiederhergestellte Redundanz braucht deshalb eine Kollisionsprüfung.

Experimental Use erlaubt Protokollversuche, auch ohne generelle Beschränkung auf geschlossene Netze. Das Etikett garantiert weder Sicherheit noch Autorisierung oder Kompatibilität. Jeder Versuch benötigt Besitzer, Scope, Ablauf und nachweisbare Bereinigung.

Nicht zugeteilter Raum ist keine lokale Reserve. Solicited-Node erfüllt eine IPv6-Funktion und ist kein freier dynamischer Pool.

Jede Zuteilung braucht ihre Regelepoche

Zu speichern sind Standardrevision, Zuteilerklasse und -version, Konfigurationshash, Auswahl- oder Lease-Ereignis, vollständige IPv6-Adresse, Scope, Gruppen-ID, Ethernet-Ziel, Anwendung und Lebensdauer. Bei SSM gehört S zur Kanalidentität.

Anschließend müssen weitere Zuteiler, Kollisionssonden, MLD/IGMP, Snooping, Weiterleitung, erste und letzte Pakete, unerwartete Quellen, Umnummerierung und Abbau des alten Zustands folgen.

„Im aktuellen Bereich“, „zugeteilt“, „eindeutig“, „beigetreten“, „weitergeleitet“ und „von der Anwendung empfangen“ sind getrennte Aussagen.

Heng Lus Vorrang des laufenden Codes verortet den Beweis in dieser ausgeführten Kette. Seine minimale Anfangsspezifikation mit lokalen Folgeentscheidungen erklärt die schmale gemeinsame Aufteilung. Die Unterscheidung zwischen formaler und praktischer Datenkontrolle zeigt, warum IETF und IANA den Raum beschreiben, ohne den lokalen Zuteiler und den Empfang zu kontrollieren.

Das Register ist migriert. Die laufende Infrastruktur muss es noch beweisen.