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

Vom Client initiierter Konfigurationsaustausch

Ein Client initiiert einen Nachrichtenaustausch mit einem oder mehreren Servern, um Konfigurationsinformationen von Interesse zu erwerben oder zu aktualisieren. Der Client kann den Konfigurationsaustausch als Teil des Konfigurationsprozesses des Betriebssystems initiieren, wenn er dazu von der Anwendungsschicht aufgefordert wird, wenn er von der zustandslosen Adressautokonfiguration verlangt wird oder wie erforderlich, um die Lebensdauer einer Adresse zu verlängern (Renew- und Rebind-Nachrichten).

18.1. Client-Verhalten

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 an einen neuen Link gewechselt ist. Er verwendet Information-Request-Nachrichten, wenn er Konfigurationsinformationen, aber keine Adressen benötigt.

Wenn der Client eine Quelladresse von ausreichendem Geltungsbereich besitzt, die vom Server als Rückantwortadresse verwendet werden kann, und der Client eine Server Unicast-Option (Abschnitt 22.12) vom Server empfangen hat, SOLLTE der Client alle Request-, Renew-, Release- und Decline-Nachrichten per Unicast an den Server senden.

DISKUSSION:

  Die Verwendung von Unicast kann Verzögerungen durch das Weiterleiten
  von Nachrichten durch Relay-Agenten vermeiden sowie Overhead und
  doppelte Antworten von Servern aufgrund der Zustellung von
  Client-Nachrichten an mehrere Server vermeiden.  Das Verlangen, dass
  der Client alle DHCP-Nachrichten über einen Relay-Agenten weiterleitet,
  ermöglicht das Einschließen von Relay-Agent-Optionen in alle vom
  Client gesendeten Nachrichten.  Der Server sollte die Verwendung von
  Unicast nur dann ermöglichen, wenn Relay-Agent-Optionen nicht verwendet
  werden.

18.1.1. Erzeugung und Übertragung von Request-Nachrichten

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

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

Der Client platziert den Bezeichner des Zielservers in eine Server Identifier-Option.

Der Client MUSS eine Client Identifier-Option aufnehmen, 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 den Server auffordert, ihm einige Netzwerkadressen zuzuweisen).

Der Client MUSS eine Option Request-Option (siehe Abschnitt 22.7) aufnehmen, um die Optionen anzugeben, an deren Erhalt der Client interessiert ist. Der Client KANN Optionen mit Datenwerten als Hinweis für den Server über Parameterwerte aufnehmen, die er zurückgegeben haben möchte.

Der Client nimmt eine Reconfigure Accept-Option (siehe Abschnitt 22.20) auf, die angibt, ob der Client bereit ist, Reconfigure-Nachrichten vom Server zu akzeptieren.

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 Maßnahme basierend auf der lokalen Richtlinie des Clients. Beispiele für Maßnahmen, die der Client ergreifen könnte, umfassen:

Auswahl eines anderen Servers aus einer Liste dem Client bekannter Server; beispielsweise Server, die mit einer Advertise-Nachricht geantwortet haben.
Initiierung des in Abschnitt 17 beschriebenen Server-Suchprozesses.
Abbruch des Konfigurationsprozesses und Meldung des Fehlers.

18.1.2. Erzeugung und Übertragung von Confirm-Nachrichten

Immer wenn ein Client möglicherweise an einen neuen Link gewechselt ist, sind die Präfixe der Adressen, die den Schnittstellen an diesem Link zugewiesen sind, möglicherweise nicht mehr für den Link geeignet, an den der Client angehängt ist. Beispiele für Zeitpunkte, zu denen ein Client möglicherweise an einen neuen Link gewechselt ist, umfassen:

o Der Client startet neu.

o Der Client wird physisch mit einer kabelgebundenen Verbindung verbunden.

o Der Client kehrt aus dem Ruhezustand zurück.

o Der Client wechselt bei Verwendung einer drahtlosen Technologie den Zugriffspunkt.

In jeder Situation, in der ein Client möglicherweise an einen neuen Link gewechselt ist, MUSS der Client einen Confirm/Reply-Nachrichtenaustausch initiieren. Der Client nimmt alle IAs auf, die der Schnittstelle zugewiesen sind, die möglicherweise an einen neuen Link gewechselt ist, zusammen mit den diesen IAs zugeordneten Adressen, in seine Confirm-Nachricht auf. Alle antwortenden Server werden angeben, ob diese Adressen für den Link geeignet sind, an den der Client angehängt ist, mit dem Status in der Reply-Nachricht, die sie an den Client zurückgeben.

Der Client setzt das Feld "msg-type" auf CONFIRM. 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, die der Schnittstelle zugewiesen sind, für die die Confirm-Nachricht gesendet wird. Die IA-Optionen umfassen alle Adressen, die der Client derzeit mit diesen IAs verknüpft hat. Der Client SOLLTE die Felder T1 und T2 in allen IA_NA-Optionen sowie die Felder preferred-lifetime und valid-lifetime in den IA Address-Optionen auf 0 setzen, da der Server diese Felder ignorieren wird.

Die erste Confirm-Nachricht des Clients auf der Schnittstelle MUSS 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 empfängt, bevor der Nachrichtenübertragungsprozess wie in Abschnitt 14 beschrieben endet, SOLLTE der Client weiterhin alle IP-Adressen verwenden, wobei er die zuletzt bekannten Lebensdauern für diese Adressen verwendet, und SOLLTE weiterhin alle anderen zuvor erhaltenen Konfigurationsparameter verwenden.

18.1.3. Erzeugung und Übertragung von Renew-Nachrichten

Um die gültige und bevorzugte Lebensdauer für die Adressen, die mit einer IA verknüpft sind, 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 nimmt IA Address-Optionen in der IA-Option für die Adressen auf, die mit der IA verknüpft sind. Der Server bestimmt neue Lebensdauern für die Adressen in der IA gemäß der administrativen Konfiguration des Servers. Der Server kann der IA auch neue Adressen hinzufügen. Der Server kann Adressen aus der IA entfernen, indem er die bevorzugte und gültige Lebensdauer jener Adressen auf null setzt.

Der Server steuert den Zeitpunkt, zu dem der Client den Server kontaktiert, um die Lebensdauern zugewiesener Adressen zu verlängern, über die einer IA zugewiesenen Parameter T1 und T2.

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 nimmt eine IA-Option mit allen derzeit der IA zugewiesenen Adressen in seine Renew-Nachricht auf.

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

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

Der Client platziert den Bezeichner des Zielservers in eine Server Identifier-Option.

Der Client MUSS eine Client Identifier-Option aufnehmen, 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 die Liste der Adressen, die der Client derzeit mit den IAs verknüpft hat, in der Renew-Nachricht aufnehmen.

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 endet, wenn die Zeit T2 erreicht ist (siehe Abschnitt 18.1.4), zu welchem Zeitpunkt der Client einen Rebind-Nachrichtenaustausch beginnt.

18.1.4. Erzeugung und Übertragung von Rebind-Nachrichten

Zum Zeitpunkt T2 für eine IA (der nur erreicht wird, wenn der Server, an den die zum Zeitpunkt T1 gesendete Renew-Nachricht gerichtet war, nicht geantwortet hat) initiiert der Client einen Rebind/Reply-Nachrichtenaustausch mit einem beliebigen verfügbaren Server. Der Client nimmt eine IA-Option mit allen derzeit der IA zugewiesenen Adressen in seine Rebind-Nachricht auf.

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

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 die gültigen Lebensdauern aller Adressen
        abgelaufen sind

Der Nachrichtenaustausch endet, wenn die gültigen Lebensdauern aller der IA zugewiesenen Adressen abgelaufen sind (siehe Abschnitt 10), zu welchem Zeitpunkt der Client mehrere alternative Handlungsmöglichkeiten zur Auswahl hat; beispielsweise:

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. Erzeugung und Übertragung von Information-request-Nachrichten

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 erzeugt eine Transaktions-ID und fügt diesen Wert in das Feld "transaction-id" ein.

Der Client SOLLTE eine Client Identifier-Option aufnehmen, um sich gegenüber dem Server zu identifizieren. Wenn der Client keine Client Identifier-Option aufnimmt, wird der Server keine client-spezifischen Optionen an den Client zurückgeben können, oder der Server kann wählen, gar nicht auf die Nachricht zu antworten. Der Client MUSS eine Client Identifier-Option aufnehmen, wenn die Information-request-Nachricht authentifiziert wird.

Die erste Information-request-Nachricht des Clients auf der Schnittstelle MUSS 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. Erzeugung und Übertragung von Release-Nachrichten

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 erzeugt eine Transaktions-ID und platziert diesen Wert in das Feld "transaction-id".

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

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

Der Client DARF KEINE der freizugebenden Adressen als Quelladresse in der Release-Nachricht oder in einer nachfolgend übertragenen Nachricht verwenden.

Da Release-Nachrichten verloren gehen können, SOLLTE der Client die Release erneut übertragen, wenn keine Reply empfangen wird. Es gibt jedoch Szenarien, in denen der Client möglicherweise nicht warten möchte, bis das normale Wiederholungs-Timeout abläuft, bevor er aufgibt (z. B. bei Stromabschaltung). Implementierungen SOLLTEN einmal oder mehrmals wiederholen, können aber wählen, das Wiederholungsverfahren früh abzubrechen.

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 die Verwendung aller freizugebenden Adressen sofort einstellen, sobald er den Release-Nachrichtenaustauschprozess beginnt. Wenn Adressen freigegeben werden, aber die Reply eines DHCP-Servers verloren geht, wird der Client die Release-Nachricht erneut übertragen, und der Server kann mit einer Reply antworten, die einen Status NoBinding angibt. Daher behandelt der Client eine Reply-Nachricht mit Status NoBinding in einem Release-Nachrichtenaustausch nicht, als ob sie einen Fehler anzeigt.

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 jener Adresse abläuft.

18.1.7. Erzeugung und Übertragung von Decline-Nachrichten

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 erzeugt eine Transaktions-ID und platziert diesen Wert in das Feld "transaction-id".

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

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

Der Client DARF KEINE der abzulehnenden Adressen als Quelladresse in der Decline-Nachricht oder in einer nachfolgend ü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, aber die Reply eines DHCP-Servers verloren geht, wird der Client die Decline-Nachricht erneut übertragen, und der Server kann mit einer Reply antworten, die einen Status NoBinding angibt. Daher behandelt der Client eine Reply-Nachricht mit Status NoBinding in einem Decline-Nachrichtenaustausch nicht, als ob sie einen Fehler anzeigt.

18.1.8. Empfang von Reply-Nachrichten

Nach Empfang einer gültigen Reply-Nachricht als Antwort auf eine Solicit- (mit einer Rapid Commit-Option), Request-, Confirm-, Renew-, Rebind- oder Information-request-Nachricht entnimmt der Client die Konfigurationsinformationen, die in der Reply enthalten sind.

Der Client SOLLTE auf jeder der Adressen in allen IAs, die er in der Reply-Nachricht empfängt, bevor er diese Adresse für den Verkehr verwendet, eine Duplikaterkennung [17] durchführen. Wenn festgestellt wird, dass eine der Adressen auf dem Link bereits 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:

Erfassung der Zeiten T1 und T2.
Hinzufügen aller neuen Adressen in der IA-Option zu der vom Client erfassten IA.
Aktualisierung der Lebensdauern für alle Adressen in der IA-Option, die der Client bereits in der IA erfasst hat.
Verwerfen aller Adressen aus der IA, wie vom Client erfasst, die in der IA Address-Option eine gültige Lebensdauer von 0 haben.
Unverändertlassen aller Informationen über Adressen, die der Client in der IA erfasst hat, die aber nicht in der IA vom Server enthalten waren.

Die Verwaltung der spezifischen Konfigurationsinformationen ist in der Definition jeder Option in Abschnitt 22 im Detail dargelegt.

Wenn der Client eine Reply-Nachricht mit einem Statuscode mit UnspecFail empfängt, zeigt der Server an, dass er nicht in der Lage war, die Nachricht aufgrund einer nicht näher bezeichneten Fehlerbedingung zu verarbeiten. Wenn der Client die ursprüngliche Nachricht an denselben Server überträgt, um den gewünschten Vorgang zu wiederholen, MUSS der Client die Rate begrenzen, mit der er die Nachricht wiederholt, und die Dauer der Zeit begrenzen, während der er die Nachricht wiederholt.

Wenn der Client eine Reply-Nachricht mit einer Status Code-Option mit dem Wert UseMulticast empfängt, 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 erneut unter Verwendung von Multicast.

Wenn der Client einen NotOnLink-Status vom Server als Antwort auf eine Confirm-Nachricht empfängt, führt der Client eine DHCP-Serversuche durch, wie in Abschnitt 17 beschrieben, und eine vom Client initiierte Konfiguration, wie in Abschnitt 18 beschrieben. Wenn der Client irgendeine Reply-Nachricht empfängt, die keinen NotOnLink-Status angibt, 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 empfängt, kann der Client entweder die Request ohne Angabe von Adressen erneut ausgeben oder den DHCP-Server-Suchprozess 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 aus allen IAs, die keine Status Code-Option mit dem Code NoAddrsAvail enthalten. Wenn der Client keine Adressen in einer der IAs erhält, kann er entweder einen anderen Server versuchen (vielleicht durch Neustart des DHCP-Server-Suchprozesses) oder die Information-request- Nachricht verwenden, um nur andere Konfigurationsinformationen zu erhalten.

Wenn der Client eine gültige Reply-Nachricht als Antwort auf eine Renew- oder Rebind-Nachricht empfängt, 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 weiteren Renew/Rebind-Nachrichten)
sendet der Client eine Renew/Rebind, wenn die IA nicht in der Reply-Nachricht enthalten ist
andernfalls akzeptiert er die Informationen in der IA

Wenn der Client eine gültige Reply-Nachricht als Antwort auf eine Release-Nachricht empfängt, 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 empfängt, betrachtet der Client das Decline-Ereignis als abgeschlossen, unabhängig von den vom Server zurückgegebenen Status Code-Optionen.

18.2. Server-Verhalten

Für diese Erörterung wird angenommen, dass der Server in einer implementationsspezifischen Weise mit für Clients interessanten Konfigurationen konfiguriert wurde.

In den meisten Fällen wird der Server als Antwort auf eine Client-Nachricht eine Reply senden. Diese Reply-Nachricht MUSS immer die Server Identifier-Option enthalten, die den DUID des Servers enthält, und die Client Identifier-Option aus der Client-Nachricht, falls eine vorhanden war.

In den meisten Reply-Nachrichten nimmt der Server Optionen mit Konfigurationsinformationen für den Client auf. 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 aufgenommen hat, nimmt der Server in der Reply-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.

18.2.1. Empfang von Request-Nachrichten

Wenn der Server eine Request-Nachricht per Unicast von einem Client empfängt, 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 dem DUID des Servers, die Client Identifier-Option aus der Client-Nachricht und keine weiteren Optionen enthält.

Wenn der Server eine gültige Request-Nachricht empfängt, erzeugt der Server die Bindings für diesen Client gemäß der Richtlinie und Konfiguration des Servers und zeichnet die IAs und andere vom Client angeforderte Informationen auf.

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

Der Server MUSS eine Server Identifier-Option mit dem 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 für den Link, an den der Client verbunden ist, nicht geeignet ist, MUSS der Server die IA an den Client mit einer Status Code-Option mit dem Wert NotOnLink zurückgeben.

Wenn der Server keine Adressen an eine IA in der Nachricht vom Client zuweisen kann, MUSS 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 aufnehmen.

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

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

Der Server nimmt andere Optionen mit Konfigurationsinformationen auf, 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 aufgenommen hat, für die der Server bereits eine Binding besitzt, 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

Wenn der Server eine Confirm-Nachricht empfängt, ermittelt der Server, ob die Adressen in der Confirm-Nachricht für den Link geeignet sind, an den der Client angehängt ist. Wenn alle Adressen in der Confirm-Nachricht diesen Test bestehen, gibt der Server einen Status Success zurück. Wenn eine der Adressen diesen Test nicht besteht, gibt der Server einen Status NotOnLink zurück. Wenn der Server nicht in der Lage ist, diesen Test durchzuführen (beispielsweise hat der Server keine Informationen über Präfixe auf dem Link, an den der Client verbunden ist), oder wenn keine Adressen in einer der vom Client gesendeten IAs waren, DARF der Server KEINE Antwort an den Client senden.

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

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

Der Server MUSS eine Server Identifier-Option mit dem DUID des Servers und die Client Identifier-Option aus der Confirm-Nachricht in die Reply-Nachricht aufnehmen. Der Server nimmt eine Status Code-Option auf, die den Status der Confirm-Nachricht angibt.

18.2.3. Empfang von Renew-Nachrichten

Wenn der Server eine Renew-Nachricht per Unicast von einem Client empfängt, 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 dem DUID des Servers, die Client Identifier-Option aus der Client-Nachricht und keine weiteren Optionen enthält.

Wenn der Server eine Renew-Nachricht empfängt, die eine IA-Option von einem Client enthält, lokalisiert er die Binding des Clients und überprüft, dass 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 Status Code-Option auf NoBinding gesetzt in der Reply-Nachricht zurück.

Wenn der Server feststellt, dass eine der Adressen für den Link, an den der Client angehängt ist, nicht geeignet ist, gibt der Server die Adresse an den Client mit Lebensdauern von 0 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 die Liste der Adressen und die Lebensdauern von Adressen in IAs, die an den Client zurückgegeben werden, ändern.

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

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

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

18.2.4. Empfang von Rebind-Nachrichten

Wenn der Server eine Rebind-Nachricht empfängt, die eine IA-Option von einem Client enthält, lokalisiert er die Binding des Clients und überprüft, dass 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 ermittelt, dass die Adressen in der IA gemäß den expliziten Konfigurationsinformationen des Servers für den Link, an den die Schnittstelle des Clients angehängt ist, nicht geeignet sind, KANN der Server eine Reply-Nachricht an den Client senden, die die IA des Clients enthält, wobei die Lebensdauern für die Adressen in der IA auf null gesetzt sind. Diese Reply stellt eine explizite Benachrichtigung an den Client dar, dass die Adressen in der IA nicht länger gültig sind. In dieser Situation verwirft der Server, wenn er keine Reply-Nachricht sendet, die Rebind-Nachricht stillschweigend.

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

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

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

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

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

18.2.5. Empfang von Information-request-Nachrichten

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

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

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

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

Wenn die Information-request-Nachricht vom Client keine Client Identifier- Option enthielt, SOLLTE 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 weiterhin übertragen.

18.2.6. Empfang von Release-Nachrichten

Wenn der Server eine Release-Nachricht per Unicast von einem Client empfängt, 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 dem DUID des Servers, die Client Identifier-Option aus der Client-Nachricht und keine weiteren Optionen enthält.

Nach Empfang einer gültigen Release-Nachricht prüft der Server die IAs und die Adressen in den IAs auf Gültigkeit. Wenn die IAs in der Nachricht in einer Binding 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, kann aber einen Fehler protokollieren.

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

Ein Server kann wählen, einen Datensatz zugewiesener Adressen und IAs aufrechtzuerhalten, nachdem die Lebensdauern der Adressen abgelaufen sind, um dem Server die erneute Zuweisung der zuvor zugewiesenen Adressen an einen Client zu ermöglichen.

18.2.7. Empfang von Decline-Nachrichten

Wenn der Server eine Decline-Nachricht per Unicast von einem Client empfängt, 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 dem DUID des Servers, die Client Identifier-Option aus der Client-Nachricht und keine weiteren Optionen enthält.

Nach Empfang einer gültigen Decline-Nachricht prüft der Server die IAs und die Adressen in den IAs auf Gültigkeit. Wenn die IAs in der Nachricht in einer Binding 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 einen Fehler protokollieren kann, wenn er eine solche Adresse findet).

Der Client hat festgestellt, dass Adressen in den Decline-Nachrichten bereits auf seinem Link verwendet werden. Daher SOLLTE der Server die vom Client abgelehnten Adressen markieren, sodass diese Adressen nicht anderen Clients zugewiesen werden, und KANN eine Benachrichtigung wählen, 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 dürfen.

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

18.2.8. Übertragung von Reply-Nachrichten

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

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