Zusammenfassung

  • Der IETF-Datatracker verzeichnet draft-ietf-pim-gaap-23 am 3. September 2026 und führt das Dokument nun unter AD Followup; es bleibt ein experimenteller Internet-Draft und ist kein verabschiedeter RFC.
  • Fassung 23 schreibt für IPv4 239.0.0.0/10 und für IPv6 den Experimental-Use-Bereich aus RFC 10028 vor, damit unabhängig entwickelte Implementierungen im selben Adressraum rechnen.
  • Die Fassung hält zugleich fest, dass eine Partitionsseite für denselben Namen den Kandidaten +1, die andere +2 wählen kann. Da die Adressen verschieden sind, entsteht keine Kollision; die Gruppe kann nach der Heilung geteilt bleiben.
  • Kollisionsfreiheit ist ein negativer Befund und kein positiver Beleg dafür, dass Gruppenname, Adresse und Teilnehmer wieder zusammengefunden haben.
  • Ein lokaler Konvergenzbeleg könnte diese Evidenz sichern. Das ist ein Analysevorschlag von Daniel Kade, keine Vorgabe des IETF oder des Entwurfs.

Ein gemeinsamer Bereich schließt eine Konfigurationslücke

Die Dokumenthistorie datiert Fassung 23 des Group Address Allocation Protocol auf den 3. September. Am selben Tag wechselte der Unterstatus von Revised I-D Needed zu AD Followup; die IANA-Prüfung sprang auf Version Changed - Review Needed zurück. Das sind Stationen laufender Arbeit. Sie besagen weder, dass der IESG zugestimmt hat, noch dass ein RFC veröffentlicht wurde.

Im Änderungsprotokoll der Fassung 23 heißt es, die DISCUSS-Position und die Kommentare von Éric Vyncke seien bearbeitet worden. Inhaltlich zeigt die Revision zwei verschiedene Koordinationsprobleme: Eines lässt sich durch einen gemeinsamen Startwert beseitigen, das andere bleibt selbst danach ungelöst.

GAAP soll Multicast-Teilnehmern eine Gruppenadresse verschaffen, ohne dass ein zentraler Dienst sie zuteilt. Eine Anwendung liefert einen Gruppennamen. Daraus bildet das Protokoll mit SHA-256 genau vier erlaubte Kandidaten: den unveränderten Namen und denselben Namen mit +1, +2 oder +3. Ein Knoten sendet für den ersten Kandidaten eine Claim-Nachricht und wartet ungefähr ein periodisches Claim-Intervall, also etwa eine Minute. Meldet in dieser Zeit kein anderer Gruppenname dieselbe Netzwerkschichtadresse, darf die Anwendung sie verwenden. Bei einer Kollision folgt der nächste Kandidat.

Eine globale Zuordnungstabelle ist nicht vorgesehen. Knoten müssen Claims anderer Knoten nicht zwischenspeichern. Jeder hält nur die eigenen Zuweisungen und Timer; nach einem Neustart wird dieser Soft State durch neue Claims aufgebaut. Das spart gemeinsamen Zustand. Umso wichtiger ist, dass getrennt entwickelte Software dieselben grundlegenden Parameter nutzt.

Der offizielle Vergleich zwischen Fassung 22 und 23 zeigt die Korrektur. Zuvor waren die Anwendungsbereiche durch den Betreiber konfigurierbar. Nun begründet der Entwurf feste Werte damit, dass ein konfigurierbarer Bereich nur mit sich selbst zuverlässig kompatibel wäre: Ein Betreiber kann Anwendungen auswählen, aber nicht bestimmen, welche unabhängig geschriebene GAAP-Implementierung diese jeweils mitbringen.

IPv4-Implementierungen müssen deshalb 239.0.0.0/10 verwenden. Der Text verweist auf RFC 2365 für die noch verfügbaren Blöcke zur Erweiterung des Organization-Local-Geltungsbereichs und auf RFC 5771 für die Zuteilungsregeln. Bei IPv6 gilt 0xFE000000–0xFEFFFFFF, der in RFC 10028 für neue dynamische Zuteilungsversuche ausgewiesene Experimental-Use-Bereich. Er ist nicht GAAP vorbehalten; auch andere Experimente dürfen ihn nutzen.

Diese Festlegung ist ein echter Interoperabilitätsschritt. Zwei konforme Programme beginnen nicht länger in getrennten Adresswelten. Ein gemeinsamer Kandidatenraum garantiert jedoch nicht, dass sie für einen konkreten Namen am Ende denselben Kandidaten auswählen.

Zwei lokal richtige Antworten können die Heilung überstehen

Die Partitionsreparatur erfasst zunächst einen sichtbaren Fall. Nutzen beide Seiten dieselbe Adresse für einen Gruppennamen, treffen ihre Claims nach Wiederherstellung der Verbindung aufeinander. Das Verfahren kann den Zustand vergleichen und auflösen.

Der neu beschriebene Fall ist stiller. Auf der einen Seite zwingt eine unabhängige lokale Kollision den gemeinsamen Namen vom Basiskandidaten zu +1. Auf der anderen Seite führt eine andere lokale Kollision denselben Namen zu +2. Beide Entscheidungen stammen aus der geschlossenen Kandidatenliste und können in ihrem jeweiligen Teilnetz korrekt sein.

Nach der Verbindung meldet die eine Seite Adresse A, die andere Adresse B. Der von GAAP definierte Konflikt — dieselbe Adresse für verschiedene Namen — tritt nicht auf. Nichts kollidiert. Fassung 23 sagt ausdrücklich, dass die Gruppe geteilt bleibt, und nennt die Lösung eine offene Frage des Experiments.

Vyncke hatte in seiner IESG-Abstimmungsposition genau danach gefragt: Würden partitionierte Netze mit +1 und +2 erkannt, und würden alle Teilnehmer konvergieren? Die Revision macht die Grenze nun zu einem Teil der Spezifikation. Sie liefert aber noch keinen Mechanismus für deren Überwindung.

Eine Null im Kollisionszähler kann damit zwei gegensätzliche Wirklichkeiten abbilden. Entweder führt ein Name zu einer Adresse und alle Teilnehmer finden sich wieder. Oder derselbe Name führt zu zwei Adressen, die Teilnehmer bleiben getrennt, und keine Seite beansprucht die Adresse der anderen. Das Ausbleiben eines negativen Ereignisses beweist nicht die positive Eigenschaft des Rendezvous.

RFC 10019, die von GAAP zitierte Problembeschreibung, fordert für dezentrale Multicast-Zuteilungen die Erkennung und Auflösung von Adresskollisionen nach einer vorübergehenden Partition. Diese Aufgabe bleibt bestehen. Der neue Grenzfall ist benachbart, aber anders: Er betrifft divergierende Zuordnungen eines Namens. „Kollision gelöst“ und „Name konvergiert“ müssen getrennte Versuchsergebnisse sein.

Das Experiment braucht einen positiven Rendezvous-Nachweis

Der Entwurf beschreibt seinen Reifegrad zurückhaltend. Dezentrale, hashbasierte Multicast-Zuteilung sei noch nicht eingesetzt worden. Das Experiment soll zeigen, ob Kollisionsprüfung und -auflösung in praktischen Umgebungen genügen, welche Kollisionsraten in verschiedenen Größenordnungen entstehen und wie der periodische Claim-Verkehr skaliert. Es endet, wenn Betriebserfahrung eine spätere Standards-Track-Behandlung stützt oder grundlegende Grenzen eine Revision verlangen.

Der stille Split gehört nun in diese Auswertung. Eine Kollisionsstatistik misst, wie oft zwei Namen auf dieselbe Adresse treffen und wie oft das Reparaturverfahren reagiert. Sie misst nicht, wie oft ein Name auf zwei Adressen fortbesteht, weil dieser Zustand den Kollisionszähler nie erreicht. Das Experiment muss daher Zuordnung und Erreichbarkeit nach der Heilung direkt beobachten.

Dafür ist kein zentraler Zuteilungsdienst nötig. Ein lokaler Konvergenzbeleg könnte eine datensparsame Kennung des Gruppennamens, die Kohorten beider Partitionsseiten, den jeweiligen Kandidatenindex, die ausgewählten Adressen, Trennungs- und Heilungszeitpunkt, den Erkennungspfad, die anschließende Anwendungsreichweite und das Reparaturergebnis verbinden. Ein Prüfer könnte dann nur drei ehrliche Ergebnisse festhalten: Konvergenz beobachtet, Divergenz beobachtet oder Beobachtung unzureichend.

Dieser Beleg ist mein redaktioneller Vorschlag. Er steht weder in GAAP noch in einer Vorgabe von IETF, IANA oder der PIM-Arbeitsgruppe. Er soll verhindern, dass das Fehlen eines schlechten Signals als Messung einer guten Eigenschaft ausgegeben wird.

Lu Hengs Minimum Initial Specification, Localized Future Decision hilft, diese Evidenz mit Dezentralisierung zu verbinden. Der feste Bereich ist die kleine gemeinsame Regel, die unabhängige Implementierungen zum Zusammentreffen brauchen. Wie ein seltener Split erkannt, gespeichert und behoben wird, kann im Experiment lokal weiterentwickelt werden, solange die Resultate vergleichbar bleiben.

Running Code Primary trennt Dokumentfortschritt von Wirkungsnachweis. Ein neuer Status, eine IANA-Zuteilung oder eine aufgehobene DISCUSS-Position verändern den institutionellen Datensatz. Sie zeigen nicht, dass zwei Implementierungen nach unterschiedlichen lokalen Kollisionen zu einer Zuordnung zurückkehren. Das kann nur ein reproduzierbarer Test leisten, der die Partition erzeugt, +1 und +2 auslöst, den Pfad heilt und die tatsächlich verwendeten Zuordnungen festhält.

Fassung 23 verbessert das Experiment, weil sie die Grenze nicht mehr verschweigt. Der nächste Governance-Schritt besteht darin, die festen Bereiche nicht als Stellvertreter für einen größeren Erfolg zu verwenden. Konvergenz muss selbst beobachtbar werden.

Quellen

  1. GAAP im IETF-Datatracker
  2. GAAP-Dokumenthistorie
  3. GAAP, Fassung 23
  4. GAAP, Fassung 22
  5. Offizieller Vergleich 22–23
  6. IESG-Abstimmung zu GAAP
  7. RFC 10019: Problem der konfigurationslosen Multicast-Adressvergabe
  8. RFC 10028: Dynamische IPv6-Multicast-Group-IDs
  9. RFC 2365: Administrativ begrenztes IP-Multicast
  10. RFC 5771: IANA-Richtlinien für IPv4-Multicast-Adressen
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision
  12. Lu Heng — Running Code Primary