5. Client/Server-Austausche

Dieser Abschnitt bewahrt den RFC-Text zu DHCPv6, einschliesslich Nachrichtenaustausch, Relay-Verhalten, DUIDs, IA_NA, IA_TA, IA_PD, DHCP-Optionen, RKAP-Authentifizierung, IANA-Registern, normativen Anforderungen und der Optionsvorkommensmatrizen im Anhang.

Originaler RFC-Text

5.  Client/Server-Austausche

   Clients und Server tauschen DHCP-Nachrichten unter Verwendung von UDP
   aus (siehe [RFC0768] und [BCP145]).  Der Client verwendet eine
   link-local source address oder durch andere Mechanismen bestimmte
   Adressen zum Senden und Empfangen von DHCP-Nachrichten.

   Ein DHCP-Client sendet alle Nachrichten unter Verwendung einer
   reservierten, link-scoped multicast destination address
   (All_DHCP_Relay_Agents_and_Servers - ff02::1:2), sodass der Client
   nicht mit der Adresse oder den Adressen von DHCP-Servern konfiguriert
   werden muss.

   Damit ein DHCP-Client eine Nachricht an einen DHCP-Server senden kann,
   der nicht am selben Link angeschlossen ist, leitet ein DHCP relay agent
   auf dem Link des Clients Nachrichten zwischen Client und Server weiter.
   Der Betrieb des Relay Agent ist fuer den Client transparent.  Die
   Diskussion der Nachrichtenaustausche im restlichen Teil dieses
   Abschnitts laesst die Beschreibung der Weiterleitung von Nachrichten
   durch Relay Agents aus.

5.1.  Client/Server-Austausche mit zwei Nachrichten

   Wenn ein DHCP-Client nicht benoetigt, dass ein DHCP-Server ihm
   IP-Adressen oder delegierte Praefixe zuweist, kann der Client andere
   Konfigurationsinformationen, etwa eine Liste verfuegbarer DNS-Server
   [RFC3646] oder NTP-Server [RFC5908], durch einen einzelnen
   Nachrichten- und Antwortaustausch mit einem DHCP-Server erhalten.  Um
   andere Konfigurationsinformationen zu erhalten, sendet der Client
   zunaechst eine Information-request-Nachricht an die Multicast-Adresse
   All_DHCP_Relay_Agents_and_Servers.  Server antworten mit einer
   Reply-Nachricht, die die anderen Konfigurationsinformationen fuer den
   Client enthaelt.

   Ein Client kann den Server auch auffordern, die Adresszuweisung
   und/oder Praefixdelegation zu beschleunigen, indem ein Austausch mit
   zwei Nachrichten anstelle des im naechsten Abschnitt beschriebenen
   normalen Austauschs mit vier Nachrichten verwendet wird.  Eine
   beschleunigte Zuweisung kann vom Client angefordert werden, und Server
   koennen die Anforderung erfuellen oder nicht (siehe Sections 18.3.1
   und 21.14 fuer weitere Details und warum Server diese Anforderung
   moeglicherweise nicht erfuellen).  Clients koennen diesen
   beschleunigten Dienst in Umgebungen anfordern, in denen wahrscheinlich
   nur ein Server auf einem Link verfuegbar ist und nicht erwartet wird,
   dass ein zweiter Server verfuegbar wird, oder wenn der moeglichst
   schnelle Abschluss des Konfigurationsprozesses Prioritaet hat.

   Um den beschleunigten Austausch mit zwei Nachrichten anzufordern,
   sendet der Client eine Solicit-Nachricht an die Multicast-Adresse
   All_DHCP_Relay_Agents_and_Servers und fordert die Zuweisung von
   Adressen und/oder delegierten Praefixen sowie andere
   Konfigurationsinformationen an.  Diese Nachricht enthaelt einen Hinweis
   (die Rapid Commit option; siehe Section 21.14), dass der Client bereit
   ist, eine sofortige Reply-Nachricht vom Server zu akzeptieren.  Der
   Server, der bereit ist, die Zuweisung von Adressen und/oder delegierten
   Praefixen an den Client sofort festzuschreiben, antwortet mit einer
   Reply-Nachricht.  Die Konfigurationsinformationen und die Adressen
   und/oder delegierten Praefixe in der Reply-Nachricht sind dann sofort
   fuer den Client nutzbar.

   Jede dem Client zugewiesene Adresse oder jedes delegierte Praefix hat
   zugehoerige preferred und valid lifetimes, die vom Server angegeben
   werden.  Um eine Verlaengerung der einer Adresse oder einem delegierten
   Praefix zugewiesenen lifetimes anzufordern, sendet der Client eine
   Renew-Nachricht an den Server.  Der Server sendet dem Client eine
   Reply-Nachricht mit den neuen lifetimes, sodass der Client die Adresse
   oder das delegierte Praefix ohne Unterbrechung weiterverwenden kann.
   Wenn der Server die lifetime einer Adresse oder eines delegierten
   Praefixes nicht verlaengern kann, zeigt er dies an, indem er die
   Adresse oder das delegierte Praefix mit lifetimes von 0 zurueckgibt.
   Gleichzeitig kann der Server andere Adressen oder delegierte Praefixe
   zuweisen.

   Siehe Section 18 fuer Beschreibungen zusaetzlicher Austausche mit zwei
   Nachrichten zwischen Client und Server.

5.2.  Client/Server-Austausche mit vier Nachrichten

   Um die Zuweisung einer oder mehrerer Adressen und/oder delegierter
   Praefixe anzufordern, sucht ein Client zunaechst einen DHCP-Server und
   fordert dann vom Server die Zuweisung von Adressen und/oder delegierten
   Praefixen sowie andere Konfigurationsinformationen an.  Der Client
   sendet eine Solicit-Nachricht an die Multicast-Adresse
   All_DHCP_Relay_Agents_and_Servers, um verfuegbare DHCP-Server zu
   finden.  Jeder Server, der die Anforderungen des Clients erfuellen
   kann, antwortet mit einer Advertise-Nachricht.  Der Client waehlt dann
   einen der Server aus und sendet eine Request-Nachricht an den Server,
   in der er um den Lease von Adressen und/oder delegierten Praefixen
   sowie andere Konfigurationsinformationen bittet.  Der Server antwortet
   mit einer Reply-Nachricht, die die geleasten Adressen, delegierten
   Praefixe und die Konfiguration enthaelt.

   Wie im vorherigen Abschnitt beschrieben, kann der Client eine
   Verlaengerung der lifetimes anfordern, die Adressen oder delegierten
   Praefixen zugewiesen sind (dies ist ein Austausch mit zwei
   Nachrichten).

5.3.  Server/Client-Austausche

   Ein Server, der zuvor mit einem Client kommuniziert und ausgehandelt
   hat, dass der Client auf Reconfigure-Nachrichten lauscht, kann dem
   Client eine Reconfigure-Nachricht senden, um den Client dazu zu
   veranlassen, seine Konfiguration durch Senden einer
   Information-request-, Renew- oder Rebind-Nachricht zu aktualisieren.
   Reconfigure-Nachrichten werden gemaess Section 20.4 authentifiziert.
   Der Client fuehrt dann den zuvor beschriebenen Austausch mit zwei
   Nachrichten aus.  Dies kann verwendet werden, um
   Konfigurationsaenderungen fuer einen Client zu beschleunigen, etwa die
   Notwendigkeit, ein Netzwerk neu zu nummerieren (siehe [RFC6879] und
   [RFC9096]).