5. Scambi client/server

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

5.  Scambi client/server

   Client e server scambiano messaggi DHCP usando UDP (vedere [RFC0768] e
   [BCP145]).  Il client usa un indirizzo sorgente link-local o indirizzi
   determinati tramite altri meccanismi per trasmettere e ricevere
   messaggi DHCP.

   Un client DHCP invia tutti i messaggi usando un indirizzo di
   destinazione multicast riservato e con ambito link
   (All_DHCP_Relay_Agents_and_Servers - ff02::1:2), cosi che il client
   non debba essere configurato con l'indirizzo o gli indirizzi dei server
   DHCP.

   Per consentire a un client DHCP di inviare un messaggio a un server
   DHCP che non e collegato allo stesso link, un DHCP relay agent sul link
   del client inoltrera i messaggi tra client e server.  Il funzionamento
   del relay agent e trasparente per il client.  La discussione degli
   scambi di messaggi nel resto di questa sezione omettera la descrizione
   dell'inoltro dei messaggi da parte dei relay agent.

5.1.  Scambi client/server che coinvolgono due messaggi

   Quando un client DHCP non ha bisogno che un server DHCP gli assegni
   indirizzi IP o prefissi delegati, il client puo ottenere altre
   informazioni di configurazione, come una lista di server DNS disponibili
   [RFC3646] o server NTP [RFC5908], tramite un singolo scambio di
   messaggio e risposta con un server DHCP.  Per ottenere altre
   informazioni di configurazione, il client invia prima un messaggio
   Information-request all'indirizzo multicast
   All_DHCP_Relay_Agents_and_Servers.  I server rispondono con un
   messaggio Reply contenente le altre informazioni di configurazione per
   il client.

   Un client puo anche richiedere al server di accelerare l'assegnazione
   di indirizzi e/o la delega di prefisso usando uno scambio a due
   messaggi invece del normale scambio a quattro messaggi discusso nella
   sezione successiva.  L'assegnazione accelerata puo essere richiesta dal
   client e i server possono o meno onorare la richiesta (vedere
   Sections 18.3.1 e 21.14 per maggiori dettagli e perche i server
   potrebbero non onorare questa richiesta).  I client possono richiedere
   questo servizio accelerato in ambienti in cui e probabile che vi sia un
   solo server disponibile su un link e nessuna aspettativa che un secondo
   server diventi disponibile, oppure quando completare il processo di
   configurazione il piu rapidamente possibile e una priorita.

   Per richiedere lo scambio accelerato a due messaggi, il client invia
   un messaggio Solicit all'indirizzo multicast
   All_DHCP_Relay_Agents_and_Servers richiedendo l'assegnazione di
   indirizzi e/o prefissi delegati e altre informazioni di configurazione.
   Questo messaggio include un'indicazione (l'opzione Rapid Commit; vedere
   Section 21.14) che il client e disposto ad accettare un messaggio Reply
   immediato dal server.  Il server disposto a impegnare immediatamente
   l'assegnazione di indirizzi e/o prefissi delegati al client risponde
   con un messaggio Reply.  Le informazioni di configurazione e gli
   indirizzi e/o prefissi delegati nel messaggio Reply sono quindi
   immediatamente disponibili per l'uso da parte del client.

   Ogni indirizzo o prefisso delegato assegnato al client ha preferred e
   valid lifetimes associate specificate dal server.  Per richiedere
   un'estensione delle lifetimes assegnate a un indirizzo o prefisso
   delegato, il client invia un messaggio Renew al server.  Il server
   invia al client un messaggio Reply con le nuove lifetimes, consentendo
   al client di continuare a usare l'indirizzo o il prefisso delegato
   senza interruzione.  Se il server non e in grado di estendere la
   lifetime di un indirizzo o prefisso delegato, lo indica restituendo
   l'indirizzo o il prefisso delegato con lifetimes pari a 0.  Allo stesso
   tempo, il server puo assegnare altri indirizzi o prefissi delegati.

   Vedere Section 18 per descrizioni di ulteriori scambi a due messaggi
   tra client e server.

5.2.  Scambi client/server che coinvolgono quattro messaggi

   Per richiedere l'assegnazione di uno o piu indirizzi e/o prefissi
   delegati, un client prima individua un server DHCP e poi richiede al
   server l'assegnazione di indirizzi e/o prefissi delegati e altre
   informazioni di configurazione.  Il client invia un messaggio Solicit
   all'indirizzo multicast All_DHCP_Relay_Agents_and_Servers per trovare
   server DHCP disponibili.  Qualsiasi server in grado di soddisfare i
   requisiti del client risponde con un messaggio Advertise.  Il client
   quindi sceglie uno dei server e invia al server un messaggio Request
   chiedendo il lease di indirizzi e/o prefissi delegati e altre
   informazioni di configurazione.  Il server risponde con un messaggio
   Reply che contiene gli indirizzi in lease, i prefissi delegati e la
   configurazione.

   Come descritto nella sezione precedente, il client puo richiedere
   un'estensione delle lifetimes assegnate a indirizzi o prefissi delegati
   (questo e uno scambio a due messaggi).

5.3.  Scambi server/client

   Un server che ha comunicato in precedenza con un client e ha negoziato
   che il client ascolti messaggi Reconfigure puo inviare al client un
   messaggio Reconfigure per indurre il client ad aggiornare la propria
   configurazione inviando un messaggio Information-request, Renew o
   Rebind.  I messaggi Reconfigure sono autenticati come da Section 20.4.
   Il client quindi esegue lo scambio a due messaggi come descritto in
   precedenza.  Questo puo essere usato per accelerare modifiche di
   configurazione a un client, come la necessita di rinumerare una rete
   (vedere [RFC6879] e [RFC9096]).