Zusammenfassung

  • draft-ietf-pim-ipv6-zeroconf-assignment-12 lässt eine Anwendung eine Adresse nutzen, wenn sie keinen Hinweis auf bestehende Nutzung empfängt. Diese negative Evidenz gilt nur innerhalb der tatsächlich erreichbaren mDNS-Sicht.
  • Ein dauerhaft gespeicherter Gruppenwert erspart keine neue Prüfung. Nach einer Partition muss der Verlierer eines Konflikts den Stream stoppen, eine andere ID wählen und sie speichern; die Entdeckung kann laut Entwurf erhebliche Zeit beanspruchen.

Revision 12 trägt das Datum 22. September 2026. Der eingefrorene Datatracker-Stand zeigt einen aktiven PIM-Working-Group-Entwurf (Internet-Draft), der beim IESG eingereicht wurde und bis 6. Oktober im IETF Last Call steht. Vorgesehen ist Proposed Standard. Ein RFC, abgeschlossene IANA-Einträge oder ein bestätigter Interoperabilitätsnachweis sind das nicht.

Das Verfahren wählt für einen neuen Stream oder nach einem Konflikt eine zufällige Gruppen-ID aus dem beantragten Bereich 0x90000000–0x9FFFFFFF. Zusammen mit der Kennung der Quellschnittstelle entsteht eine link-lokale, quellenspezifische IPv6-Multicast-Adresse. Daraus folgt die Ethernet-Multicast-Adresse; im Beispiel wird aus 9abc:def0 die Adresse 33:33:9A:BC:DE:F0.

Anschließend werden die Hexadezimalstellen der Ethernet-Adresse unter .eth-addr.arpa umgekehrt angeordnet. Für den entstehenden Namen veröffentlicht die Anwendung einen eindeutigen PTR. Sie prüft ihn nach mDNS-Regeln, kündigt ihn an, beantwortet Anfragen, hält eine fortlaufende Anfrage offen und verteidigt den Datensatz.

Die Revision benennt dabei eine entscheidende Annahme: „implicit availability“. Erhält die Anwendung keinen Hinweis, dass die Adresse belegt ist, betrachtet sie sie als verfügbar. Gleich danach warnt der Text, dass Filterung von mDNS auf Host- oder Netzebene die Koordination verhindert und Kollisionen auslösen kann.

Schweigen ist damit kein globaler Beleg. Es dokumentiert nur, dass innerhalb eines bestimmten Zeitfensters über bestimmte Schnittstellen und Verbindungswege kein Widerspruch sichtbar wurde. Eine ACL, ein ausgefallener Reflector oder eine unterbrochene Verbindung kann einen vorhandenen Anspruch verbergen. Auch die Formel n / 2^28 beschreibt lediglich die Zufallsauswahl, nicht die Vollständigkeit der Beobachtung.

Eine Partition macht das konkret. Fällt ein Switch aus, startet auf der einen Seite ein bestehender Stream mit seiner gespeicherten ID. Auf der anderen Seite kann eine neue Anwendung dieselbe Zahl wählen. Beide führen eine Probe durch, doch die PTR-Nachrichten überschreiten die Trennung nicht. Beide lokalen Entscheidungen wirken gültig.

Nach der Reparatur existieren zwei Ansprüche in einem Netz. Deshalb verlangt der Entwurf eine fortlaufende PTR-Abfrage. Wird der Konflikt erkannt, entscheidet das mDNS-Verfahren; der Verlierer muss die Übertragung stoppen, eine neue Gruppen-ID wählen und den gespeicherten Wert überschreiben.

Der Zeitpunkt ist offen. Weil mDNS auf geringe Bandbreite ausgelegt ist, könne es nach der Wiedervereinigung erhebliche Zeit dauern, eine Datensatzkollision zu erkennen, heißt es im Entwurf. Eine allgemeine Obergrenze fehlt. Besonders relevant ist das für Netze, in denen jederzeit neue Streams entstehen können.

Währenddessen können beide Sender auf einer Statusseite gesund erscheinen. Dieselbe Ethernet-Zieladresse kann Pakete für unterschiedliche IPv6-Multicast-Ziele tragen. Ein Kontrollsystem, das nur einen erfolgreichen PTR sieht, verwechselt einen lokalen Erfolg mit netzweiter Eindeutigkeit.

Optional darf der Netzwerkstack des Hosts diesen Widerspruch direkt beobachten: gleiche Multicast-Ethernet-Zieladresse, andere IPv6-Zieladresse. Dann muss die Anwendung den Stream stoppen und neu wählen. Nur eine Seite muss weichen, beide dürfen es; welches System nachgibt, koordiniert der Entwurf nicht.

Für Infrastruktur gibt es einen Veto-Datensatz. Erkennt ein Netzkomponent eine nicht auflösbare Kollision, hängt er -veto an das erste Ziel-Label des PTR. Dadurch liegt sein Wert in der mDNS-Konfliktordnung stets später und gewinnt. Das Veto wird ohne vorherige Probe veröffentlicht und zwingt die Anwendung zum Wechsel.

Es bleibt aber nicht dauerhaft. Ist der ursächliche PTR verschwunden oder abgelaufen, fragt der Veto-Sender fünf Sekunden lang nach. Bleibt die Antwort aus, wartet er zufällig 20 bis 120 Millisekunden und sendet ein Goodbye. Die Anwendung hat ihre Ersatz-ID bereits gespeichert; ein permanentes Veto ist unnötig.

Diese Durchsetzung lässt sich missbrauchen. Gefälschte Konfliktantworten können jede neue Auswahl blockieren, falsche Vetos bestehende Streams wiederholt verdrängen. Wer mDNS filtert, kann die Konfliktvermeidung neutralisieren. Der Entwurf setzt kooperative Teilnehmer voraus und kann diese Eigenschaft nicht selbst erzwingen.

Auch Persistenz ist keine Bestätigung der Gegenwart. Die gespeicherte ID soll in einem unveränderten Netz Ruhe schaffen. Revision 12 sagt jedoch ausdrücklich, dass kein vorheriger Schritt übersprungen werden darf. Erneute Probe, Ankündigung, Dauerabfrage und Verteidigung bleiben notwendig, weil sich das Netz während der Offline-Zeit verändert haben kann.

Aus Sicht der Running-Code Primacy zählt deshalb die nachweisbare Ausführung: Auswahl, Ableitung, Probe, Ankündigung, Beobachtung, Verteidigung, Stopp und Ersatz. Ein ruhiger Datenbankwert ist kein Beleg für einen unveränderten Beobachtungsraum. Formale Stabilität des Identifikators kann operative Instabilität verdecken.

Das Verfahren ist zudem keine Service-Discovery. Es koordiniert einen PTR für die Adresse, schreibt aber nicht vor, wie Empfänger die Stream-Adresse erfahren. DNS-SD mit _udp und einem TXT wird nur als naheliegende Möglichkeit genannt. Danach fehlen weiterhin Nachweise für Mitgliedschaft, Weiterleitung, Paketzustellung und Verarbeitung.

Über mehrere Subnetze müssen PTRs verteilt werden, etwa per mDNS-Reflector. Dies bezeichnet der Entwurf als weiter offene Forschungs- und Verbesserungsfrage. Weitergeleitete Streams brauchen eine unicastpräfixbasierte IPv6-Multicast-Adresse statt der link-lokalen Variante. Wegen der Annahme kooperativer Hosts ist das Verfahren nicht für das globale Internet geeignet.

Die gemeinsame Schicht sollte deshalb schlank bleiben: lokale Eindeutigkeit koordinieren, wenn Teilnehmer einander hören können. Sie darf nicht zur allgemeinen Verfügbarkeitsbescheinigung werden. Das Betriebsjournal benötigt Gruppen-ID, Quellschnittstelle, beide abgeleiteten Adressen, Speicher-Epoche, geprüfte Schnittstellen, Reflector-Reichweite, Filter, Partition, Konflikt oder Veto, Stopp, Ersatz und neue Probe. Empfänger, Weiterleitung und Ergebnis folgen mit eigenen Belegen.

Die richtige Frage lautet nicht, ob mDNS eingeschaltet war. Sie lautet, wer den Anspruch hätte widerlegen können. Ohne diese Reichweite bedeutet „frei“ nur: Noch hat kein sichtbarer Teilnehmer widersprochen.

Quellen