14. Uebertragung von Nachrichten durch einen Client

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

14.  Uebertragung von Nachrichten durch einen Client

   Sofern in diesem Dokument oder in einem Dokument, das beschreibt, wie
   IPv6 ueber einen bestimmten Link-Typ transportiert wird (fuer
   Link-Typen, die Multicast nicht unterstuetzen), nichts anderes
   angegeben ist, sendet ein Client DHCP-Nachrichten an die Multicast-
   Adresse All_DHCP_Relay_Agents_and_Servers.

   DHCP-Server SHOULD NOT pruefen, ob die verwendete Layer-2-Adresse
   Multicast war oder nicht, solange die Layer-3-Adresse korrekt war.

   Ein Client verwendet Multicast, um alle Server oder einen einzelnen
   Server zu erreichen.  Ein einzelner Server wird angegeben, indem die
   DUID dieses Servers in einer Server Identifier option (siehe
   Section 21.3) in der Nachricht des Clients angegeben wird.  (Alle
   Server empfangen diese Nachricht, aber nur der angegebene Server
   antwortet.)  Alle Server sind gemeint, wenn diese Option nicht
   bereitgestellt wird.

14.1.  Ratenbegrenzung

   Ein DHCPv6-Client MUST die Rate der DHCP-Nachrichten begrenzen, die er
   sendet oder erneut sendet.  Dies minimiert die Auswirkungen
   anhaltender Nachrichtenbursts oder Schleifen, beispielsweise wenn ein
   Client die Antwort eines Servers zurueckweist, die Anforderung
   wiederholt und dieselbe Serverantwort erhaelt, die wiederum vom Client
   zurueckgewiesen wird.

   Diese Schleife kann sich unbegrenzt wiederholen, wenn kein
   Beendigungs-/Stoppmechanismus vorhanden ist.  Daher darf ein Client
   Uebertragungen nicht zu haeufig initiieren.

   Eine empfohlene Methode zur Implementierung der Ratenbegrenzungs-
   funktion ist ein Token Bucket (siehe Appendix A von [RFC3290]), der
   die durchschnittliche Uebertragungsrate auf eine bestimmte Anzahl in
   einem bestimmten Zeitintervall begrenzt.  Diese Methode zur Begrenzung
   von Burstiness garantiert ausserdem, dass die langfristige
   Uebertragungsrate nicht ueberschritten wird.

   Eine Uebertragungsratenbegrenzung SHOULD konfigurierbar sein.  Ein
   moeglicher Standardwert koennte 20 Nachrichten in 20 Sekunden sein.

   Fuer ein Geraet mit mehreren Schnittstellen MUST die Begrenzung pro
   Schnittstelle durchgesetzt werden.

   Die Ratenbegrenzung weitergeleiteter DHCP-Nachrichten und
   serverseitiger Nachrichten liegt ausserhalb des Umfangs dieser
   Spezifikation.

14.2.  Client-Verhalten, wenn T1 und/oder T2 0 sind

   In bestimmten Faellen koennen T1- und/oder T2-Werte auf 0 gesetzt
   werden.  Derzeit gibt es zwei solche Faelle:

   1.  ein Client hat eine IA_NA option (siehe Section 21.4) mit einem
       Nullwert empfangen

   2.  ein Client hat eine IA_PD option (siehe Section 21.21) mit einem
       Nullwert empfangen

   Dies ist ein Hinweis darauf, dass die renew- und rebind-Zeiten dem
   Ermessen des Clients ueberlassen bleiben.  Sie sind jedoch nicht
   vollstaendig frei waehlbar.

   Wenn T1- und/oder T2-Werte auf 0 gesetzt sind, MUST der Client einen
   Zeitpunkt waehlen, um Nachrichtenstuerme zu vermeiden.  Insbesondere
   MUST NOT er sofort senden.  Wenn der Client mehrere IA-Optionen
   empfangen hat, SHOULD er renew- und/oder rebind-Uebertragungszeiten so
   waehlen, dass alle IA-Optionen moeglichst in einem Austausch
   verarbeitet werden.  Der Client MUST renew- und rebind-Zeiten so
   waehlen, dass die in Section 14.1 definierten
   Ratenbegrenzungsvorgaben nicht verletzt werden.