19. Vom DHCP-Server initiierter Konfigurationsaustausch
19. Vom DHCP-Server initiierter Konfigurationsaustausch (DHCP Server-Initiated Configuration Exchange)
Ein Server initiiert einen Konfigurationsaustausch, damit DHCP-Clients neue Adressen und andere Konfigurationsinformationen erhalten. Ein Administrator kann beispielsweise einen Server-initiierten Konfigurationsaustausch verwenden, wenn Links in der DHCP-Domäne neu nummeriert werden sollen. Weitere Beispiele sind Änderungen am Standort von Verzeichnisservern, Hinzufügen neuer Dienste wie Drucken und Verfügbarkeit neuer Software.
19.1. Server-Verhalten (Server Behavior)
Ein Server sendet eine Reconfigure-Nachricht, damit ein Client sofort einen Renew/Reply- oder Information-request/Reply-Nachrichtenaustausch mit dem Server initiiert.
19.1.1. Erstellung und Übertragung von Reconfigure-Nachrichten
Der Server setzt das "msg-type"-Feld auf RECONFIGURE. Der Server setzt das transaction-id-Feld auf 0. Der Server enthält eine Server Identifier-Option mit seinem DUID und eine Client Identifier-Option mit dem DUID des Clients in der Reconfigure-Nachricht.
Der Server KANN eine Option Request-Option enthalten, um den Client über geänderte oder neue 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 enthalten, die keine anderen 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 ist die Verwendung eines Sicherheitsmechanismus in Reconfigure-Nachrichten vorgeschrieben. Der Server MUSS die DHCP-Authentifizierung in der Reconfigure-Nachricht verwenden.
Der Server MUSS eine Reconfigure Message-Option (definiert in Abschnitt 22.19) enthalten, um auszuwählen, ob der Client mit einer Renew-Nachricht oder einer Information-Request-Nachricht antwortet.
Der Server DARF KEINE anderen Optionen in der Reconfigure enthalten, außer wie in der Definition einzelner Optionen ausdrücklich erlaubt.
Ein Server sendet jede Reconfigure-Nachricht an einen einzelnen DHCP-Client unter Verwendung einer IPv6-Unicast-Adresse mit ausreichendem Gültigkeitsbereich, die dem DHCP-Client gehört. Wenn der Server keine Adresse hat, 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 entsprechenden 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 im Gange sind.
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-Nachrichtenanfrage.
19.1.2. Timeout und Wiederholung von Reconfigure-Nachrichten
Wenn der Server innerhalb von REC_TIMEOUT Millisekunden keine Renew- oder Information-request-Nachricht vom Client empfängt, sendet der Server die Reconfigure-Nachricht erneut, verdoppelt den REC_TIMEOUT-Wert und wartet erneut. Der Server setzt diesen Prozess fort, bis REC_MAX_RC erfolglose Versuche unternommen wurden, zu welchem Zeitpunkt der Server den Neukonfigurationsprozess 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 (Receipt of Renew Messages)
Der Server generiert 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 enthalten, die die IAs und neue Werte für andere Konfigurationsparameter in der Reply-Nachricht enthalten, auch wenn diese IAs und Parameter nicht in der Renew-Nachricht vom Client angefordert wurden.
19.3. Empfang von Information-request-Nachrichten (Receipt of Information-request Messages)
Der Server generiert 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 enthalten, die neue Werte für andere Konfigurationsparameter in der Reply-Nachricht enthalten, auch wenn diese Parameter nicht in der Information-request-Nachricht vom Client angefordert wurden.
19.4. Client-Verhalten (Client Behavior)
Ein Client empfängt Reconfigure-Nachrichten, die an 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 Programme auf Anwendungsebene beeinflussen können, SOLLTE der Client diese Ereignisse protokollieren und KANN diese Programme über eine implementierungsspezifische Schnittstelle über die Änderung benachrichtigen.
19.4.1. Empfang von Reconfigure-Nachrichten
Bei Empfang einer gültigen Reconfigure-Nachricht antwortet der Client mit einer Renew-Nachricht oder einer Information-request-Nachricht, wie durch die Reconfigure Message-Option angegeben (wie in Abschnitt 22.19 definiert). Der Client ignoriert das transaction-id-Feld in der empfangenen Reconfigure-Nachricht. Während die Transaktion läuft, verwirft der Client alle empfangenen Reconfigure-Nachrichten stillschweigend.
DISKUSSION:
Die Reconfigure-Nachricht fungiert als Auslöser, der dem Client signalisiert, einen erfolgreichen Nachrichtenaustausch abzuschließen. Sobald der Client eine Reconfigure-Nachricht empfangen hat, setzt der Client den Nachrichtenaustausch fort (wiederholt die Renew- oder Information-request-Nachricht bei Bedarf); der Client ignoriert alle zusätzlichen Reconfigure-Nachrichten, bis der Austausch abgeschlossen ist. Nachfolgende Reconfigure-Nachrichten veranlassen den Client, einen neuen Austausch zu initiieren.
Wie funktioniert dieser Mechanismus bei duplizierten oder wiederholten Reconfigure-Nachrichten? Duplizierte Nachrichten werden ignoriert, da der Client den Austausch nach dem Empfang der ersten Reconfigure-Nachricht beginnt. Wiederholte Nachrichten lösen entweder den Austausch aus (wenn die erste Reconfigure-Nachricht nicht vom Client empfangen wurde) oder werden ignoriert. Der Server kann die Wiederholung von Reconfigure-Nachrichten an den Client einstellen, sobald der Server die Renew- oder Information-request-Nachricht vom Client empfängt.
Es ist möglich, dass eine duplizierte oder wiederholte Reconfigure-Nachricht ausreichend verzögert wird (und außerhalb der Reihenfolge geliefert wird), um beim Client anzukommen, nachdem der Austausch (initiiert durch die ursprüngliche Reconfigure-Nachricht) abgeschlossen wurde. In diesem Fall würde der Client einen redundanten Austausch initiieren. Die Wahrscheinlichkeit einer verzögerten und außerhalb der Reihenfolge gelieferten Nachricht ist gering genug, um ignoriert zu werden. Die Folge des redundanten Austauschs ist Ineffizienz anstelle eines fehlerhaften Betriebs.
19.4.2. Erstellung und Übertragung von Renew-Nachrichten
Wenn der Client auf eine Reconfigure-Nachricht antwortet, erstellt und sendet er die Renew-Nachricht genau auf die gleiche Weise wie in Abschnitt 18.1.3 beschrieben, 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. Erstellung und Übertragung von Information-request-Nachrichten
Wenn der Client auf eine Reconfigure-Nachricht antwortet, erstellt und sendet er die Information-request-Nachricht genau auf die gleiche Weise wie in Abschnitt 18.1.5 beschrieben, mit der Ausnahme, dass der Client eine Server Identifier-Option mit dem Bezeichner aus der Reconfigure-Nachricht enthält, auf die der Client antwortet.
19.4.4. Timeout und Wiederholung von Renew- oder Information-request-Nachrichten
Der Client verwendet dieselben Variablen und denselben Wiederholungsalgorithmus wie bei Renew- oder Information-request-Nachrichten, die als Teil eines Client-initiierten Konfigurationsaustauschs generiert wurden. Siehe die Abschnitte 18.1.3 und 18.1.5 für Details. 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
Bei Empfang einer gültigen Reply-Nachricht verarbeitet der Client die Optionen und setzt (oder setzt zurück) die Konfigurationsparameter entsprechend. Der Client zeichnet und aktualisiert die Lebensdauern für alle in den IAs in der Reply-Nachricht angegebenen Adressen.