19. Vom Server initiierter Konfigurationsaustausch (Server-Initiated Configuration Exchange)
- Vom Server initiierter Konfigurationsaustausch
Ein Server initiiert einen Konfigurationsaustausch, um DHCP-Clients zu veranlassen, neue Adressen und andere Konfigurationsinformationen zu erhalten. Beispielsweise kann ein Administrator einen vom Server initiierten Konfigurationsaustausch verwenden, wenn Links in der DHCP-Domäne neu nummeriert werden sollen. Weitere Beispiele umfassen Änderungen am Standort von Verzeichnisservern, Hinzufügung neuer Dienste wie Drucken und Verfügbarkeit neuer Software.
19.1. Server-Verhalten
Ein Server sendet eine Reconfigure-Nachricht, um einen Client zu veranlassen, unverzüglich einen Renew/Reply- oder Information-request/ Reply-Nachrichtenaustausch mit dem Server zu initiieren.
19.1.1. Erzeugung und Übertragung von Reconfigure-Nachrichten
Der Server setzt das Feld "msg-type" auf RECONFIGURE. Der Server setzt das Feld transaction-id auf 0. Der Server nimmt eine Server Identifier-Option mit seinem DUID und eine Client Identifier-Option mit dem DUID des Clients in die Reconfigure-Nachricht auf.
Der Server KANN eine Option Request-Option aufnehmen, um den Client über die geänderten Informationen oder neu hinzugefügten Informationen zu informieren. Insbesondere gibt der Server die IA-Option in der Option Request-Option an, wenn der Server möchte, dass der Client neue Adressinformationen erhält. Wenn der Server die IA-Option in der Option Request-Option identifiziert, MUSS der Server eine IA-Option aufnehmen, die keine weiteren Unteroptionen enthält, um jede IA zu identifizieren, die auf dem Client neu konfiguriert werden soll.
Aufgrund des Risikos von Denial-of-Service-Angriffen gegen DHCP-Clients wird in Reconfigure-Nachrichten ein Sicherheitsmechanismus zwingend vorgeschrieben. Der Server MUSS DHCP-Authentifizierung in der Reconfigure-Nachricht verwenden.
Der Server MUSS eine Reconfigure Message-Option (definiert in Abschnitt 22.19) aufnehmen, um auszuwählen, ob der Client mit einer Renew- Nachricht oder einer Information-Request-Nachricht antwortet.
Der Server DARF KEINE anderen Optionen in die Reconfigure-Nachricht aufnehmen, außer wie speziell in der Definition einzelner Optionen erlaubt.
Ein Server sendet jede Reconfigure-Nachricht an einen einzelnen DHCP-Client, unter Verwendung einer IPv6-Unicast-Adresse von ausreichendem Geltungsbereich, die dem DHCP-Client gehört. Wenn der Server keine Adresse besitzt, an die er die Reconfigure-Nachricht direkt an den Client senden kann, verwendet der Server eine Relay-reply- Nachricht (wie in Abschnitt 20.3 beschrieben), um die Reconfigure- Nachricht an einen Relay-Agenten zu senden, der die Nachricht an den Client weiterleitet. Der Server kann die Adresse des Clients (und den geeigneten Relay-Agenten, falls erforderlich) über die Informationen erhalten, die der Server über Clients hat, die mit dem Server in Kontakt waren, oder über einen externen Agenten.
Um mehr als einen Client neu zu konfigurieren, sendet der Server eine separate Nachricht per Unicast an jeden Client. Der Server kann die Neukonfiguration mehrerer Clients gleichzeitig initiieren; beispielsweise kann ein Server eine Reconfigure-Nachricht an zusätzliche Clients senden, während vorherige Neukonfigurations-Nachrichtenaustausche noch laufen.
Die Reconfigure-Nachricht veranlasst den Client, einen Renew/Reply- oder Information-request/Reply-Nachrichtenaustausch mit dem Server zu initiieren. Der Server interpretiert den Empfang einer Renew- oder Information-request-Nachricht (je nachdem, was in der ursprünglichen Reconfigure-Nachricht angegeben wurde) vom Client als Erfüllung der Reconfigure-Nachricht-Anforderung.
19.1.2. Zeitüberschreitung und Wiederholung von Reconfigure-Nachrichten
Wenn der Server keine Renew- oder Information-request-Nachricht vom Client innerhalb von REC_TIMEOUT Millisekunden empfängt, überträgt der Server die Reconfigure-Nachricht erneut, verdoppelt den Wert REC_TIMEOUT und wartet erneut. Der Server fährt mit diesem Prozess fort, bis REC_MAX_RC erfolglose Versuche unternommen wurden, an welchem Punkt der Server den Rekonfigurationsprozess für diesen Client abbrechen SOLLTE.
Standard- und Anfangswerte für REC_TIMEOUT und REC_MAX_RC sind in Abschnitt 5.5 dokumentiert.
19.2. Empfang von Renew-Nachrichten
Der Server erzeugt und sendet eine Reply-Nachricht an den Client, wie in den Abschnitten 18.2.3 und 18.2.8 beschrieben, einschließlich Optionen für Konfigurationsparameter.
Der Server KANN Optionen mit den IAs und neuen Werten für andere Konfigurationsparameter in die Reply-Nachricht aufnehmen, selbst wenn jene IAs und Parameter nicht in der Renew-Nachricht vom Client angefordert wurden.
19.3. Empfang von Information-request-Nachrichten
Der Server erzeugt und sendet eine Reply-Nachricht an den Client, wie in den Abschnitten 18.2.5 und 18.2.8 beschrieben, einschließlich Optionen für Konfigurationsparameter.
Der Server KANN Optionen mit neuen Werten für andere Konfigurationsparameter in die Reply-Nachricht aufnehmen, selbst wenn jene Parameter nicht in der Information-request-Nachricht vom Client angefordert wurden.
19.4. Client-Verhalten
Ein Client empfängt Reconfigure-Nachrichten, die an den UDP-Port 546 auf Schnittstellen gesendet werden, für die er Konfigurationsinformationen über DHCP erhalten hat. Diese Nachrichten können jederzeit gesendet werden. Da die Ergebnisse eines Neukonfigurationsereignisses Anwendungsschichtprogramme betreffen können, SOLLTE der Client diese Ereignisse protokollieren und KANN diese Programme über die Änderung über eine implementationsspezifische Schnittstelle benachrichtigen.
19.4.1. Empfang von Reconfigure-Nachrichten
Nach Empfang einer gültigen Reconfigure-Nachricht antwortet der Client mit entweder einer Renew-Nachricht oder einer Information-request-Nachricht, wie durch die Reconfigure Message-Option (definiert in Abschnitt 22.19) angegeben. Der Client ignoriert das Feld transaction-id in der empfangenen Reconfigure-Nachricht. Während die Transaktion läuft, verwirft der Client alle Reconfigure-Nachrichten, die er empfängt, stillschweigend.
DISKUSSION:
Die Reconfigure-Nachricht wirkt als Auslöser, der den Client
signalisiert, einen erfolgreichen Nachrichtenaustausch
abzuschließen. Sobald der Client eine Reconfigure empfangen hat,
fährt der Client mit dem Nachrichtenaustausch fort (wobei er die
Renew- oder Information-request-Nachricht bei Bedarf erneut
überträgt); der Client ignoriert alle weiteren Reconfigure-Nachrichten,
bis der Austausch abgeschlossen ist. Nachfolgende Reconfigure-
Nachrichten veranlassen den Client, einen neuen Austausch zu
initiieren.
Wie funktioniert dieser Mechanismus angesichts von duplizierten oder
erneut übertragenen Reconfigure-Nachrichten? Duplikate werden
ignoriert, da der Client den Austausch nach dem Empfang der ersten
Reconfigure beginnt. Erneut übertragene Nachrichten werden entweder
den Austausch auslösen (wenn die erste Reconfigure vom Client nicht
empfangen wurde) oder ignoriert werden. Der Server kann die
Wiederholungsübertragung von Reconfigure-Nachrichten an den Client
einstellen, sobald er die Renew- oder Information-request-Nachricht
vom Client empfängt.
Es könnte möglich sein, dass eine duplizierte oder erneut übertragene
Reconfigure ausreichend verzögert (und außerhalb der Reihenfolge
zugestellt) beim Client eintrifft, nachdem der Austausch (durch die
ursprüngliche Reconfigure initiiert) abgeschlossen ist. In diesem
Fall würde der Client einen redundanten Austausch initiieren. Die
Wahrscheinlichkeit einer verzögerten und außerhalb der Reihenfolge
erfolgenden Zustellung ist klein genug, um ignoriert zu werden. Die
Folge des redundanten Austauschs ist Ineffizienz eher als
fehlerhaftes Verhalten.
19.4.2. Erzeugung und Übertragung von Renew-Nachrichten
Als Antwort auf eine Reconfigure erzeugt und sendet der Client die Renew-Nachricht genau auf dieselbe Weise wie in Abschnitt 18.1.3 umrissen, mit der Ausnahme, dass der Client die Option Request-Option und alle IA-Optionen aus der Reconfigure-Nachricht in die Renew-Nachricht kopiert.
19.4.3. Erzeugung und Übertragung von Information-request-Nachrichten
Als Antwort auf eine Reconfigure erzeugt und sendet der Client die Information-request-Nachricht genau auf dieselbe Weise wie in Abschnitt 18.1.5 umrissen, mit der Ausnahme, dass der Client eine Server Identifier-Option mit dem Bezeichner aus der Reconfigure-Nachricht aufnimmt, auf die der Client antwortet.
19.4.4. Zeitüberschreitung und Wiederholung von Renew- oder Information-request-Nachrichten
Der Client verwendet dieselben Variablen und denselben Wiederholungsalgorithmus wie bei Renew- oder Information-request- Nachrichten, die im Rahmen eines vom Client initiierten Konfigurationsaustauschs erzeugt wurden. Einzelheiten siehe Abschnitte 18.1.3 und 18.1.5. Wenn der Client bis zum Ende des Wiederholungsprozesses keine Antwort vom Server empfängt, ignoriert und verwirft der Client die Reconfigure-Nachricht.
19.4.5. Empfang von Reply-Nachrichten
Nach Empfang einer gültigen Reply-Nachricht verarbeitet der Client die Optionen und setzt (oder setzt zurück) Konfigurationsparameter entsprechend. Der Client zeichnet die Lebensdauern für alle Adressen, die in IAs in der Reply-Nachricht angegeben sind, auf und aktualisiert sie.