18. Vom DHCP-Client initiierter Konfigurationsaustausch (DHCP Client-Initiated Configuration Exchange)

Ein Client initiiert einen Nachrichtenaustausch mit einem oder mehreren Servern, um interessante Konfigurationsinformationen zu erwerben oder zu aktualisieren. Der Client kann den Konfigurationsaustausch als Teil des Betriebssystem-Konfigurationsprozesses initiieren, wenn er von der Anwendungsschicht dazu aufgefordert wird, wenn dies durch Stateless Address Autoconfiguration erforderlich ist oder wenn die Lebensdauer einer Adresse verlängert werden muss (Renew- und Rebind-Nachrichten).

18.1. Client-Verhalten (Client Behavior)

Ein Client verwendet Request-, Renew-, Rebind-, Release- und Decline-Nachrichten während des normalen Lebenszyklus von Adressen. Er verwendet Confirm, um Adressen zu validieren, wenn er möglicherweise zu einem neuen Link gewechselt ist. Er verwendet Information-Request-Nachrichten, wenn er Konfigurationsinformationen, aber keine Adressen benötigt.

Wenn der Client über eine Quelladresse mit ausreichendem Gültigkeitsbereich verfügt, die vom Server als Rücksendeadresse verwendet werden kann, und der Client eine Server Unicast-Option (Abschnitt 22.12) vom Server erhalten hat, SOLLTE (SHOULD) der Client alle Request-, Renew-, Release- und Decline-Nachrichten per Unicast an den Server senden.

DISKUSSION (DISCUSSION):

Die Verwendung von Unicast kann Verzögerungen durch die Weiterleitung von Nachrichten durch Relay-Agenten vermeiden sowie Overhead und doppelte Antworten von Servern vermeiden, die durch die Zustellung von Client-Nachrichten an mehrere Server entstehen. Die Anforderung, dass der Client alle DHCP-Nachrichten über einen Relay-Agenten weiterleitet, ermöglicht die Einbeziehung von Relay-Agent-Optionen in alle vom Client gesendeten Nachrichten. Der Server sollte die Verwendung von Unicast nur aktivieren, wenn keine Relay-Agent-Optionen verwendet werden.

18.1.1. Erstellung und Übertragung von Request-Nachrichten (Creation and Transmission of Request Messages)

Der Client verwendet eine Request-Nachricht, um IAs mit Adressen zu füllen und andere Konfigurationsinformationen zu erhalten. Der Client fügt eine oder mehrere IA-Optionen in die Request-Nachricht ein. Der Server gibt dann Adressen und andere Informationen über die IAs in IA-Optionen in einer Reply-Nachricht an den Client zurück.

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

Der Client platziert die Kennung des Zielservers in einer Server Identifier-Option.

Der Client MUSS (MUST) eine Client Identifier-Option enthalten, um sich gegenüber dem Server zu identifizieren. Der Client fügt alle anderen geeigneten Optionen hinzu, einschließlich einer oder mehrerer IA-Optionen (wenn der Client anfordert, dass der Server ihm einige Netzwerkadressen zuweist).

Der Client MUSS (MUST) eine Option Request-Option (siehe Abschnitt 22.7) enthalten, um die Optionen anzugeben, die der Client empfangen möchte. Der Client KANN (MAY) Optionen mit Datenwerten als Hinweise an den Server über Parameterwerte enthalten, die der Client zurückgegeben haben möchte.

Der Client fügt eine Reconfigure Accept-Option (siehe Abschnitt 22.20) hinzu, die angibt, ob der Client bereit ist, Reconfigure-Nachrichten vom Server zu akzeptieren oder nicht.

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

IRT   REQ_TIMEOUT
MRT   REQ_MAX_RT
MRC   REQ_MAX_RC
MRD   0

Wenn der Nachrichtenaustausch fehlschlägt, ergreift der Client eine Aktion basierend auf der lokalen Richtlinie des Clients. Beispiele für Aktionen, die der Client ergreifen könnte, sind:

• Auswahl eines anderen Servers aus einer Liste von dem Client bekannten Servern; zum Beispiel Server, die mit einer Advertise-Nachricht geantwortet haben.
• Initiierung des in Abschnitt 17 beschriebenen Server-Erkennungsprozesses.
• Beendigung des Konfigurationsprozesses und Meldung eines Fehlers.

18.1.2. Erstellung und Übertragung von Confirm-Nachrichten (Creation and Transmission of Confirm Messages)

Wann immer ein Client möglicherweise zu einem neuen Link gewechselt ist, sind die Präfixe der den Schnittstellen auf diesem Link zugewiesenen Adressen möglicherweise nicht mehr für den Link geeignet, mit dem der Client verbunden ist. Beispiele für Zeiten, zu denen ein Client möglicherweise zu einem neuen Link gewechselt ist:

• Der Client startet neu.
• Der Client wird physisch mit einer kabelgebundenen Verbindung verbunden.
• Der Client kehrt aus dem Ruhemodus zurück.
• Der Client, der eine drahtlose Technologie verwendet, wechselt den Zugangspunkt.

In jeder Situation, in der ein Client möglicherweise zu einem neuen Link gewechselt ist, MUSS (MUST) der Client einen Confirm/Reply-Nachrichtenaustausch initiieren. Der Client fügt alle IAs, die der Schnittstelle zugewiesen sind, die möglicherweise zu einem neuen Link gewechselt ist, zusammen mit den diesen IAs zugeordneten Adressen in seine Confirm-Nachricht ein. Alle antwortenden Server geben an, ob diese Adressen für den Link geeignet sind, mit dem der Client verbunden ist, mit dem Status in der Reply-Nachricht, die sie an den Client zurücksenden.

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

Der Client MUSS (MUST) eine Client Identifier-Option enthalten, um sich gegenüber dem Server zu identifizieren. Der Client fügt IA-Optionen für alle IAs hinzu, die der Schnittstelle zugewiesen sind, für die die Confirm-Nachricht gesendet wird. Die IA-Optionen enthalten alle Adressen, die der Client derzeit mit diesen IAs verknüpft hat. Der Client SOLLTE (SHOULD) die Felder T1 und T2 in allen IA_NA-Optionen und die Felder preferred-lifetime und valid-lifetime in den IA Address-Optionen auf 0 setzen, da der Server diese Felder ignoriert.

Die erste Confirm-Nachricht vom Client auf der Schnittstelle MUSS (MUST) um eine zufällige Zeitspanne zwischen 0 und CNF_MAX_DELAY verzögert werden. Der Client überträgt die Nachricht gemäß Abschnitt 14 unter Verwendung der folgenden Parameter:

IRT   CNF_TIMEOUT
MRT   CNF_MAX_RT
MRC   0
MRD   CNF_MAX_RD

Wenn der Client keine Antworten erhält, bevor der Nachrichtenübertragungsprozess beendet wird, wie in Abschnitt 14 beschrieben, SOLLTE (SHOULD) der Client weiterhin alle IP-Adressen verwenden, wobei er die zuletzt bekannten Lebensdauern für diese Adressen verwendet, und SOLLTE (SHOULD) weiterhin alle anderen zuvor erhaltenen Konfigurationsparameter verwenden.

18.1.3. Erstellung und Übertragung von Renew-Nachrichten (Creation and Transmission of Renew Messages)

Um die gültigen und bevorzugten Lebensdauern für die mit einer IA verknüpften Adressen zu verlängern, sendet der Client eine Renew-Nachricht an den Server, von dem der Client die Adressen in der IA erhalten hat, die eine IA-Option für die IA enthält. Der Client fügt IA Address-Optionen in die IA-Option für die mit der IA verknüpften Adressen ein. Der Server bestimmt neue Lebensdauern für die Adressen in der IA gemäß der administrativen Konfiguration des Servers. Der Server kann auch neue Adressen zur IA hinzufügen. Der Server kann Adressen aus der IA entfernen, indem er die bevorzugten und gültigen Lebensdauern dieser Adressen auf Null setzt.

Der Server steuert die Zeit, zu der der Client den Server kontaktiert, um die Lebensdauern zugewiesener Adressen zu verlängern, über die T1- und T2-Parameter, die einer IA zugewiesen sind.

Zum Zeitpunkt T1 für eine IA initiiert der Client einen Renew/Reply-Nachrichtenaustausch, um die Lebensdauern aller Adressen in der IA zu verlängern. Der Client fügt eine IA-Option mit allen derzeit der IA zugewiesenen Adressen in seine Renew-Nachricht ein.

Wenn T1 oder T2 vom Server auf 0 gesetzt wird (für eine IA_NA) oder wenn es keine T1- oder T2-Zeiten gibt (für eine IA_TA), kann der Client nach eigenem Ermessen eine Renew- bzw. Rebind-Nachricht senden.

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

Der Client platziert die Kennung des Zielservers in einer Server Identifier-Option.

Der Client MUSS (MUST) eine Client Identifier-Option enthalten, um sich gegenüber dem Server zu identifizieren. Der Client fügt alle geeigneten Optionen hinzu, einschließlich einer oder mehrerer IA-Optionen. Der Client MUSS (MUST) die Liste der Adressen, die der Client derzeit mit den IAs verknüpft hat, in die Renew-Nachricht aufnehmen.

Der Client MUSS (MUST) eine Option Request-Option (siehe Abschnitt 22.7) enthalten, um die Optionen anzugeben, die der Client empfangen möchte. Der Client KANN (MAY) Optionen mit Datenwerten als Hinweise an den Server über Parameterwerte enthalten, die der Client zurückgegeben haben möchte.

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

IRT   REN_TIMEOUT
MRT   REN_MAX_RT
MRC   0
MRD   Verbleibende Zeit bis T2

Der Nachrichtenaustausch wird beendet, wenn die Zeit T2 erreicht wird (siehe Abschnitt 18.1.4), zu diesem Zeitpunkt beginnt der Client einen Rebind-Nachrichtenaustausch.

18.1.4. Erstellung und Übertragung von Rebind-Nachrichten (Creation and Transmission of Rebind Messages)

Zum Zeitpunkt T2 für eine IA (der nur erreicht wird, wenn der Server, an den die Renew-Nachricht zum Zeitpunkt T1 gesendet wurde, nicht geantwortet hat) initiiert der Client einen Rebind/Reply-Nachrichtenaustausch mit jedem verfügbaren Server. Der Client fügt eine IA-Option mit allen derzeit der IA zugewiesenen Adressen in seine Rebind-Nachricht ein.

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

Der Client MUSS (MUST) eine Client Identifier-Option enthalten, um sich gegenüber dem Server zu identifizieren. Der Client fügt alle geeigneten Optionen hinzu, einschließlich einer oder mehrerer IA-Optionen. Der Client MUSS (MUST) die Liste der Adressen, die der Client derzeit mit den IAs verknüpft hat, in die Rebind-Nachricht aufnehmen.

Der Client MUSS (MUST) eine Option Request-Option (siehe Abschnitt 22.7) enthalten, um die Optionen anzugeben, die der Client empfangen möchte. Der Client KANN (MAY) Optionen mit Datenwerten als Hinweise an den Server über Parameterwerte enthalten, die der Client zurückgegeben haben möchte.

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

IRT   REB_TIMEOUT
MRT   REB_MAX_RT
MRC   0
MRD   Verbleibende Zeit bis zum Ablauf der gültigen Lebensdauern aller Adressen

Der Nachrichtenaustausch wird beendet, wenn die gültigen Lebensdauern aller der IA zugewiesenen Adressen ablaufen (siehe Abschnitt 10), zu diesem Zeitpunkt hat der Client mehrere alternative Aktionen zur Auswahl; zum Beispiel:

• Der Client kann wählen, eine Solicit-Nachricht zu verwenden, um einen neuen DHCP-Server zu lokalisieren und eine Request für die abgelaufene IA an den neuen Server zu senden.
• Der Client kann andere Adressen in anderen IAs haben, sodass der Client wählen kann, die abgelaufene IA zu verwerfen und die Adressen in den anderen IAs zu verwenden.

18.1.5. Erstellung und Übertragung von Information-request-Nachrichten (Creation and Transmission of Information-request Messages)

Der Client verwendet eine Information-request-Nachricht, um Konfigurationsinformationen zu erhalten, ohne dass ihm Adressen zugewiesen werden.

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

Der Client SOLLTE (SHOULD) eine Client Identifier-Option enthalten, um sich gegenüber dem Server zu identifizieren. Wenn der Client keine Client Identifier-Option enthält, kann der Server keine clientspezifischen Optionen an den Client zurückgeben, oder der Server kann wählen, überhaupt nicht auf die Nachricht zu antworten. Der Client MUSS (MUST) eine Client Identifier-Option enthalten, wenn die Information-Request-Nachricht authentifiziert wird.

Der Client MUSS (MUST) eine Option Request-Option (siehe Abschnitt 22.7) enthalten, um die Optionen anzugeben, die der Client empfangen möchte. Der Client KANN (MAY) Optionen mit Datenwerten als Hinweise an den Server über Parameterwerte enthalten, die der Client zurückgegeben haben möchte.

Die erste Information-request-Nachricht vom Client auf der Schnittstelle MUSS (MUST) um eine zufällige Zeitspanne zwischen 0 und INF_MAX_DELAY verzögert werden. Der Client überträgt die Nachricht gemäß Abschnitt 14 unter Verwendung der folgenden Parameter:

IRT   INF_TIMEOUT
MRT   INF_MAX_RT
MRC   0
MRD   0

18.1.6. Erstellung und Übertragung von Release-Nachrichten (Creation and Transmission of Release Messages)

Um eine oder mehrere Adressen freizugeben, sendet ein Client eine Release-Nachricht an den Server.

Der Client setzt das Feld "msg-type" auf RELEASE. Der Client generiert eine Transaktions-ID und platziert diesen Wert im Feld "transaction-id".

Der Client platziert die Kennung des Servers, der die Adresse(n) zugewiesen hat, in einer Server Identifier-Option.

Der Client MUSS (MUST) eine Client Identifier-Option enthalten, um sich gegenüber dem Server zu identifizieren. Der Client fügt Optionen, die die IAs für die Adressen enthalten, die er freigibt, in das Feld "options" ein. Die freizugebenden Adressen MÜSSEN (MUST) in den IAs enthalten sein. Alle Adressen für die IAs, die der Client weiterhin verwenden möchte, DÜRFEN NICHT (MUST NOT) zu den IAs hinzugefügt werden.

Der Client DARF NICHT (MUST NOT) eine der Adressen, die er freigibt, als Quelladresse in der Release-Nachricht oder in einer anschließend übertragenen Nachricht verwenden.

Da Release-Nachrichten verloren gehen können, sollte der Client das Release erneut übertragen, wenn keine Reply empfangen wird. Es gibt jedoch Szenarien, in denen der Client möglicherweise nicht auf das normale Wiederholungszeitlimit warten möchte, bevor er aufgibt (z.B. beim Herunterfahren). Implementierungen SOLLTEN (SHOULD) ein- oder mehrmals erneut übertragen, KÖNNEN (MAY) jedoch wählen, das Wiederholungsverfahren vorzeitig zu beenden.

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

IRT   REL_TIMEOUT
MRT   0
MRC   REL_MAX_RC
MRD   0

Der Client MUSS (MUST) aufhören, alle freizugebenden Adressen zu verwenden, sobald der Client den Release-Nachrichtenaustauschprozess beginnt. Wenn Adressen freigegeben werden, die Reply von einem DHCP-Server jedoch verloren geht, überträgt der Client die Release-Nachricht erneut, und der Server kann mit einer Reply antworten, die einen Status von NoBinding anzeigt. Daher behandelt der Client eine Reply-Nachricht mit einem Status von NoBinding in einem Release-Nachrichtenaustausch nicht als Fehleranzeige.

Beachten Sie, dass, wenn der Client die Adressen nicht freigibt, jede der IA zugewiesene Adresse vom Server zurückgefordert wird, wenn die gültige Lebensdauer dieser Adresse abläuft.

18.1.7. Erstellung und Übertragung von Decline-Nachrichten (Creation and Transmission of Decline Messages)

Wenn ein Client feststellt, dass eine oder mehrere ihm von einem Server zugewiesene Adressen bereits von einem anderen Knoten verwendet werden, sendet der Client eine Decline-Nachricht an den Server, um ihn darüber zu informieren, dass die Adresse verdächtig ist.

Der Client setzt das Feld "msg-type" auf DECLINE. Der Client generiert eine Transaktions-ID und platziert diesen Wert im Feld "transaction-id".

Der Client platziert die Kennung des Servers, der die Adresse(n) zugewiesen hat, in einer Server Identifier-Option.

Der Client MUSS (MUST) eine Client Identifier-Option enthalten, um sich gegenüber dem Server zu identifizieren. Der Client fügt Optionen, die die IAs für die Adressen enthalten, die er ablehnt, in das Feld "options" ein. Die abzulehnenden Adressen MÜSSEN (MUST) in den IAs enthalten sein. Alle Adressen für die IAs, die der Client weiterhin verwenden möchte, sollten nicht zu den IAs hinzugefügt werden.

Der Client DARF NICHT (MUST NOT) eine der Adressen, die er ablehnt, als Quelladresse in der Decline-Nachricht oder in einer anschließend übertragenen Nachricht verwenden.

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

IRT   DEC_TIMEOUT
MRT   0
MRC   DEC_MAX_RC
MRD   0

Wenn Adressen abgelehnt werden, die Reply von einem DHCP-Server jedoch verloren geht, überträgt der Client die Decline-Nachricht erneut, und der Server kann mit einer Reply antworten, die einen Status von NoBinding anzeigt. Daher behandelt der Client eine Reply-Nachricht mit einem Status von NoBinding in einem Decline-Nachrichtenaustausch nicht als Fehleranzeige.

18.1.8. Empfang von Reply-Nachrichten (Receipt of Reply Messages)

Beim Empfang einer gültigen Reply-Nachricht als Antwort auf eine Solicit- (mit einer Rapid Commit-Option), Request-, Confirm-, Renew-, Rebind- oder Information-request-Nachricht extrahiert der Client die im Reply enthaltenen Konfigurationsinformationen. Der Client KANN (MAY) wählen, jeden Statuscode oder jede Nachricht aus der Statuscode-Option in der Reply-Nachricht zu melden.

Der Client SOLLTE (SHOULD) eine Duplikat-Adresserkennung [17] für jede der Adressen in allen IAs durchführen, die er in der Reply-Nachricht erhält, bevor er diese Adresse für Datenverkehr verwendet. Wenn festgestellt wird, dass eine der Adressen auf dem Link verwendet wird, sendet der Client eine Decline-Nachricht an den Server, wie in Abschnitt 18.1.7 beschrieben.

Wenn die Reply als Antwort auf eine Solicit- (mit einer Rapid Commit-Option), Request-, Renew- oder Rebind-Nachricht empfangen wurde, aktualisiert der Client die Informationen, die er über IAs aus den IA-Optionen in der Reply-Nachricht aufgezeichnet hat:

• T1- und T2-Zeiten aufzeichnen.
• Alle neuen Adressen in der IA-Option zur IA hinzufügen, wie vom Client aufgezeichnet.
• Lebensdauern für alle Adressen in der IA-Option aktualisieren, die der Client bereits in der IA aufgezeichnet hat.
• Alle Adressen aus der IA verwerfen, wie vom Client aufgezeichnet, die in der IA Address-Option eine gültige Lebensdauer von 0 haben.
• Alle Informationen über Adressen unverändert lassen, die der Client in der IA aufgezeichnet hat, die jedoch nicht in der IA vom Server enthalten waren.

Die Verwaltung der spezifischen Konfigurationsinformationen wird in der Definition jeder Option in Abschnitt 22 detailliert beschrieben.

Wenn der Client eine Reply-Nachricht mit einem Status Code erhält, der UnspecFail enthält, gibt der Server an, dass er die Nachricht aufgrund einer nicht spezifizierten Fehlerbedingung nicht verarbeiten konnte. Wenn der Client die ursprüngliche Nachricht an denselben Server erneut überträgt, um die gewünschte Operation zu wiederholen, MUSS (MUST) der Client die Rate begrenzen, mit der er die Nachricht erneut überträgt, und die Dauer der Zeit begrenzen, während der er die Nachricht erneut überträgt.

Wenn der Client eine Reply-Nachricht mit einer Status Code-Option mit dem Wert UseMulticast erhält, zeichnet der Client den Empfang der Nachricht auf und sendet nachfolgende Nachrichten an den Server über die Schnittstelle, auf der die Nachricht empfangen wurde, unter Verwendung von Multicast. Der Client sendet die ursprüngliche Nachricht unter Verwendung von Multicast erneut.

Wenn der Client einen NotOnLink-Status vom Server als Antwort auf eine Confirm-Nachricht erhält, führt der Client eine DHCP-Server-Anforderung durch, wie in Abschnitt 17 beschrieben, und eine vom Client initiierte Konfiguration, wie in Abschnitt 18 beschrieben. Wenn der Client Reply-Nachrichten erhält, die keinen NotOnLink-Status anzeigen, kann der Client die Adressen in der IA verwenden und alle Nachrichten ignorieren, die einen NotOnLink-Status anzeigen.

Wenn der Client einen NotOnLink-Status vom Server als Antwort auf eine Request erhält, kann der Client entweder die Request ohne Angabe von Adressen erneut ausgeben oder den DHCP-Server-Erkennungsprozess neu starten (siehe Abschnitt 17).

Der Client untersucht den Statuscode in jeder IA einzeln. Wenn der Statuscode NoAddrsAvail ist, hat der Client keine verwendbaren Adressen in der IA erhalten und kann wählen, zu versuchen, Adressen für die IA von einem anderen Server zu erhalten. Der Client verwendet Adressen und andere Informationen von allen IAs, die keine Status Code-Option mit dem Code NoAddrsAvail enthalten. Wenn der Client in keiner der IAs Adressen erhält, kann er entweder einen anderen Server ausprobieren (möglicherweise den DHCP-Server-Erkennungsprozess neu starten) oder die Information-request-Nachricht verwenden, um nur andere Konfigurationsinformationen zu erhalten.

Wenn der Client eine Reply-Nachricht als Antwort auf eine Renew- oder Rebind-Nachricht erhält, untersucht der Client jede IA unabhängig. Für jede IA in der ursprünglichen Renew- oder Rebind-Nachricht:

• sendet der Client eine Request-Nachricht, wenn die IA eine Status Code-Option mit dem Status NoBinding enthielt (und sendet keine zusätzlichen Renew/Rebind-Nachrichten)
• sendet der Client eine Renew/Rebind, wenn die IA nicht in der Reply-Nachricht ist
• akzeptiert der Client andernfalls die Informationen in der IA

Wenn der Client eine gültige Reply-Nachricht als Antwort auf eine Release-Nachricht erhält, betrachtet der Client das Release-Ereignis als abgeschlossen, unabhängig von den vom Server zurückgegebenen Status Code-Optionen.

Wenn der Client eine gültige Reply-Nachricht als Antwort auf eine Decline-Nachricht erhält, betrachtet der Client das Decline-Ereignis als abgeschlossen, unabhängig von den vom Server zurückgegebenen Status Code-Optionen.

18.2. Server-Verhalten (Server Behavior)

Für diese Diskussion wird angenommen, dass der Server auf implementierungsspezifische Weise mit für Clients interessanter Konfiguration konfiguriert wurde.

In den meisten Fällen sendet der Server eine Reply als Antwort auf eine Client-Nachricht. Diese Reply-Nachricht MUSS (MUST) immer die Server Identifier-Option mit der DUID des Servers und die Client Identifier-Option aus der Client-Nachricht enthalten, falls eine vorhanden war.

In den meisten Reply-Nachrichten enthält der Server Optionen mit Konfigurationsinformationen für den Client. Der Server muss sich der Empfehlungen zu Paketgrößen und der Verwendung von Fragmentierung in Abschnitt 5 von RFC 2460 bewusst sein. Wenn der Client eine Option Request-Option in seiner Nachricht enthielt, enthält der Server Optionen in der Reply-Nachricht mit Konfigurationsparametern für alle in der Option Request-Option identifizierten Optionen, die der Server konfiguriert wurde, um an den Client zurückzugeben. Der Server KANN (MAY) zusätzliche Optionen an den Client zurückgeben, wenn er so konfiguriert wurde.

18.2.1. Empfang von Request-Nachrichten (Receipt of Request Messages)

Wenn der Server eine Request-Nachricht per Unicast von einem Client erhält, an den der Server keine Unicast-Option gesendet hat, verwirft der Server die Request-Nachricht und antwortet mit einer Reply-Nachricht, die eine Status Code-Option mit dem Wert UseMulticast, eine Server Identifier-Option mit der DUID des Servers, die Client Identifier-Option aus der Client-Nachricht und keine anderen Optionen enthält.

Wenn der Server eine gültige Request-Nachricht erhält, erstellt der Server die Bindungen für diesen Client gemäß der Richtlinie und den Konfigurationsinformationen des Servers und zeichnet die IAs und andere vom Client angeforderte Informationen auf.

Der Server erstellt eine Reply-Nachricht, indem er das Feld "msg-type" auf REPLY setzt und die Transaktions-ID aus der Request-Nachricht in das transaction-id-Feld kopiert.

Der Server MUSS (MUST) eine Server Identifier-Option mit der DUID des Servers und die Client Identifier-Option aus der Request-Nachricht in die Reply-Nachricht aufnehmen.

Wenn der Server feststellt, dass das Präfix einer oder mehrerer IP-Adressen in einer IA in der Nachricht vom Client nicht für den Link geeignet ist, mit dem der Client verbunden ist, MUSS (MUST) der Server die IA mit einer Status Code-Option mit dem Wert NotOnLink an den Client zurückgeben.

Wenn der Server einer IA in der Nachricht vom Client keine Adressen zuweisen kann, MUSS (MUST) der Server die IA in der Reply-Nachricht ohne Adressen in der IA und eine Status Code-Option in der IA mit dem Statuscode NoAddrsAvail enthalten.

Für alle IAs, denen der Server Adressen zuweisen kann, enthält der Server die IA mit Adressen und anderen Konfigurationsparametern und zeichnet die IA als neue Client-Bindung auf.

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

Der Server enthält andere Optionen mit Konfigurationsinformationen, die an den Client zurückgegeben werden sollen, wie in Abschnitt 18.2 beschrieben.

Wenn der Server feststellt, dass der Client eine IA in der Request-Nachricht enthalten hat, für die der Server bereits eine Bindung hat, die die IA mit dem Client verknüpft, hat der Client eine Request-Nachricht erneut gesendet, für die er keine Reply-Nachricht erhalten hat. Der Server sendet entweder eine zuvor zwischengespeicherte Reply-Nachricht erneut oder sendet eine neue Reply-Nachricht.

18.2.2. Empfang von Confirm-Nachrichten (Receipt of Confirm Messages)

Wenn der Server eine Confirm-Nachricht erhält, bestimmt der Server, ob die Adressen in der Confirm-Nachricht für den Link geeignet sind, mit dem der Client verbunden ist. Wenn alle Adressen in der Confirm-Nachricht diesen Test bestehen, gibt der Server einen Status von Success zurück. Wenn eine der Adressen diesen Test nicht besteht, gibt der Server einen Status von NotOnLink zurück. Wenn der Server diesen Test nicht durchführen kann (z.B. hat der Server keine Informationen über Präfixe auf dem Link, mit dem der Client verbunden ist) oder wenn in keiner der vom Client gesendeten IAs Adressen vorhanden waren, DARF (MUST NOT) der Server keine Antwort an den Client senden.

Der Server ignoriert die Felder T1 und T2 in den IA-Optionen und die Felder preferred-lifetime und valid-lifetime in den IA Address-Optionen.

Der Server erstellt eine Reply-Nachricht, indem er das Feld "msg-type" auf REPLY setzt und die Transaktions-ID aus der Confirm-Nachricht in das transaction-id-Feld kopiert.

Der Server MUSS (MUST) eine Server Identifier-Option mit der DUID des Servers und die Client Identifier-Option aus der Confirm-Nachricht in die Reply-Nachricht aufnehmen. Der Server enthält eine Status Code-Option, die den Status der Confirm-Nachricht angibt.

18.2.3. Empfang von Renew-Nachrichten (Receipt of Renew Messages)

Wenn der Server eine Renew-Nachricht per Unicast von einem Client erhält, an den der Server keine Unicast-Option gesendet hat, verwirft der Server die Renew-Nachricht und antwortet mit einer Reply-Nachricht, die eine Status Code-Option mit dem Wert UseMulticast, eine Server Identifier-Option mit der DUID des Servers, die Client Identifier-Option aus der Client-Nachricht und keine anderen Optionen enthält.

Wenn der Server eine Renew-Nachricht erhält, die eine IA-Option von einem Client enthält, lokalisiert er die Bindung des Clients und überprüft, ob die Informationen in der IA vom Client mit den für diesen Client gespeicherten Informationen übereinstimmen.

Wenn der Server keinen Client-Eintrag für die IA finden kann, gibt der Server die IA ohne Adressen mit einer auf NoBinding gesetzten Status Code-Option in der Reply-Nachricht zurück.

Wenn der Server feststellt, dass eine der Adressen nicht für den Link geeignet ist, mit dem der Client verbunden ist, gibt der Server die Adresse mit Lebensdauern von 0 an den Client zurück.

Wenn der Server die Adressen in der IA für den Client findet, sendet der Server die IA mit neuen Lebensdauern und T1/T2-Zeiten an den Client zurück. Der Server kann wählen, die Liste der Adressen und die Lebensdauern der Adressen in IAs zu ändern, die an den Client zurückgegeben werden.

Der Server erstellt eine Reply-Nachricht, indem er das Feld "msg-type" auf REPLY setzt und die Transaktions-ID aus der Renew-Nachricht in das transaction-id-Feld kopiert.

Der Server MUSS (MUST) eine Server Identifier-Option mit der DUID des Servers und die Client Identifier-Option aus der Renew-Nachricht in die Reply-Nachricht aufnehmen.

Der Server enthält andere Optionen mit Konfigurationsinformationen, die an den Client zurückgegeben werden sollen, wie in Abschnitt 18.2 beschrieben.

18.2.4. Empfang von Rebind-Nachrichten (Receipt of Rebind Messages)

Wenn der Server eine Rebind-Nachricht erhält, die eine IA-Option von einem Client enthält, lokalisiert er die Bindung des Clients und überprüft, ob die Informationen in der IA vom Client mit den für diesen Client gespeicherten Informationen übereinstimmen.

Wenn der Server keinen Client-Eintrag für die IA finden kann und der Server feststellt, dass die Adressen in der IA gemäß den expliziten Konfigurationsinformationen des Servers nicht für den Link geeignet sind, mit dem die Schnittstelle des Clients verbunden ist, KANN (MAY) der Server eine Reply-Nachricht an den Client senden, die die IA des Clients mit den auf Null gesetzten Lebensdauern für die Adressen in der IA enthält. Diese Reply stellt eine explizite Benachrichtigung an den Client dar, dass die Adressen in der IA nicht mehr gültig sind. In dieser Situation verwirft der Server die Rebind-Nachricht stillschweigend, wenn er keine Reply-Nachricht sendet.

Wenn der Server feststellt, dass eine der Adressen nicht mehr für den Link geeignet ist, mit dem der Client verbunden ist, gibt der Server die Adresse mit Lebensdauern von 0 an den Client zurück.

Wenn der Server die Adressen in der IA für den Client findet, SOLLTE (SHOULD) der Server die IA mit neuen Lebensdauern und T1/T2-Zeiten an den Client zurücksenden.

Der Server erstellt eine Reply-Nachricht, indem er das Feld "msg-type" auf REPLY setzt und die Transaktions-ID aus der Rebind-Nachricht in das transaction-id-Feld kopiert.

Der Server MUSS (MUST) eine Server Identifier-Option mit der DUID des Servers und die Client Identifier-Option aus der Rebind-Nachricht in die Reply-Nachricht aufnehmen.

Der Server enthält andere Optionen mit Konfigurationsinformationen, die an den Client zurückgegeben werden sollen, wie in Abschnitt 18.2 beschrieben.

18.2.5. Empfang von Information-request-Nachrichten (Receipt of Information-request Messages)

Wenn der Server eine Information-request-Nachricht erhält, fordert der Client Konfigurationsinformationen an, die nicht die Zuweisung von Adressen umfassen. Der Server bestimmt alle für den Client geeigneten Konfigurationsparameter basierend auf den dem Server bekannten Server-Konfigurationsrichtlinien.

Der Server erstellt eine Reply-Nachricht, indem er das Feld "msg-type" auf REPLY setzt und die Transaktions-ID aus der Information-request-Nachricht in das transaction-id-Feld kopiert.

Der Server MUSS (MUST) eine Server Identifier-Option mit der DUID des Servers in die Reply-Nachricht aufnehmen. Wenn der Client eine Client Identification-Option in die Information-request-Nachricht aufgenommen hat, kopiert der Server diese Option in die Reply-Nachricht.

Der Server enthält Optionen mit Konfigurationsinformationen, die an den Client zurückgegeben werden sollen, wie in Abschnitt 18.2 beschrieben.

Wenn die vom Client empfangene Information-request-Nachricht keine Client Identifier-Option enthielt, SOLLTE (SHOULD) der Server mit einer Reply-Nachricht antworten, die alle Konfigurationsparameter enthält, die nicht durch die Identität des Clients bestimmt werden. Wenn der Server wählt, nicht zu antworten, kann der Client die Information-request-Nachricht auf unbestimmte Zeit weiter übertragen.

18.2.6. Empfang von Release-Nachrichten (Receipt of Release Messages)

Wenn der Server eine Release-Nachricht per Unicast von einem Client erhält, an den der Server keine Unicast-Option gesendet hat, verwirft der Server die Release-Nachricht und antwortet mit einer Reply-Nachricht, die eine Status Code-Option mit dem Wert UseMulticast, eine Server Identifier-Option mit der DUID des Servers, die Client Identifier-Option aus der Client-Nachricht und keine anderen Optionen enthält.

Beim Empfang einer gültigen Release-Nachricht untersucht der Server die IAs und die Adressen in den IAs auf Gültigkeit. Wenn die IAs in der Nachricht in einer Bindung für den Client sind und die Adressen in den IAs vom Server diesen IAs zugewiesen wurden, löscht der Server die Adressen aus den IAs und macht die Adressen für die Zuweisung an andere Clients verfügbar. Der Server ignoriert Adressen, die nicht der IA zugewiesen sind, obwohl er wählen kann, einen Fehler zu protokollieren.

Nachdem alle Adressen verarbeitet wurden, generiert der Server eine Reply-Nachricht und enthält eine Status Code-Option mit dem Wert Success, eine Server Identifier-Option mit der DUID des Servers und eine Client Identifier-Option mit der DUID des Clients. Für jede IA in der Release-Nachricht, für die der Server keine Bindungsinformationen hat, fügt der Server eine IA-Option unter Verwendung der IAID aus der Release-Nachricht hinzu und enthält eine Status Code-Option mit dem Wert NoBinding in der IA-Option. Keine anderen Optionen sind in der IA-Option enthalten.

Ein Server kann wählen, einen Datensatz zugewiesener Adressen und IAs nach Ablauf der Lebensdauern der Adressen beizubehalten, um dem Server zu ermöglichen, die zuvor zugewiesenen Adressen einem Client neu zuzuweisen.

18.2.7. Empfang von Decline-Nachrichten (Receipt of Decline Messages)

Wenn der Server eine Decline-Nachricht per Unicast von einem Client erhält, an den der Server keine Unicast-Option gesendet hat, verwirft der Server die Decline-Nachricht und antwortet mit einer Reply-Nachricht, die eine Status Code-Option mit dem Wert UseMulticast, eine Server Identifier-Option mit der DUID des Servers, die Client Identifier-Option aus der Client-Nachricht und keine anderen Optionen enthält.

Beim Empfang einer gültigen Decline-Nachricht untersucht der Server die IAs und die Adressen in den IAs auf Gültigkeit. Wenn die IAs in der Nachricht in einer Bindung für den Client sind und die Adressen in den IAs vom Server diesen IAs zugewiesen wurden, löscht der Server die Adressen aus den IAs. Der Server ignoriert Adressen, die nicht der IA zugewiesen sind (obwohl er wählen kann, einen Fehler zu protokollieren, wenn er eine solche Adresse findet).

Der Client hat festgestellt, dass alle Adressen in den Decline-Nachrichten bereits auf seinem Link verwendet werden. Daher SOLLTE (SHOULD) der Server die vom Client abgelehnten Adressen markieren, damit diese Adressen nicht anderen Clients zugewiesen werden, und KANN (MAY) wählen, eine Benachrichtigung zu machen, dass Adressen abgelehnt wurden. Die lokale Richtlinie auf dem Server bestimmt, wann die in einer Decline-Nachricht identifizierten Adressen für die Zuweisung verfügbar gemacht werden können.

Nachdem alle Adressen verarbeitet wurden, generiert der Server eine Reply-Nachricht und enthält eine Status Code-Option mit dem Wert Success, eine Server Identifier-Option mit der DUID des Servers und eine Client Identifier-Option mit der DUID des Clients. Für jede IA in der Decline-Nachricht, für die der Server keine Bindungsinformationen hat, fügt der Server eine IA-Option unter Verwendung der IAID aus der Release-Nachricht hinzu und enthält eine Status Code-Option mit dem Wert NoBinding in der IA-Option. Keine anderen Optionen sind in der IA-Option enthalten.

18.2.8. Übertragung von Reply-Nachrichten (Transmission of Reply Messages)

Wenn die ursprüngliche Nachricht direkt vom Server empfangen wurde, sendet der Server die Reply-Nachricht per Unicast direkt an den Client unter Verwendung der Adresse im Quelladressfeld aus dem IP-Datagramm, in dem die ursprüngliche Nachricht empfangen wurde. Die Reply-Nachricht MUSS (MUST) über die Schnittstelle per Unicast gesendet werden, auf der die ursprüngliche Nachricht empfangen wurde.

Wenn die ursprüngliche Nachricht in einer Relay-forward-Nachricht empfangen wurde, erstellt der Server eine Relay-reply-Nachricht mit der Reply-Nachricht in der Nutzlast einer Relay Message-Option (siehe Abschnitt 22.10). 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 per Unicast direkt an den Relay-Agenten unter Verwendung der Adresse im Quelladressfeld aus dem IP-Datagramm, in dem die Relay-forward-Nachricht empfangen wurde.