17. DHCP-Server-Anfrage

Dieser Abschnitt beschreibt, wie ein Client Server lokalisiert, die Adressen an IAs zuweisen werden, die dem Client gehören.

Der Client ist dafür verantwortlich, IAs zu erstellen und anzufordern, dass ein Server IPv6-Adressen an die IA zuweist. Der Client erstellt zuerst eine IA und weist ihr einen IAID zu. Der Client sendet dann eine Solicit-Nachricht, die eine IA-Option enthält, die die IA beschreibt. Server, die Adressen an die IA zuweisen können, antworten dem Client mit einer Advertise-Nachricht. Der Client initiiert dann einen Konfigurationsaustausch, wie in Abschnitt 18 beschrieben.

Wenn der Client eine Reply-Nachricht mit gebundenen Adresszuweisungen und anderen Ressourcen als Antwort auf die Solicit-Nachricht akzeptieren wird, enthält der Client eine Rapid Commit Option (siehe Abschnitt 22.14) in der Solicit-Nachricht.

17.1. Client-Verhalten

Ein Client verwendet die Solicit-Nachricht, um DHCP-Server zu entdecken, die konfiguriert sind, Adressen zuzuweisen oder andere Konfigurationsparameter auf dem Link zurückzugeben, an den der Client angeschlossen ist.

17.1.1. Erstellung von Solicit-Nachrichten

Der Client setzt das "msg-type"-Feld auf SOLICIT. Der Client generiert eine Transaktions-ID und fügt diesen Wert in das "transaction-id"-Feld ein.

Der Client MUSS eine Client Identifier Option enthalten, um sich dem Server zu identifizieren. Der Client enthält IA-Optionen für alle IAs, denen der Server Adressen zuweisen soll. Der Client KANN Adressen in den IAs als Hinweis für den Server über Adressen enthalten, für die der Client eine Präferenz hat. Der Client DARF KEINE anderen Optionen in der Solicit-Nachricht enthalten, außer wie in der Definition einzelner Optionen ausdrücklich erlaubt.

Der Client verwendet IA_NA-Optionen, um die Zuweisung von nicht-temporären Adressen anzufordern, und verwendet IA_TA-Optionen, um die Zuweisung von temporären Adressen anzufordern. IA_NA- oder IA_TA-Optionen oder eine Kombination aus beiden können in DHCP-Nachrichten enthalten sein.

Der Client SOLLTE eine Option Request Option (siehe Abschnitt 22.7) enthalten, um die Optionen anzugeben, die der Client interessiert ist zu empfangen. Der Client KANN zusätzlich Instanzen dieser Optionen enthalten, die in der Option Request Option identifiziert sind, mit Datenwerten als Hinweise für den Server über Parameterwerte, die der Client zurückgegeben haben möchte.

Der Client enthält eine Reconfigure Accept Option (siehe Abschnitt 22.20), wenn der Client bereit ist, Reconfigure-Nachrichten vom Server zu akzeptieren.

17.1.2. Übertragung von Solicit-Nachrichten

Die erste Solicit-Nachricht vom Client auf der Schnittstelle MUSS um eine zufällige Zeit zwischen 0 und SOL_MAX_DELAY verzögert werden. Im Fall einer Solicit-Nachricht, die übertragen wird, wenn DHCP durch IPv6 Neighbor Discovery initiiert wird, gibt die Verzögerung die Zeit an, die nach IPv6 Neighbor Discovery gewartet werden muss, die den Client veranlasst, das stateful Address Autoconfiguration Protocol aufzurufen (siehe Abschnitt 5.5.3 von RFC 2462). Diese zufällige Verzögerung desynchronisiert Clients, die zur gleichen Zeit starten (z.B. nach einem Stromausfall).

Der Client überträgt die Nachricht gemäß Abschnitt 14 unter Verwendung der folgenden Parameter:

IRT: SOL_TIMEOUT
MRT: SOL_MAX_RT
MRC: 0
MRD: 0

Wenn der Client eine Rapid Commit Option in seiner Solicit-Nachricht enthalten hat, beendet der Client den Warteprozess, sobald eine Reply-Nachricht mit einer Rapid Commit Option empfangen wird.

Wenn der Client auf eine Advertise-Nachricht wartet, wird der Mechanismus in Abschnitt 14 wie folgt für die Verwendung bei der Übertragung von Solicit-Nachrichten modifiziert. Der Nachrichtenaustausch wird nicht durch den Empfang einer Advertise beendet, bevor das erste RT abgelaufen ist. Vielmehr sammelt der Client Advertise-Nachrichten, bis das erste RT abgelaufen ist. Außerdem MUSS das erste RT so gewählt werden, dass es strikt größer als IRT ist, indem RAND strikt größer als 0 gewählt wird.

Ein Client MUSS Advertise-Nachrichten für die ersten RT Sekunden sammeln, es sei denn, er empfängt eine Advertise-Nachricht mit einem Präferenzwert von 255. Der Präferenzwert wird in der Preference Option (Abschnitt 22.8) übertragen. Jede Advertise, die keine Preference Option enthält, wird als Präferenzwert 0 betrachtet. Wenn der Client eine Advertise-Nachricht empfängt, die eine Preference Option mit einem Präferenzwert von 255 enthält, beginnt der Client sofort einen Client-initiierten Nachrichtenaustausch (wie in Abschnitt 18 beschrieben), indem er eine Request-Nachricht an den Server sendet, von dem die Advertise-Nachricht empfangen wurde. Wenn der Client eine Advertise-Nachricht empfängt, die keine Preference Option mit einem Präferenzwert von 255 enthält, wartet der Client weiter, bis das erste RT abgelaufen ist. Wenn das erste RT abgelaufen ist und der Client eine Advertise-Nachricht empfangen hat, SOLLTE der Client mit einem Client-initiierten Nachrichtenaustausch fortfahren, indem er eine Request-Nachricht sendet.

Wenn der Client keine Advertise-Nachrichten empfängt, bevor das erste RT abgelaufen ist, beginnt er den in Abschnitt 14 beschriebenen Wiederholungsmechanismus. Der Client beendet den Wiederholungsprozess, sobald er eine Advertise-Nachricht empfängt, und der Client handelt auf der empfangenen Advertise-Nachricht, ohne auf zusätzliche Advertise-Nachrichten zu warten.

Ein DHCP-Client SOLLTE MRC und MRD auf 0 wählen. Wenn der DHCP-Client mit MRC oder MRD auf einen Wert ungleich 0 konfiguriert ist, MUSS er aufhören, die Schnittstelle zu konfigurieren, wenn der Nachrichtenaustausch fehlschlägt. Nachdem der DHCP-Client aufgehört hat, die Schnittstelle zu konfigurieren, SOLLTE er den Rekonfigurationsprozess nach einem externen Ereignis neu starten, wie z.B. Benutzereingabe, Systemneustart oder wenn der Client an einen neuen Link angeschlossen wird.

17.1.3. Empfang von Advertise-Nachrichten

Der Client MUSS alle Advertise-Nachrichten ignorieren, die eine Status Code Option mit dem Wert NoAddrsAvail enthalten, mit der Ausnahme, dass der Client die zugehörige Statusnachricht dem Benutzer anzeigen KANN.

Nach dem Empfang einer oder mehrerer gültiger Advertise-Nachrichten wählt der Client eine oder mehrere Advertise-Nachrichten basierend auf den folgenden Kriterien aus.

Die Advertise-Nachrichten mit dem höchsten Server-Präferenzwert werden allen anderen Advertise-Nachrichten vorgezogen.
Innerhalb einer Gruppe von Advertise-Nachrichten mit demselben Server-Präferenzwert KANN ein Client die Server auswählen, deren Advertise-Nachrichten Informationen ankündigen, die für den Client von Interesse sind. Zum Beispiel kann der Client einen Server wählen, der eine Anzeige mit Konfigurationsoptionen zurückgegeben hat, die für den Client von Interesse sind.
Der Client KANN einen weniger bevorzugten Server wählen, wenn dieser Server einen besseren Satz von angekündigten Parametern hat, wie z.B. die in IAs angekündigten verfügbaren Adressen.

Sobald ein Client Advertise-Nachricht(en) ausgewählt hat, speichert der Client typischerweise Informationen über jeden Server, wie Server-Präferenzwert, angekündigte Adressen, wann die Anzeige empfangen wurde, usw.

Wenn der Client einen alternativen Server auswählen muss, falls der gewählte Server nicht antwortet, wählt der Client den nächsten Server gemäß den oben angegebenen Kriterien.

17.1.4. Empfang von Reply-Nachrichten

Wenn der Client eine Rapid Commit Option in der Solicit-Nachricht enthält, erwartet er eine Reply-Nachricht, die eine Rapid Commit Option als Antwort enthält. Der Client verwirft alle Reply-Nachrichten, die er empfängt und die keine Rapid Commit Option enthalten. Wenn der Client eine gültige Reply-Nachricht empfängt, die eine Rapid Commit Option enthält, verarbeitet er die Nachricht wie in Abschnitt 18.1.8 beschrieben. Wenn er keine solche Reply-Nachricht empfängt und eine gültige Advertise-Nachricht empfängt, verarbeitet der Client die Advertise-Nachricht wie in Abschnitt 17.1.3 beschrieben.

Wenn der Client anschließend eine gültige Reply-Nachricht empfängt, die eine Rapid Commit Option enthält, tut er entweder:

verarbeitet die Reply-Nachricht wie in Abschnitt 18.1.8 beschrieben und verwirft alle Reply-Nachrichten, die als Antwort auf die Request-Nachricht empfangen wurden, oder
verarbeitet alle Reply-Nachrichten, die als Antwort auf die Request-Nachricht empfangen wurden, und verwirft die Reply-Nachricht, die die Rapid Commit Option enthält.

17.2. Server-Verhalten

Ein Server sendet eine Advertise-Nachricht als Antwort auf gültige Solicit-Nachrichten, die er empfängt, um dem Client die Verfügbarkeit des Servers mitzuteilen.

17.2.1. Empfang von Solicit-Nachrichten

Der Server bestimmt die Informationen über den Client und seinen Standort wie in Abschnitt 11 beschrieben und überprüft seine administrative Richtlinie bezüglich der Antwort an den Client. Wenn der Server nicht berechtigt ist, dem Client zu antworten, verwirft der Server die Solicit-Nachricht. Zum Beispiel, wenn die administrative Richtlinie für den Server ist, dass er nur einem Client antworten darf, der bereit ist, eine Reconfigure-Nachricht zu akzeptieren, und wenn der Client mit einer Reconfigure Accept Option in der Solicit-Nachricht anzeigt, dass er keine Reconfigure-Nachricht akzeptieren wird, verwirft der Server die Solicit-Nachricht.

Wenn der Client eine Rapid Commit Option in der Solicit-Nachricht enthalten hat und der Server so konfiguriert wurde, dass er mit gebundenen Adresszuweisungen und anderen Ressourcen antwortet, antwortet der Server auf die Solicit mit einer Reply-Nachricht wie in Abschnitt 17.2.3 beschrieben. Andernfalls ignoriert der Server die Rapid Commit Option und verarbeitet den Rest der Nachricht, als ob keine Rapid Commit Option vorhanden wäre.

17.2.2. Erstellung und Übertragung von Advertise-Nachrichten

Der Server setzt das "msg-type"-Feld auf ADVERTISE und kopiert den Inhalt des transaction-id-Felds aus der Solicit-Nachricht, die vom Client empfangen wurde, in die Advertise-Nachricht. Der Server enthält seinen Server-Bezeichner in einer Server Identifier Option und kopiert den Client Identifier aus der Solicit-Nachricht in die Advertise-Nachricht.

Der Server KANN eine Preference Option hinzufügen, um den Präferenzwert für die Advertise-Nachricht zu übertragen. Die Server-Implementierung SOLLTE die Einstellung eines Server-Präferenzwerts durch den Administrator ermöglichen. Der Server-Präferenzwert MUSS standardmäßig null sein, es sei denn, er wird vom Serveradministrator anders konfiguriert.

Der Server enthält eine Reconfigure Accept Option, wenn der Server erfordern möchte, dass der Client Reconfigure-Nachrichten akzeptiert.

Der Server enthält Optionen, die der Server in einer nachfolgenden Reply-Nachricht an den Client zurückgeben wird. Die Informationen in diesen Optionen können vom Client bei der Auswahl eines Servers verwendet werden, wenn der Client mehr als eine Advertise-Nachricht empfängt. Wenn der Client eine Option Request Option in der Solicit-Nachricht enthalten hat, enthält der Server Optionen in der Advertise-Nachricht, die Konfigurationsparameter für alle Optionen enthalten, die in der Option Request Option identifiziert sind und die der Server so konfiguriert wurde, dass er sie an den Client zurückgibt. Der Server KANN zusätzliche Optionen an den Client zurückgeben, wenn er so konfiguriert wurde. Der Server muss sich der Empfehlungen zu Paketgrößen und der Verwendung von Fragmentierung in Abschnitt 5 von RFC 2460 bewusst sein.

Wenn die Solicit-Nachricht vom Client eine oder mehrere IA-Optionen enthielt, MUSS der Server IA-Optionen in der Advertise-Nachricht enthalten, die alle Adressen enthalten, die den IAs zugewiesen würden, die in der Solicit-Nachricht vom Client enthalten sind. Wenn der Client Adressen in den IAs in der Solicit-Nachricht enthalten hat, verwendet der Server diese Adressen als Hinweise über die Adressen, die der Client empfangen möchte.

Wenn der Server keine Adressen an IAs in einer nachfolgenden Request vom Client zuweisen wird, MUSS der Server eine Advertise-Nachricht an den Client senden, die nur eine Status Code Option mit Code NoAddrsAvail und eine Statusnachricht für den Benutzer, eine Server Identifier Option mit dem DUID des Servers und eine Client Identifier Option mit dem DUID des Clients enthält.

Wenn die Solicit-Nachricht direkt vom Server empfangen wurde, sendet der Server die Advertise-Nachricht direkt als Unicast an den Client unter Verwendung der Adresse im Quelladressfeld aus dem IP-Datagramm, in dem die Solicit-Nachricht empfangen wurde. Die Advertise-Nachricht MUSS als Unicast auf dem Link gesendet werden, von dem die Solicit-Nachricht empfangen wurde.

Wenn die Solicit-Nachricht in einer Relay-forward-Nachricht empfangen wurde, konstruiert der Server eine Relay-reply-Nachricht mit der Advertise-Nachricht in der Nutzlast einer "relay-message" Option. Wenn die Relay-forward-Nachrichten eine Interface-id Option enthielten, kopiert der Server diese Option in die Relay-reply-Nachricht. Der Server sendet die Relay-reply-Nachricht direkt als Unicast an den Relay-Agent unter Verwendung der Adresse im Quelladressfeld aus dem IP-Datagramm, in dem die Relay-forward-Nachricht empfangen wurde.

17.2.3. Erstellung und Übertragung von Reply-Nachrichten

Der Server MUSS die Zuweisung von Adressen oder anderen Konfigurationsinformationen binden, bevor er eine Reply-Nachricht an einen Client als Antwort auf eine Solicit-Nachricht sendet.

DISKUSSION:

Bei Verwendung des Solicit-Reply-Nachrichtenaustauschs bindet der Server die Zuweisung von Adressen, bevor er die Reply-Nachricht sendet. Der Client kann annehmen, dass ihm die Adressen in der Reply-Nachricht zugewiesen wurden, und muss keine Request-Nachricht für diese Adressen senden.

Typischerweise werden Server, die so konfiguriert sind, dass sie den Solicit-Reply-Nachrichtenaustausch verwenden, so bereitgestellt, dass nur ein Server auf eine Solicit-Nachricht antwortet. Wenn mehr als ein Server antwortet, verwendet der Client nur die Adressen von einem der Server, während die Adressen von den anderen Servern an den Client gebunden werden, aber vom Client nicht verwendet werden.

Der Server enthält eine Rapid Commit Option in der Reply-Nachricht, um anzuzeigen, dass die Reply eine Antwort auf eine Solicit-Nachricht ist.

Der Server enthält eine Reconfigure Accept Option, wenn der Server erfordern möchte, dass der Client Reconfigure-Nachrichten akzeptiert.

Der Server erzeugt die Reply-Nachricht, als hätte er eine Request-Nachricht empfangen, wie in Abschnitt 18.2.1 beschrieben. Der Server überträgt die Reply-Nachricht wie in Abschnitt 18.2.8 beschrieben.