15. Fiabilite des echanges de messages inities par le client

Cette section conserve le texte de la RFC relatif a DHCPv6, notamment les echanges de messages, le comportement des relais, les DUID, IA_NA, IA_TA, IA_PD, les options DHCP, l'authentification RKAP, les registres IANA, les exigences normatives et les matrices d'apparition des options en annexe.

Texte original de la RFC

15.  Fiabilite des echanges de messages inities par le client

   Les clients DHCP sont responsables de la livraison fiable des messages
   dans les echanges de messages inities par le client decrits dans la
   Section 18.  Si un client DHCP ne recoit pas une reponse attendue d'un
   serveur, le client doit retransmettre son message selon la strategie
   de retransmission decrite ci-dessous.

   Noter que la procedure decrite dans cette section est legerement
   modifiee lorsqu'elle est utilisee avec le message Solicit.  La
   procedure modifiee est decrite dans la Section 18.2.1.

   Le client commence l'echange de messages en transmettant un message au
   serveur.  L'echange de messages se termine lorsque soit (1) le client
   recoit avec succes la ou les reponses appropriees d'un ou de plusieurs
   serveurs, soit (2) l'echange de messages est considere comme ayant
   echoue selon le mecanisme de retransmission decrit ci-dessous.

   Le client MUST mettre a jour une valeur "elapsed-time" dans une option
   Elapsed Time (voir Section 21.9) dans le message retransmis.  Dans
   certains cas, le client peut egalement devoir modifier des valeurs dans
   les options IA Address (voir Section 21.6) ou IA Prefix (voir
   Section 21.22) si une valid lifetime de l'un des baux du client expire
   avant la retransmission.  Ainsi, chaque fois que ce document fait
   reference a une "retransmission" d'un message du client, cela designe
   a la fois la modification du message original et l'envoi de cette
   nouvelle instance de message au serveur.

   Le comportement de retransmission du client est controle et decrit par
   les variables suivantes:

   RT:    Retransmission timeout

   IRT:   Initial retransmission time

   MRC:   Maximum retransmission count

   MRT:   Maximum retransmission time

   MRD:   Maximum retransmission duration

   RAND:  Randomization factor

   Les valeurs specifiques de chacun de ces parametres pertinents pour
   les differents messages sont donnees dans les sous-sections de la
   Section 18.2, en utilisant les valeurs definies dans la Table 1 de la
   Section 7.6.  L'algorithme pour RAND est commun a toutes les
   transmissions de messages.

   A chaque transmission ou retransmission de message, le client definit
   RT selon les regles donnees ci-dessous.  Si RT expire avant la fin de
   l'echange de messages, le client recalcule RT et retransmet le message.

   Chacun des calculs d'un nouveau RT inclut un facteur de randomisation
   (RAND), qui est un nombre aleatoire choisi selon une distribution
   uniforme entre -0.1 et +0.1.  Le facteur de randomisation est inclus
   pour minimiser la synchronisation des messages transmis par les clients
   DHCP.

   L'algorithme de choix d'un nombre aleatoire n'a pas besoin d'etre
   cryptographiquement robuste.  L'algorithme SHOULD produire une
   sequence differente de nombres aleatoires a chaque invocation du
   client DHCP.

   Le RT pour la premiere transmission de message est fonde sur IRT:

      RT = IRT + RAND*IRT

   Le RT de chaque transmission de message suivante est fonde sur la
   valeur precedente de RT:

      RT = 2*RTprev + RAND*RTprev

   MRT specifie une borne superieure pour la valeur de RT (sans tenir
   compte de la randomisation ajoutee par l'utilisation de RAND).  Si MRT
   vaut 0, il n'existe pas de limite superieure pour la valeur de RT.
   Sinon:

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

   MRC specifie une borne superieure au nombre de fois ou un client peut
   retransmettre un message.  Sauf si MRC vaut zero, l'echange de
   messages echoue des que le client a transmis le message MRC fois.

   MRD specifie une borne superieure a la duree pendant laquelle un
   client peut retransmettre un message.  Sauf si MRD vaut zero, l'echange
   de messages echoue des que MRD secondes se sont ecoulees depuis la
   premiere transmission du message par le client.

   Si MRC et MRD sont tous deux non nuls, l'echange de messages echoue
   des que l'une des conditions specifiees dans les deux paragraphes
   precedents est remplie.

   Si MRC et MRD valent tous deux zero, le client continue de transmettre
   le message jusqu'a ce qu'il recoive une reponse.

   Il n'est pas attendu qu'un client ecoute une reponse pendant toute la
   periode RT, et il peut desactiver ses capacites d'ecoute apres avoir
   attendu au moins la plus courte des durees entre RT et MAX_WAIT_TIME,
   pour economiser l'energie ou pour d'autres raisons.  Bien entendu, un
   client MUST ecouter les messages Reconfigure s'il en a negocie
   l'utilisation avec le serveur.