Zusammenfassung

  • RFC 9915 beschreibt DHCPv6 für zustandslose Konfiguration und zustandsbehaftete Vergabe von IPv6-Adressen und Präfixen; es kann neben SLAAC oder an dessen Stelle eingesetzt werden.
  • RFC 9915 ist seit Januar 2026 der IETF Internet Standard STD 102, ersetzt RFC 8415 und enthält verifizierte Errata.
  • Die wesentliche Änderung ist kein neues Adresspaket, sondern ein engeres Lebenszyklusmodell für Identitäten, Identity Associations, Laufzeiten, Renew, Rebind und Prefix Delegation.

Im Austausch identifiziert der Client sich über eine DUID, der Server über einen Server Identifier. Solicit, Advertise, Request, Reply und die nachfolgenden Vorgänge bilden einen fortlaufenden Kontext. Eine erfolgreiche Reply-Nachricht beweist deshalb nur, dass ein Anfangszustand hergestellt wurde. Für jede Identity Association gelten eigene Ressourcen und Laufzeiten: IA_NA kann Adressen verwalten, während Prefix Delegation den Zustand eines delegierten Präfixes trägt. T1 markiert den üblichen Renew-Zeitpunkt, T2 den Übergang zum Rebind.

Beim Renew fragt der Client typischerweise den Server, der den Zustand geliefert hat, nach einer Verlängerung. Scheitert dieser Pfad, sucht der Client beim Rebind breiter nach einem erreichbaren Server. Genau dort werden Serverwechsel, Relay-Grenzen, veränderte Multicast-Erreichbarkeit und abweichende Server Identifier sichtbar. Reconfigure kann einen Client dazu auffordern, einen neuen Austausch zu beginnen; sie ersetzt aber weder Messung noch einen Test für den Fall, dass die Aufforderung oder die Antwort nicht ankommt.

Prefix Delegation bleibt ein zustandsbehafteter DHCPv6-Dienst. Ein Customer-Edge-Router muss das delegierte Präfix, seine Laufzeiten und die Nutzung in nachgelagerten Netzen zusammenhalten. Ein Provider- oder Relay-Wechsel kann daher eine zunächst funktionierende Adresse von späterer Nichterreichbarkeit entkoppeln. RFC 7084 liefert Anforderungen für IPv6-Customer-Edge-Router und den Delegationskontext, sagt aber nichts über die Konformität eines bestimmten Produkts aus. Der Test muss Neustart, Serverausfall, Restlaufzeit, Renew, Rebind und die Erreichbarkeit der nachgelagerten Netze umfassen.

RFC 9915 entfernt IA_TA für die temporäre Adresszuweisung und die Server-Unicast-Fähigkeit. Dazu gehören die Server-Unicast-Option und der Statuscode UseMulticast. Das bedeutet nicht, dass Datenschutzadressen verschwunden sind. SLAAC nach RFC 4862 und temporäre Adressen nach RFC 8981 bleiben ein eigener Mechanismus. DHCPv6 ersetzt SLAAC also nicht automatisch in jedem Netz; die konkrete Architektur muss beide Rollen und die gewünschte Privatsphäre ausdrücklich festlegen.

Mehrere zustandsbehaftete Optionen oder mehrere IAs dürfen nicht als eine unteilbare Transaktion behandelt werden. Eine Adress-IA kann erneuert werden, während eine andere IA oder ein delegiertes Präfix scheitert. RFC 7550 macht diese Mehrfach-IA-Grenze operativ relevant. Überwachung sollte daher DUID, Server Identifier, IA-Zustand, T1, T2, verbleibende Laufzeit, Relay-Pfad, Reconfigure-Ergebnis und die tatsächlich verwendete delegierte Präfixroute einzeln erfassen.

Anspruch–RFC-Nachweis

Anspruch Nachweis
Aktuelles DHCPv6-Verhalten, Laufzeiten und entfernte Fähigkeiten RFC 9915
Abgelöste Vergleichsbasis RFC 8415
SLAAC und sein Zusammenspiel RFC 4862
Customer-Edge- und Delegationskontext RFC 7084
Mehrere zustandsbehaftete DHCPv6-Optionen RFC 7550
Temporäre SLAAC-Datenschutzadressen RFC 8981

Dies ist keine Aussage über Herstellerunterstützung, universelle Einführung oder die Sicherheit einer bestimmten Zeitgrenze. Auch das Verhalten einer gemischten RFC-8415/RFC-9915-Umgebung muss gemessen werden.