Zusammenfassung

  • Nach einer Änderung der Netzinformationen kann ein DHCPv6-Client mit Confirm prüfen lassen, ob seine vorhandenen Adressen auf den aktuellen Link gehören. Der Request richtet sich bewusst nicht an den ursprünglichen Lease-Server.
  • Success gilt für sämtliche übermittelten Adressen. T1, T2 sowie Preferred und Valid Lifetime werden bei dieser Prüfung ignoriert; die Antwort verlängert keine Frist.
  • Tomek Mrugalski und die übrigen Autoren von RFC 9915 trennen damit Linkwissen, Bindungsautorität und Laufzeitbeobachtung. Wer „bestätigt“ als „erneuert“ meldet, verbindet Belege, die der Standard auseinanderhält.

Zwei Uhren, aber nur eine Frage

Ein Notebook verlässt ein Büro, verbindet sich später mit einem anderen Netz und besitzt noch IPv6-Adressen. Die Router- oder Linkinformationen haben sich geändert. Der DHCPv6-Client muss entscheiden, ob er die vorhandene Konfiguration weiterverwenden kann.

Für diesen Moment definiert RFC 9915 Confirm. Der Name suggeriert eine umfassende Bestätigung, doch die Nachricht stellt eine begrenzte Frage: Sind alle mitgesandten Adressen für den Link geeignet, an dem sich der Client jetzt befindet?

Der Client muss seine Kennung und die betreffenden Identity Associations samt Adressen senden. Delegierte Präfixe gehören nicht in diesen Vorgang. Ebenso fehlt eine Server Identifier Option. Enthält die Nachricht doch eine solche Kennung, verwirft ein Server sie.

Gerade das fehlende Serverziel erklärt die Zuständigkeit. Nicht der frühere Zuteiler muss antworten. Jeder Server, der über hinreichendes Wissen zu den Präfixen des aktuellen Links verfügt, kann die topologische Aussage treffen.

Passen alle Adressen, lautet der Status Success. Passt mindestens eine nicht, lautet er NotOnLink. Fehlen dem Server die erforderlichen Linkinformationen oder enthält die Anfrage keine Adresse, antwortet er nicht. Ein Timeout ist deshalb weder ein verspätetes Ja noch ein negatives Urteil, sondern das Ausbleiben eines Urteils.

Warum die Zeitfelder auf null stehen

Die Nachricht transportiert Strukturen, die auch Lease-Zeiten tragen können. Für Confirm soll der Client jedoch T1 und T2 in IA_NA sowie Preferred und Valid Lifetime in IA Address auf null setzen. Der Server ignoriert diese Werte.

Die Nullen sind keine technische Nebensache. Sie zeigen, welche Akte der Austausch nicht enthält. Der Server erhält Adressen, um ihre Zugehörigkeit zu einem Link zu bewerten. Er erhält keine autoritative Zeitforderung und soll aus der Anfrage keine neue Laufzeit ableiten.

Ein Server kann die aktive Präfixkonfiguration eines Links kennen, ohne die ursprüngliche Clientbindung zu besitzen. Das ist genug für Confirm, aber nicht für eine Verlängerung. Der Standard verlangt keine fiktive Zusammenführung beider Wissensbestände.

Bei Renew ist die Zuständigkeit anders. Sobald T1 erreicht ist, spricht der Client den Server an, von dem er seine Leases erhalten hat. Dieser Server kann die Bindung suchen und neue Werte für T1, T2, Preferred Lifetime und Valid Lifetime zurückgeben. Bleibt dieser Versuch bis T2 erfolglos, kann der Client mit Rebind einen verfügbaren Server um eine Verlängerungsentscheidung bitten.

Auch die IANA-Registrierung hält die Operationen mit den Codes 4, 5 und 6 getrennt. Die Reihenfolge ist kein Fortschrittsbalken, sondern eine Aufteilung von Entscheidungsrechten: Linkeignung, Verlängerung beim Zuteiler und Übernahme der Verlängerung nach dessen Ausfall.

Derselbe sichtbare Zustand kann aus zwei Belegen entstehen

Nach einem erfolgreichen Confirm darf der Client die Adressen weiterverwenden. Maßgeblich bleiben die zuletzt bekannten Laufzeiten. Waren vor dem Austausch noch 1.800 Sekunden gültig, entstehen durch Success keine neuen 1.800 Sekunden.

Auch nach einer ergebnislosen Confirm-Phase soll der Client bestehende Leases und weitere Konfiguration mit ihren zuletzt bekannten Zeiten weiterverwenden. Unmittelbar danach sieht die Schnittstelle in beiden Fällen gleich aus: Die Adresse ist noch vorhanden.

Für eine Diagnose ist dieser sichtbare Zustand unzureichend. Nur ein gültiger Reply, der über Transaction ID, Serverkennung und Status mit dem Request verbunden ist, beweist die positive Linkbewertung. Ohne ihn beruht die Fortsetzung auf der Timeout-Regel, nicht auf Success.

Das Ende bestimmt weiterhin RFC 4862. Eine Adresse kann preferred, danach deprecated und schließlich invalid sein. Eine deprecated Adresse darf bestehende Kommunikation tragen, soll aber nicht für neue Verbindungen bevorzugt werden. Eine invalid gewordene Adresse darf weder als Quelle benutzt noch als Ziel angenommen werden. Confirm setzt diese Zustandsfolge nicht zurück.

Das Verfahren schützt also den Betrieb vor unnötiger Unterbrechung, ohne eine Verlängerung zu erfinden. Fortsetzung ist eine zulässige Handlung; neue Lease-Zeit wäre eine neue Behauptung.

Ein positives Ergebnis ist kein Mehrheitsentscheid

Mehrere Server können auf denselben Request antworten. Sobald mindestens ein gültiger Reply Success meldet, kann der Client die Adressen benutzen und Antworten mit NotOnLink ignorieren. Nur wenn er einen oder mehrere Replies erhält und sämtliche NotOnLink melden, beginnt er erneut mit der Serverfindung.

Diese Regel zählt keine Stimmen. Unterschiedliche Server können mit verschiedenen Konfigurationsständen, Relay-Kontexten oder administrativen Ausschnitten arbeiten. Das Protokoll akzeptiert einen verwendbaren positiven Nachweis, um Kontinuität zu ermöglichen. Es erklärt damit die widersprechenden Server nicht für konsistent.

Ein Betriebsdatensatz sollte deshalb die Minderheit nicht wegaggregieren. Liefert ein Server Success und liefern zwei NotOnLink, gehören alle DUIDs, Relay-Pfade, Interfaces, Adressmengen und verwendeten Präfixstände in den Beleg. Die Abweichung kann auf eine veraltete Bereitstellung hinweisen, lange bevor Nutzer sie als Fehler bemerken.

Hinzu kommt die Mengensemantik. Der Server bewertet alle vorgelegten Adressen gemeinsam. Eine einzige unpassende Adresse führt zu NotOnLink, doch der Status bezeichnet sie nicht. Wer nur das Ergebnis speichert, kann später nicht mehr feststellen, welcher Input die Entscheidung ausgelöst hat.

Fünf Grenzen eines grünen Status

Eine Adresse kann auf das richtige Präfix passen und dennoch bei Duplicate Address Detection scheitern. Linkeignung beweist keine Eindeutigkeit.

Sie kann on-link sein, während der nächste Router oder Nachbar unerreichbar bleibt. Neighbor Unreachability Detection aus RFC 4861 besitzt eigene Zustände und Beobachtungen.

Sie kann als Quelladresse gültig sein, obwohl eine Upstream-Route fehlt oder gefiltert wird. Das Präfixwissen eines DHCP-Servers ist kein Zustellbeleg.

Die Lease kann gültig sein, obwohl eine Anwendungssitzung abgebrochen ist. Adresskonfiguration stellt keinen Transportzustand wieder her.

Und der antwortende Server kann das Linkpräfix kennen, obwohl die ursprüngliche Bindung bei einem anderen Server liegt oder dort nicht mehr vorhanden ist. Success weist keine durchgehende Verwahrung der Bindungsdaten nach.

Diese Grenzen machen die Nachricht nicht schwach. Sie machen ihre Aussage überprüfbar und mit anderen Mechanismen kombinierbar. Ein kleines gemeinsames Urteil bleibt nützlich, solange es nicht stellvertretend für fünf fremde Zustände sprechen muss.

Tomek Mrugalski als Verbindung von Norm und Implementierung

RFC 9915 ist als Internet Standard STD 102 veröffentlicht. Als Autoren nennt er Tomek Mrugalski, Bernie Volz, Michael C. Richardson, Sheng Jiang und Timothy Winters; die Danksagungen zeigen eine größere Arbeitsgemeinschaft. Autorenschaft erklärt den Entstehungskontext, aber sie garantiert nicht das Verhalten eines bestimmten Clients oder Servers.

Mrugalskis öffentlich dokumentierter Weg führt durch beide Seiten der IETF-Formel von Konsens und laufendem Code. Der IETF Datatracker verzeichnet zahlreiche DHCP-bezogene RFC-Beiträge. Das schriftliche ISC-Profil beschreibt Dibbler, das aus seiner Hochschularbeit zu einer DHCPv6-Implementierung wurde, und seine spätere Mitarbeit an Kea. Diese Angaben sind beruflicher Kontext mit Zeitbezug, keine pauschale Konformitätsaussage.

Die schmale Confirm-Semantik lässt sich mit Heng Lus Minimum Initial Specification lesen: Standardisiert wird der kleinste Fakt, den unterschiedliche Akteure gemeinsam brauchen. Der aktuelle Link kann über Präfixe urteilen; die Lease-Instanz behält ihre Zeitentscheidung.

Running-Code Primacy lenkt den Blick anschließend vom Nachrichtennamen zum ausgeführten Pfad. Ein Logeintrag „Confirm“ sagt noch nicht, ob Success, ausschließlich NotOnLink oder gar kein Reply vorlag. Diese Pfade können kurzzeitig dieselbe Adresse auf dem Interface hinterlassen und später auseinanderlaufen.

Das Agency Problem wird sichtbar, wenn Nutzen und Nachweiskosten verteilt sind. Ein Hersteller kann leicht „Confirm success“ zählen. Der Zugangsbetreiber besitzt Link- und Relay-Kontext. Der Lease-Dienst trägt die Bindungshistorie. Der Kunde trägt den Ausfall, wenn die alte Zeit endet. Wird die billigste Kennzahl zur umfassenden Zusage, kontrolliert der Berichterstatter die Bedeutung, während andere das Risiko übernehmen.

Sechs Belege statt eines erneuerten Versprechens

Der erste Beleg beschreibt den Auslöser: Interface, alte und neue Router- oder Linkinformationen, Clientzustand und Zeitpunkt. Er verbindet den Request mit einem konkreten Netzwechsel.

Der zweite friert die alte Lease vor der Prüfung ein: DUID des zuteilenden Servers, IAID, Adresse, Zuteilungszeit, T1, T2, Preferred Lifetime, Valid Lifetime und Restsekunden. Nur so bleibt die weiterlaufende Uhr sichtbar.

Der dritte hält den Request fest: Client-DUID, Transaction ID, vollständige Adressmenge, Interface und das Fehlen des Server Identifier. Der fehlende Adressat belegt die Linkfrage.

Der vierte enthält jeden Reply: Server-DUID, Relay-Pfad, Linkkontext, Status und die verwendete Präfix- oder Konfigurationsrevision. Schweigen wird als Ende des Austauschs protokolliert, nicht als konstruierter Erfolg.

Der fünfte erklärt die Aggregation: mindestens ein Success, sämtliche erhaltenen Replies NotOnLink oder kein gültiger Reply. Dazu gehört die tatsächlich ausgeführte Cliententscheidung.

Der sechste trennt spätere Autorität: Renew oder Rebind, neue Zeiten, Deprecation und Invalidierung, Duplicate Address Detection, Nachbar-, Routing- und Anwendungssignale. Gemeinsam können sie Dienstfähigkeit zeigen; aus Success allein dürfen sie nicht zurückgerechnet werden.

Eine ehrliche Statuszeile lautet: „Server S bewertete die Adressen zum Zeitpunkt T als für den Link geeignet; ursprüngliche Lease-Zeiten unverändert.“ Sie ist weniger glatt als „erneuert“, aber sie bleibt wahr, wenn die Uhr abläuft.

Quellen