Zusammenfassung

  • DHCPv6 Reconfigure enthält nicht die neue Konfiguration. Die Nachricht fordert einen zuvor zustimmenden Client zu Renew, Rebind oder Information-request auf; erst der folgende Austausch kann einen neuen Zustand hervorbringen.
  • Nach RFC 6977 darf eine Reconfigure-Reply Success melden, obwohl der Server keinem angefragten Client ein Reconfigure senden wird. Verarbeitung, Auswahl, Zustellung, Authentisierung, Transaktion, Installation und Dienstbetrieb brauchen getrennte Nachweise.

Die grüne Anzeige kam zuerst

Ein Relay in einem Zugangsnetz erkennt, dass sich eine Bereitstellungsinformation für einen Link geändert hat. Es übermittelt Link-Adresse und mehrere DUIDs in einer Reconfigure-Request. Der Server antwortet mit Success; das Betriebswerkzeug markiert den Vorgang als abgeschlossen.

Noch muss sich kein einziger Client geändert haben. Für manche Kennungen fehlt dem Server ein brauchbarer Binding-Zustand. Andere Clients haben Reconfigure Accept nie gesendet. Weitere Nachrichten warten hinter einer Rate-Limitierung. Eine ausgelieferte Nachricht kann an der Authentisierung scheitern, einen Renew ohne anschließende Reply auslösen oder zu einem neuen DHCP-Zustand führen, während eine Anwendung weiterhin die alte Adresse nutzt.

Die Anzeige ist korrekt, wenn sie nur sagt, dass der Server die Relay-Anfrage verarbeitet hat. Gefährlich wird sie, sobald dieser begrenzte Beleg zur Bestätigung aller späteren Handlungen erweitert wird.

RFC 6977 zieht die Grenze ausdrücklich. In einer erfolgreichen Antwort werden jene Clients aufgeführt, an die der Server kein Reconfigure senden wird. Die Liste darf sämtliche angefragten Clients enthalten und der Status dennoch Success bleiben. Eine Bestätigung zwischen Relay und Server ist absichtlich keine Ausführungsquittung des Endgeräts.

Der aktuelle Vertrag ist ein Auslöser, kein Konfigurationspaket

RFC 9915 ist die aktuelle DHCPv6-Basisspezifikation und löst RFC 8415 ab. IANA führt RECONFIGURE als Nachrichtentyp 10. Die gemeinsame Funktion ist schmal: Ein einzelner Client soll einen neuen DHCPv6-Austausch beginnen.

Reconfigure wird per Unicast gesendet und enthält Server Identifier, den passenden Client Identifier, akzeptable Authentisierung sowie die Option Reconfigure Message. Diese darf ausschließlich Renew, Rebind oder Information-request wählen. Neue Adressen, Präfixe und gewöhnliche Konfigurationsoptionen gehören nicht in den Auslöser, sondern gegebenenfalls in die Reply des Folgeaustauschs.

Der Server besitzt damit die Autorität, ein Gespräch anzustoßen, nicht den Client-Zustand unmittelbar zu schreiben. Der Client prüft Identität, Authentisierung und Replay-Wert und formuliert seine eigene Anfrage. Der Server berechnet mit seinem dann aktuellen Zustand eine Reply. Die Implementierung installiert das Ergebnis; der Betreiber beobachtet die tatsächliche Wirkung.

Eine Aufzeichnung des Reconfigure belegt lediglich, dass ein gültiger Auslöser an eine Kennung gesendet wurde. Sie belegt nicht, dass die Kennung noch zum gegenwärtigen Gerät gehört, der Austausch abgeschlossen ist, der Zustand installiert wurde oder die Anwendung migriert ist.

Zustimmung bleibt sichtbar und freiwillig

Ein Client erklärt seine Bereitschaft über Reconfigure Accept. Fehlt diese Option, darf der Server den Client nicht als Teilnehmer behandeln. Er bleibt dennoch ein vollwertiger DHCPv6-Client und folgt normalen Laufzeiten, selbst initiiertem Renew oder gewöhnlichen Information-request-Nachrichten.

So wird eine optionale Fähigkeit nicht unbemerkt zur Pflicht. Zugleich entsteht eine Planungsgrenze. Wenn 70 Prozent einer Flotte zustimmen, kann Reconfigure 70 Prozent beschleunigen. Für den Rest müssen Zeit, Überlappung und Beobachtung vorgesehen werden. Teilnehmende zu zählen bedeutet nicht, die gesamte Population zu beherrschen.

RFC 8947 zeigt bei kleinen Geräten, dass Authentisierung und persistenter Zustand relevante Kosten haben. Eine begrenzte Implementierung verändert die Reaktionsgeschwindigkeit, nicht die Interoperabilität des Geräts.

Authentisierung bestätigt den Absender, nicht den Endzustand

Das Reconfigure Key Authentication Protocol liefert in einer ersten Reply einen 128-Bit-Schlüssel und nutzt anschließend HMAC-MD5. Die erste Schlüsselübergabe erfolgt unverschlüsselt auf dem DHCPv6-Pfad. Diese Grenze gehört in das Bedrohungsmodell, auch wenn spätere Nachrichten authentisiert sind.

Der Replay-Erkennungswert muss monoton wachsen und einen Serverneustart überstehen. Ein Failover-Knoten kann Leases wiederherstellen, aber Schlüssel oder Zähler verlieren. Dann kennt er mögliche Ziele, kann jedoch keinen akzeptablen Auslöser erzeugen. Werden Geheimnisse repliziert, steigt die Verfügbarkeit ebenso wie der mögliche Kompromittierungsbereich.

Authentisierung beantwortet eine begrenzte Frage: Kam die Nachricht von der Autorität mit dem Schlüssel und ist ihr Replay-Wert neu? Sie beantwortet nicht, ob das Relay den richtigen Link, der Server den richtigen Client und die Folge-Reply den richtigen Zustand gewählt haben. Auch die Anwendungskontinuität bleibt offen.

„Authentisiert“ als Synonym für „Ende-zu-Ende richtig“ zu verwenden, würde die durch Kryptografie sichtbare Grenze wieder beseitigen.

Das Relay schlägt vor, der Server entscheidet

RFC 6977 definiert Reconfigure-Request und Reconfigure-Reply zwischen Relay und Server. Das Relay darf Link-Adresse und mutmaßlich betroffene Client-Kennungen angeben. Der Server entscheidet weiterhin, ob er das Relay kennt, dessen Ursprung akzeptiert, über ausreichenden Zustand verfügt, welche Clients geeignet sind und mit welchem Tempo er arbeitet.

Voreinstellung ist die Ablehnung. Anfragen unbekannter Relays sollen verworfen werden. RFC 8213 kann die Relay-Server-Kommunikation mit IPsec schützen. Ein geschützter Kanal bestätigt jedoch nicht die Richtigkeit der vorgeschlagenen Population. Ein kompromittiertes Relay kann die falschen Teilnehmer über eine vollständig gesicherte Verbindung nennen.

Bei Wiederholungen darf das Relay Clients entfernen, aber keine neuen hinzufügen. Diese Asymmetrie verhindert eine stillschweigende Ausweitung während des Vorgangs. Sie ersetzt nicht die Prüfung von Link, DUID, Binding und Ursprungsautorität.

Erhalten mehrere Server dieselbe Anfrage, können abweichende Zustände und Regeln zu unterschiedlichen Auswahlen führen. Mehrere Success-Antworten bilden keinen Konsens über das Ergebnis. Jeder Auslöser muss dem sendenden Server, dem einzelnen Client und der Folgetransaktion zugeordnet bleiben.

Sechs getrennte Tatsachen für eine Änderung

Eine belastbare Betriebsspur trennt mindestens:

  1. beobachtete Ursprungsänderung und vom Relay vorgeschlagene Population;
  2. Annahme oder Ablehnung durch einen bestimmten Server;
  3. Client-Auswahl und tatsächliche Aussendung;
  4. akzeptierte Authentisierung und Folgeanfrage des Clients;
  5. abgeschlossene und verarbeitete Reply;
  6. installierten Zustand und geprüften Anwendungspfad.

Die Nachweise entstehen an unterschiedlichen Stellen: Relay-Log, Reconfigure-Reply, Auswahlentscheidung, Versandzähler, Authentisierungsergebnis, Transaktionskennung, lokaler Zustand und Diensttest. Die Differenz zwischen zwei Stufen ist eine Diagnose, kein zu glättendes Rauschen.

Success mit sämtlichen Clients in der Ausschlussliste bedeutet erfolgreiche Anfrageverarbeitung bei null Abdeckung. Renew ohne Reply bedeutet erfolgreicher Auslöser und gescheiterte Transaktion. Ein installierter DHCP-Zustand bei einer Anwendung auf der alten Adresse bedeutet Konfigurationserfolg und Migrationsfehler. Ein einziges Abschlussfeld kann diese Wahrheiten nicht ausdrücken.

Die Warteschlange verändert die Bedeutung der Zeit

Ein Ereignis kann in zahlreiche einzelne Reconfigure-Nachrichten und ebenso viele DHCPv6-Austausche auffächern. RFC 6977 sieht Rate-Limitierung vor, damit normale Zuweisungen, Erneuerungen und Wiederherstellung geschützt bleiben.

Eine jetzt angenommene Anfrage bedeutet nicht, dass alle Auslöser jetzt gesendet werden. Die maßgebliche Zeitachse reicht von der Ursprungsbeobachtung über Auswahl, Warteschlange, Versand und Client-Anfrage bis zu Reply und Installation. Die Latenz der Reconfigure-Reply misst nur den Anfang.

Sichere Regeln setzen Höchstwerte pro Ursprungsereignis, Anfrage, Serverintervall und Änderungsfenster sowie eine Grenze für Wiederholungen. Endlose Versuche machen abwesende Clients zu dauerhafter Last und können den Vorfall verschärfen.

Die maximale Wartedauer muss zudem in die sichere Überlappung des alten Zustands passen. Überschreitet die Warteschlange diesen Zeitraum, wird eine protokollkonforme Verzögerung zum Ausfall.

Wiederhergestellter Zustand ist nicht die Gegenwart

Leasequery, Bulk Leasequery und Active Leasequery aus RFC 5007, RFC 5460 und RFC 7653 helfen, Bindings wiederherzustellen oder fortlaufend zu übertragen. Sie verringern Unwissen nach einem Failover, verwandeln aber eine frühere Beobachtung nicht in gegenwärtige Anwesenheit.

Der gespeicherte Client kann den Link verlassen haben. Ein aktiver Strom kann verspätet, ungeordnet oder resynchronisierungsbedürftig sein. Ein Lease kann ohne Reconfigure-Schlüssel und Replay-Zustand wiederkehren. Herkunft, Alter und Vollständigkeit müssen jede weitreichende Auswahl begleiten.

Das YANG-Modell aus RFC 9243 macht die Konfiguration eines DHCPv6-Dienstes sichtbarer. Es beschreibt die Absicht der Steuerungsebene, nicht den wirksamen Zustand eines Endgeräts. Es ist ein eigener Beleg, kein Ersatz für Beobachtung.

Renummerierung zeigt den Preis einer falschen Abkürzung

RFC 6879 beschreibt IPv6-Unternehmensnetze, die ihre Präfixe ändern. Reconfigure kann einige Clients schneller zum Server zurückholen. Es beseitigt weder die nötige Überlappung von altem und neuem Zustand noch nicht teilnehmende Clients oder Anwendungen mit alten Adressen.

Ein umkehrbarer Plan hält beide Zustände für eine erklärte Dauer, sucht ausgeschlossene und verspätete Clients und zieht den alten erst nach unabhängiger Beobachtung zurück. Wer die Überlappung wegen eines Relay-Server-Success verkürzt, macht normale Verzögerung oder freiwillige Nichtteilnahme zum Ausfall.

Reconfigure ist ein optionaler Beschleuniger innerhalb einer Migration, keine Erlaubnis zum sofortigen Abschalten.

Die gemeinsame Schicht soll wissen, was sie nicht weiß

Eine Spezifikation kann Formate, Kennungen, Zustimmung, Authentisierung, Replay-Verhalten und drei zulässige Folgetransaktionen definieren. Sie kennt weder den geschäftlichen Anlass noch das Risiko einer Anwendung, die lokale Vertrauensbeziehung, die Serverkapazität oder den sicheren Rückzugszeitpunkt.

Das Relay entscheidet, welches Ereignis eine Anfrage verdient, und schlägt Kandidaten vor. Der Server entscheidet Vertrauen, Abgleich, Auswahl und Budget. Der Client führt seinen Code aus. Der Betreiber legt Schutz, Evidenz und Rückkehr fest. Ein kleiner gemeinsamer Kern belässt künftige Entscheidungen bei den laufenden Teilnehmern.

Heng Lus Disziplin stellt running code an die erste Stelle. Aufzeichnungen, Empfehlungen und Bestätigungen beschreiben Wirklichkeit, sie erzeugen sie nicht. Erst Implementierung, Prüfung, Betrieb und Nutzung machen einen neuen Zustand real.

Minimum Initial Specification liefert den kleinen interoperablen Auslöser. Localized Future Decision belässt Vertrauen, Auswahl, Implementierung und Schutz vor Ort. Voluntary Adoption bleibt in der Option sichtbar, die ein Client auslassen darf. Der Standard beschreibt die Aufforderung; laufende Systeme bestimmen das Ergebnis.

Quellen