14. Transmission des messages par un 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

14.  Transmission des messages par un client

   Sauf indication contraire dans ce document ou dans un document qui
   decrit comment IPv6 est transporte sur un type de lien specifique
   (pour les types de liens qui ne prennent pas en charge le multicast),
   un client envoie les messages DHCP a l'adresse multicast
   All_DHCP_Relay_Agents_and_Servers.

   Les serveurs DHCP SHOULD NOT verifier si l'adresse de couche 2
   utilisee etait multicast ou non, tant que l'adresse de couche 3 etait
   correcte.

   Un client utilise le multicast pour joindre tous les serveurs ou un
   serveur individuel.  Un serveur individuel est indique en specifiant
   le DUID de ce serveur dans une option Server Identifier (voir
   Section 21.3) du message du client.  (Tous les serveurs recevront ce
   message, mais seul le serveur indique repondra.)  Tous les serveurs
   sont indiques lorsque cette option n'est pas fournie.

14.1.  Limitation du debit

   Un client DHCPv6 MUST limiter le debit des messages DHCP qu'il
   transmet ou retransmet.  Cela minimise l'impact des rafales ou boucles
   de messages prolongees, par exemple lorsqu'un client rejette la
   reponse d'un serveur, repete la requete et obtient la meme reponse du
   serveur, qui est a nouveau rejetee par le client.

   Cette boucle peut se repeter indefiniment s'il n'existe pas de
   mecanisme de sortie/arret.  Par consequent, un client ne doit pas
   initier des transmissions trop frequemment.

   Une methode recommandee pour mettre en oeuvre la fonction de
   limitation de debit est un token bucket (voir Appendix A de
   [RFC3290]), qui limite le debit moyen de transmission a un certain
   nombre pendant un certain intervalle de temps.  Cette methode de
   bornage des rafales garantit egalement que le debit de transmission a
   long terme ne sera pas depasse.

   Une limite de debit de transmission SHOULD etre configurable.  Une
   valeur par defaut possible pourrait etre 20 messages en 20 secondes.

   Pour un equipement qui possede plusieurs interfaces, la limite MUST
   etre appliquee par interface.

   La limitation de debit des messages DHCP transferes et des messages
   cote serveur sort du perimetre de cette specification.

14.2.  Comportement du client lorsque T1 et/ou T2 valent 0

   Dans certains cas, les valeurs T1 et/ou T2 peuvent etre definies a 0.
   Actuellement, il existe deux cas de ce type:

   1.  un client a recu une option IA_NA (voir Section 21.4) avec une
       valeur zero

   2.  un client a recu une option IA_PD (voir Section 21.21) avec une
       valeur zero

   Cela indique que les temps de renew et de rebind sont laisses a la
   discretion du client.  Cependant, ils ne sont pas entierement
   discretionnaires.

   Lorsque les valeurs T1 et/ou T2 sont definies a 0, le client MUST
   choisir un instant qui evite les tempetes de messages.  En
   particulier, il MUST NOT transmettre immediatement.  Si le client a
   recu plusieurs options IA, il SHOULD choisir les instants de
   transmission renew et/ou rebind de sorte que toutes les options IA
   soient traitees dans un seul echange, si possible.  Le client MUST
   choisir les temps de renew et de rebind de facon a ne pas enfreindre
   les restrictions de limitation de debit definies dans Section 14.1.