17. Sollecitazione di server DHCP

Questa sezione descrive come un client individua i server che assegneranno indirizzi alle IA appartenenti al client.

Il client è responsabile della creazione delle IA e della richiesta che un server assegni indirizzi IPv6 alla IA. Il client crea per prima cosa una IA e le assegna un IAID. Il client trasmette quindi un messaggio Solicit contenente un'opzione IA che descrive la IA. I server che possono assegnare indirizzi alla IA rispondono al client con un messaggio Advertise. Il client avvia quindi uno scambio di configurazione come descritto nella sezione 18.

Se il client accetterà un messaggio Reply con assegnazioni di indirizzi impegnate e altre risorse in risposta al messaggio Solicit, il client include un'opzione Rapid Commit (si veda la sezione 22.14) nel messaggio Solicit.

17.1. Comportamento del client

Un client usa il messaggio Solicit per individuare server DHCP configurati per assegnare indirizzi o restituire altri parametri di configurazione sul link a cui il client è collegato.

17.1.1. Creazione di messaggi Solicit

Il client imposta il campo "msg-type" su SOLICIT. 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 qualsiasi IA a cui vuole che il server assegni indirizzi. Il client PUÒ includere indirizzi nelle IA come suggerimento al server sugli indirizzi per i quali il client ha una preferenza. Il client NON DEVE includere alcuna altra opzione nel messaggio Solicit, salvo quanto specificamente consentito nella definizione delle singole opzioni.

Il client usa opzioni IA_NA per richiedere l'assegnazione di indirizzi non temporanei e usa opzioni IA_TA per richiedere l'assegnazione di indirizzi temporanei. Sia opzioni IA_NA che IA_TA, o una combinazione di entrambe, possono essere incluse nei messaggi DHCP.

Il client DOVREBBE includere un'opzione Option Request (si veda la sezione 22.7) per indicare le opzioni che il client è interessato a ricevere. Il client PUÒ inoltre includere istanze di quelle opzioni che sono identificate nell'opzione Option Request, 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) se il client è disposto ad accettare messaggi Reconfigure dal server.

17.1.2. Trasmissione di messaggi Solicit

Il primo messaggio Solicit dal client sull'interfaccia DEVE essere ritardato di una quantità casuale di tempo tra 0 e SOL_MAX_DELAY. Nel caso di un messaggio Solicit trasmesso quando DHCP è avviato da IPv6 Neighbor Discovery, il ritardo dà la quantità di tempo da attendere dopo che IPv6 Neighbor Discovery causa l'invocazione del protocollo di autoconfigurazione degli indirizzi con stato (stateful address autoconfiguration protocol) da parte del client (si veda la sezione 5.5.3 di RFC 2462). Questo ritardo casuale desincronizza i client che partono nello stesso momento (per esempio, dopo un'interruzione di corrente).

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

IRT   SOL_TIMEOUT
MRT   SOL_MAX_RT
MRC   0
MRD   0

Se il client ha incluso un'opzione Rapid Commit nel suo messaggio Solicit, il client termina il processo di attesa non appena riceve un messaggio Reply con un'opzione Rapid Commit.

Se il client è in attesa di un messaggio Advertise, il meccanismo nella sezione 14 è modificato come segue per l'uso nella trasmissione di messaggi Solicit. Lo scambio di messaggi non è terminato dalla ricezione di un Advertise prima che sia trascorso il primo RT. Piuttosto, il client raccoglie i messaggi Advertise finché non è trascorso il primo RT. Inoltre, il primo RT DEVE essere scelto in modo da essere strettamente maggiore di IRT scegliendo RAND strettamente maggiore di 0.

Un client DEVE raccogliere i messaggi Advertise per i primi RT secondi, a meno che non riceva un messaggio Advertise con un valore di preferenza di 255. Il valore di preferenza è trasportato nell'opzione Preference (sezione 22.8). Qualsiasi Advertise che non include un'opzione Preference è considerato avere un valore di preferenza di 0. Se il client riceve un messaggio Advertise che include un'opzione Preference con un valore di preferenza di 255, il client inizia immediatamente uno scambio di messaggi avviato dal client (come descritto nella sezione 18) inviando un messaggio Request al server da cui è stato ricevuto il messaggio Advertise. Se il client riceve un messaggio Advertise che non include un'opzione Preference con un valore di preferenza di 255, il client continua ad attendere finché non trascorre il primo RT. Se trascorre il primo RT e il client ha ricevuto un messaggio Advertise, il client DOVREBBE proseguire con uno scambio di messaggi avviato dal client inviando un messaggio Request.

Se il client non riceve alcun messaggio Advertise prima che trascorra il primo RT, inizia il meccanismo di ritrasmissione descritto nella sezione 14. Il client termina il processo di ritrasmissione non appena riceve qualsiasi messaggio Advertise, e il client agisce sul messaggio Advertise ricevuto senza attendere ulteriori messaggi Advertise.

Un client DHCP DOVREBBE scegliere MRC e MRD pari a 0. Se il client DHCP è configurato con MRC o MRD impostati a un valore diverso da 0, DEVE smettere di tentare di configurare l'interfaccia se lo scambio di messaggi fallisce. Dopo che il client DHCP ha smesso di tentare di configurare l'interfaccia, DOVREBBE riavviare il processo di riconfigurazione dopo qualche evento esterno, come un input utente, un riavvio di sistema, o quando il client è collegato a un nuovo link.

17.1.3. Ricezione di messaggi Advertise

Il client DEVE ignorare qualsiasi messaggio Advertise che include un'opzione Status Code contenente il valore NoAddrsAvail, con l'eccezione che il client PUÒ visualizzare il relativo messaggio di stato all'utente.

Al ricevimento di uno o più messaggi Advertise validi, il client seleziona uno o più messaggi Advertise in base ai seguenti criteri.

Quelli con il valore di preferenza del server più alto sono preferiti rispetto a tutti gli altri messaggi Advertise.
All'interno di un gruppo di messaggi Advertise con lo stesso valore di preferenza del server, un client PUÒ selezionare quei server i cui messaggi Advertise pubblicizzano informazioni di interesse per il client. Per esempio, il client può scegliere un server che ha restituito una pubblicità con opzioni di configurazione di interesse per il client.
Il client PUÒ scegliere un server meno preferito se quel server ha un migliore insieme di parametri pubblicizzati, come gli indirizzi disponibili pubblicizzati nelle IA.

Una volta selezionato/i il/i messaggio/i Advertise, il client tipicamente memorizzerà informazioni su ciascun server, come il valore di preferenza del server, gli indirizzi pubblicizzati, quando è stata ricevuta la pubblicità, e così via.

Se il client deve selezionare un server alternativo nel caso in cui un server scelto non risponda, il client sceglie il server successivo secondo i criteri sopra indicati.

17.1.4. Ricezione di messaggi Reply

Se il client include un'opzione Rapid Commit nel messaggio Solicit, si aspetterà un messaggio Reply che include un'opzione Rapid Commit in risposta. Il client scarta tutti i messaggi Reply che riceve che non includono un'opzione Rapid Commit. Se il client riceve un messaggio Reply valido che include un'opzione Rapid Commit, elabora il messaggio come descritto nella sezione 18.1.8. Se non riceve tale messaggio Reply e riceve invece un messaggio Advertise valido, il client elabora il messaggio Advertise come descritto nella sezione 17.1.3.

Se il client riceve successivamente un messaggio Reply valido che include un'opzione Rapid Commit, esso o:

elabora il messaggio Reply come descritto nella sezione 18.1.8, e scarta tutti i messaggi Reply ricevuti in risposta al messaggio Request, oppure
elabora tutti i messaggi Reply ricevuti in risposta al messaggio Request e scarta il messaggio Reply che include l'opzione Rapid Commit.

17.2. Comportamento del server

Un server invia un messaggio Advertise in risposta ai messaggi Solicit validi che riceve per annunciare la disponibilità del server al client.

17.2.1. Ricezione di messaggi Solicit

Il server determina le informazioni sul client e sulla sua posizione come descritto nella sezione 11 e verifica la propria politica amministrativa circa la risposta al client. Se al server non è permesso rispondere al client, il server scarta il messaggio Solicit. Per esempio, se la politica amministrativa per il server è che esso può rispondere solo a un client disposto ad accettare un messaggio Reconfigure, se il client indica con un'opzione Reconfigure Accept nel messaggio Solicit che non accetterà un messaggio Reconfigure, i server scartano il messaggio Solicit.

Se il client ha incluso un'opzione Rapid Commit nel messaggio Solicit e il server è stato configurato per rispondere con assegnazioni di indirizzi impegnate e altre risorse, il server risponde al Solicit con un messaggio Reply come descritto nella sezione 17.2.3. Altrimenti, il server ignora l'opzione Rapid Commit ed elabora la parte rimanente del messaggio come se non fosse presente alcuna opzione Rapid Commit.

17.2.2. Creazione e trasmissione di messaggi Advertise

Il server imposta il campo "msg-type" su ADVERTISE e copia il contenuto del campo transaction-id dal messaggio Solicit ricevuto dal client nel messaggio Advertise. Il server include il proprio identificatore di server in un'opzione Server Identifier e copia il Client Identifier dal messaggio Solicit nel messaggio Advertise.

Il server PUÒ aggiungere un'opzione Preference per trasportare il valore di preferenza per il messaggio Advertise. L'implementazione del server DOVREBBE consentire l'impostazione di un valore di preferenza del server da parte dell'amministratore. Il valore di preferenza del server DEVE essere predefinito a zero a meno che non sia diversamente configurato dall'amministratore del server.

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

Il server include le opzioni che il server restituirà al client in un successivo messaggio Reply. Le informazioni in queste opzioni possono essere usate dal client nella selezione di un server se il client riceve più di un messaggio Advertise. Se il client ha incluso un'opzione Option Request nel messaggio Solicit, il server include nel messaggio Advertise 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. Il server deve essere consapevole delle raccomandazioni sulle dimensioni dei pacchetti e sull'uso della frammentazione nella sezione 5 di RFC 2460.

Se il messaggio Solicit dal client includeva una o più opzioni IA, il server DEVE includere opzioni IA nel messaggio Advertise contenenti gli indirizzi che sarebbero assegnati alle IA contenute nel messaggio Solicit dal client. Se il client ha incluso indirizzi nelle IA nel messaggio Solicit, il server usa tali indirizzi come suggerimenti sugli indirizzi che il client vorrebbe ricevere.

Se il server non assegnerà alcun indirizzo a nessuna IA in una successiva Request dal client, il server DEVE inviare un messaggio Advertise al client che include solo un'opzione Status Code con codice NoAddrsAvail e un messaggio di stato per l'utente, un'opzione Server Identifier con il DUID del server, e un'opzione Client Identifier con il DUID del client.

Se il messaggio Solicit è stato ricevuto direttamente dal server, il server invia in unicast il messaggio Advertise direttamente al client usando l'indirizzo nel campo indirizzo sorgente dal datagramma IP in cui il messaggio Solicit è stato ricevuto. Il messaggio Advertise DEVE essere inviato in unicast sul link da cui il messaggio Solicit è stato ricevuto.

Se il messaggio Solicit è stato ricevuto in un messaggio Relay-forward, il server costruisce un messaggio Relay-reply con il messaggio Advertise nel payload di un'opzione "relay-message". 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.

17.2.3. Creazione e trasmissione di messaggi Reply

Il server DEVE impegnare l'assegnazione di qualsiasi indirizzo o altra informazione di configurazione prima di inviare un messaggio Reply a un client in risposta a un messaggio Solicit.

DISCUSSIONE:

Quando si usa lo scambio di messaggi Solicit-Reply, il server impegna l'assegnazione di qualsiasi indirizzo prima di inviare il messaggio Reply. Il client può presumere che gli siano stati assegnati gli indirizzi nel messaggio Reply e non ha bisogno di inviare un messaggio Request per quegli indirizzi.

Tipicamente, i server configurati per usare lo scambio di messaggi Solicit-Reply saranno distribuiti in modo che solo un server risponda a un messaggio Solicit. Se più di un server risponde, il client userà solo gli indirizzi di uno dei server, mentre gli indirizzi dagli altri server saranno impegnati per il client ma non usati dal client.

Il server include un'opzione Rapid Commit nel messaggio Reply per indicare che il Reply è in risposta a un messaggio Solicit.

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

Il server produce il messaggio Reply come se avesse ricevuto un messaggio Request, come descritto nella sezione 18.2.1. Il server trasmette il messaggio Reply come descritto nella sezione 18.2.8.