17. Sollecitazione del Server DHCP

Questa sezione descrive come un client localizza i server che assegneranno indirizzi agli IA appartenenti al client.

Il client è responsabile della creazione degli IA e della richiesta che un server assegni indirizzi IPv6 all'IA. Il client crea prima un IA e gli assegna un IAID. Il client trasmette quindi un messaggio Solicit contenente un'opzione IA che descrive l'IA. I server che possono assegnare indirizzi all'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 (vedere sezione 22.14) nel messaggio Solicit.

17.1. Comportamento del Client

Un client utilizza il messaggio Solicit per scoprire server DHCP configurati per assegnare indirizzi o restituire altri parametri di configurazione sul collegamento a cui il client è connesso.

17.1.1. Creazione di Messaggi Solicit

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

Il client DEVE (MUST) includere un'opzione Identificatore Client per identificarsi al server. Il client include opzioni IA per qualsiasi IA a cui desidera che il server assegni indirizzi. Il client PUÒ (MAY) includere indirizzi negli IA come suggerimento al server sugli indirizzi per i quali il client ha una preferenza. Il client NON DEVE (MUST NOT) includere altre opzioni nel messaggio Solicit, tranne come specificamente consentito nella definizione delle singole opzioni.

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

Il client DOVREBBE (SHOULD) includere un'opzione Option Request (vedere sezione 22.7) per indicare le opzioni che il client è interessato a ricevere. Il client PUÒ (MAY) includere inoltre istanze di quelle opzioni che sono identificate nell'opzione Option Request, 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) 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 (MUST) essere ritardato di un tempo casuale tra 0 e SOL_MAX_DELAY. Nel caso di un messaggio Solicit trasmesso quando DHCP è avviato dalla scoperta dei vicini IPv6, il ritardo indica il tempo di attesa dopo che la scoperta dei vicini IPv6 fa sì che il client invochi il protocollo di autoconfigurazione degli indirizzi con stato (vedere sezione 5.5.3 di RFC 2462). Questo ritardo casuale desincronizza i client che si avviano contemporaneamente (ad esempio, dopo un'interruzione di corrente).

Il client trasmette il messaggio secondo la sezione 14, utilizzando 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 viene ricevuto 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 viene terminato dalla ricezione di un Advertise prima che sia trascorso il primo RT. Piuttosto, il client raccoglie messaggi Advertise fino a quando non è trascorso il primo RT. Inoltre, il primo RT DEVE (MUST) essere selezionato per essere strettamente maggiore di IRT scegliendo RAND per essere strettamente maggiore di 0.

Un client DEVE (MUST) raccogliere 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 fino a quando non trascorre il primo RT. Se il primo RT trascorre e il client ha ricevuto un messaggio Advertise, il client DOVREBBE (SHOULD) continuare con uno scambio di messaggi avviato dal client inviando un messaggio Request.

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

Un client DHCP DOVREBBE (SHOULD) scegliere MRC e MRD a 0. Se il client DHCP è configurato con MRC o MRD impostato su un valore diverso da 0, DEVE (MUST) smettere di provare a configurare l'interfaccia se lo scambio di messaggi fallisce. Dopo che il client DHCP smette di provare a configurare l'interfaccia, DOVREBBE (SHOULD) riavviare il processo di riconfigurazione dopo un evento esterno, come input dell'utente, riavvio del sistema, o quando il client è connesso a un nuovo collegamento.

17.1.3. Ricezione di Messaggi Advertise

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

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

• Quei messaggi Advertise 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Ò (MAY) selezionare quei server i cui messaggi Advertise pubblicizzano informazioni di interesse per il client. Ad esempio, il client può scegliere un server che ha restituito un annuncio con opzioni di configurazione di interesse per il client.
• Il client PUÒ (MAY) scegliere un server meno preferito se quel server ha un insieme migliore di parametri pubblicizzati, come gli indirizzi disponibili pubblicizzati negli IA.

Una volta che un client ha selezionato messaggi Advertise, il client tipicamente memorizzerà informazioni su ciascun server, come il valore di preferenza del server, gli indirizzi pubblicizzati, quando è stato ricevuto l'annuncio, e così via.

Se il client ha bisogno di 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 Messaggio 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 qualsiasi messaggio Reply che riceve che non include 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 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, o:

• elabora il messaggio Reply come descritto nella sezione 18.1.8, e scarta qualsiasi messaggio Reply ricevuto in risposta al messaggio Request, o
• elabora qualsiasi messaggio Reply ricevuto 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 la sua posizione come descritto nella sezione 11 e verifica la sua politica amministrativa riguardo alla risposta al client. Se il server non è autorizzato a rispondere al client, il server scarta il messaggio Solicit. Ad esempio, se la politica amministrativa per il server è che può rispondere solo a un client che è 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 e elabora il resto 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" a ADVERTISE e copia il contenuto del campo transaction-id dal messaggio Solicit ricevuto dal client nel messaggio Advertise. Il server include il suo identificatore server in un'opzione Server Identifier e copia l'identificatore client dal messaggio Solicit nel messaggio Advertise.

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

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

Il server include opzioni che il server restituirà al client in un messaggio Reply successivo. Le informazioni in queste opzioni possono essere utilizzate 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 opzioni nel messaggio Advertise 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. 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 (MUST) includere opzioni IA nel messaggio Advertise contenenti qualsiasi indirizzo che verrebbe assegnato agli IA contenuti nel messaggio Solicit dal client. Se il client ha incluso indirizzi negli IA nel messaggio Solicit, il server utilizza quegli indirizzi come suggerimenti sugli indirizzi che il client vorrebbe ricevere.

Se il server non assegnerà alcun indirizzo a nessun IA in una Request successiva dal client, il server DEVE (MUST) 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 utilizzando l'indirizzo nel campo indirizzo sorgente del datagramma IP in cui è stato ricevuto il messaggio Solicit. Il messaggio Advertise DEVE (MUST) essere inviato in unicast sul collegamento da cui è stato ricevuto il messaggio Solicit.

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 relay utilizzando l'indirizzo nel campo indirizzo sorgente del datagramma IP in cui è stato ricevuto il messaggio Relay-forward.

17.2.3. Creazione e Trasmissione di Messaggi Reply

Il server DEVE (MUST) impegnarsi nell'assegnazione di qualsiasi indirizzo o altre informazioni di configurazione prima di inviare un messaggio Reply a un client in risposta a un messaggio Solicit.

DISCUSSIONE:

Quando si utilizza 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 che sono configurati per utilizzare 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 utilizzerà solo gli indirizzi da uno dei server, mentre gli indirizzi dagli altri server saranno impegnati al client ma non utilizzati 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 desidera 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.