Zusammenfassung

  • Eine PvD ist eine Konsistenzgrenze für Quelladresse, DNS, ersten Router und weitere Netzkonfiguration. FQDN, Flags und Sequenznummer kennzeichnen und erneuern diese Grenze; sie bilden keine Rangliste möglicher Wege.
  • Vertrauen entsteht als Kette: Zusatzinformationen im selben PvD abrufen, Namen und Zertifikat prüfen, Kennung, Ablauf und Präfixe abgleichen, lokale Auswahlregeln anwenden und anschließend Quelle, Resolver, Next Hop und Ergebnis der echten Verbindung belegen.

Frisch, bekannt und trotzdem nicht gewählt

Ein Host erhält auf demselben Link zwei explizite PvDs. Die erste trägt den FQDN eines bekannten Betreibers. Das H-Flag kündigt Zusatzinformationen an, und die Sequenznummer wurde seit der letzten Messung erhöht. Ein Betriebsdashboard hebt diese PvD hervor und meldet sie als ausgewählt.

Das per HTTPS authentisierte JSON enthält jedoch noInternet: true. Die Domain ist funktionsfähig, aber auf lokale Dienste beschränkt. Für eine öffentliche Webverbindung wählt die Host-Policy die zweite PvD. Eine interne Anwendung könnte gleichzeitig die erste nutzen.

Das Protokoll widerspricht sich nicht. Name, Aktualität, Eignung für einen Zweck und ausgeführte Auswahl sind vier Aussagen. Das Dashboard hat sie zu einer einzigen Ampel verdichtet.

Gerade diese Verdichtung verursacht in mehrfach angebundenen Systemen schwer erklärbare Fehler. Eine Quelladresse aus Netz A kann mit einem Resolver aus Netz B und dem Standardrouter aus Netz C verbunden werden. Jeder Wert ist für sich plausibel; die Kombination ist es nicht. RFC 7556 führt die Provisioning Domain ein, damit der Ursprung der Konfiguration erhalten bleibt.

Keine andere Bezeichnung für ein Interface

RFC 7556 beschreibt eine PvD als konsistente Menge von Netzkonfigurationsdaten. Dazu können Quellpräfixe, DNS-Server, Suchsuffixe, Proxyangaben und Standardgateways gehören.

Mehrere PvDs können über denselben Link eintreffen. Umgekehrt kann eine PvD mehrere Links umfassen. Die Grenze ist daher weder Steckplatz noch Interface-Name, sondern die Aussage, welche Parameter gemeinsam eingesetzt werden dürfen.

Die Architektur kennt implizite PvDs, die aus der Konfigurationsquelle abgeleitet werden, und explizite PvDs mit Identität. Ein PvD-fähiger Host hält Parameter und Herkunft zusammen. Für eine Verbindung wählen Betriebssystem, Nutzer oder Anwendung nach Sicherheitsbedarf, Kosten, Reichweite und Verfügbarkeit eine passende Domain und verwenden dann deren Adressen, Resolver und Router.

Ein allgemeingültiger Sieger ist nicht vorgesehen. Ein abgeschottetes Produktionsnetz kann für Maschinensteuerung richtig und für einen Browser ungeeignet sein. Verschiedene Anwendungen desselben Hosts dürfen deshalb gleichzeitig unterschiedliche PvDs verwenden.

Die Router Advertisement benennt den Kontext

RFC 8801 definiert die PvD Option als Neighbor-Discovery-Typ 21 in IPv6 Router Advertisements. Sie enthält eine PvD ID als FQDN, H/L/R-Flags, eine 16-Bit-Sequenz, Delay und gegebenenfalls eingebettete RA-Informationen.

Der ankündigende Betreiber soll den FQDN besitzen und verwalten. Derselbe Bezeichner ist nur für letztlich identische Dienste gedacht; unterschiedliche Angebote brauchen unterschiedliche IDs. Das schafft ein stabiles Namensrecht, authentisiert aber nicht automatisch den lokalen Router. Ein Angreifer auf dem Link kann ebenfalls einen bekannten FQDN in eine gefälschte RA schreiben.

Die Flags haben enge Bedeutungen. H kündigt per HTTPS abrufbare Zusatzinformationen an. L ordnet ältere DHCPv4-Informationen zu. R weist auf einen inneren RA-Kopf und Optionen für PvD-fähige Hosts hin. H beweist weder Abruf noch Akzeptanz, R keine Bevorzugung.

Auch die Sequenznummer ist kein Prioritätswert. Ihre Änderung macht zuvor abgerufene Informationen veraltet und kann einen erneuten, zufällig verzögerten Abruf auslösen. Die 42 einer PvD steht nicht über der 7 einer anderen. Delay steuert Last, nicht Dringlichkeit.

Die Prüfung muss im betrachteten PvD bleiben

Ist H gesetzt, darf der Host https://<PvD-ID>/.well-known/pvd abrufen. Ohne H darf er diesen Mechanismus nicht nutzen. Die Antwort trägt den Medientyp application/pvd+json.

DNS-Auflösung der PvD ID, Zertifikatsprüfung, HTTPS-Verbindung, Quelladress- und Next-Hop-Auswahl müssen ausschließlich die Konfiguration der betrachteten PvD verwenden. Wer den Namen über ein zweites Netz auflöst und das Objekt über ein drittes holt, hat die behauptete Bindung nicht geprüft.

Diese Forderung schützt auch Vertraulichkeit. Split DNS kann je Kontext andere Antworten liefern, und das Quellpräfix beeinflusst den richtigen ersten Router. Eine Anfrage nach einem unternehmensspezifischen PvD-Namen über einen fremden Zugang verrät zudem, welchem Netz das Gerät begegnet ist. Eine bloße URL im Log genügt nicht.

Das TLS-Zertifikat muss eine DNS-ID enthalten, die der PvD ID entspricht. Scheitert die Prüfung, wird die Verbindung geschlossen und die PvD so behandelt, als besäße sie keine Zusatzinformationen. Damit autorisiert der FQDN-Inhaber den Informationsdienst. Die lokale RA und alle Präfixe sind dadurch noch nicht bestätigt.

Das JSON bindet Namen und Präfixe

Ein gültiges Objekt enthält identifier, expires und prefixes. Die Kennung muss zum angekündigten Namen passen, der Ablauf in der Zukunft liegen und die Präfixliste alle zugehörigen Prefix Information Options der RA abdecken. Fehlt ein Pflichtfeld oder bleibt ein Präfix ungedeckt, darf die Information nicht verwendet werden.

Damit werden zwei Oberflächen abgeglichen. Der lokale Router erklärt, eine Konfiguration gehöre zu einem Namen. Der authentisierte Dienst erklärt, der Name erkenne bestimmte Präfixe an. Kontrolle über nur eine Seite erzeugt noch keine vollständige Autorität.

dnsZones kann erreichbare Namensräume beschreiben. noInternet: true kennzeichnet eine eingeschränkte PvD, keinen Defekt. Für Fabrik, Klinik oder Unternehmensdienst kann gerade die Begrenzung gewollt sein.

Unbekannte Schlüssel werden ignoriert. IANA führt das gemeinsame Register; private Erweiterungen gehören in organisatorische oder vendor-*-Unterwörterbücher. Registrierung vereinheitlicht Semantik, beweist aber keine konkrete Behauptung und keine flächendeckende Implementierung.

Aktualität braucht eine Abbruchkante

Sequenzwechsel oder Ablauf machen gespeicherte Informationen veraltet. Delay und zufällige Aktualisierungsfenster verhindern gleichzeitige Anfragen vieler Hosts. Absolute Zeit kann wegen einer falschen Host-Uhr irreführen und darf allein keine sicherheitskritische Entscheidung tragen.

Ein bösartiger Router könnte mit vielen PvD IDs DNS-, TLS- und HTTP-Verbindungen zu fremden Servern auslösen. Hosts begrenzen die Rate, fragen nach Zertifikats-, HTTP- oder JSON-Fehlern dieselbe ID während der aktuellen Netzanbindung nicht erneut ab und stoppen nach zehn oder mehr Fehlern alle PvD-Abfragen für diese Anbindung.

Wer H setzt, übernimmt zugleich eine Betriebsverpflichtung. Selbst ein Captive Portal muss DNS, Zertifikatsprüfung und HTTPS zum Informationsdienst vor der Anmeldung zulassen. Der Host sollte eine temporäre IPv6-Adresse aus der PvD verwenden und Cookies oder identifizierende Header vermeiden.

Erst die laufende Verbindung belegt die Wahl

Nach der Validierung entscheidet die Host-Policy für den konkreten Zweck. Der Betreiber benennt und liefert einen konsistenten Kontext. Der FQDN-Inhaber autorisiert den Informationsdienst. Das JSON beschreibt Grenzen. Der Host beurteilt, ob sie zur Anwendung passen.

Die ausgeführte Quelladresse, der verwendete Resolver, der erste Router, das Ziel und das Ergebnis sind die Belege. Running-Code Primacy bedeutet hier nicht, die Standards zu übergehen, sondern ihre minimalen Zuordnungen in realem Verhalten nachzuweisen.

Quellen