14. Trasmissione dei messaggi da parte di un client

Questa sezione conserva il testo della RFC su DHCPv6, inclusi scambi di messaggi, comportamento dei relay, DUID, IA_NA, IA_TA, IA_PD, opzioni DHCP, autenticazione RKAP, registri IANA, requisiti normativi e matrici in appendice sull'apparizione delle opzioni.

Testo originale della RFC

14.  Trasmissione dei messaggi da parte di un client

   Salvo diversa specificazione in questo documento o in un documento che
   descrive come IPv6 viene trasportato su un tipo specifico di link (per
   i tipi di link che non supportano il multicast), un client invia i
   messaggi DHCP all'indirizzo multicast
   All_DHCP_Relay_Agents_and_Servers.

   I server DHCP SHOULD NOT controllare se l'indirizzo di Layer 2 usato
   fosse multicast o meno, purche l'indirizzo di Layer 3 fosse corretto.

   Un client usa il multicast per raggiungere tutti i server o un singolo
   server.  Un singolo server e indicato specificando il DUID di quel
   server in un'opzione Server Identifier (vedere Section 21.3) nel
   messaggio del client.  (Tutti i server riceveranno questo messaggio,
   ma solo il server indicato rispondera.)  Tutti i server sono indicati
   quando questa opzione non e fornita.

14.1.  Limitazione della frequenza

   Un client DHCPv6 MUST limitare la frequenza dei messaggi DHCP che
   trasmette o ritrasmette.  Questo minimizzera l'impatto di burst o
   loop prolungati di messaggi, ad esempio quando un client rifiuta la
   risposta di un server, ripete la richiesta e ottiene la stessa
   risposta del server, che viene nuovamente rifiutata dal client.

   Questo loop puo ripetersi all'infinito se non esiste un meccanismo di
   uscita/arresto.  Pertanto, un client non deve avviare trasmissioni
   troppo frequentemente.

   Un metodo raccomandato per implementare la funzione di limitazione
   della frequenza e un token bucket (vedere Appendix A di [RFC3290]),
   che limita la frequenza media di trasmissione a un certo numero in un
   certo intervallo di tempo.  Questo metodo di contenimento dei burst
   garantisce anche che la frequenza di trasmissione a lungo termine non
   venga superata.

   Un limite della frequenza di trasmissione SHOULD essere configurabile.
   Un possibile valore predefinito potrebbe essere 20 messaggi in 20
   secondi.

   Per un dispositivo che ha piu interfacce, il limite MUST essere
   applicato per ciascuna interfaccia.

   La limitazione della frequenza dei messaggi DHCP inoltrati e dei
   messaggi lato server non rientra nell'ambito di questa specifica.

14.2.  Comportamento del client quando T1 e/o T2 sono 0

   In alcuni casi, i valori T1 e/o T2 possono essere impostati a 0.
   Attualmente esistono due casi di questo tipo:

   1.  un client ha ricevuto un'opzione IA_NA (vedere Section 21.4) con
       valore zero

   2.  un client ha ricevuto un'opzione IA_PD (vedere Section 21.21) con
       valore zero

   Questo indica che i tempi di renew e rebind sono lasciati alla
   discrezione del client.  Tuttavia, non sono completamente
   discrezionali.

   Quando i valori T1 e/o T2 sono impostati a 0, il client MUST scegliere
   un tempo che eviti tempeste di messaggi.  In particolare, MUST NOT
   trasmettere immediatamente.  Se il client ha ricevuto piu opzioni IA,
   esso SHOULD scegliere i tempi di trasmissione renew e/o rebind in modo
   che tutte le opzioni IA siano gestite in un unico scambio, se
   possibile.  Il client MUST scegliere i tempi di renew e rebind in modo
   da non violare le restrizioni di limitazione della frequenza definite
   nella Section 14.1.