Zusammenfassung

  • Reconfigure ist ein authentisierter Auslöser für Renew, Rebind oder Information-request; die Sendung beweist keine neue Client-Konfiguration.
  • Der Empfang der verlangten Client-Anfrage erfüllt die Reconfigure-Anfrage des Servers, doch Reply, lokale Installation und Betriebswirkung bleiben eigene Nachweise.

Das missverständlichste Wort im Log ist oft „gesendet“. RFC 9915 beschreibt Reconfigure nicht als Abschluss, sondern als Nachricht, mit der ein Server den Client auffordert, einen weiteren Austausch zu beginnen. Eine daraus abgeleitete grüne Statusanzeige überspringt die Bedingungen, die der Standard ausdrücklich beibehält.

Zuerst geht es um Bereitschaft und Validierung. Mit Reconfigure Accept teilt der Client dem Server mit, ob er Reconfigure akzeptieren will; ohne diese Option ist die Vorgabe Ablehnung. Außerdem muss der Client eine Nachricht verwerfen, die nicht unicast ist, erforderliche Kennungen oder die Reconfigure-Message-Option nicht enthält, einen ungültigen Nachrichtentyp verlangt oder keine gültige Authentisierung hat. Der Sendeeintrag beweist folglich nur die Aktion des Servers, nicht einen nutzbaren Empfang beim Client.

Kommt eine gültige Nachricht an, entsteht ein weiterer enger Beleg. Die Option legt Renew, Rebind oder Information-request fest. Der Client beginnt den gewählten Austausch und verwirft zusätzliche Reconfigure-Nachrichten, während er läuft. Der Begriff trigger ist treffend: Die Nachricht setzt einen nächsten Vorgang in Gang, sie installiert nicht selbst Adresse, Präfix, Resolver oder andere Werte.

Später kann der Server eine begrenzte Rückmeldung feststellen. RFC 9915 erlaubt ihm, den Empfang des verlangten Renew, Rebind oder Information-request als Erfüllung seiner Reconfigure-Anfrage zu werten. Daraus folgt: Der Server erhielt den von ihm verlangten Nachrichtentyp. Nicht daraus folgt: Ein Reply wurde verarbeitet, sein Inhalt akzeptiert oder im lokalen System umgesetzt.

Auch die Folgevorgänge sind nicht gleichbedeutend. Renew und Rebind haben eigene Bindungs- und Auswahlregeln; Information-request fordert Konfigurationsdaten ohne Adressen oder Präfixe an. Das Reply kann jeweils die Konfigurationsinformation tragen. Für die Behauptung einer bestimmten Änderung braucht es daher das Reply und passende Optionen oder IAs. Für eine Aussage über Installation, Routing, DNS-Nutzung, Verkehr oder Anwendungserfolg braucht es zusätzlich die Beobachtung am jeweiligen Ort.

Die Authentisierung der Reconfigure schützt nur eine definierte Kante. RFC 9915 verlangt sie wegen des DoS-Risikos. RFC 9096, ebenfalls mit Volz als Mitautor, ordnet DHCPv6-Sicherheits- und Datenschutzverbesserungen ein. Beides ist kein allgemeiner Nachweis für Verfügbarkeit oder Ende-zu-Ende-Erfolg.

Ein prüfbares Protokoll erhält die Verbindungen: Client-DUID, Server-Identifier, Sendung und Validierung, angeforderten msg-type, beim Server eingegangene passende Anfrage, Reply und relevante Felder. Bei einer Betriebsbehauptung kommt eine getrennte Installations- oder Laufzeitbeobachtung hinzu. Das IANA-Register benennt DHCPv6-Codes; es bestätigt nicht, dass die folgenden Schritte passiert sind.

Damit folgt die Darstellung Heng Lus Disziplin der kleinsten beobachteten Aussage. „Server sendete Reconfigure“ und „Server erhielt die angeforderte Nachricht“ sind belastbar. „Client ist konfiguriert“ ist ohne weitere Belege eine zu große Behauptung. Volz ist einer von fünf Autoren eines kollektiven Standards, nicht Betreiber eines konkreten Clients, Servers oder Netzes.

Quellen