18. Scambio di configurazione avviato dal client DHCP

Un client avvia uno scambio di messaggi con uno o più server per acquisire o aggiornare informazioni di configurazione di interesse. Il client può avviare lo scambio di configurazione come parte del processo di configurazione del sistema operativo, quando richiesto dal livello applicativo, quando richiesto dalla Stateless Address Autoconfiguration o come richiesto per estendere il tempo di vita di un indirizzo (messaggi Renew e Rebind).

18.1. Comportamento del client

Un client usa messaggi Request, Renew, Rebind, Release e Decline durante il normale ciclo di vita degli indirizzi. Usa Confirm per validare gli indirizzi quando potrebbe essersi spostato su un nuovo link. Usa messaggi Information-Request quando ha bisogno di informazioni di configurazione ma non di indirizzi.

Se il client ha un indirizzo sorgente di ambito sufficiente che può essere usato dal server come indirizzo di ritorno, e il client ha ricevuto un'opzione Server Unicast (sezione 22.12) dal server, il client DOVREBBE inviare in unicast i messaggi Request, Renew, Release e Decline al server.

DISCUSSIONE:

L'uso dell'unicast può evitare ritardi dovuti all'inoltro dei messaggi da parte degli agenti di relay, nonché sovraccarico e risposte duplicate da parte dei server dovute alla consegna dei messaggi dei client a più server. Richiedere che il client inoltri tutti i messaggi DHCP attraverso un agente di relay consente l'inclusione di opzioni dell'agente di relay in tutti i messaggi inviati dal client. Il server dovrebbe abilitare l'uso dell'unicast solo quando le opzioni dell'agente di relay non saranno usate.

18.1.1. Creazione e trasmissione di messaggi Request

Il client usa un messaggio Request per popolare le IA con indirizzi e ottenere altre informazioni di configurazione. Il client include una o più opzioni IA nel messaggio Request. Il server restituisce quindi indirizzi e altre informazioni sulle IA al client in opzioni IA in un messaggio Reply.

Il client genera un ID di transazione e inserisce questo valore nel campo "transaction-id".

Il client inserisce l'identificatore del server di destinazione in un'opzione Server Identifier.

Il client DEVE includere un'opzione Client Identifier per identificarsi presso il server. Il client aggiunge eventuali altre opzioni appropriate, incluse una o più opzioni IA (se il client sta richiedendo che il server gli assegni alcuni indirizzi di rete).

Il client DEVE includere un'opzione Option Request (si veda la sezione 22.7) per indicare le opzioni che il client è interessato a ricevere. Il client PUÒ includere opzioni con valori di dati come suggerimenti al server sui valori di parametro che il client vorrebbe fossero restituiti.

Il client include un'opzione Reconfigure Accept (si veda la sezione 22.20) che indica se il client è disposto o meno ad accettare messaggi Reconfigure dal server.

Il client trasmette il messaggio secondo la sezione 14, usando i seguenti parametri:

IRT   REQ_TIMEOUT
MRT   REQ_MAX_RT
MRC   REQ_MAX_RC
MRD   0

Se lo scambio di messaggi fallisce, il client intraprende un'azione basata sulla politica locale del client. Esempi di azioni che il client potrebbe intraprendere includono:

Selezionare un altro server da un elenco di server noti al client; per esempio, server che hanno risposto con un messaggio Advertise.
Avviare il processo di individuazione dei server descritto nella sezione 17.
Terminare il processo di configurazione e segnalare il fallimento.

18.1.2. Creazione e trasmissione di messaggi Confirm

Ogni volta che un client potrebbe essersi spostato su un nuovo link, i prefissi dagli indirizzi assegnati alle interfacce su quel link potrebbero non essere più appropriati per il link a cui il client è collegato. Esempi di momenti in cui un client potrebbe essersi spostato su un nuovo link includono:

Il client si riavvia.
Il client è collegato fisicamente a una connessione cablata.
Il client riprende dalla modalità di sospensione.
Il client che usa una tecnologia wireless cambia punto di accesso.

In qualsiasi situazione in cui un client potrebbe essersi spostato su un nuovo link, il client DEVE avviare uno scambio di messaggi Confirm/Reply. Il client include tutte le IA assegnate all'interfaccia che potrebbero essersi spostate su un nuovo link, insieme agli indirizzi associati a tali IA, nel suo messaggio Confirm. Qualsiasi server che risponde indicherà se tali indirizzi sono appropriati per il link a cui il client è collegato con lo stato nel messaggio Reply che restituisce al client.

Il client imposta il campo "msg-type" su CONFIRM. Il client genera un ID di transazione e inserisce questo valore nel campo "transaction-id".

Il client DEVE includere un'opzione Client Identifier per identificarsi presso il server. Il client include opzioni IA per tutte le IA assegnate all'interfaccia per cui il messaggio Confirm è inviato. Le opzioni IA includono tutti gli indirizzi che il client ha attualmente associati a quelle IA. Il client DOVREBBE impostare i campi T1 e T2 in qualsiasi opzione IA_NA, e i campi preferred-lifetime e valid-lifetime nelle opzioni IA Address a 0, poiché il server ignorerà questi campi.

Il primo messaggio Confirm dal client sull'interfaccia DEVE essere ritardato di una quantità casuale di tempo tra 0 e CNF_MAX_DELAY. Il client trasmette il messaggio secondo la sezione 14, usando i seguenti parametri:

IRT   CNF_TIMEOUT
MRT   CNF_MAX_RT
MRC   0
MRD   CNF_MAX_RD

Se il client non riceve risposte prima che il processo di trasmissione del messaggio termini, come descritto nella sezione 14, il client DOVREBBE continuare a usare eventuali indirizzi IP, usando gli ultimi tempi di vita noti per tali indirizzi, e DOVREBBE continuare a usare eventuali altri parametri di configurazione precedentemente ottenuti.

18.1.3. Creazione e trasmissione di messaggi Renew

Per estendere i tempi di vita valido e preferito per gli indirizzi associati a una IA, il client invia un messaggio Renew al server da cui il client ha ottenuto gli indirizzi nella IA contenente un'opzione IA per la IA. Il client include opzioni IA Address nell'opzione IA per gli indirizzi associati alla IA. Il server determina nuovi tempi di vita per gli indirizzi nella IA secondo la configurazione amministrativa del server. Il server può anche aggiungere nuovi indirizzi alla IA. Il server può rimuovere indirizzi dalla IA impostando i tempi di vita preferito e valido di tali indirizzi a zero.

Il server controlla il momento in cui il client contatta il server per estendere i tempi di vita sugli indirizzi assegnati attraverso i parametri T1 e T2 assegnati a una IA.

Al tempo T1 per una IA, il client avvia uno scambio di messaggi Renew/Reply per estendere i tempi di vita su tutti gli indirizzi nella IA. Il client include un'opzione IA con tutti gli indirizzi attualmente assegnati alla IA nel suo messaggio Renew.

Se T1 o T2 è impostato a 0 dal server (per una IA_NA) o non ci sono tempi T1 o T2 (per una IA_TA), il client può inviare rispettivamente un messaggio Renew o Rebind, a discrezione del client.

Il client imposta il campo "msg-type" su RENEW. Il client genera un ID di transazione e inserisce questo valore nel campo "transaction-id".

Il client inserisce l'identificatore del server di destinazione in un'opzione Server Identifier.

Il client DEVE includere un'opzione Client Identifier per identificarsi presso il server. Il client aggiunge eventuali opzioni appropriate, incluse una o più opzioni IA. Il client DEVE includere l'elenco degli indirizzi che il client ha attualmente associati alle IA nel messaggio Renew.

Il client trasmette il messaggio secondo la sezione 14, usando i seguenti parametri:

IRT   REN_TIMEOUT
MRT   REN_MAX_RT
MRC   0
MRD   Tempo rimanente fino a T2

Lo scambio di messaggi è terminato quando è raggiunto il tempo T2 (si veda la sezione 18.1.4), momento in cui il client avvia uno scambio di messaggi Rebind.

18.1.4. Creazione e trasmissione di messaggi Rebind

Al tempo T2 per una IA (che sarà raggiunto solo se il server a cui è stato inviato il messaggio Renew al tempo T1 non ha risposto), il client avvia uno scambio di messaggi Rebind/Reply con qualsiasi server disponibile. Il client include un'opzione IA con tutti gli indirizzi attualmente assegnati alla IA nel suo messaggio Rebind.

Il client imposta il campo "msg-type" su REBIND. Il client genera un ID di transazione e inserisce questo valore nel campo "transaction-id".

Il client trasmette il messaggio secondo la sezione 14, usando i seguenti parametri:

IRT   REB_TIMEOUT
MRT   REB_MAX_RT
MRC   0
MRD   Tempo rimanente fino alla scadenza dei tempi di vita validi di tutti gli indirizzi

Lo scambio di messaggi è terminato quando scadono i tempi di vita validi di tutti gli indirizzi assegnati alla IA (si veda la sezione 10), momento in cui il client ha diverse azioni alternative tra cui scegliere; per esempio:

Il client può scegliere di usare un messaggio Solicit per individuare un nuovo server DHCP e inviare una Request per la IA scaduta al nuovo server.
Il client può avere altri indirizzi in altre IA, quindi il client può scegliere di scartare la IA scaduta e usare gli indirizzi nelle altre IA.

18.1.5. Creazione e trasmissione di messaggi Information-request

Il client usa un messaggio Information-request per ottenere informazioni di configurazione senza che gli siano assegnati indirizzi.

Il client imposta il campo "msg-type" su INFORMATION-REQUEST. Il client genera un ID di transazione e inserisce questo valore nel campo "transaction-id".

Il client DOVREBBE includere un'opzione Client Identifier per identificarsi presso il server. Se il client non include un'opzione Client Identifier, il server non sarà in grado di restituire alcuna opzione specifica del client al client, o il server può scegliere di non rispondere affatto al messaggio. Il client DEVE includere un'opzione Client Identifier se il messaggio Information-Request sarà autenticato.

Il primo messaggio Information-request dal client sull'interfaccia DEVE essere ritardato di una quantità casuale di tempo tra 0 e INF_MAX_DELAY. Il client trasmette il messaggio secondo la sezione 14, usando i seguenti parametri:

IRT   INF_TIMEOUT
MRT   INF_MAX_RT
MRC   0
MRD   0

18.1.6. Creazione e trasmissione di messaggi Release

Per rilasciare uno o più indirizzi, un client invia un messaggio Release al server.

Il client imposta il campo "msg-type" su RELEASE. Il client genera un ID di transazione e inserisce questo valore nel campo "transaction-id".

Il client inserisce l'identificatore del server che ha allocato l'indirizzo/i in un'opzione Server Identifier.

Il client DEVE includere un'opzione Client Identifier per identificarsi presso il server. Il client include opzioni contenenti le IA per gli indirizzi che sta rilasciando nel campo "options". Gli indirizzi da rilasciare DEVONO essere inclusi nelle IA. Eventuali indirizzi per le IA che il client desidera continuare a usare NON DEVONO essere aggiunti alle IA.

Il client NON DEVE usare alcuno degli indirizzi che sta rilasciando come indirizzo sorgente nel messaggio Release o in qualsiasi messaggio trasmesso successivamente.

Poiché i messaggi Release possono andare persi, il client dovrebbe ritrasmettere il Release se non riceve alcun Reply. Tuttavia, ci sono scenari in cui il client potrebbe non voler attendere il normale timeout di ritrasmissione prima di rinunciare (per esempio, allo spegnimento). Le implementazioni DOVREBBERO ritrasmettere una o più volte, ma POSSONO scegliere di terminare la procedura di ritrasmissione in anticipo.

Il client trasmette il messaggio secondo la sezione 14, usando i seguenti parametri:

IRT   REL_TIMEOUT
MRT   0
MRC   REL_MAX_RC
MRD   0

Il client DEVE smettere di usare tutti gli indirizzi che sta rilasciando non appena il client inizia il processo di scambio del messaggio Release. Se gli indirizzi sono rilasciati ma il Reply da un server DHCP è perso, il client ritrasmetterà il messaggio Release, e il server può rispondere con un Reply indicante uno stato di NoBinding. Pertanto, il client non tratta un messaggio Reply con uno stato di NoBinding in uno scambio di messaggi Release come se indicasse un errore.

Si noti che se il client non riesce a rilasciare gli indirizzi, ciascun indirizzo assegnato alla IA sarà recuperato dal server quando scade il tempo di vita valido di tale indirizzo.

18.1.7. Creazione e trasmissione di messaggi Decline

Se un client rileva che uno o più indirizzi a esso assegnati da un server sono già in uso da un altro nodo, il client invia un messaggio Decline al server per informarlo che l'indirizzo è sospetto.

Il client imposta il campo "msg-type" su DECLINE. Il client genera un ID di transazione e inserisce questo valore nel campo "transaction-id".

Il client inserisce l'identificatore del server che ha allocato l'indirizzo/i in un'opzione Server Identifier.

Il client DEVE includere un'opzione Client Identifier per identificarsi presso il server. Il client include opzioni contenenti le IA per gli indirizzi che sta rifiutando nel campo "options". Gli indirizzi da rifiutare DEVONO essere inclusi nelle IA. Eventuali indirizzi per le IA che il client desidera continuare a usare non dovrebbero essere aggiunti alle IA.

Il client NON DEVE usare alcuno degli indirizzi che sta rifiutando come indirizzo sorgente nel messaggio Decline o in qualsiasi messaggio trasmesso successivamente.

Il client trasmette il messaggio secondo la sezione 14, usando i seguenti parametri:

IRT   DEC_TIMEOUT
MRT   0
MRC   DEC_MAX_RC
MRD   0

Se gli indirizzi sono rifiutati ma il Reply da un server DHCP è perso, il client ritrasmetterà il messaggio Decline, e il server può rispondere con un Reply indicante uno stato di NoBinding. Pertanto, il client non tratta un messaggio Reply con uno stato di NoBinding in uno scambio di messaggi Decline come se indicasse un errore.

18.1.8. Ricezione di messaggi Reply

Al ricevimento di un messaggio Reply valido in risposta a un messaggio Solicit (con un'opzione Rapid Commit), Request, Confirm, Renew, Rebind o Information-request, il client estrae le informazioni di configurazione contenute nel Reply. Il client PUÒ scegliere di segnalare qualsiasi codice di stato o messaggio dall'opzione status code nel messaggio Reply.

Il client DOVREBBE eseguire il rilevamento di indirizzi duplicati [17] su ciascuno degli indirizzi in qualsiasi IA ricevuta nel messaggio Reply prima di usare tale indirizzo per il traffico. Se uno qualsiasi degli indirizzi risulta in uso sul link, il client invia un messaggio Decline al server come descritto nella sezione 18.1.7.

Se il Reply è stato ricevuto in risposta a un Solicit (con un'opzione Rapid Commit), Request, Renew o Rebind, il client aggiorna le informazioni che ha registrato sulle IA dalle opzioni IA contenute nel messaggio Reply:

Registra i tempi T1 e T2.
Aggiunge eventuali nuovi indirizzi nell'opzione IA alla IA come registrata dal client.
Aggiorna i tempi di vita per tutti gli indirizzi nell'opzione IA che il client ha già registrato nella IA.
Scarta tutti gli indirizzi dalla IA, come registrata dal client, che hanno un tempo di vita valido di 0 nell'opzione IA Address.
Lascia invariata qualsiasi informazione sugli indirizzi che il client ha registrato nella IA ma che non erano inclusi nella IA dal server.

La gestione delle specifiche informazioni di configurazione è dettagliata nella definizione di ciascuna opzione nella sezione 22.

Se il client riceve un messaggio Reply con un Status Code contenente UnspecFail, il server sta indicando che non è riuscito a elaborare il messaggio a causa di una condizione di fallimento non specificata. Se il client ritrasmette il messaggio originale allo stesso server per riprovare l'operazione desiderata, il client DEVE limitare la frequenza con cui ritrasmette il messaggio e limitare la durata del tempo durante il quale lo ritrasmette.

Quando il client riceve un messaggio Reply con un'opzione Status Code con il valore UseMulticast, il client registra il ricevimento del messaggio e invia messaggi successivi al server attraverso l'interfaccia su cui il messaggio è stato ricevuto usando il multicast. Il client reinvia il messaggio originale usando il multicast.

Quando il client riceve uno stato NotOnLink dal server in risposta a un messaggio Confirm, il client esegue la sollecitazione di server DHCP, come descritto nella sezione 17, e la configurazione avviata dal client come descritto nella sezione 18. Se il client riceve messaggi Reply che non indicano uno stato NotOnLink, il client può usare gli indirizzi nella IA e ignorare eventuali messaggi che indicano uno stato NotOnLink.

Quando il client riceve uno stato NotOnLink dal server in risposta a un messaggio Request, il client può sia riemettere il Request senza specificare alcun indirizzo sia riavviare il processo di individuazione dei server DHCP (si veda la sezione 17).

Il client esamina il codice di stato in ciascuna IA individualmente. Se il codice di stato è NoAddrsAvail, il client non ha ricevuto indirizzi utilizzabili nella IA e può scegliere di provare a ottenere indirizzi per la IA da un altro server. Il client usa indirizzi e altre informazioni da qualsiasi IA che non contenga un'opzione Status Code con il codice NoAddrsAvail. Se il client non riceve indirizzi in nessuna delle IA, può sia provare un altro server (forse riavviando il processo di individuazione dei server DHCP) sia usare il messaggio Information-request per ottenere solo altre informazioni di configurazione.

Quando il client riceve un messaggio Reply in risposta a un messaggio Renew o Rebind, il client esamina ciascuna IA indipendentemente. Per ciascuna IA nel messaggio Renew o Rebind originale, il client:

invia un messaggio Request se la IA conteneva un'opzione Status Code con lo stato NoBinding (e non invia ulteriori messaggi Renew/Rebind)
invia un Renew/Rebind se la IA non è nel messaggio Reply
altrimenti accetta le informazioni nella IA

Quando il client riceve un messaggio Reply valido in risposta a un messaggio Release, il client considera l'evento Release completato, indipendentemente dalle opzioni Status Code restituite dal server.

Quando il client riceve un messaggio Reply valido in risposta a un messaggio Decline, il client considera l'evento Decline completato, indipendentemente dalle opzioni Status Code restituite dal server.

18.2. Comportamento del server

Per questa discussione, si assume che il server sia stato configurato, in modo specifico dell'implementazione, con la configurazione di interesse per i client.

Nella maggior parte dei casi, il server invierà un Reply in risposta a un messaggio del client. Questo messaggio Reply DEVE sempre contenere l'opzione Server Identifier contenente il DUID del server e l'opzione Client Identifier dal messaggio del client se era presente.

Nella maggior parte dei messaggi Reply, il server include opzioni contenenti informazioni di configurazione per il client. Il server deve essere consapevole delle raccomandazioni sulle dimensioni dei pacchetti e sull'uso della frammentazione nella sezione 5 di RFC 2460. Se il client ha incluso un'opzione Option Request nel suo messaggio, il server include nel messaggio Reply opzioni contenenti parametri di configurazione per tutte le opzioni identificate nell'opzione Option Request che il server è stato configurato per restituire al client. Il server PUÒ restituire opzioni aggiuntive al client se è stato configurato per farlo.

18.2.1. Ricezione di messaggi Request

Quando il server riceve un messaggio Request in unicast da un client a cui il server non ha inviato un'opzione unicast, il server scarta il messaggio Request e risponde con un messaggio Reply contenente un'opzione Status Code con il valore UseMulticast, un'opzione Server Identifier contenente il DUID del server, l'opzione Client Identifier dal messaggio del client, e nessun'altra opzione.

Quando il server riceve un messaggio Request valido, il server crea i binding per quel client secondo la politica e le informazioni di configurazione del server e registra le IA e altre informazioni richieste dal client.

Il server costruisce un messaggio Reply impostando il campo "msg-type" su REPLY, e copiando l'ID di transazione dal messaggio Request nel campo transaction-id.

Il server DEVE includere un'opzione Server Identifier contenente il DUID del server e l'opzione Client Identifier dal messaggio Request nel messaggio Reply.

Se il server trova che il prefisso su uno o più indirizzi IP in qualsiasi IA nel messaggio dal client non è appropriato per il link a cui il client è connesso, il server DEVE restituire la IA al client con un'opzione Status Code con il valore NotOnLink.

Se il server non può assegnare alcun indirizzo a una IA nel messaggio dal client, il server DEVE includere la IA nel messaggio Reply senza indirizzi nella IA e con un'opzione Status Code nella IA contenente il codice di stato NoAddrsAvail.

Per qualsiasi IA a cui il server può assegnare indirizzi, il server include la IA con indirizzi e altri parametri di configurazione, e registra la IA come un nuovo binding del client.

Il server include un'opzione Reconfigure Accept se il server vuole richiedere che il client accetti messaggi Reconfigure.

Il server include altre opzioni contenenti informazioni di configurazione da restituire al client come descritto nella sezione 18.2.

Se il server trova che il client ha incluso una IA nel messaggio Request per cui il server ha già un binding che associa la IA al client, il client ha rinviato un messaggio Request per cui non ha ricevuto un messaggio Reply. Il server reinvia sia un messaggio Reply precedentemente memorizzato nella cache sia un nuovo messaggio Reply.

18.2.2. Ricezione di messaggi Confirm

Quando il server riceve un messaggio Confirm, il server determina se gli indirizzi nel messaggio Confirm sono appropriati per il link a cui il client è collegato. Se tutti gli indirizzi nel messaggio Confirm superano questo test, il server restituisce uno stato di Success. Se uno qualsiasi degli indirizzi non supera questo test, il server restituisce uno stato di NotOnLink. Se il server non è in grado di eseguire questo test (per esempio, il server non ha informazioni sui prefissi sul link a cui il client è connesso), o non c'erano indirizzi in nessuna delle IA inviate dal client, il server NON DEVE inviare una risposta al client.

Il server ignora i campi T1 e T2 nelle opzioni IA e i campi preferred-lifetime e valid-lifetime nelle opzioni IA Address.

Il server costruisce un messaggio Reply impostando il campo "msg-type" su REPLY, e copiando l'ID di transazione dal messaggio Confirm nel campo transaction-id.

Il server DEVE includere un'opzione Server Identifier contenente il DUID del server e l'opzione Client Identifier dal messaggio Confirm nel messaggio Reply. Il server include un'opzione Status Code che indica lo stato del messaggio Confirm.

18.2.3. Ricezione di messaggi Renew

Quando il server riceve un messaggio Renew in unicast da un client a cui il server non ha inviato un'opzione unicast, il server scarta il messaggio Renew e risponde con un messaggio Reply contenente un'opzione Status Code con il valore UseMulticast, un'opzione Server Identifier contenente il DUID del server, l'opzione Client Identifier dal messaggio del client, e nessun'altra opzione.

Quando il server riceve un messaggio Renew che contiene un'opzione IA da un client, individua il binding del client e verifica che le informazioni nella IA dal client corrispondano alle informazioni memorizzate per quel client.

Se il server non riesce a trovare una voce del client per la IA, il server restituisce la IA contenente nessun indirizzo con un'opzione Status Code impostata su NoBinding nel messaggio Reply.

Se il server trova che uno qualsiasi degli indirizzi non è appropriato per il link a cui il client è collegato, il server restituisce l'indirizzo al client con tempi di vita di 0.

Se il server trova gli indirizzi nella IA per il client, allora il server rinvia la IA al client con nuovi tempi di vita e tempi T1/T2. Il server può scegliere di cambiare l'elenco degli indirizzi e i tempi di vita degli indirizzi nelle IA che sono restituite al client.

Il server costruisce un messaggio Reply impostando il campo "msg-type" su REPLY, e copiando l'ID di transazione dal messaggio Renew nel campo transaction-id.

Il server DEVE includere un'opzione Server Identifier contenente il DUID del server e l'opzione Client Identifier dal messaggio Renew nel messaggio Reply.

Il server include altre opzioni contenenti informazioni di configurazione da restituire al client come descritto nella sezione 18.2.

18.2.4. Ricezione di messaggi Rebind

Quando il server riceve un messaggio Rebind che contiene un'opzione IA da un client, individua il binding del client e verifica che le informazioni nella IA dal client corrispondano alle informazioni memorizzate per quel client.

Se il server non riesce a trovare una voce del client per la IA e il server determina che gli indirizzi nella IA non sono appropriati per il link a cui l'interfaccia del client è collegata secondo le informazioni di configurazione esplicite del server, il server PUÒ inviare un messaggio Reply al client contenente la IA del client, con i tempi di vita per gli indirizzi nella IA impostati a zero. Questo Reply costituisce una notifica esplicita al client che gli indirizzi nella IA non sono più validi. In questa situazione, se il server non invia un messaggio Reply, scarta silenziosamente il messaggio Rebind.

Se il server trova che uno qualsiasi degli indirizzi non è più appropriato per il link a cui il client è collegato, il server restituisce l'indirizzo al client con tempi di vita di 0.

Se il server trova gli indirizzi nella IA per il client, allora il server DOVREBBE rinviare la IA al client con nuovi tempi di vita e tempi T1/T2.

Il server costruisce un messaggio Reply impostando il campo "msg-type" su REPLY, e copiando l'ID di transazione dal messaggio Rebind nel campo transaction-id.

Il server DEVE includere un'opzione Server Identifier contenente il DUID del server e l'opzione Client Identifier dal messaggio Rebind nel messaggio Reply.

Il server include altre opzioni contenenti informazioni di configurazione da restituire al client come descritto nella sezione 18.2.

18.2.5. Ricezione di messaggi Information-request

Quando il server riceve un messaggio Information-request, il client sta richiedendo informazioni di configurazione che non includono l'assegnazione di alcun indirizzo. Il server determina tutti i parametri di configurazione appropriati per il client, basandosi sulle politiche di configurazione del server note al server.

Il server costruisce un messaggio Reply impostando il campo "msg-type" su REPLY, e copiando l'ID di transazione dal messaggio Information-request nel campo transaction-id.

Il server DEVE includere un'opzione Server Identifier contenente il DUID del server nel messaggio Reply. Se il client ha incluso un'opzione Client Identification nel messaggio Information-request, il server copia quell'opzione nel messaggio Reply.

Il server include opzioni contenenti informazioni di configurazione da restituire al client come descritto nella sezione 18.2.

Se il messaggio Information-request ricevuto dal client non includeva un'opzione Client Identifier, il server DOVREBBE rispondere con un messaggio Reply contenente eventuali parametri di configurazione che non siano determinati dall'identità del client. Se il server sceglie di non rispondere, il client può continuare a ritrasmettere il messaggio Information-request indefinitamente.

18.2.6. Ricezione di messaggi Release

Quando il server riceve un messaggio Release in unicast da un client a cui il server non ha inviato un'opzione unicast, il server scarta il messaggio Release e risponde con un messaggio Reply contenente un'opzione Status Code con valore UseMulticast, un'opzione Server Identifier contenente il DUID del server, l'opzione Client Identifier dal messaggio del client, e nessun'altra opzione.

Al ricevimento di un messaggio Release valido, il server esamina le IA e gli indirizzi nelle IA per verificarne la validità. Se le IA nel messaggio sono in un binding per il client, e gli indirizzi nelle IA sono stati assegnati dal server a quelle IA, il server elimina gli indirizzi dalle IA e rende gli indirizzi disponibili per l'assegnazione ad altri client. Il server ignora gli indirizzi non assegnati alla IA, sebbene possa scegliere di registrare un errore.

Dopo che tutti gli indirizzi sono stati elaborati, il server genera un messaggio Reply e include un'opzione Status Code con valore Success, un'opzione Server Identifier con il DUID del server, e un'opzione Client Identifier con il DUID del client. Per ciascuna IA nel messaggio Release per cui il server non ha informazioni di binding, il server aggiunge un'opzione IA usando l'IAID dal messaggio Release, e include un'opzione Status Code con il valore NoBinding nell'opzione IA. Nessun'altra opzione è inclusa nell'opzione IA.

Un server può scegliere di conservare un registro di indirizzi e IA assegnati dopo che i tempi di vita sugli indirizzi sono scaduti per consentire al server di riassegnare gli indirizzi precedentemente assegnati a un client.

18.2.7. Ricezione di messaggi Decline

Quando il server riceve un messaggio Decline in unicast da un client a cui il server non ha inviato un'opzione unicast, il server scarta il messaggio Decline e risponde con un messaggio Reply contenente un'opzione Status Code con il valore UseMulticast, un'opzione Server Identifier contenente il DUID del server, l'opzione Client Identifier dal messaggio del client, e nessun'altra opzione.

Al ricevimento di un messaggio Decline valido, il server esamina le IA e gli indirizzi nelle IA per verificarne la validità. Se le IA nel messaggio sono in un binding per il client, e gli indirizzi nelle IA sono stati assegnati dal server a quelle IA, il server elimina gli indirizzi dalle IA. Il server ignora gli indirizzi non assegnati alla IA (sebbene possa scegliere di registrare un errore se trova tale indirizzo).

Il client ha trovato che gli indirizzi nei messaggi Decline sono già in uso sul suo link. Pertanto, il server DOVREBBE contrassegnare gli indirizzi rifiutati dal client in modo che tali indirizzi non siano assegnati ad altri client, e PUÒ scegliere di inviare una notifica che degli indirizzi sono stati rifiutati. La politica locale sul server determina quando gli indirizzi identificati in un messaggio Decline possono essere resi disponibili per l'assegnazione.

Dopo che tutti gli indirizzi sono stati elaborati, il server genera un messaggio Reply e include un'opzione Status Code con il valore Success, un'opzione Server Identifier con il DUID del server, e un'opzione Client Identifier con il DUID del client. Per ciascuna IA nel messaggio Decline per cui il server non ha informazioni di binding, il server aggiunge un'opzione IA usando l'IAID dal messaggio Release e include un'opzione Status Code con il valore NoBinding nell'opzione IA. Nessun'altra opzione è inclusa nell'opzione IA.

18.2.8. Trasmissione di messaggi Reply

Se il messaggio originale è stato ricevuto direttamente dal server, il server invia in unicast il messaggio Reply direttamente al client usando l'indirizzo nel campo indirizzo sorgente dal datagramma IP in cui il messaggio originale è stato ricevuto. Il messaggio Reply DEVE essere inviato in unicast attraverso l'interfaccia su cui il messaggio originale è stato ricevuto.

Se il messaggio originale è stato ricevuto in un messaggio Relay-forward, il server costruisce un messaggio Relay-reply con il messaggio Reply nel payload di un'opzione Relay Message (si veda la sezione 22.10). Se i messaggi Relay-forward includevano un'opzione Interface-id, il server copia quell'opzione nel messaggio Relay-reply. Il server invia in unicast il messaggio Relay-reply direttamente all'agente di relay usando l'indirizzo nel campo indirizzo sorgente dal datagramma IP in cui il messaggio Relay-forward è stato ricevuto.