Zusammenfassung

  • RFC 3307 wies server- und hostbasierter dynamischer Vergabe denselben Group-ID-Bereich 0x80000000-0xFFFFFFFF zu; dessen oberstes Segment wurde zugleich für Solicited-Node-Multicast verwendet.
  • RFC 10028 teilt den Raum in sechs IANA-Einträge für MADCAP, unzugewiesenen Raum, SSM-Hostvergabe, Private Use, Experimental Use und Solicited-Node. Damit verschwindet eine normative Überlappung, nicht jede Multicast-Kollision.
  • Mike McBride ist Mitautor neben Nate Karstens und Dino Farinacci. Das Register koordiniert gemeinsame Kennungen; Softwareversion, SSM-Voraussetzungen, Weiterleitung, Quellgültigkeit und Hörerberechtigung bleiben getrennte Betriebsnachweise.

Eine Kollision kann beginnen, bevor ein Programm eine Zufallszahl erzeugt. Sie beginnt dann in der Tabelle, die zwei Programmen denselben zulässigen Raum gibt.

RFC 3307 kannte zwei Arten dynamischer IPv6-Multicast-Vergabe. Ein Server durfte eine Gruppenkennung zuteilen, etwa über MADCAP. Ein Host durfte selbst wählen, wie es ein künftiges konfigurationsfreies Verfahren benötigen würde. Beide sollten 0x80000000 bis 0xFFFFFFFF verwenden. Der Teil 0xFF000000-0xFFFFFFFF gehörte außerdem zu Solicited-Node-Adressen des IPv6 Neighbor Discovery.

Server und Host konnten also jeweils spezifikationsgemäß handeln und denselben Wert erzeugen. Das ist keine bloße Implementierungspanne. Die gemeinsame Regel hatte zwei Entscheidungswege nicht voneinander isoliert.

RFC 10028 erschien im August 2026 auf dem IETF Standards Track und repariert genau diese Überlappung. Nate Karstens, Dino Farinacci und Mike McBride sind die drei Autoren. McBride dient hier als personeller Zugang, nicht als Alleinerfinder oder privater Verwalter des IANA-Raums.

Das am 31. August 2026 erfasste IETF-Profil führt ihn als PIM-Vorsitzenden, Delegierten bei MBONED und ANIMA, Gutachter des Routing Area Directorate und Autor von neun RFCs. RFC 10028 nennt Futurewei als Zugehörigkeit. Ein historischer Beitrag der Open Networking Foundation liefert beruflichen Kontext aus dem Jahr 2017. Diese Quellen belegen Identität und datierte Rollen, nicht die Einführung bei einem Hersteller.

Wenn die Zuordnung selbst überlappt

Die unteren 32 Bit einer IPv6-Multicast-Adresse sind nach RFC 3307 die Group ID. Auf Ethernet werden diese Bits direkt in die Multicast-Adresse der Sicherungsschicht abgebildet. Ein doppelter Wert bleibt daher nicht in einem Verwaltungsregister. Netzkarte und Switch können unterschiedliche Ströme unter derselben Link-Layer-Zieladresse sehen.

MADCAP nach RFC 2730 ist ein Client-Server-Protokoll. Hosts fordern Multicast-Adressen oder Leases von einem Zuteilungsserver an. Das in RFC 10019 beschriebene Zeroconf-Problem verlangt dagegen ein dezentrales Verfahren ohne diesen Server. Beide Modelle können sinnvoll sein. Sie können aber nicht zuverlässig nebeneinander wählen, wenn beide den gesamten dynamischen Bereich beanspruchen.

Zufallsauswahl ist keine Zuständigkeitsgrenze. Sie verändert Wahrscheinlichkeiten, nicht Rechte. Die Solicited-Node-Überlappung war noch deutlicher, weil der Bereich bereits eine architektonische Funktion hatte und trotzdem im allgemeinen dynamischen Intervall lag.

RFC 10019 zeigt, welche Arbeit danach übrig bleibt. Ein dezentrales Verfahren muss mehrere Anwendungen und Vergabemechanismen vertragen, Kollisionen auf Netzwerk- und Link-Layer erkennen und Konflikte nach vorübergehenden Partitionen auflösen. Begrenzte Switch-Tabellen und Hash-Buckets können weitere Zusammenstöße erzeugen.

RFC 10028 entfernt den Konflikt, den die Spezifikation selbst vermeiden kann: Sie weist verschiedenen Vergabeverfahren nicht länger denselben Zahlenraum zu.

Sechs Bereiche mit begrenzter Aussagekraft

Das IANA-Register Dynamic Multicast Group IDs enthält zunächst:

  • 0x80000000-0x8FFFFFFF für MADCAP;
  • 0x90000000-0xEFFFFFFF als unzugewiesen;
  • 0xF0000000-0xFCFFFFFF für Hostvergabe von SSM-Gruppenadressen;
  • 0xFD000000-0xFDFFFFFF für Private Use;
  • 0xFE000000-0xFEFFFFFF für Experimental Use;
  • 0xFF000000-0xFFFFFFFF für Solicited-Node-Multicast.

Eine künftige gewöhnliche Zuteilung aus dem freien Bereich verlangt Standards Action. Das Register führt nur Bereich, Beschreibung und Referenz. Es enthält keine Produktstände, Verkehrsmessungen, Routingrichtlinien oder Empfängerrechte.

Gerade diese Beschränkung macht die gemeinsame Schicht belastbar. Um zu verhindern, dass MADCAP und ein SSM-Host denselben Abschnitt erhalten, muss IANA nicht wissen, welchem Geschäftsmodell ein Strom dient. Sie muss nur die Kennungsräume unterscheidbar halten.

Die schmale Funktion begrenzt jedoch das Ergebnis. IPv6-Adressen können sich oberhalb der abgebildeten Bits unterscheiden und trotzdem dieselbe Ethernet-Adresse ergeben. Hardware kann Einträge verdichten. Getrennte Netze können unabhängig wählen und den Konflikt erst bei der Wiedervereinigung erkennen. Ein Angreifer kann eine formal gültige Adresse missbrauchen.

Das neue Register beseitigt die Klasse „zwei offiziell berechtigte Allocator im gleichen Bereich“. Es beseitigt nicht alle Netzwerk-, Link-Layer- oder Hardwarekollisionen. Die Erkennungs- und Auflösungsanforderungen aus RFC 10019 bleiben daher erforderlich.

Der SSM-Bereich liefert keine SSM-Fähigkeit

Der Hostbereich ist ausdrücklich für Source-Specific Multicast vorgesehen. Bei SSM besteht ein Kanal aus (S,G), Quelle und Gruppe. RFC 4607 erklärt, dass verschiedene Quellen denselben Gruppenwert nutzen können, weil die vollständigen Kanäle dennoch verschieden sind. Der zusätzliche Koordinatenwert vermindert den Bedarf, jedes G global eindeutig zu machen.

Die Quelle entsteht aber nicht durch die Wahl der Hexadezimalzahl. Die Anwendung muss S kennen. Der Host muss quellenspezifische Mitgliedschaft über IGMPv3 oder MLDv2 ausdrücken. Designated Router und PIM-Domain müssen die Semantik erhalten. RFC 8815 empfiehlt SSM für Interdomain-Multicast und benennt zugleich Anwendungs- und Systemunterstützung als reale Einführungshürde.

RFC 10028 sagt deshalb, dass SSM nicht universell unterstützt wird. Eine Wahl aus 0xF0000000-0xFCFFFFFF installiert kein MLDv2, konfiguriert kein PIM und authentifiziert keinen Sender. Richtiger Namensraum und funktionierender Kanal sind verschiedene Tatsachen.

Heng Lus Minimum Initial Specification und Running-Code Primacy liefern dafür eine nützliche Disziplin. Die gemeinsame Spezifikation enthält nur die notwendige Interoperabilitätsgrenze. Spätere Entscheidungen bleiben näher am Betreiber. Ob eine Änderung real wurde, zeigt ihre Annahme im Code und ihr beobachtetes Verhalten. Das setzt ein IANA-Protokollregister nicht mit einem RIR gleich; es verhindert lediglich, dass ein Eintrag als Betriebsbeweis ausgegeben wird.

Alte MADCAP-Binaries behalten die alte Karte

RFC 10028 verkleinert den MADCAP-Bereich erheblich. Zum Zeitpunkt der Abfassung kannten die Autoren eine Implementierung und keine großflächige Einführung. Das Wort „bekannt“ ist entscheidend. Es beschreibt den Kenntnisstand, nicht die nachgewiesene Abwesenheit in jedem Netz.

Bestehende Implementierungen müssen den neuen Bereich verwenden oder in einer Umgebung laufen, in der keine anderen IPv6-Multicast-Vergabeverfahren kollidieren können. Eine aktualisierte IANA-Seite verändert weder ein altes Binary noch ein nicht mehr gewartetes Gerät oder eine jahrelang kopierte Konfiguration.

Ein Migrationsnachweis verknüpft deshalb Kennung und Erzeuger: Allocator, Version, Mechanismus, Konfiguration, geltender Registerstand, Zeit und Messergebnis. Wer nur die vollständige IPv6-Adresse protokolliert, kann später kaum zwischen altem MADCAP, konformem SSM-Host, Abbildungsverdichtung, Partition oder Missbrauch unterscheiden.

Es entsteht zudem eine Wahrnehmungsverzerrung. Das neue Verfahren ist oft besser instrumentiert und als jüngste Änderung sichtbar. Trifft es auf einen alten Server, wird womöglich der konforme neue Teilnehmer abgeschaltet. Ohne Herkunftsnachweis schützt die Organisation die unsichtbare Altlast.

Entscheidung, Register und Beobachtung nicht vermischen

Der RFC belegt die kollektive IETF-Entscheidung. IANA belegt den aktuellen öffentlichen Registerstand. Ein Implementierungstest belegt die Bereichsbegrenzung einer bestimmten Version. (S,G)-Kontrolltests und Paketbeobachtungen belegen Verhalten zu Zeit und Pfad. Identitäts- und Zugriffsunterlagen belegen Quelle oder Berechtigung.

Kein Nachweis erbt automatisch die anderen.

Die IANA-Zeile misst keine Verbreitung. Eine SSM-Adresse belegt keine Pfadfähigkeit. Empfang beweist keine legitime Quelle. Eine kollisionsfreie Probe deckt andere Scopes, Topologien und Hardwaregrenzen nicht ab.

Ein schlankes Betriebsledger reicht: Allocator und Version, Verfahren, Group ID und vollständige Adresse, RFC/IANA-Snapshot, SSM-Voraussetzungen, Kollisionsklasse und Erkennung, Weiterleitungsbeobachtung, Quellprüfung, Hörerberechtigung und Rollback-Verantwortung. Jedes Feld bleibt in der Zuständigkeit seines Beweises.

McBride, Karstens und Farinacci versprachen nicht, ein Register werde Multicast betreiben. Sie verhinderten, dass die gemeinsame Regel selbst weiterhin einen vermeidbaren Konflikt erzeugt.

Das Register ermöglicht Koexistenz. Das laufende Netz muss sie nachweisen.

Quellen