Zusammenfassung

  • RFC 9762 ergänzt den PIO um eine positive, präfixbezogene Präferenz: Ein fähiger Client soll DHCPv6 Prefix Delegation versuchen, bevor er neue Einzeladressen aus einem gemeinsam genutzten SLAAC-Präfix bildet.
  • P=1 ist kein Lease. Belastbare Evidenz trennt empfangenes RA, Client-Entscheidung, DHCP Reply, Eignung des Präfixes, Relay-Binding, Route und Filter, Quell- und First-Hop-Wahl sowie Datenverkehr und Anwendungsergebnis.
  • Das Fehlen von P bedeutet nicht, dass DHCPv6-PD fehlt. Ein empfangenes P erbt zugleich die Vertrauensgrenze von Router Advertisements und kann durch Fälschung oder Oszillation Konfiguration verzögern und REBIND-Last erzeugen.

Im Change-Review standen zwei Zeilen direkt nebeneinander. Die Router-Vorlage hatte P=1 wie beabsichtigt aktiviert. Dieselbe Automatisierung hatte jedoch auch A gelöscht, obwohl genau diese Kopplung nicht Teil des Auftrags war. Als PD später keinen geeigneten Lease lieferte, war der geplante SLAAC-Rückweg verschwunden.

Das Beispiel zeigt, warum RFC 9762 P und A ausdrücklich getrennt hält. P beschreibt eine Präferenz für den ersten Versuch. A bewahrt eine andere Fähigkeit des PIO. Weder ein Konfigurationswerkzeug noch ein Monitoring-System darf aus der Nähe beider Bits eine gemeinsame Autorität erfinden.

Der Name DHCPv6-PD Preferred Flag klingt stärker als der beobachtete Fakt. Ein System sieht P und schreibt „Prefix Delegation verfügbar“. Daraus werden leicht „Präfix erhalten“, „Route installiert“ und „Dienst erreichbar“. Auf dem Draht ist nur belegt, dass eine bestimmte Schnittstelle ein RA mit einem bestimmten PIO empfangen hat und ein Client mit PD-Unterstützung einen Grund bekam, einen weiteren Ablauf zu beginnen.

Die Präferenz muss vor der ersten Adresse eintreffen

Das Timing erklärt den Platz im PIO. Bildet der Host zuerst SLAAC-Adressen aus dem gemeinsamen On-Link-Präfix, können Anwendungen diese sofort verwenden. Erhält er später ein eigenes delegiertes Präfix, vermindert das Beibehalten beider Adresssätze den Skalierungsvorteil. Das Entfernen des ersten Satzes kann bestehende Verbindungen unterbrechen.

Mit P=1 kann der Betreiber deshalb vor dieser Verzweigung das in RFC 9663 beschriebene Modell pro Client bevorzugen. Die Aussage gehört zum einzelnen PIO. Ein globales Präfix kann PD bevorzugen, während ein ULA-Präfix im selben RA weiter SLAAC verwendet. Bei Multihoming dürfen verschiedene Upstreams unterschiedliche Entscheidungen signalisieren.

P ist von den RA-Bits M und O unabhängig. Manche ältere Geräte starten PD nur, wenn M oder O gesetzt ist; ein Netz mit solchen Clients sollte eventuell auch eines dieser Bits setzen. Ebenso müssen Router P und das Autonomous-Bit A separat konfigurierbar machen. Das Ändern von P darf A nicht automatisch verändern.

Diese Trennung erhält einen Fallback. P und A können gleichzeitig gesetzt sein. Solange der Client P befolgt, behandelt er A für neue Adressen als nicht gesetzt. Erhält er kein geeignetes delegiertes Präfix, kann er die P-Verarbeitung an der Schnittstelle abschalten und auf SLAAC oder IA_NA zurückfallen. RFC 4862 liefert die angepassten Autokonfigurationsregeln, RFC 4861 den Rahmen für Neighbor Discovery und RA. Das neue Bit verändert eine Entscheidung, nicht beide Protokolle insgesamt.

Eine Liste verleiht der Präferenz Zeit

Der Client führt pro Interface eine Liste aller Präfixe aus PIOs mit P=1 und noch positiver Preferred Lifetime. Wächst die Liste von null auf einen Eintrag, soll er PD starten, sofern es nicht bereits läuft. Läuft die Preferred Lifetime ab oder trifft ein PIO mit Lifetime null ein, wird der Eintrag entfernt.

Der Rückweg ist absichtlich bedingt. Wird die Liste leer, soll der Client Requests und Renewals nur beenden, wenn kein anderer Grund für PD besteht. Die Laufzeiten bereits delegierter Präfixe bleiben unberührt. Der RA-Sender kann seine Einladung zurückziehen, aber nicht den noch gültigen Lease des DHCP-Servers widerrufen.

Ändert sich die Liste bei vorhandenen Delegationen, gilt dies normalerweise als neue Konfigurationsinformation und löst REBIND aus, außer die Liste ist nun leer. RFC 8415 definiert die DHCPv6-Zustandsmaschine. Rebind, Reply, Server, Transaktion und IA_PD sind eigene Belege; sie stecken nicht implizit im vorherigen RA.

Ein verwertbares Journal hält RA-Quelle, Interface, PIO, P/A/L, Preferred und Valid Lifetime sowie die Generation der Liste fest. Ein separater Datensatz zeigt, ob der Client tatsächlich Solicit oder Rebind sendete und welche lokale Regel dies auslöste. Ein aktueller P-Wert kann Ablauf, expliziten Rückzug, Paketverlust und Oszillation nicht unterscheiden.

Eine Reply kann ein ungeeignetes Präfix liefern

Der Request muss einen Prefix-Length-Hint enthalten, der kurz genug ist, um SLAAC-Adressen zu bilden. Ein zurückgegebenes Präfix kann trotzdem zu lang sein und muss dann verworfen werden. Ein kürzeres Präfix kann akzeptiert und in geeignete längere Präfixe unterteilt werden.

Das ursprüngliche RA garantiert keinen dieser Ausgänge. Server oder Relay können unerreichbar sein, der Pool kann leer sein, eine Policy den Client ablehnen oder die Reply einen Fehlerstatus enthalten. Länge und Lifetimes können ungeeignet sein. Nach einem begrenzten erfolglosen Versuch darf der Client die P-Verarbeitung abschalten und eine andere Adressmethode nutzen.

Der Nachweis einer Delegation verbindet daher Request und Length Hint mit dem tatsächlich gewählten Server oder Relay, der Reply, dem IAPREFIX, Preferred und Valid Lifetime und der Annahmeentscheidung. Der empfangene PIO belegt nur die frühere Präferenz.

Auch die umgekehrte Behauptung ist falsch. P ist rein positiv. Kein PIO mit P sagt nicht, dass PD nicht existiert. Ein CE-Router nach RFC 7084 oder ein explizit konfigurierter Host kann unabhängig davon weiterarbeiten. Keine Einladung beobachtet ist nicht kein Dienst vorhanden.

Erst das Relay projiziert den Lease in den Pfad

Im Modell von RFC 9663 delegiert der Server ein Präfix und der First-Hop-Router installiert eine Route dorthin mit der Link-Local-Adresse des Clients als Next Hop. Für die Infrastruktur ist das Präfix off-link. Statt eines Neighbor-Cache-Eintrags für jede globale Client-Adresse kann sie eine Route pro Gerät führen, obwohl der Host viele Adressen, Container oder interne Netze betreibt.

Diese Projektion ist kein Werk des P-Bits. RFC 8987 verpflichtet ein delegating relay, Leases, Next Hops und lokale Routen zu führen, Ingress-Filter anzupassen, Zustand gemäß DHCP-Lifetimes zu erhalten oder zu löschen und Betriebsdaten sichtbar zu machen. Eine Reply am Client beweist keine installierte Route. Eine Route auf einem Router beweist keinen synchronen redundanten Peer. Ein RIB-Eintrag beweist kein Forwarding.

Auch der Client trägt Routing-Verantwortung. Das delegierte Präfix ist auf der Empfangsschnittstelle off-link. Ein Paket mit einem Ziel in diesem Präfix darf nicht auf dieselbe Schnittstelle zurückgesendet werden, weil eine Schleife entstehen kann. Eine hochmetrische Discard-Route ist eine mögliche Sicherung. Adressen aus der Delegation sollen für die Source Address Selection nach RFC 6724 mit der Empfangsschnittstelle verbunden werden.

Bei Multihoming gehört die Link-Local-Adresse des antwortenden Servers oder Relays zur Zuordnung. Liefern redundante Systeme dasselbe Präfix, können mehrere Zuordnungen erforderlich sein. RFC 8028 erklärt, weshalb Quellpräfix und First Hop zueinander passen müssen. Ein korrektes Präfix über den falschen Upstream liefert weiterhin einen Fehler.

Die vollständige Evidenzkette lautet somit: RA-Empfang; P-Listen-Generation; DHCP-Request; akzeptierte Reply; Lease; Relay-Binding; Route und Filter; Adressbildung; Quellenwahl; First Hop; Paketzustellung; Anwendungserfolg. Jeder Übergang braucht seinen eigenen Zeitstempel und Eigentümer.

Kommunikation auf demselben Link nimmt einen anderen Weg

Bei einem eindeutigen Präfix pro Client sind globale Adressen anderer Clients off-link. Das erste Paket zwischen zwei Geräten derselben Broadcast-Domain geht an den Default Router. Ein ICMPv6 Redirect kann einen direkteren Pfad vermitteln. RFC 9762 empfiehlt den Hosts die Verarbeitung, sofern lokale Policy nichts anderes sagt. Andernfalls kann lokale Kommunikation zusätzliche Latenz zeigen.

Ein Internet-Test deckt dies nicht ab. Delegation und externer Pfad können funktionieren, während Peer-to-Peer-Verkehr, lokale Discovery oder laterale ACLs unerwartet geroutet werden. Die Abnahme muss Off-Link- und Same-Link-Verkehr sowie beide Richtungen trennen.

Auch das Ressourcenmodell verschiebt sich. RFC 9663 tauscht mehr Präfixraum und Routen pro Client gegen weniger adressbezogenen ND-Zustand und gemeinsames Schicksal der Adressen eines Geräts. Für ein großes WLAN kann das sinnvoll sein; in einem Heimnetz mit wenigen verfügbaren /64 kann es den Pool erschöpfen. P signalisiert den bevorzugten Tausch, nicht seine Kapazitätsprüfung.

Der IANA-Eintrag authentifiziert keinen Router

Die IANA Registry für IPv6 Neighbor Discovery PIO Flags weist Bit 3 der P-Funktion zu. Sie schafft eine gemeinsame Syntax. Sie bestätigt nicht, dass ein RA-Sender an einem Access-Port berechtigt war.

Ohne den Schutz aus RFC 6105 kann ein lokaler Angreifer ein passendes PIO mit P=1 senden und Hosts dazu bringen, A zu ignorieren. Fehlt brauchbare PD-Infrastruktur, verzögert sich die Adressbildung oder scheitert. RFC 7113 zeigt zudem, dass die Konfiguration „RA-Guard aktiv“ nicht beweist, dass Umgehungen durch Fragmente und Extension Headers geschlossen sind.

DHCP besitzt eine weitere Vertrauensgrenze. Ohne DHCPv6-Shield aus RFC 7610 kann ein falscher Server ungültige Präfixe oder Parameter liefern. Selbst unter einem Betreiber bleiben RA und DHCP Reply getrennte Nachrichten an getrennten Ausführungspunkten. Vertrauen springt nicht von einer zur anderen.

Ein fehlerhaftes oder bösartiges System kann P wiederholt setzen und löschen. Listenänderungen lösen REBIND-Arbeit aus. Das Rate Limiting von RFC 8415 begrenzt Client-Nachrichten, beweist aber weder Lastfreiheit noch Kontinuität. Eingang, Transition und Downstream-Arbeit müssen separat gemessen werden.

Kleine Autorität ist hier die Architektur

P ist nicht zu schwach, weil es die ganze Kette nicht beweist. Sein begrenzter Zweck koordiniert die erste Wahl und lässt Allocation, Routing, Filter, Fallback und Ergebnis bei ihren Eigentümern. Heng Lus Prinzip einer minimalen Anfangsspezifikation mit lokalisierten künftigen Entscheidungen beschreibt diese schmale gemeinsame Fläche. Die Primarität laufenden Codes verlangt den Nachweis ausgeführter Zustände. Seine Realitätsschichten trennen Norm, Paket, Lease, Route und Nutzerergebnis.

Der Wert des Bits bleibt erhalten, wenn auch die Behauptung begrenzt bleibt.