Zusammenfassung

  • RFC 3736 ermöglicht einem Knoten mit bereits vorhandener IPv6-Adresse, weitere Parameter über einen DHCPv6-Austausch aus Information-request und Reply anzufordern, ohne eine Adresse zu beantragen.
  • „Zustandslos“ heißt, dass der Server für diesen Dienst keinen dynamischen Zustand je Client vorhalten muss; eine optionale Client-Kennung, lokale Richtlinien und Relay-Funktionen bleiben relevant.

Adresse und Resolver sind verschiedene Aufgaben

Die zustandslose IPv6-Adresskonfiguration kann einem Host anhand von Router Advertisements eine Adresse verschaffen. Damit sind aber nicht alle Konfigurationsfragen beantwortet. Der Host kann weiterhin Adressen rekursiver DNS-Server, Informationen zu SIP-Servern oder andere Optionen benötigen. DHCP lässt sich leicht als ein einziges Paket verstehen: Der Client fragt beim Server eine Adresse an und erhält zugleich die übrige Netzkonfiguration.

RFC 3736 trennt diese Funktionen. Der Client hat seine Adresse bereits auf anderem Weg erhalten — üblicherweise durch zustandslose Adresskonfiguration oder manuelle Einrichtung — und besitzt mindestens eine link-lokale Adresse zur Kommunikation. Mit Information-request und einer Option-Request-Option benennt er die gewünschten Optionstypen. Der Server antwortet mit Reply und den ausgewählten Konfigurationsparametern. In diesem Modus wird weder eine Identity Association für eine Adresse angefordert noch eine Adresse zugewiesen.

Der Austausch ist bewusst auf zwei Nachrichten begrenzt: erst Information-request, dann Reply. Ein Host kann DNS-Einstellungen anfordern, ohne daraus eine Adress-Lease zu machen. Dasselbe Serversystem kann sowohl Clients mit Adressbedarf als auch solche mit reinem Informationsbedarf bedienen; Relays arbeiten wie beim zustandsbehafteten DHCP.

„Zustandslos“ bedeutet jedoch nicht, dass der Server ohne Konfiguration oder Richtlinien arbeitet. RFC 3736 besagt, dass er keinen dynamischen Zustand über jeden Client speichern muss. Ein Client darf eine Client Identifier mitsenden, wenn ein Administrator die Antwort für diesen Knoten anpassen möchte. Der Server wählt Optionen weiterhin gemäß seiner Konfigurationsrichtlinie aus, und ein Relay kann Nachrichten weiterhin weiterleiten. Nicht erforderlich ist die clientbezogene Adressbindung, die dieser Informationsdienst sonst anlegen und verfolgen müsste.

Diese Unterscheidung hilft beim Lesen der IPv6-Router-Advertisement-Flags. In RFC 4861 zeigt Managed an, dass Adressen über DHCPv6 verfügbar sind; Other signalisiert weitere DHCPv6-Informationen, etwa DNS. Ist Managed gesetzt, ist Other redundant. Die Flags sagen etwas über Verfügbarkeit aus, nicht darüber, ob ein Host den DHCP-Austausch abgeschlossen, einen Resolver eingerichtet oder dessen Erreichbarkeit bewiesen hat.

Ohne Adress-Lease fehlt auch deren Uhr

Zugewiesene Adressen haben bevorzugte und gültige Lebensdauern. Sie zeigen dem Client, wann eine Adresse weiterverwendet werden kann und wann sie ungültig wird. Andere Konfigurationswerte haben womöglich keine entsprechende Laufzeit. RFC 3736 ließ ausdrücklich offen, wann der Host eine weitere Information-request zur Aktualisierung senden sollte; auch für einen Wechsel auf einen neuen Link gab es keine Aktualisierungsregel.

RFC 4242 ergänzte später die Option Information Refresh Time. Sie setzt eine Obergrenze dafür, wie lange ein Client bis zur nächsten DHCPv6-Aktualisierung warten soll. Die Begründung ist aufschlussreich: Ohne Adress- oder Präfix-Lease gibt es womöglich auch keine Lebensdauer, die den Client zum erneuten Kontakt auffordert. RFC 8415 fasste DHCPv6 später zusammen, löste RFC 3736 und RFC 4242 ab und behielt den zweistufigen Informationsaustausch bei.

Die Geschichte lautet also nicht: „Sobald SLAAC eine Adresse bildete, war DHCP überflüssig.“ Adressbildung und weitere Hostparameter ließen sich trennen. Das senkte den erforderlichen Clientzustand beim Informationsserver, ließ aber Quellpriorität, Aktualisierung, Schnittstellenbezug und die Einrichtung des Resolvers im Host als eigene Lebenszyklusaufgaben bestehen. Ein Reply belegt, dass das Protokoll Optionen zurückgab. Es belegt allein weder ihre Installation noch eine erfolgreiche DNS-Abfrage.

Diese RFCs zeigen nicht, wie häufig heutige Clients den Modus verwenden oder wie ein bestimmtes Netz ihn konfiguriert. Sie spezifizieren Mechanismus und Grenzen, nicht Verbreitung oder Serviceergebnis.

Quellen