19. Scambio di configurazione avviato dal server DHCP

Un server avvia uno scambio di configurazione per causare ai client DHCP di ottenere nuovi indirizzi e altre informazioni di configurazione. Per esempio, un amministratore può usare uno scambio di configurazione avviato dal server quando i link nel dominio DHCP devono essere rinumerati. Altri esempi includono modifiche nella posizione dei server di directory, aggiunta di nuovi servizi come la stampa, e disponibilità di nuovi software.

19.1. Comportamento del server

Un server invia un messaggio Reconfigure per causare a un client di avviare immediatamente uno scambio di messaggi Renew/Reply o Information-request/Reply con il server.

19.1.1. Creazione e trasmissione di messaggi Reconfigure

Il server imposta il campo "msg-type" su RECONFIGURE. Il server imposta il campo transaction-id a 0. Il server include un'opzione Server Identifier contenente il proprio DUID e un'opzione Client Identifier contenente il DUID del client nel messaggio Reconfigure.

Il server PUÒ includere un'opzione Option Request per informare il client di quali informazioni sono state modificate o di nuove informazioni che sono state aggiunte. In particolare, il server specifica l'opzione IA nell'opzione Option Request se il server vuole che il client ottenga nuove informazioni sugli indirizzi. Se il server individua l'opzione IA nell'opzione Option Request, il server DEVE includere un'opzione IA che non contiene altre sub-option per identificare ciascuna IA che deve essere riconfigurata sul client.

A causa del rischio di attacchi di denial of service contro i client DHCP, l'uso di un meccanismo di sicurezza è obbligatorio nei messaggi Reconfigure. Il server DEVE usare l'autenticazione DHCP nel messaggio Reconfigure.

Il server DEVE includere un'opzione Reconfigure Message (definita nella sezione 22.19) per selezionare se il client risponde con un messaggio Renew o con un messaggio Information-Request.

Il server NON DEVE includere alcuna altra opzione nel messaggio Reconfigure, salvo quanto specificamente consentito nella definizione delle singole opzioni.

Un server invia ciascun messaggio Reconfigure a un singolo client DHCP, usando un indirizzo IPv6 unicast di ambito sufficiente appartenente al client DHCP. Se il server non ha un indirizzo a cui può inviare il messaggio Reconfigure direttamente al client, il server usa un messaggio Relay-reply (come descritto nella sezione 20.3) per inviare il messaggio Reconfigure a un agente di relay che inoltrerà il messaggio al client. Il server può ottenere l'indirizzo del client (e dell'agente di relay appropriato, se richiesto) attraverso le informazioni che il server possiede sui client che sono stati in contatto con il server, o attraverso qualche agente esterno.

Per riconfigurare più di un client, il server invia in unicast un messaggio separato a ciascun client. Il server può avviare la riconfigurazione di più client contemporaneamente; per esempio, un server può inviare un messaggio Reconfigure ad altri client mentre scambi di messaggi di riconfigurazione precedenti sono ancora in corso.

Il messaggio Reconfigure causa al client di avviare uno scambio di messaggi Renew/Reply o Information-request/Reply con il server. Il server interpreta la ricezione di un messaggio Renew o Information-request (quale che sia stato specificato nel messaggio Reconfigure originale) dal client come soddisfacimento della richiesta del messaggio Reconfigure.

19.1.2. Timeout e ritrasmissione di messaggi Reconfigure

Se il server non riceve un messaggio Renew o Information-request dal client entro REC_TIMEOUT millisecondi, il server ritrasmette il messaggio Reconfigure, raddoppia il valore di REC_TIMEOUT e attende di nuovo. Il server continua questo processo finché non sono stati fatti REC_MAX_RC tentativi non riusciti, momento in cui il server DOVREBBE interrompere il processo di riconfigurazione per quel client.

I valori predefiniti e iniziali per REC_TIMEOUT e REC_MAX_RC sono documentati nella sezione 5.5.

19.2. Ricezione di messaggi Renew

Il server genera e invia un messaggio Reply al client come descritto nelle sezioni 18.2.3 e 18.2.8, includendo opzioni per i parametri di configurazione.

Il server PUÒ includere opzioni contenenti le IA e nuovi valori per altri parametri di configurazione nel messaggio Reply, anche se quelle IA e quei parametri non erano stati richiesti nel messaggio Renew dal client.

19.3. Ricezione di messaggi Information-request

Il server genera e invia un messaggio Reply al client come descritto nelle sezioni 18.2.5 e 18.2.8, includendo opzioni per i parametri di configurazione.

Il server PUÒ includere opzioni contenenti nuovi valori per altri parametri di configurazione nel messaggio Reply, anche se quei parametri non erano stati richiesti nel messaggio Information-request dal client.

19.4. Comportamento del client

Un client riceve messaggi Reconfigure inviati alla porta UDP 546 sulle interfacce per le quali ha ottenuto informazioni di configurazione tramite DHCP. Questi messaggi possono essere inviati in qualsiasi momento. Poiché i risultati di un evento di riconfigurazione possono interessare programmi a livello di applicazione, il client DOVREBBE registrare questi eventi, e PUÒ notificare tali programmi della modifica attraverso un'interfaccia specifica dell'implementazione.

19.4.1. Ricezione di messaggi Reconfigure

Al ricevimento di un messaggio Reconfigure valido, il client risponde con un messaggio Renew o un messaggio Information-request come indicato dall'opzione Reconfigure Message (come definita nella sezione 22.19). Il client ignora il campo transaction-id nel messaggio Reconfigure ricevuto. Mentre la transazione è in corso, il client scarta silenziosamente qualsiasi messaggio Reconfigure che riceve.

DISCUSSIONE:

Il messaggio Reconfigure agisce come un trigger che segnala al client di completare uno scambio di messaggi riuscito. Una volta che il client ha ricevuto un Reconfigure, il client procede con lo scambio di messaggi (ritrasmettendo il messaggio Renew o Information-request se necessario); il client ignora ulteriori messaggi Reconfigure finché lo scambio non è completato. Messaggi Reconfigure successivi causano al client di avviare un nuovo scambio.

Come funziona questo meccanismo di fronte a messaggi Reconfigure duplicati o ritrasmessi? I messaggi duplicati saranno ignorati perché il client inizierà lo scambio dopo la ricezione del primo Reconfigure. I messaggi ritrasmessi o innescheranno lo scambio (se il primo Reconfigure non era stato ricevuto dal client) o saranno ignorati. Il server può interrompere la ritrasmissione di messaggi Reconfigure al client una volta che riceve il messaggio Renew o Information-request dal client.

Potrebbe essere possibile che un Reconfigure duplicato o ritrasmesso sia sufficientemente ritardato (e consegnato fuori ordine) da arrivare al client dopo che lo scambio (avviato dal Reconfigure originale) è stato completato. In questo caso, il client avvierebbe uno scambio ridondante. La probabilità di consegna ritardata e fuori ordine è abbastanza piccola da essere ignorata. La conseguenza dello scambio ridondante è l'inefficienza piuttosto che un funzionamento errato.

19.4.2. Creazione e trasmissione di messaggi Renew

Quando risponde a un Reconfigure, il client crea e invia il messaggio Renew esattamente nello stesso modo descritto nella sezione 18.1.3, con l'eccezione che il client copia l'opzione Option Request e qualsiasi opzione IA dal messaggio Reconfigure nel messaggio Renew.

19.4.3. Creazione e trasmissione di messaggi Information-request

Quando risponde a un Reconfigure, il client crea e invia il messaggio Information-request esattamente nello stesso modo descritto nella sezione 18.1.5, con l'eccezione che il client include un'opzione Server Identifier con l'identificatore dal messaggio Reconfigure a cui il client sta rispondendo.

19.4.4. Timeout e ritrasmissione di messaggi Renew o Information-request

Il client usa le stesse variabili e lo stesso algoritmo di ritrasmissione che usa con i messaggi Renew o Information-request generati come parte di uno scambio di configurazione avviato dal client. Si vedano le sezioni 18.1.3 e 18.1.5 per i dettagli. Se il client non riceve una risposta dal server entro la fine del processo di ritrasmissione, il client ignora e scarta il messaggio Reconfigure.

19.4.5. Ricezione di messaggi Reply

Al ricevimento di un messaggio Reply valido, il client elabora le opzioni e imposta (o reimposta) i parametri di configurazione appropriatamente. Il client registra e aggiorna i tempi di vita per tutti gli indirizzi specificati nelle IA nel messaggio Reply.