18. Scambio di configurazione avviato dal client DHCP (DHCP Client-Initiated Configuration Exchange)

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 dallo strato applicativo, quando richiesto dall'Autoconfigu razione Stateless degli Indirizzi (Stateless Address Autoconfiguration) o quando necessario per estendere la durata di un indirizzo (messaggi Renew e Rebind).

18.1. Comportamento del client (Client Behavior)

Un client utilizza i messaggi Request, Renew, Rebind, Release e Decline durante il ciclo di vita normale degli indirizzi. Utilizza Confirm per validare gli indirizzi quando potrebbe essersi spostato su un nuovo collegamento. Utilizza i messaggi Information-Request quando necessita di informazioni di configurazione ma non di indirizzi.

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

DISCUSSIONE (DISCUSSION):

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

18.1.1. Creazione e trasmissione dei messaggi Request (Creation and Transmission of Request Messages)

Il client utilizza 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 quindi restituisce 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 posiziona l'identificatore del server di destinazione in un'opzione Server Identifier.

Il client DEVE (MUST) includere un'opzione Client Identifier per identificarsi al server. Il client aggiunge qualsiasi altra opzione appropriata, inclusa una o più opzioni IA (se il client sta richiedendo che il server gli assegni alcuni indirizzi di rete).

Il client DEVE (MUST) includere un'opzione Option Request (vedere sezione 22.7) per indicare le opzioni che il client è interessato a ricevere. Il client PUÒ (MAY) includere opzioni con valori di dati come suggerimenti al server sui valori dei parametri che il client vorrebbe ricevere.

Il client include un'opzione Reconfigure Accept (vedere 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, utilizzando 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; ad esempio, server che hanno risposto con un messaggio Advertise.
• Avviare il processo di scoperta del server descritto nella sezione 17.
• Terminare il processo di configurazione e segnalare un fallimento.

18.1.2. Creazione e trasmissione dei messaggi Confirm (Creation and Transmission of Confirm Messages)

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

• Il client si riavvia.
• Il client è fisicamente collegato a una connessione cablata.
• Il client ritorna dalla modalità sleep.
• Il client che utilizza una tecnologia wireless cambia punto di accesso.

In qualsiasi situazione in cui un client potrebbe essersi spostato su un nuovo collegamento, il client DEVE (MUST) avviare uno scambio di messaggi Confirm/Reply. Il client include qualsiasi IA assegnata all'interfaccia che potrebbe essersi spostata su un nuovo collegamento, insieme agli indirizzi associati a tali IA, nel suo messaggio Confirm. Tutti i server che rispondono indicheranno se tali indirizzi sono appropriati per il collegamento a cui il client è collegato con lo stato nel messaggio Reply che restituiscono 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 (MUST) includere un'opzione Client Identifier per identificarsi al server. Il client include opzioni IA per tutte le IA assegnate all'interfaccia per cui viene inviato il messaggio Confirm. Le opzioni IA includono tutti gli indirizzi che il client ha attualmente associato a tali IA. Il client DOVREBBE (SHOULD) impostare i campi T1 e T2 in tutte le opzioni IA_NA, e i campi preferred-lifetime e valid-lifetime nelle opzioni IA Address su 0, poiché il server ignorerà questi campi.

Il primo messaggio Confirm dal client sull'interfaccia DEVE (MUST) essere ritardato di un tempo casuale compreso tra 0 e CNF_MAX_DELAY. Il client trasmette il messaggio secondo la sezione 14, utilizzando 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 (SHOULD) continuare a utilizzare qualsiasi indirizzo IP, utilizzando le ultime durate di vita note per tali indirizzi, e DOVREBBE (SHOULD) continuare a utilizzare qualsiasi altro parametro di configurazione precedentemente ottenuto.

18.1.3. Creazione e trasmissione dei messaggi Renew (Creation and Transmission of Renew Messages)

Per estendere le durate di vita valide e preferite 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 nuove durate 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 le durate di vita preferite e valide di tali indirizzi a zero.

Il server controlla il momento in cui il client contatta il server per estendere le durate 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 le durate di vita di 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 su 0 dal server (per una IA_NA) o se 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 posiziona l'identificatore del server di destinazione in un'opzione Server Identifier.

Il client DEVE (MUST) includere un'opzione Client Identifier per identificarsi al server. Il client aggiunge qualsiasi opzione appropriata, inclusa una o più opzioni IA. Il client DEVE (MUST) includere l'elenco degli indirizzi che il client ha attualmente associato alle IA nel messaggio Renew.

Il client DEVE (MUST) includere un'opzione Option Request (vedere sezione 22.7) per indicare le opzioni che il client è interessato a ricevere. Il client PUÒ (MAY) includere opzioni con valori di dati come suggerimenti al server sui valori dei parametri che il client vorrebbe ricevere.

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

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

Lo scambio di messaggi termina quando viene raggiunto il tempo T2 (vedere sezione 18.1.4), momento in cui il client inizia uno scambio di messaggi Rebind.

18.1.4. Creazione e trasmissione dei messaggi Rebind (Creation and Transmission of Rebind Messages)

Al tempo T2 per una IA (che verrà 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 DEVE (MUST) includere un'opzione Client Identifier per identificarsi al server. Il client aggiunge qualsiasi opzione appropriata, inclusa una o più opzioni IA. Il client DEVE (MUST) includere l'elenco degli indirizzi che il client ha attualmente associato alle IA nel messaggio Rebind.

Il client DEVE (MUST) includere un'opzione Option Request (vedere sezione 22.7) per indicare le opzioni che il client è interessato a ricevere. Il client PUÒ (MAY) includere opzioni con valori di dati come suggerimenti al server sui valori dei parametri che il client vorrebbe ricevere.

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

IRT   REB_TIMEOUT
MRT   REB_MAX_RT
MRC   0
MRD   Tempo rimanente fino alla scadenza delle durate di vita valide di tutti gli indirizzi

Lo scambio di messaggi termina quando scadono le durate di vita valide di tutti gli indirizzi assegnati alla IA (vedere sezione 10), momento in cui il client ha diverse azioni alternative tra cui scegliere; ad esempio:

• Il client può scegliere di utilizzare un messaggio Solicit per localizzare 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 utilizzare gli indirizzi nelle altre IA.

18.1.5. Creazione e trasmissione dei messaggi Information-request (Creation and Transmission of Information-request Messages)

Il client utilizza un messaggio Information-request per ottenere informazioni di configurazione senza che gli vengano 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 (SHOULD) includere un'opzione Client Identifier per identificarsi al server. Se il client non include un'opzione Client Identifier, il server non sarà in grado di restituire opzioni specifiche del client al client, o il server può scegliere di non rispondere affatto al messaggio. Il client DEVE (MUST) includere un'opzione Client Identifier se il messaggio Information-Request verrà autenticato.

Il client DEVE (MUST) includere un'opzione Option Request (vedere sezione 22.7) per indicare le opzioni che il client è interessato a ricevere. Il client PUÒ (MAY) includere opzioni con valori di dati come suggerimenti al server sui valori dei parametri che il client vorrebbe ricevere.

Il primo messaggio Information-request dal client sull'interfaccia DEVE (MUST) essere ritardato di un tempo casuale compreso tra 0 e INF_MAX_DELAY. Il client trasmette il messaggio secondo la sezione 14, utilizzando i seguenti parametri:

IRT   INF_TIMEOUT
MRT   INF_MAX_RT
MRC   0
MRD   0

18.1.6. Creazione e trasmissione dei messaggi Release (Creation and Transmission of Release Messages)

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 posiziona questo valore nel campo "transaction-id".

Il client posiziona l'identificatore del server che ha allocato gli indirizzi in un'opzione Server Identifier.

Il client DEVE (MUST) includere un'opzione Client Identifier per identificarsi al server. Il client include opzioni contenenti le IA per gli indirizzi che sta rilasciando nel campo "options". Gli indirizzi da rilasciare DEVONO (MUST) essere inclusi nelle IA. Qualsiasi indirizzo per le IA che il client desidera continuare a utilizzare NON DEVE (MUST NOT) essere aggiunto alle IA.

Il client NON DEVE (MUST NOT) utilizzare nessuno degli indirizzi che sta rilasciando come indirizzo di origine nel messaggio Release o in qualsiasi messaggio trasmesso successivamente.

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

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

IRT   REL_TIMEOUT
MRT   0
MRC   REL_MAX_RC
MRD   0

Il client DEVE (MUST) smettere di utilizzare tutti gli indirizzi rilasciati non appena il client inizia il processo di scambio del messaggio Release. Se gli indirizzi vengono rilasciati ma il Reply da un server DHCP viene perso, il client ritrasmette il messaggio Release, e il server può rispondere con un Reply che indica 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, ogni indirizzo assegnato alla IA verrà recuperato dal server quando scade la durata di vita valida di quell'indirizzo.

18.1.7. Creazione e trasmissione dei messaggi Decline (Creation and Transmission of Decline Messages)

Se un client rileva che uno o più indirizzi assegnatigli 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 posiziona questo valore nel campo "transaction-id".

Il client posiziona l'identificatore del server che ha allocato gli indirizzi in un'opzione Server Identifier.

Il client DEVE (MUST) includere un'opzione Client Identifier per identificarsi al server. Il client include opzioni contenenti le IA per gli indirizzi che sta rifiutando nel campo "options". Gli indirizzi da rifiutare DEVONO (MUST) essere inclusi nelle IA. Qualsiasi indirizzo per le IA che il client desidera continuare a utilizzare non dovrebbe essere aggiunto alle IA.

Il client NON DEVE (MUST NOT) utilizzare nessuno degli indirizzi che sta rifiutando come indirizzo di origine nel messaggio Decline o in qualsiasi messaggio trasmesso successivamente.

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

IRT   DEC_TIMEOUT
MRT   0
MRC   DEC_MAX_RC
MRD   0

Se gli indirizzi vengono rifiutati ma il Reply da un server DHCP viene perso, il client ritrasmette il messaggio Decline, e il server può rispondere con un Reply che indica 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 dei messaggi Reply (Receipt of Reply Messages)

Alla ricezione 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Ò (MAY) scegliere di segnalare qualsiasi codice di stato o messaggio dall'opzione codice di stato nel messaggio Reply.

Il client DOVREBBE (SHOULD) eseguire il rilevamento di indirizzi duplicati [17] su ciascuno degli indirizzi in qualsiasi IA che riceve nel messaggio Reply prima di utilizzare quell'indirizzo per il traffico. Se uno degli indirizzi risulta essere in uso sul collegamento, il client invia un messaggio Decline al server come descritto nella sezione 18.1.7.

Se il Reply è stato ricevuto in risposta a un messaggio 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:

• Registrare i tempi T1 e T2.
• Aggiungere tutti i nuovi indirizzi nell'opzione IA alla IA come registrato dal client.
• Aggiornare le durate di vita per tutti gli indirizzi nell'opzione IA che il client ha già registrato nella IA.
• Scartare tutti gli indirizzi dalla IA, come registrato dal client, che hanno una durata di vita valida di 0 nell'opzione IA Address.
• Lasciare invariate tutte le informazioni sugli indirizzi che il client ha registrato nella IA ma che non erano inclusi nella IA dal server.

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

Se il client riceve un messaggio Reply con un codice di stato contenente UnspecFail, il server sta indicando che non è stato in grado di 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 (MUST) limitare la velocità con cui ritrasmette il messaggio e limitare la durata del tempo durante il quale ritrasmette il messaggio.

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

Quando il client riceve uno stato NotOnLink dal server in risposta a un messaggio Confirm, il client esegue la sollecitazione del 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ò utilizzare gli indirizzi nella IA e ignorare tutti i messaggi che indicano uno stato NotOnLink.

Quando il client riceve uno stato NotOnLink dal server in risposta a una Request, il client può riemettere la Request senza specificare indirizzi o riavviare il processo di scoperta del server DHCP (vedere 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 utilizza indirizzi e altre informazioni da qualsiasi IA che non contiene un'opzione Status Code con il codice NoAddrsAvail. Se il client non riceve indirizzi in nessuna delle IA, può provare un altro server (forse riavviando il processo di scoperta del server DHCP) o utilizzare 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 (Server Behavior)

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

Nella maggior parte dei casi, il server invierà un Reply in risposta a un messaggio client. Questo messaggio Reply DEVE (MUST) sempre contenere l'opzione Server Identifier contenente il DUID del server e l'opzione Client Identifier dal messaggio 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 opzioni nel messaggio Reply 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Ò (MAY) restituire opzioni aggiuntive al client se è stato configurato per farlo.

18.2.1. Ricezione dei messaggi Request (Receipt of Request Messages)

Quando il server riceve un messaggio Request tramite 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 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 (MUST) includere un'opzione Server Identifier contenente il DUID del server e l'opzione Client Identifier dal messaggio Request nel messaggio Reply.

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

Se il server non può assegnare indirizzi a una IA nel messaggio dal client, il server DEVE (MUST) includere la IA nel messaggio Reply senza indirizzi nella IA e 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 nuovo binding client.

Il server include un'opzione Reconfigure Accept se il server desidera 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 scopre 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 reinviato un messaggio Request per cui non ha ricevuto un messaggio Reply. Il server reinvia un messaggio Reply precedentemente memorizzato nella cache o invia un nuovo messaggio Reply.

18.2.2. Ricezione dei messaggi Confirm (Receipt of Confirm Messages)

Quando il server riceve un messaggio Confirm, il server determina se gli indirizzi nel messaggio Confirm sono appropriati per il collegamento a cui il client è collegato. Se tutti gli indirizzi nel messaggio Confirm superano questo test, il server restituisce uno stato di Success. Se uno degli indirizzi non supera questo test, il server restituisce uno stato di NotOnLink. Se il server non è in grado di eseguire questo test (ad esempio, il server non ha informazioni sui prefissi sul collegamento a cui il client è connesso), o se non c'erano indirizzi in nessuna delle IA inviate dal client, il server NON DEVE (MUST NOT) 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 (MUST) 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 dei messaggi Renew (Receipt of Renew Messages)

Quando il server riceve un messaggio Renew tramite 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 client e nessun'altra opzione.

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

Se il server non può trovare una voce client per la IA, il server restituisce la IA senza indirizzi con un'opzione Status Code impostata su NoBinding nel messaggio Reply.

Se il server scopre che uno degli indirizzi non è appropriato per il collegamento a cui il client è collegato, il server restituisce l'indirizzo al client con durate di vita di 0.

Se il server trova gli indirizzi nella IA per il client, il server invia la IA al client con nuove durate di vita e tempi T1/T2. Il server può scegliere di modificare l'elenco degli indirizzi e le durate di vita degli indirizzi nelle IA che vengono 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 (MUST) 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 dei messaggi Rebind (Receipt of Rebind Messages)

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

Se il server non può trovare una voce client per la IA e il server determina che gli indirizzi nella IA non sono appropriati per il collegamento a cui l'interfaccia del client è collegata secondo le informazioni di configurazione esplicite del server, il server PUÒ (MAY) inviare un messaggio Reply al client contenente la IA del client, con le durate di vita per gli indirizzi nella IA impostate 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 scopre che uno degli indirizzi non è più appropriato per il collegamento a cui il client è collegato, il server restituisce l'indirizzo al client con durate di vita di 0.

Se il server trova gli indirizzi nella IA per il client, il server DOVREBBE (SHOULD) inviare la IA al client con nuove durate 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 (MUST) 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 dei messaggi Information-request (Receipt of Information-request Messages)

Quando il server riceve un messaggio Information-request, il client sta richiedendo informazioni di configurazione che non includono l'assegnazione di indirizzi. Il server determina tutti i parametri di configurazione appropriati per il client, in base alle 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 (MUST) 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 (SHOULD) rispondere con un messaggio Reply contenente parametri di configurazione che non sono 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 dei messaggi Release (Receipt of Release Messages)

Quando il server riceve un messaggio Release tramite 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 client e nessun'altra opzione.

Alla ricezione di un messaggio Release valido, il server esamina le IA e gli indirizzi nelle IA per 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 utilizzando 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 degli indirizzi e IA assegnati dopo la scadenza delle durate di vita sugli indirizzi per consentire al server di riassegnare gli indirizzi precedentemente assegnati a un client.

18.2.7. Ricezione dei messaggi Decline (Receipt of Decline Messages)

Quando il server riceve un messaggio Decline tramite 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 client e nessun'altra opzione.

Alla ricezione di un messaggio Decline valido, il server esamina le IA e gli indirizzi nelle IA per 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 un tale indirizzo).

Il client ha trovato tutti gli indirizzi nei messaggi Decline già in uso sul suo collegamento. Pertanto, il server DOVREBBE (SHOULD) marcare gli indirizzi rifiutati dal client in modo che tali indirizzi non vengano assegnati ad altri client, e PUÒ (MAY) scegliere di fare una notifica che gli 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 utilizzando 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 dei messaggi Reply (Transmission of Reply Messages)

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

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 (vedere 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 relay utilizzando l'indirizzo nel campo indirizzo di origine dal datagramma IP in cui è stato ricevuto il messaggio Relay-forward.