17. DHCP-Serversuche (DHCP Server Solicitation)

17. DHCP-Serversuche

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

Der Client ist dafür verantwortlich, IAs zu erzeugen und einen Server aufzufordern, der IA IPv6-Adressen zuzuweisen. Der Client erzeugt zunächst eine IA und weist ihr eine IAID zu. Der Client überträgt dann eine Solicit-Nachricht, die eine IA-Option enthält, welche 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 zugesicherten Adresszuweisungen und anderen Ressourcen als Antwort auf die Solicit-Nachricht akzeptiert, nimmt der Client eine Rapid Commit-Option (siehe Abschnitt 22.14) in die Solicit-Nachricht auf.

17.1. Client-Verhalten

Ein Client verwendet die Solicit-Nachricht, um DHCP-Server zu entdecken, die so konfiguriert sind, dass sie Adressen zuweisen oder andere Konfigurationsparameter auf dem Link zurückgeben, an den der Client angehängt ist.

17.1.1. Erzeugung von Solicit-Nachrichten

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

Der Client MUSS eine Client Identifier-Option aufnehmen, um sich gegenüber dem Server zu identifizieren. Der Client nimmt IA-Optionen für alle IAs auf, denen der Server Adressen zuweisen soll. Der Client KANN Adressen in den IAs als Hinweis für den Server über Adressen aufnehmen, für die der Client eine Vorliebe hat. Der Client DARF KEINE anderen Optionen in der Solicit-Nachricht aufnehmen, außer wie speziell in der Definition einzelner Optionen 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. Sowohl IA_NA- als auch 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) aufnehmen, um die Optionen anzugeben, an deren Erhalt der Client interessiert ist. Der Client KANN zusätzlich Instanzen jener Optionen aufnehmen, die in der Option Request-Option identifiziert sind, mit Datenwerten als Hinweis für den Server über Parameterwerte, die der Client zurückgegeben haben möchte.

Der Client nimmt eine Reconfigure Accept-Option (siehe Abschnitt 22.20) auf, wenn der Client bereit ist, Reconfigure-Nachrichten vom Server anzunehmen.

17.1.2. Übertragung von Solicit-Nachrichten

Die erste Solicit-Nachricht des Clients auf der Schnittstelle MUSS um eine zufällige Zeitspanne zwischen 0 und SOL_MAX_DELAY verzögert werden. Im Falle einer Solicit-Nachricht, die übertragen wird, wenn DHCP durch IPv6-Neighbor Discovery initiiert wird, gibt die Verzögerung die Zeitspanne an, die nach dem Auslösen des zustandsbehafteten Adressautokonfigurationsprotokolls durch die IPv6-Neighbor Discovery (siehe Abschnitt 5.5.3 von RFC 2462) abgewartet werden soll. Diese zufällige Verzögerung desynchronisiert Clients, die zur gleichen Zeit starten (beispielsweise 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 seine Solicit-Nachricht aufgenommen 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 Übertragung von Solicit-Nachrichten abgewandelt. Der Nachrichtenaustausch wird durch den Empfang einer Advertise nicht vor Ablauf des ersten RT beendet. Vielmehr sammelt der Client Advertise-Nachrichten, bis der erste RT abgelaufen ist. Zudem MUSS der erste RT strikt größer als IRT gewählt werden, 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 Präferenzwert 255 enthält, beginnt der Client sofort einen vom 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 Präferenzwert 255 enthält, fährt der Client fort zu warten, bis der erste RT abläuft. Wenn der erste RT abläuft und der Client eine Advertise-Nachricht empfangen hat, SOLLTE der Client mit einem vom Client initiierten Nachrichtenaustausch durch Senden einer Request-Nachricht fortfahren.

Wenn der Client vor Ablauf des ersten RT keine Advertise-Nachrichten empfängt, beginnt er den in Abschnitt 14 beschriebenen Wiederholungsmechanismus. Der Client beendet den Wiederholungsprozess, sobald er irgendeine Advertise-Nachricht empfängt, und der Client verarbeitet die empfangene Advertise-Nachricht, ohne auf weitere Advertise-Nachrichten zu warten.

Ein DHCP-Client SOLLTE MRC und MRD auf 0 setzen. Wenn der DHCP-Client mit einem anderen als dem Wert 0 für MRC oder MRD konfiguriert ist, MUSS er versuchen, die Schnittstelle zu konfigurieren, wenn der Nachrichtenaustausch fehlschlägt, abbrechen. Nachdem der DHCP-Client versucht hat, die Schnittstelle zu konfigurieren, SOLLTE er den Rekonfigurationsprozess nach einem externen Ereignis neu starten, wie etwa Benutzereingabe, Systemneustart oder wenn der Client an einen neuen Link angehängt wird.

17.1.3. Empfang von Advertise-Nachrichten

Der Client MUSS jede Advertise-Nachricht ignorieren, die eine Status Code-Option mit dem Wert NoAddrsAvail enthält, mit der Ausnahme, dass der Client die zugehörige Statusmeldung dem Benutzer anzeigen MAY.

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

• Solche 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 jene Server auswählen, deren Advertise-Nachrichten Informationen von Interesse für den Client bewerben. Beispielsweise kann der Client einen Server wählen, der eine Werbung mit Konfigurationsoptionen von Interesse für den Client zurückgegeben hat.

• Der Client KANN einen weniger bevorzugten Server wählen, wenn dieser Server einen besseren Satz beworbener Parameter hat, wie etwa die in IAs beworbenen verfügbaren Adressen.

Sobald ein Client Advertise-Nachricht(en) ausgewählt hat, wird er in der Regel Informationen über jeden Server speichern, wie etwa Server-Präferenzwert, beworbene Adressen, Zeitpunkt des Empfangs der Werbung und so weiter.

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

17.1.4. Empfang einer Reply-Nachricht

Wenn der Client eine Rapid Commit-Option in die Solicit-Nachricht aufnimmt, erwartet er eine Reply-Nachricht, die als Antwort eine Rapid Commit-Option 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 eine solche Reply-Nachricht nicht empfängt und stattdessen eine gültige Advertise-Nachricht empfängt, verarbeitet der Client die Advertise-Nachricht wie in Abschnitt 17.1.3 beschrieben.

Wenn der Client nachfolgend eine gültige Reply-Nachricht empfängt, die eine Rapid Commit-Option enthält, dann entweder:

  verarbeitet er 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 er 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 anzukündigen.

17.2.1. Empfang von Solicit-Nachrichten

Der Server ermittelt die Informationen über den Client und dessen Standort wie in Abschnitt 11 beschrieben und prüft seine Verwaltungsrichtlinie bezüglich der Antwort an den Client. Wenn dem Server nicht gestattet ist, auf den Client zu antworten, verwirft der Server die Solicit-Nachricht. Wenn beispielsweise die Verwaltungsrichtlinie für den Server besagt, dass er nur auf einen Client antworten darf, der bereit ist, eine Reconfigure-Nachricht zu akzeptieren, und der Client mit einer Reconfigure Accept-Option in der Solicit- Nachricht angibt, dass er keine Reconfigure-Nachricht akzeptieren wird, verwirft der Server die Solicit-Nachricht.

Wenn der Client eine Rapid Commit-Option in die Solicit-Nachricht aufgenommen hat und der Server so konfiguriert wurde, dass er mit zugesicherten 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 so, als ob keine Rapid Commit-Option vorhanden wäre.

17.2.2. Erzeugung und Übertragung von Advertise-Nachrichten

Der Server setzt das Feld "msg-type" auf ADVERTISE und kopiert den Inhalt des Felds transaction-id aus der vom Client empfangenen Solicit-Nachricht in die Advertise-Nachricht. Der Server nimmt seinen Server-Bezeichner in eine Server Identifier-Option auf 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 tragen. Die Server-Implementierung SOLLTE dem Administrator das Setzen eines Server-Präferenzwerts erlauben. Der Server-Präferenzwert MUSS standardmäßig null sein, sofern nicht anders durch den Server-Administrator konfiguriert.

Der Server nimmt eine Reconfigure Accept-Option auf, wenn der Server verlangen will, dass der Client Reconfigure-Nachrichten akzeptiert.

Der Server nimmt Optionen auf, die er in einer nachfolgenden Reply-Nachricht an den Client zurückgeben wird. Die Informationen in diesen Optionen können vom Client bei der Serverauswahl verwendet werden, wenn der Client mehr als eine Advertise-Nachricht empfängt. Wenn der Client eine Option Request-Option in der Solicit-Nachricht aufgenommen hat, nimmt der Server in der Advertise-Nachricht Optionen mit Konfigurationsparametern für alle in der Option Request-Option identifizierten Optionen auf, die er so konfiguriert hat, dass sie an den Client zurückgegeben werden. Der Server KANN zusätzliche Optionen an den Client zurückgeben, wenn er dafür konfiguriert ist. 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 des Clients eine oder mehrere IA-Optionen enthielt, MUSS der Server IA-Optionen in der Advertise-Nachricht aufnehmen, die alle Adressen enthalten, die den IAs in der Solicit- Nachricht des Clients zugewiesen würden. Wenn der Client Adressen in den IAs in der Solicit-Nachricht aufgenommen hat, verwendet der Server diese Adressen als Hinweise auf die Adressen, die der Client empfangen möchte.

Wenn der Server keine Adressen an irgendeine IA in einer nachfolgenden Request des Clients zuweisen wird, MUSS der Server eine Advertise- Nachricht an den Client senden, die nur eine Status Code-Option mit dem Code NoAddrsAvail und eine Statusmeldung 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 per Unicast an den Client unter Verwendung der Adresse im Quelladressfeld des IP-Datagramms, in dem die Solicit-Nachricht empfangen wurde. Die Advertise-Nachricht MUSS per Unicast auf dem Link übertragen werden, von dem die Solicit-Nachricht empfangen wurde.

Wenn die Solicit-Nachricht in einer Relay-forward-Nachricht empfangen wurde, erzeugt der Server eine Relay-reply-Nachricht mit der Advertise- Nachricht im Nutzdatenteil 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 per Unicast an den Relay-Agenten unter Verwendung der Adresse im Quelladressfeld des IP-Datagramms, in dem die Relay-forward-Nachricht empfangen wurde.

17.2.3. Erzeugung und Übertragung von Reply-Nachrichten

Der Server MUSS die Zuweisung aller Adressen oder anderer Konfigurationsinformationsnachrichten zusichern, bevor er eine Reply-Nachricht an einen Client als Antwort auf eine Solicit-Nachricht sendet.

DISKUSSION:

  Bei Verwendung des Solicit-Reply-Nachrichtenaustauschs sichert der
  Server die Zuweisung aller Adressen zu, 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 für die Verwendung des Solicit-Reply-
  Nachrichtenaustauschs konfiguriert sind, so bereitgestellt, dass nur ein
  Server auf eine Solicit-Nachricht antwortet.  Wenn mehr als ein Server
  antwortet, wird der Client nur die Adressen von einem der Server
  verwenden, während die Adressen der anderen Server dem Client
  zugesichert, aber vom Client nicht verwendet werden.

Der Server nimmt eine Rapid Commit-Option in die Reply-Nachricht auf, um anzuzeigen, dass die Reply als Antwort auf eine Solicit-Nachricht erfolgt.

Der Server nimmt eine Reconfigure Accept-Option auf, wenn der Server verlangen will, dass der Client Reconfigure-Nachrichten akzeptiert.

Der Server erzeugt die Reply-Nachricht so, 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.