Zusammenfassung

  • Eine Anwendung wählt eine zufällige Gruppen-ID, leitet IPv6- und Ethernet-Ziel ab und beansprucht letzteres mit einem mDNS-PTR unter .eth-addr.arpa.
  • Ein Netzgerät kann an das erste Anwendungslabel -veto anhängen; dieser Datensatz gewinnt den mDNS-Vergleich immer und zwingt den Verlierer, den Stream anzuhalten und neu zu wählen.
  • Revision 12 befindet sich im IETF Last Call, ist aber kein verabschiedeter Standard; die beantragten IANA-Einträge fehlen noch und Veto-Nachrichten werden nicht authentisiert.

Im aktuellen IANA-Register steht der vorgeschlagene Name noch nicht. Das ist kein Randdetail, sondern die erste Grenze jeder Aussage über draft-ietf-pim-ipv6-zeroconf-assignment-12.

Der am 22. September 2026 veröffentlichte Entwurf ist bis 6. Oktober im Last Call. Er beantragt den Gruppen-ID-Bereich 0x90000000-0x9FFFFFFF, eth-addr.arpa und die Special-Use-Domain 9.3.3.3.3.eth-addr.arpa.. Datatracker meldet weiterhin IANA Review Needed. Eine DNS-Directorate-Prüfung erklärt Revision 12 für bereit; sie macht daraus weder RFC noch Deployment-Beleg.

Die Anwendung wählt, der Draht bestimmt den Konflikt

Für einen neuen Stream zieht die Anwendung eine 28-Bit-ID. Nach RFC 4489 verbindet sie diese mit dem Interface Identifier der Quelle zu einer link-lokalen IPv6-Multicast-Adresse. RFC 2464 bildet daraus das Ethernet-Ziel.

Mehrere IPv6-Adressen können auf dasselbe Ethernet-Suffix fallen. Deshalb koordiniert der Entwurf nicht nur das IPv6-Symbol, sondern die Adresse, die NIC und Switch tatsächlich filtern. Die Nibbles werden rückwärts unter .eth-addr.arpa geschrieben. Aus 33:33:9A:BC:DE:F0 wird 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa.

Ein PTR unter diesem Namen zeigt auf Anwendungskennung plus Hostname. Die Anwendung probt nach RFC 6762. Bei gleichzeitiger Konkurrenz wählt der Verlierer neu. Ohne Konflikt kündigt sie den PTR an, beantwortet Anfragen und startet eine fortlaufende Abfrage. Erst dann darf sie senden.

Verfügbarkeit entsteht durch ausbleibenden Widerspruch. Gefiltertes mDNS kann daher zwei Anwendungen dasselbe Schweigen als Erlaubnis präsentieren.

Gespeichert heißt nicht verliehen

Die Gruppen-ID bleibt im persistenten Speicher, muss nach einem Neustart aber erneut konstruiert, geprüft, angekündigt und überwacht werden. Während der Pause kann sich das Netz geändert oder eine Partition geschlossen haben. Der gespeicherte Wert ist eine Präferenz aus einem früheren Beobachtungsraum, kein Lease.

Bei späterem Konflikt stoppt der Verlierer den Stream und wählt neu. Der Host darf außerdem verschiedene IPv6-Ziele erkennen, die auf dasselbe Ethernet-Ziel abgebildet werden. Eine Seite muss weichen; wie mehrere Hosts das untereinander abstimmen, legt der Entwurf nicht fest.

Das Veto ist durch die Kodierung stärker

Erkennt Infrastruktur einen unauflösbaren Tabellen- oder Filterkonflikt, veröffentlicht sie einen Veto-PTR unter demselben Owner Name. An das erste PTRDNAME-Label wird -veto angefügt. Beim RDATA-Vergleich erscheint die Label-Länge zuerst. Das längere Label liegt lexikografisch später und gewinnt den mDNS-Konflikt immer.

Das Gerät veröffentlicht ohne Probe. Die Anwendung hält an, zieht eine andere ID und überschreibt den gespeicherten Wert. Verschwindet der ursprüngliche PTR durch Ablauf oder Goodbye, fragt der Vetoinhaber fünf Sekunden lang nach. Ohne Antwort wartet er zufällig 20 bis 120 Millisekunden und zieht sein Veto per Goodbye zurück.

Nullkonfiguration bedeutet damit Arbeitsteilung der Autorität: Die Anwendung schlägt vor, Peers widersprechen, Infrastruktur überstimmt, Empfänger prüfen weiterhin den tatsächlichen Stream.

Ein garantiertes Ergebnis ist keine glaubwürdige Aussage

Wie mDNS setzt das Verfahren kooperierende Teilnehmer voraus. Ein Angreifer kann jeden Probe beantworten oder Vetos fälschen und so Auswahl, Stopp und Neuwahl endlos wiederholen. mDNS-Filterung erzeugt den Gegenfehler und verbirgt reale Konkurrenz.

Das Protokoll beweist nicht, dass der Veto-Sender wirklich ein Gerät mit Hardwarekonflikt ist. Ein erfolgreiches Announcement authentisiert auch nicht den Produzenten, autorisiert keine Nutzdaten und belegt weder Receiver Join noch Anwendungsergebnis.

Die Betriebsspur muss Stream-Identität, Gruppen-ID, Source IID, IPv6- und Ethernet-Ziel, PTR Owner/RDATA, Probe, Announcement, Query-Generation, Konflikt- oder Veto-Absender, Stoppbestätigung, Ersatzadresse, Receiver-Migration und Rückzug des alten Datensatzes verbinden.

Nach einer reparierten Partition helfen fortlaufende Abfragen, doch mDNS kann Duplikate erst spät entdecken. Zusätzliche Erkennung für während der Trennung entstehende Streams bleibt außerhalb des Entwurfs. Zufall senkt Wahrscheinlichkeit, repariert aber weder Sichtbarkeit noch getrennte Historien.

RFC 10019 formulierte diese Aufgabe, ohne Wire-Protokoll oder Gewinner festzulegen. Revision 12 liefert nun einen konkreten Mechanismus. Aus Sicht der Running-Code Primacy bleibt jeder Beleg begrenzt: PTR ist Behauptung, Vergleich ist Steuerung, Switch ist physische Beobachtung, Anwendung ist Ergebnis. Der Fortschritt liegt nicht im Verschwinden von Macht, sondern in ihrer beobachtbaren Ausübung.

Quellen