Zusammenfassung

  • RFC 9686 führt einen DHCPv6-Mechanismus ein, mit dem Clients selbst erzeugte oder statisch konfigurierte IPv6-Adressen registrieren. RFC 9915 beschreibt dafür einen vom Server angelegten Lease; die Adresse selbst wurde jedoch vom Gerät ausgewählt und nicht durch DHCPv6 zugewiesen.
  • Link- oder Präfixprüfung, Client-Identifier-Adress-Binding und Sperre für künftige Zuweisungen sind SOLLTE-Verhalten. Eine Implementierung darf die empfohlene Prüfung immer durchführen. Falsch wäre die Behauptung, RFC 9686 schreibe sie jeder konformen Implementierung ausnahmslos vor.
  • Für eine SLAAC-Adresse berechnet der Client NextAddrRegRefreshTime aus 80 Prozent der Valid Lifetime und einem Faktor zwischen 0,9 und 1,1. Diese Berechnung plant zunächst keinen Refresh; deshalb beweist das Überschreiten des berechneten Zeitpunkts allein keinen Fehler.
  • Eine akzeptierte Registrierung MUSS grundsätzlich protokolliert werden, sofern Logging nicht deaktiviert ist, und MUSS mit ADDR-REG-REPLY beantwortet werden. Das Reply bestätigt nur den Empfang und beendet Wiederholungen; es garantiert weder Speicherung noch Adressgültigkeit, Identität, Erreichbarkeit oder Handlungsbefugnis.

Die Grammatik des Standards ist Teil des Systems

RFC 9686 wurde im Dezember 2024 als IETF Standards Track RFC veröffentlicht. Sein Zweck ist präzise begrenzt: DHCPv6-Infrastruktur soll von IPv6-Adressen erfahren können, die sie nicht selbst vergeben hat. Dazu gehören per SLAAC erzeugte und statisch konfigurierte Adressen. Diese zusätzliche Beobachtbarkeit ist dort nützlich, wo Betreiber DHCP-Daten für Diagnose oder Forensik heranziehen möchten.

Der Mechanismus beginnt mit einer Fähigkeitsabfrage. Ein Client fordert OPTION_ADDR_REG_ENABLE im Rahmen regulärer DHCPv6-Kommunikation an. Ein unterstützender Server signalisiert die Option in Advertise oder Reply. Ohne dieses Signal darf der Client das Registrierungsverfahren nicht verwenden. Die Anzeige besagt lediglich, dass die DHCPv6-Infrastruktur auf der betreffenden Schnittstelle den Mechanismus unterstützt. Sie bestätigt keine konkrete Adresse und keinen bestimmten Client.

Nach Konfiguration einer gültigen, selbst erzeugten oder statischen Adresse globalen Geltungsbereichs sendet der Client ein ADDR-REG-INFORM. Link-lokale und durch DHCPv6 konfigurierte Adressen sind ausgeschlossen. Die Nachricht enthält einen Client Identifier und eine IA Address und muss von der zu registrierenden Adresse stammen. Bei einem weitergeleiteten Austausch muss die IA Address mit dem peer-address-Feld der innersten Relay-forward-Nachricht übereinstimmen.

An dieser Stelle trennt die normative Sprache zwingende Konsistenzregeln von empfohlenen Plausibilitätsprüfungen. Der Server MUSS ein ADDR-REG-INFORM verwerfen, wenn beispielsweise der Client Identifier fehlt, ein Server Identifier enthalten ist, die IA Address fehlt oder nicht zur ursprünglichen Quelladresse passt oder eine Option Request Option vorkommt. Dagegen SOLLTE er prüfen, ob die Adresse für den Link geeignet ist oder innerhalb eines an den Client delegierten Präfixes liegt. Führt er diese Prüfung aus und scheitert sie, MUSS er die Nachricht verwerfen und SOLLTE den Fehler protokollieren.

Ein SOLLTE ist weder unverbindliche Dekoration noch ein verdecktes MUSS. Es bezeichnet eine starke Empfehlung, von der unter bestimmten Umständen nach sorgfältiger Abwägung abgewichen werden kann. Daraus folgt aber keine Pflicht, diese Abweichung technisch anzubieten. Eine Implementierung kann sich dafür entscheiden, die Link- oder Präfixprüfung ausnahmslos vorzunehmen, ohne damit den Standard umzuschreiben. Der Normenfehler entsteht erst, wenn ein Test, ein Bericht oder eine Policy diese Produktentscheidung als zwingende Eigenschaft jeder konformen Implementierung ausgibt.

Ein Lease, aber keine Adresszuweisung

RFC 9915, der RFC 8415 ersetzt, klärt die Terminologie in Abschnitt 6.6. Der Text beschreibt die Registrierung selbst erzeugter Adressen als Betriebsmodell, bei dem die Adressauswahl nicht durch den DHCP-Server, sondern durch das Gerät erfolgt. Zugleich beschreibt er, dass der Server einen Lease anlegt, das Gerät periodische Aktionen zur Erneuerung ausführt und der Lease schließlich ablaufen kann.

Diese Passage verwendet für das Anlegen des Lease kein normatives RFC-2119-MUSS. Sie beschreibt das Betriebsmodell und dessen Lebenszyklus. Damit sind zwei Aussagen gleichzeitig wahr: Auf dem Server entsteht ein Lease für die Registrierung, doch dieser Lease beweist nicht, dass DHCPv6 dem Client die Adresse zugewiesen hat. Die Adresse stammt weiterhin aus SLAAC oder statischer Konfiguration.

Wer den Begriff „Lease“ vollständig vermeidet, gibt RFC 9915 ungenau wieder. Wer aus ihm eine serverseitige Adressauswahl ableitet, verfälscht die Herkunft der Adresse. Der Lease ist serverseitiger Lebenszykluszustand für eine vom Gerät gewählte Adresse, kein nachträglicher Beleg einer DHCPv6-Zuweisung.

Vom Lease ist das in RFC 9686 beschriebene Binding zwischen Client Identifier und IPv6-Adresse zu unterscheiden. Ein solches Binding anzulegen ist ein SOLLTE, kein MUSS. Für eine vorhandene Bindung gelten anschließend konkrete Aktualisierungsregeln: Gehört die Adresse demselben Client, muss der Server ihre Laufzeit aktualisieren. Besteht bereits eine Bindung zu einem anderen Client, sollte er dies protokollieren und die Bindung aktualisieren.

Für Datenmodelle und Bedienoberflächen folgt daraus eine wichtige Anforderung: Auswahlquelle der Adresse, Lease-Zustand und Binding dürfen nicht in einem einzigen undifferenzierten Status verschwinden. Ein Feld „Lease aktiv“ ohne Kennzeichnung des Registrierungstyps lädt zur falschen Schlussfolgerung ein, der Server habe die Adresse ausgewählt und vergeben. Ein Konformitätstest sollte deshalb nicht nur prüfen, ob Zustand entsteht, sondern auch, ob sich selbst erzeugte Registrierung und serverseitige Zuweisung unterscheiden lassen.

Der SLAAC-Zeitplan ist kein periodischer Taktgeber

Besondere Sorgfalt verlangt der Refresh-Algorithmus. Für eine SLAAC-Adresse definiert RFC 9686 ein AddrRegRefreshInterval von 80 Prozent der aktuellen Valid Lifetime. Der Client multipliziert diesen Wert mit einem zufällig gewählten AddrRegDesyncMultiplier zwischen 0,9 und 1,1, damit viele Geräte ihre Meldungen nicht gleichzeitig senden.

Wenn der Client eine Adresse registriert oder aktualisiert, berechnet er daraus NextAddrRegRefreshTime. Er plant zu diesem Zeitpunkt jedoch ausdrücklich keinen Refresh. Erst wenn das Netz die Valid Lifetime einer bestehenden Adresse um mehr als ein Prozent verändert, berechnet der Client das Intervall neu und plant einen Refresh für den früheren Wert aus „jetzt plus Intervall“ und dem bereits berechneten NextAddrRegRefreshTime. Läge dieser Zeitpunkt in der Vergangenheit, erfolgt der Refresh sofort.

Diese Unterscheidung ist für Tests entscheidend. Das Erreichen oder Überschreiten des berechneten Zeitpunkts ist allein kein Nachweis für einen ausgefallenen Refresh. Wenn die in Router Advertisements enthaltene Lifetime lediglich mit der Zeit herunterzählt und der erwartete Ablaufzeitpunkt unverändert bleibt, kann überhaupt kein Refresh gesendet werden: Der Server kennt bereits den vorgesehenen Ablauf. Eine Überwachung, die nach etwa 80 Prozent zwingend eine neue Nachricht erwartet, würde normgerechtes Verhalten als Störung melden.

Ändert das Netz dagegen die Valid Lifetime so, dass sich der erwartete Ablaufzeitpunkt relevant verschiebt, soll der Mechanismus die Registrierung aktualisieren. Der Faktor von höchstens 1,1 begrenzt den vorgesehenen Refresh bei einer solchen Planung auf höchstens 88 Prozent des betrachteten Lebensdauerfensters und lässt grundsätzlich Raum für Wiederholungen. Das ist eine Eigenschaft des Algorithmus, keine Garantie, dass unter allen Netzbedingungen eine Nachricht rechtzeitig eintrifft.

Für statisch konfigurierte Adressen gilt ein anderes Modell. Da sie eine unendliche Valid Lifetime besitzen, wird nach jeder Registrierung oder Aktualisierung ein weiterer Refresh vorgesehen. Das Standardintervall beträgt vier Stunden und SOLLTE konfigurierbar sein. Die vier Stunden sind das Auffrischungsintervall der Registrierung, weder Lebensdauer der statischen Adresse noch allgemeine Lease-Dauer. Eine Valid Lifetime von null bedeutet dagegen, dass der Server die Adresse als abgelaufen behandeln muss.

Was bei einer akzeptierten Registrierung gilt

Für die Verarbeitung verteilt RFC 9686 seine Vorgaben bewusst auf mehrere Stärkegrade:

Verarbeitungsschritt Normative Stärke Präzise Bedeutung
Link- oder Delegated-Prefix-Prüfung SOLLTE Der Server soll die Plausibilität prüfen. Ein Produkt darf dies stets tun; der Standard zwingt nicht jede Implementierung ausnahmslos dazu.
Fehler nach durchgeführter Prüfung MUSS verwerfen, SOLLTE protokollieren Wenn die Prüfung stattfindet und scheitert, greift die zwingende Verwerfung aus dieser Regel.
Akzeptierte Registrierung protokollieren MUSS, sofern Logging nicht deaktiviert ist Die Abschaltung ist ausdrücklich vorgesehen; ein Logeintrag ist daher nicht in jeder Betriebsart garantiert.
Client Identifier und Adresse binden SOLLTE Das Binding soll angelegt werden, ist aber keine zwingende Voraussetzung für ein Reply.
Adresse für künftige Vergabe sperren SOLLTE Der Server soll sie als nicht verfügbar markieren und nicht in späteren Advertise-Nachrichten anbieten.
ADDR-REG-REPLY senden MUSS Der Server bestätigt den Empfang, damit der Client die Wiederholung beendet.

Diese Abstufung erklärt, warum ein erfolgreiches Reply keine Speicherquittung ist. Das Antwortverhalten ist zwingend; Binding und Nichtverfügbarkeitsmarkierung sind empfohlen. Die Protokollierung ist bei akzeptierten Registrierungen grundsätzlich zwingend, darf aber durch Konfiguration abgeschaltet sein. Eine Implementierung kann daher ein normgerechtes Reply senden, ohne dass daraus allein ein dauerhaftes Binding oder ein später abrufbarer Logeintrag folgt.

Das Reply enthält die passende Transaktionskennung und eine identische IA Address. RFC 9686 begrenzt seine Semantik ausdrücklich: Es zeigt an, dass das ADDR-REG-INFORM empfangen wurde und nicht erneut gesendet werden soll. Es darf nicht als Hinweis auf die Gültigkeit der Adresse behandelt werden und ist keine Voraussetzung für deren Nutzbarkeit. Relay- oder mithörende Systeme dürfen allein aufgrund des Reply keinen Weiterleitungs- oder Sicherheitszustand hinzufügen oder verändern.

Verwerfen, Antworten und Beurteilen sind folglich verschiedene Vorgänge. Eine formal fehlerhafte Nachricht muss verworfen werden. Eine bei tatsächlich durchgeführter Link- oder Präfixprüfung als unpassend erkannte Adresse muss ebenfalls verworfen werden. Ein Reply dagegen bestätigt den Empfang einer akzeptierten Nachricht für diesen Austausch, nicht Eigentum, Erreichbarkeit oder fortgesetzte Nutzung. Es authentifiziert weder Gerät noch Person, beweist keinen späteren Datenverkehr und verleiht keine Sanktionsbefugnis.

Testpläne müssen Modalverben prüfen

Ein Testplan, der nur einen erfolgreichen Registrierungsablauf abspielt, deckt die gefährlichsten Fehler nicht auf. Er zeigt, dass Nachrichten ausgetauscht werden; er sagt nicht, ob eine Implementierung die normativen Grenzen wahrt. Sinnvoll ist eine Matrix, die jedes relevante MUSS und SOLLTE einer beobachtbaren Erwartung zuordnet und zugleich festhält, welche Schlussfolgerungen aus dem Ergebnis nicht gezogen werden dürfen.

Für zwingende Verwerfungsfälle sind negative Tests erforderlich. Eine Nachricht ohne Client Identifier muss scheitern. Dasselbe gilt für eine enthaltene Server-Identifier- oder Option-Request-Option sowie für eine fehlende oder nicht mit Quelle beziehungsweise innerstem Relay-peer-address übereinstimmende IA Address. Der Test darf sich nicht mit einem fehlenden Reply begnügen. Er sollte außerdem feststellen, ob unzulässigerweise ein Lease, Binding, eine Nichtverfügbarkeitsmarkierung oder positive Telemetrie entstanden ist.

Für die empfohlene Link- oder Präfixprüfung braucht der Prüfplan eine andere Logik. Führt das Produkt die Prüfung aus, muss eine dabei als unpassend erkannte Adresse verworfen werden; der Fehler sollte protokolliert werden. Ein Produkt darf die Prüfung als feste Designentscheidung immer ausführen. Die Testsuite darf aber nicht behaupten, dass der RFC ausnahmslos dasselbe Verhalten von jeder anderen konformen Implementierung verlange. Ebenso darf eine nicht durchgeführte Prüfung nicht als bestandene Prüfung dargestellt werden.

Diese Unterscheidung verändert auch die Form eines Konformitätsberichts. Er sollte zwischen „vom Standard zwingend“, „vom Standard empfohlen“ und „vom Produkt stets umgesetzt“ unterscheiden. Erst diese drei Kategorien zeigen, ob eine Beobachtung aus dem RFC, aus einer Implementierungsentscheidung oder aus einer lokalen Policy stammt.

Ebenso wichtig ist die Entkopplung von Reply, Binding und Logging. Ein positiver Test prüft die Antwort. Separate Prüfungen stellen fest, ob ein Binding angelegt und die Adresse für spätere Zuweisungen gesperrt wurde. Bei deaktiviertem Logging darf ein Test nicht behaupten, jede akzeptierte Registrierung hinterlasse zwingend einen Protokolleintrag. Gerade diese Trennung verhindert, dass ein Dashboard aus dem bloßen Reply eine nicht nachgewiesene Speicherwirkung ableitet.

Ablauftests müssen Valid Lifetime, Änderungen des erwarteten Ablaufzeitpunkts und Null-Lifetime abdecken. Für SLAAC darf der aus 80 Prozent und Desynchronisierungsfaktor berechnete Zeitpunkt nicht als zwingender periodischer Sendetermin modelliert werden. Bei statischen Adressen ist dagegen das reguläre, standardmäßig vierstündige Refresh-Intervall relevant. Wenn ein Binding abläuft, muss der Server es entfernen und die Adresse wieder als verfügbar betrachten. Ob historische Daten darüber hinaus erhalten bleiben, bestimmt die Aufbewahrungspolitik, nicht der aktive Zustand.

Konfigurationsnachweise gehören zur Aussage

Ein Datensatz ohne Implementierungs- und Konfigurationskontext ist mehrdeutig. Für spätere Diagnose oder Forensik sollte nachvollziehbar sein, welche Serverversion und welche relevanten Einstellungen zum Ereigniszeitpunkt galten: Führte das Produkt die Link- oder Präfixprüfung stets durch? War Logging eingeschaltet? Wurde ein Binding angelegt? War die Sperre gegen spätere Zuweisung aktiv? Welche Aufbewahrungsfrist galt?

Das ist kein Ruf nach unbegrenzter Sammlung. Konfigurationsnachweise können versioniert, zugriffsgeschützt und auf entscheidende Parameter beschränkt werden. Ihr Zweck ist, Telemetrie interpretierbar zu halten. Ohne sie kann dasselbe Reply einmal einen protokollierten Lease mit Binding begleiten und ein anderes Mal lediglich den Empfang der Nachricht dokumentieren.

Auch das Fehlen eines Eintrags ist nur mit Kontext deutbar. Ein kompromittierter Client kann die Registrierung unterlassen; Pakete können verloren gehen; die Infrastruktur kann OPTION_ADDR_REG_ENABLE nicht signalisiert haben; Logging kann deaktiviert oder die Aufbewahrungsfrist abgelaufen sein. „Nicht im Register“ bedeutet deshalb nicht „nicht im Netz“.

Quellen