19. Scambio di Configurazione Avviato dal Server DHCP
19. Scambio di Configurazione Avviato dal Server DHCP (DHCP Server-Initiated Configuration Exchange)
Un server avvia uno scambio di configurazione per fare in modo che i client DHCP ottengano nuovi indirizzi e altre informazioni di configurazione. Ad esempio, un amministratore può utilizzare uno scambio di configurazione avviato dal server quando i collegamenti 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 nuovo software.
19.1. Comportamento del Server (Server Behavior)
Un server invia un messaggio Reconfigure per far sì che un client avvii 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 su 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 desidera che il client ottenga nuove informazioni sugli indirizzi. Se il server identifica l'opzione IA nell'opzione Option Request, il server DEVE includere un'opzione IA che non contiene altre sotto-opzioni per identificare ciascuna IA che deve essere riconfigurata sul client.
A causa del rischio di attacchi denial of service contro i client DHCP, l'uso di un meccanismo di sicurezza è obbligatorio nei messaggi Reconfigure. Il server DEVE utilizzare 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 un messaggio Information-Request.
Il server NON DEVE includere altre opzioni nel Reconfigure tranne quelle specificamente consentite nella definizione delle singole opzioni.
Un server invia ciascun messaggio Reconfigure a un singolo client DHCP, utilizzando 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 utilizza un messaggio Relay-reply (come descritto nella sezione 20.3) per inviare il messaggio Reconfigure a un agente relay che inoltrerà il messaggio al client. Il server può ottenere l'indirizzo del client (e l'agente relay appropriato, se necessario) attraverso le informazioni che il server ha sui client che sono stati in contatto con il server, o attraverso un agente esterno.
Per riconfigurare più di un client, il server invia in unicast un messaggio separato a ciascun client. Il server può avviare contemporaneamente la riconfigurazione di più client; ad esempio, un server può inviare un messaggio Reconfigure a client aggiuntivi mentre gli scambi di messaggi di riconfigurazione precedenti sono ancora in corso.
Il messaggio Reconfigure fa sì che il client avvii 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 (qualunque 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 REC_TIMEOUT e attende nuovamente. Il server continua questo processo fino a quando non sono stati effettuati REC_MAX_RC tentativi infruttuosi, 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 (Receipt of Renew Messages)
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 tali IA e parametri non sono stati richiesti nel messaggio Renew dal client.
19.3. Ricezione di Messaggi Information-request (Receipt of Information-request Messages)
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 tali parametri non sono stati richiesti nel messaggio Information-request dal client.
19.4. Comportamento del Client (Client Behavior)
Un client riceve messaggi Reconfigure inviati alla porta UDP 546 su interfacce per le quali ha acquisito informazioni di configurazione tramite DHCP. Questi messaggi possono essere inviati in qualsiasi momento. Poiché i risultati di un evento di riconfigurazione possono influenzare i programmi a livello applicativo, il client DOVREBBE registrare questi eventi e PUÒ notificare questi programmi della modifica tramite un'interfaccia specifica dell'implementazione.
19.4.1. Ricezione di messaggi Reconfigure
Alla ricezione di un messaggio Reconfigure valido, il client risponde con un messaggio Renew o un messaggio Information-request come indicato dall'opzione Reconfigure Message (come definito nella sezione 22.19). Il client ignora il campo transaction-id nel messaggio Reconfigure ricevuto. Mentre la transazione è in corso, il client scarta silenziosamente tutti i messaggi 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 qualsiasi messaggio Reconfigure aggiuntivo fino al completamento dello scambio. I messaggi Reconfigure successivi fanno sì che il client avvii un nuovo scambio.
Come funziona questo meccanismo di fronte a messaggi Reconfigure duplicati o ritrasmessi? I messaggi duplicati verranno ignorati perché il client inizierà lo scambio dopo la ricezione del primo Reconfigure. I messaggi ritrasmessi attiveranno lo scambio (se il primo Reconfigure non è stato ricevuto dal client) o verranno ignorati. Il server può interrompere la ritrasmissione dei messaggi Reconfigure al client una volta che il server 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 è sufficientemente 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 tutte le opzioni 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 utilizza le stesse variabili e lo stesso algoritmo di ritrasmissione che utilizza con i messaggi Renew o Information-request generati come parte di uno scambio di configurazione avviato dal client. Vedere 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
Alla ricezione di un messaggio Reply valido, il client elabora le opzioni e imposta (o reimposta) i parametri di configurazione in modo appropriato. Il client registra e aggiorna le durate per tutti gli indirizzi specificati nelle IA nel messaggio Reply.