15. Zuverlaessigkeit clientinitiierter Nachrichtenaustausche

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

15.  Zuverlaessigkeit clientinitiierter Nachrichtenaustausche

   DHCP-Clients sind fuer die zuverlaessige Zustellung von Nachrichten in
   den in Section 18 beschriebenen clientinitiierten Nachrichtenaustauschen
   verantwortlich.  Wenn ein DHCP-Client keine erwartete Antwort von einem
   Server erhaelt, muss der Client seine Nachricht gemaess der unten
   beschriebenen Retransmission-Strategie erneut senden.

   Es ist zu beachten, dass das in diesem Abschnitt beschriebene Verfahren
   bei Verwendung mit der Solicit-Nachricht leicht modifiziert wird.  Das
   modifizierte Verfahren ist in Section 18.2.1 beschrieben.

   Der Client beginnt den Nachrichtenaustausch, indem er eine Nachricht an
   den Server sendet.  Der Nachrichtenaustausch endet, wenn entweder (1)
   der Client die passende Antwort oder die passenden Antworten von einem
   oder mehreren Servern erfolgreich empfaengt oder (2) der
   Nachrichtenaustausch gemaess dem unten beschriebenen
   Retransmission-Mechanismus als fehlgeschlagen gilt.

   Der Client MUST einen "elapsed-time"-Wert in einer Elapsed Time option
   (siehe Section 21.9) in der erneut gesendeten Nachricht aktualisieren.
   In einigen Faellen muss der Client moeglicherweise auch Werte in IA
   Address options (siehe Section 21.6) oder IA Prefix options (siehe
   Section 21.22) aendern, wenn eine valid lifetime fuer einen Lease des
   Clients vor der erneuten Uebertragung ablaeuft.  Wenn dieses Dokument
   also auf eine "retransmission" einer Clientnachricht verweist, meint es
   sowohl die Aenderung der urspruenglichen Nachricht als auch das Senden
   dieser neuen Nachrichteninstanz an den Server.

   Das Retransmission-Verhalten des Clients wird durch die folgenden
   Variablen gesteuert und beschrieben:

   RT:    Retransmission timeout

   IRT:   Initial retransmission time

   MRC:   Maximum retransmission count

   MRT:   Maximum retransmission time

   MRD:   Maximum retransmission duration

   RAND:  Randomization factor

   Spezifische Werte fuer jeden dieser Parameter, die fuer die
   verschiedenen Nachrichten relevant sind, werden in den Unterabschnitten
   von Section 18.2 angegeben, wobei die in Table 1 in Section 7.6
   definierten Werte verwendet werden.  Der Algorithmus fuer RAND ist fuer
   alle Nachrichtenuebertragungen gemeinsam.

   Bei jeder Nachrichtenuebertragung oder -wiederuebertragung setzt der
   Client RT gemaess den unten angegebenen Regeln.  Wenn RT ablaeuft,
   bevor der Nachrichtenaustausch endet, berechnet der Client RT neu und
   sendet die Nachricht erneut.

   Jede Berechnung eines neuen RT enthaelt einen Randomisierungsfaktor
   (RAND), der eine Zufallszahl ist, die mit einer gleichmaessigen
   Verteilung zwischen -0.1 und +0.1 gewaehlt wird.  Der
   Randomisierungsfaktor wird einbezogen, um die Synchronisierung von
   Nachrichten, die von DHCP-Clients gesendet werden, zu minimieren.

   Der Algorithmus zur Auswahl einer Zufallszahl muss nicht
   kryptographisch solide sein.  Der Algorithmus SHOULD bei jedem Aufruf
   des DHCP-Clients eine andere Folge von Zufallszahlen erzeugen.

   RT fuer die erste Nachrichtenuebertragung basiert auf IRT:

      RT = IRT + RAND*IRT

   RT fuer jede nachfolgende Nachrichtenuebertragung basiert auf dem
   vorherigen Wert von RT:

      RT = 2*RTprev + RAND*RTprev

   MRT gibt eine Obergrenze fuer den Wert von RT an (ohne die durch die
   Verwendung von RAND hinzugefuegte Randomisierung zu beruecksichtigen).
   Wenn MRT den Wert 0 hat, gibt es keine Obergrenze fuer den Wert von RT.
   Andernfalls:

      if (RT > MRT)
         RT = MRT + RAND*MRT

   MRC gibt eine Obergrenze fuer die Anzahl der Male an, die ein Client
   eine Nachricht erneut senden darf.  Sofern MRC nicht null ist, schlaegt
   der Nachrichtenaustausch fehl, sobald der Client die Nachricht MRC-mal
   gesendet hat.

   MRD gibt eine Obergrenze fuer die Zeitdauer an, waehrend der ein Client
   eine Nachricht erneut senden darf.  Sofern MRD nicht null ist, schlaegt
   der Nachrichtenaustausch fehl, sobald MRD Sekunden verstrichen sind,
   seit der Client die Nachricht erstmals gesendet hat.

   Wenn sowohl MRC als auch MRD ungleich null sind, schlaegt der
   Nachrichtenaustausch fehl, sobald eine der in den vorherigen beiden
   Absaetzen angegebenen Bedingungen erfuellt ist.

   Wenn sowohl MRC als auch MRD null sind, sendet der Client die Nachricht
   weiter, bis er eine Antwort empfaengt.

   Von einem Client wird nicht erwartet, dass er waehrend der gesamten
   RT-Periode auf eine Antwort wartet; er kann seine Empfangsfaehigkeiten
   nach mindestens der kuerzeren Wartezeit von RT und MAX_WAIT_TIME
   aufgrund von Energieeinsparung oder aus anderen Gruenden deaktivieren.
   Selbstverstaendlich MUST ein Client auf Reconfigure lauschen, wenn er
   dessen Verwendung mit dem Server ausgehandelt hat.