4. Specifica del protocollo client-server DHCP (Specification of the DHCP Client-Server Protocol)
In questa sezione, si presume che un server DHCP abbia un blocco di indirizzi di rete da cui può soddisfare le richieste di nuovi indirizzi. Ogni server mantiene anche un database di indirizzi assegnati e lease nell'archiviazione persistente locale.
4.1 Costruzione e invio di messaggi DHCP (Constructing and sending DHCP messages)
Sia i client che i server DHCP costruiscono messaggi DHCP riempiendo i campi nella sezione in formato fisso del messaggio e aggiungendo elementi di dati etichettati nell'area opzioni a lunghezza variabile. L'area opzioni include prima un 'magic cookie' di quattro ottetti (descritto nella sezione 3), seguito dalle opzioni. L'ultima opzione deve sempre essere l'opzione 'end'.
DHCP utilizza UDP come protocollo di trasporto. I messaggi DHCP da un client a un server vengono inviati alla porta 'server DHCP' (67), e i messaggi DHCP da un server a un client vengono inviati alla porta 'client DHCP' (68). Un server con più indirizzi di rete (ad esempio, un host multihomed) può utilizzare uno qualsiasi dei suoi indirizzi di rete nei messaggi DHCP in uscita.
Il campo 'identificatore di server' viene utilizzato sia per identificare un server DHCP in un messaggio DHCP che come indirizzo di destinazione dai client ai server. Un server con più indirizzi di rete deve essere preparato ad accettare uno qualsiasi dei suoi indirizzi di rete come identificazione di quel server in un messaggio DHCP. Per adattarsi a una connettività di rete potenzialmente incompleta, un server deve scegliere un indirizzo come 'identificatore di server' che, secondo la migliore conoscenza del server, sia raggiungibile dal client. Ad esempio, se il server DHCP e il client DHCP sono connessi alla stessa sottorete (cioè, il campo 'giaddr' nel messaggio dal client è zero), il server dovrebbe selezionare l'indirizzo IP che il server sta utilizzando per la comunicazione su quella sottorete come 'identificatore di server'. Se il server sta utilizzando più indirizzi IP su quella sottorete, può essere utilizzato uno qualsiasi di questi indirizzi. Se il server ha ricevuto un messaggio tramite un agente relay DHCP, il server dovrebbe scegliere un indirizzo dall'interfaccia su cui è stato ricevuto il messaggio come 'identificatore di server' (a meno che il server non abbia altre informazioni migliori su cui basare la sua scelta). I client DHCP devono utilizzare l'indirizzo IP fornito nell'opzione 'identificatore di server' per qualsiasi richiesta unicast al server DHCP.
I messaggi DHCP trasmessi da un client prima che quel client ottenga il suo indirizzo IP devono avere il campo indirizzo sorgente nell'header IP impostato a 0.
Se il campo 'giaddr' in un messaggio DHCP da un client è diverso da zero, il server invia tutti i messaggi di risposta alla porta 'server DHCP' sull'agente relay BOOTP il cui indirizzo appare in 'giaddr'. Se il campo 'giaddr' è zero e il campo 'ciaddr' è diverso da zero, allora il server invia in unicast i messaggi DHCPOFFER e DHCPACK all'indirizzo in 'ciaddr'. Se 'giaddr' è zero e 'ciaddr' è zero e il bit broadcast è impostato, allora il server trasmette i messaggi DHCPOFFER e DHCPACK a 0xffffffff. Se il bit broadcast non è impostato e 'giaddr' è zero e 'ciaddr' è zero, allora il server invia in unicast i messaggi DHCPOFFER e DHCPACK all'indirizzo hardware del client e all'indirizzo 'yiaddr'. In tutti i casi, quando 'giaddr' è zero, il server trasmette tutti i messaggi DHCPNAK a 0xffffffff.
Se le opzioni in un messaggio DHCP si estendono nei campi 'sname' e 'file', l'opzione 'option overload' DEVE apparire nel campo 'options', con valore 1, 2 o 3, come specificato in RFC 1533. Se l'opzione 'option overload' è presente nel campo 'options', le opzioni nel campo 'options' DEVONO essere terminate con un'opzione 'end', e POSSONO contenere una o più opzioni 'pad' per riempire il campo options. Le opzioni nei campi 'sname' e 'file' (se utilizzate come indicato dall'opzione 'option overload') DEVONO iniziare con il primo ottetto del campo, DEVONO essere terminate con un'opzione 'end', e DEVONO essere seguite da opzioni 'pad' per riempire il resto del campo. Qualsiasi singola opzione nei campi 'options', 'sname' e 'file' DEVE essere completamente contenuta in quel campo. Le opzioni nel campo 'options' DEVONO essere interpretate per prime, in modo che qualsiasi opzione 'option overload' possa essere interpretata. Il campo 'file' DEVE essere interpretato successivamente (se l'opzione 'option overload' indica che il campo 'file' contiene opzioni DHCP), seguito dal campo 'sname'.
I valori da passare in un tag 'option' possono essere troppo lunghi per stare nei 255 ottetti disponibili in una singola opzione (ad esempio, un elenco di router in un'opzione 'router' [21]). Le opzioni possono apparire solo una volta, a meno che non sia diversamente indicato nel documento delle opzioni. Il client concatena i valori di più istanze della stessa opzione in un singolo elenco di parametri per la configurazione.
I client DHCP sono responsabili di tutte le ritrasmissioni di messaggi. Il client DEVE adottare una strategia di ritrasmissione che incorpora un algoritmo di backoff esponenziale randomizzato per determinare il ritardo tra le ritrasmissioni. Il ritardo tra le ritrasmissioni DOVREBBE essere scelto per consentire un tempo sufficiente affinché le risposte dal server vengano consegnate in base alle caratteristiche dell'internet tra client e server. Ad esempio, in un internet Ethernet 10Mb/sec, il ritardo prima della prima ritrasmissione DOVREBBE essere di 4 secondi randomizzato dal valore di un numero casuale uniforme scelto dall'intervallo da -1 a +1. I client con orologi che forniscono una granularità di risoluzione inferiore a un secondo possono scegliere un valore di randomizzazione non intero. Il ritardo prima della prossima ritrasmissione DOVREBBE essere di 8 secondi randomizzato dal valore di un numero uniforme scelto dall'intervallo da -1 a +1. Il ritardo di ritrasmissione DOVREBBE essere raddoppiato con le ritrasmissioni successive fino a un massimo di 64 secondi. Il client PUÒ fornire un'indicazione dei tentativi di ritrasmissione all'utente come indicazione del progresso del processo di configurazione.
Il campo 'xid' viene utilizzato dal client per abbinare i messaggi DHCP in arrivo con le richieste in sospeso. Un client DHCP DEVE scegliere 'xid' in modo da minimizzare le possibilità di utilizzare un 'xid' identico a quello utilizzato da un altro client. Ad esempio, un client può scegliere un 'xid' iniziale casuale diverso ogni volta che il client viene riavviato, e quindi utilizzare 'xid' sequenziali fino al successivo riavvio. La scelta di un nuovo 'xid' per ogni ritrasmissione è una decisione di implementazione. Un client può scegliere di riutilizzare lo stesso 'xid' o di scegliere un nuovo 'xid' per ogni messaggio ritrasmesso.
Normalmente, i server DHCP e gli agenti relay BOOTP tentano di consegnare i messaggi DHCPOFFER, DHCPACK e DHCPNAK direttamente al client utilizzando la consegna unicast. L'indirizzo di destinazione IP (nell'header IP) è impostato sull'indirizzo DHCP 'yiaddr' e l'indirizzo di destinazione del livello di collegamento è impostato sull'indirizzo DHCP 'chaddr'. Sfortunatamente, alcune implementazioni client non sono in grado di ricevere tali datagrammi IP unicast fino a quando l'implementazione non è stata configurata con un indirizzo IP valido (portando a un deadlock in cui l'indirizzo IP del client non può essere consegnato fino a quando il client non è stato configurato con un indirizzo IP).
Un client che non può ricevere datagrammi IP unicast fino a quando il suo software di protocollo non è stato configurato con un indirizzo IP DOVREBBE impostare il bit BROADCAST nel campo 'flags' a 1 in tutti i messaggi DHCPDISCOVER o DHCPREQUEST che quel client invia. Il bit BROADCAST fornirà un suggerimento ai server DHCP e agli agenti relay BOOTP per trasmettere tutti i messaggi al client sulla sottorete del client. Un client che può ricevere datagrammi IP unicast prima che il suo software di protocollo sia stato configurato DOVREBBE cancellare il bit BROADCAST a 0. Il documento di chiarimenti BOOTP discute le ramificazioni dell'uso del bit BROADCAST [21].
Un server o un agente relay che invia o inoltra un messaggio DHCP direttamente a un client DHCP (cioè, non a un agente relay specificato nel campo 'giaddr') DOVREBBE esaminare il bit BROADCAST nel campo 'flags'. Se questo bit è impostato a 1, il messaggio DHCP DOVREBBE essere inviato come broadcast IP utilizzando un indirizzo broadcast IP (preferibilmente 0xffffffff) come indirizzo di destinazione IP e l'indirizzo broadcast del livello di collegamento come indirizzo di destinazione del livello di collegamento. Se il bit BROADCAST è cancellato a 0, il messaggio DOVREBBE essere inviato come unicast IP all'indirizzo IP specificato nel campo 'yiaddr' e all'indirizzo del livello di collegamento specificato nel campo 'chaddr'. Se l'unicast non è possibile, il messaggio PUÒ essere inviato come broadcast IP utilizzando un indirizzo broadcast IP (preferibilmente 0xffffffff) come indirizzo di destinazione IP e l'indirizzo broadcast del livello di collegamento come indirizzo di destinazione del livello di collegamento.
4.2 Controlli amministrativi del server DHCP (DHCP server administrative controls)
I server DHCP non sono tenuti a rispondere a ogni messaggio DHCPDISCOVER e DHCPREQUEST che ricevono. Ad esempio, un amministratore di rete, per mantenere un controllo rigoroso sui client collegati alla rete, può scegliere di configurare i server DHCP per rispondere solo ai client che sono stati precedentemente registrati tramite qualche meccanismo esterno. La specifica DHCP descrive solo le interazioni tra client e server quando i client e i server scelgono di interagire; è al di fuori dell'ambito della specifica DHCP descrivere tutti i controlli amministrativi che gli amministratori di sistema potrebbero voler utilizzare. Implementazioni specifiche del server DHCP possono incorporare tutti i controlli o le politiche desiderati da un amministratore di rete.
In alcuni ambienti, i server DHCP dovranno considerare il valore delle opzioni di classe fornitore incluse nei messaggi DHCPDISCOVER o DHCPREQUEST quando determinano i parametri corretti per un particolare client.
Un server DHCP deve utilizzare un identificatore univoco per associare un client al suo lease. Il client PUÒ scegliere di fornire esplicitamente l'identificatore tramite l'opzione 'identificatore di client'. Se il client fornisce un 'identificatore di client', il client DEVE utilizzare lo stesso 'identificatore di client' in tutti i messaggi successivi, e il server DEVE utilizzare quell'identificatore per identificare il client. Se il client non fornisce un'opzione 'identificatore di client', il server DEVE utilizzare il contenuto del campo 'chaddr' per identificare il client. È fondamentale per il corretto funzionamento di DHCP che il client utilizzi un identificatore univoco nella sottorete a cui il client è collegato nell'opzione 'identificatore di client'. L'uso di 'chaddr' come identificatore univoco del client può portare a risultati inaspettati, poiché quell'identificatore potrebbe essere associato a un'interfaccia hardware che potrebbe essere spostata su un nuovo client. Alcuni siti possono scegliere di utilizzare un numero di serie del produttore come 'identificatore di client', per evitare cambiamenti inaspettati nell'indirizzo di rete di un client dovuti al trasferimento di interfacce hardware tra computer. I siti possono anche scegliere di utilizzare un nome DNS come 'identificatore di client', facendo in modo che l'indirizzo di rete di un client sia associato al nome DNS piuttosto che a un box hardware specifico.
I client DHCP sono liberi di utilizzare qualsiasi strategia per selezionare un server DHCP tra quelli da cui il client riceve un messaggio DHCPOFFER. L'implementazione client di DHCP DOVREBBE fornire un meccanismo che permetta all'utente di selezionare direttamente i valori dell''identificatore di classe fornitore'.
4.3 Comportamento del server DHCP (DHCP server behavior)
Un server DHCP elabora i messaggi DHCP in arrivo da un client in base allo stato corrente del binding per quel client. Un server DHCP può ricevere i seguenti messaggi da un client:
- DHCPDISCOVER
- DHCPREQUEST
- DHCPDECLINE
- DHCPRELEASE
- DHCPINFORM
La tabella 3 mostra l'uso dei campi e delle opzioni in un messaggio DHCP da parte di un server. Il resto di questa sezione descrive l'azione del server DHCP per ogni possibile messaggio in arrivo.
4.3.1 Messaggio DHCPDISCOVER
Quando un server riceve un messaggio DHCPDISCOVER da un client, il server sceglie un indirizzo di rete per il client richiedente. Se non è disponibile alcun indirizzo, il server può scegliere di segnalare il problema all'amministratore di sistema. Se è disponibile un indirizzo, il nuovo indirizzo DOVREBBE essere scelto come segue:
- L'indirizzo corrente del client come registrato nel binding corrente del client, ALTRIMENTI
- L'indirizzo precedente del client come registrato nel binding (ora scaduto o rilasciato) del client, se tale indirizzo è nel pool di indirizzi disponibili del server e non è ancora assegnato, ALTRIMENTI
- L'indirizzo richiesto nell'opzione 'indirizzo IP richiesto', se tale indirizzo è valido e non è ancora assegnato, ALTRIMENTI
- Un nuovo indirizzo assegnato dal pool di indirizzi disponibili del server; l'indirizzo è selezionato in base alla sottorete da cui è stato ricevuto il messaggio (se 'giaddr' è 0) o all'indirizzo dell'agente relay che ha inoltrato il messaggio ('giaddr' quando non è 0).
Come descritto nella sezione 4.2, un server PUÒ, per motivi amministrativi, assegnare un indirizzo diverso da quello richiesto, o può rifiutarsi di allocare un indirizzo a un particolare client anche se sono disponibili indirizzi liberi.
Si noti che, in alcune architetture di rete (ad esempio, internet con più di una sottorete IP assegnata a un segmento di rete fisico), potrebbe essere il caso che un client DHCP debba essere assegnato un indirizzo da una sottorete diversa dall'indirizzo registrato in 'giaddr'. Quindi, DHCP non richiede che al client venga assegnato un indirizzo dalla sottorete in 'giaddr'. Un server è libero di scegliere un'altra sottorete, ed è al di fuori dell'ambito della specifica DHCP descrivere i mezzi con cui l'indirizzo IP assegnato potrebbe essere scelto.
Sebbene non sia richiesto per il corretto funzionamento di DHCP, il server NON DOVREBBE riutilizzare l'indirizzo di rete selezionato prima che il client risponda al messaggio DHCPOFFER del server. Il server può scegliere di registrare l'indirizzo come offerto al client.
Il server deve anche scegliere un tempo di scadenza per il lease, come segue:
- SE il client non ha richiesto un lease specifico nel messaggio DHCPDISCOVER e il client ha già un indirizzo di rete assegnato, il server restituisce il tempo di scadenza del lease precedentemente assegnato a quell'indirizzo (si noti che il client deve richiedere esplicitamente un lease specifico per estendere il tempo di scadenza su un indirizzo precedentemente assegnato), ALTRIMENTI
- SE il client non ha richiesto un lease specifico nel messaggio DHCPDISCOVER e il client non ha un indirizzo di rete assegnato, il server assegna un tempo di lease predefinito configurato localmente, ALTRIMENTI
- SE il client ha richiesto un lease specifico nel messaggio DHCPDISCOVER (indipendentemente dal fatto che il client abbia un indirizzo di rete assegnato), il server può scegliere di restituire il lease richiesto (se il lease è accettabile per la politica locale) o di selezionare un altro lease.
Tabella dei campi e delle opzioni utilizzati dai server DHCP
| Campo | DHCPOFFER | DHCPACK | DHCPNAK |
|---|---|---|---|
| op | BOOTREPLY | BOOTREPLY | BOOTREPLY |
| htype | (da RFC "Assigned Numbers") | ||
| hlen | (lunghezza indirizzo hardware in ottetti) | ||
| hops | 0 | 0 | 0 |
| xid | 'xid' dal messaggio DHCPDISCOVER del client | 'xid' dal messaggio DHCPREQUEST del client | 'xid' dal messaggio DHCPREQUEST del client |
| secs | 0 | 0 | 0 |
| ciaddr | 0 | 'ciaddr' da DHCPREQUEST o 0 | 0 |
| yiaddr | Indirizzo IP offerto al client | Indirizzo IP assegnato al client | 0 |
| siaddr | Indirizzo IP del prossimo server di bootstrap | Indirizzo IP del prossimo server di bootstrap | 0 |
| flags | 'flags' dal messaggio DHCPDISCOVER del client | 'flags' dal messaggio DHCPREQUEST del client | 'flags' dal messaggio DHCPREQUEST del client |
| giaddr | 'giaddr' dal messaggio DHCPDISCOVER del client | 'giaddr' dal messaggio DHCPREQUEST del client | 'giaddr' dal messaggio DHCPREQUEST del client |
| chaddr | 'chaddr' dal messaggio DHCPDISCOVER del client | 'chaddr' dal messaggio DHCPREQUEST del client | 'chaddr' dal messaggio DHCPREQUEST del client |
| sname | Nome host del server o opzioni | Nome host del server o opzioni | (inutilizzato) |
| file | Nome file di avvio client o opzioni | Nome file di avvio client o opzioni | (inutilizzato) |
| options | opzioni | opzioni |
| Opzione | DHCPOFFER | DHCPACK | DHCPNAK |
|---|---|---|---|
| Indirizzo IP richiesto | NON DEVE | NON DEVE | NON DEVE |
| Durata lease indirizzo IP | DEVE | DEVE (DHCPREQUEST) NON DEVE (DHCPINFORM) | NON DEVE |
| Usa campi 'file'/'sname' | PUÒ | PUÒ | NON DEVE |
| Tipo messaggio DHCP | DHCPOFFER | DHCPACK | DHCPNAK |
| Elenco richieste parametri | NON DEVE | NON DEVE | NON DEVE |
| Messaggio | DOVREBBE | DOVREBBE | DOVREBBE |
| Identificatore di client | NON DEVE | NON DEVE | PUÒ |
| Identificatore di classe fornitore | PUÒ | PUÒ | PUÒ |
| Identificatore di server | DEVE | DEVE | DEVE |
| Dimensione massima messaggio | NON DEVE | NON DEVE | NON DEVE |
| Tutti gli altri | PUÒ | PUÒ | NON DEVE |
Tabella 3: Campi e opzioni utilizzati dai server DHCP
Una volta determinati l'indirizzo di rete e il lease, il server costruisce un messaggio DHCPOFFER con i parametri di configurazione offerti. È importante che tutti i server DHCP restituiscano gli stessi parametri (con la possibile eccezione di un indirizzo di rete appena assegnato) per garantire un comportamento prevedibile del client indipendentemente dal server selezionato dal client. I parametri di configurazione DEVONO essere selezionati applicando le seguenti regole nell'ordine indicato di seguito. L'amministratore di rete è responsabile della configurazione di più server DHCP per garantire risposte uniformi da quei server. Il server DEVE restituire al client:
- L'indirizzo di rete del client, come determinato dalle regole fornite in precedenza in questa sezione,
- Il tempo di scadenza per il lease del client, come determinato dalle regole fornite in precedenza in questa sezione,
- I parametri richiesti dal client, secondo le seguenti regole:
- SE il server è stato esplicitamente configurato con un valore predefinito per il parametro, il server DEVE includere quel valore in un'opzione appropriata nel campo 'option', ALTRIMENTI
- SE il server riconosce il parametro come un parametro definito nel documento dei requisiti dell'host, il server DEVE includere il valore predefinito per quel parametro indicato nel documento dei requisiti dell'host in un'opzione appropriata nel campo 'option', ALTRIMENTI
- Il server NON DEVE restituire un valore per quel parametro,
- Il server DEVE fornire quanti più parametri richiesti possibile e DEVE omettere tutti i parametri che non può fornire. Il server DEVE includere ogni parametro richiesto solo una volta a meno che non sia esplicitamente consentito nel documento Opzioni DHCP e Estensioni Fornitore BOOTP.
- Tutti i parametri del binding esistente che differiscono dai valori predefiniti del documento dei requisiti dell'host,
- Tutti i parametri specifici per questo client (come identificato dal contenuto di 'chaddr' o 'identificatore di client' nel messaggio DHCPDISCOVER o DHCPREQUEST), ad esempio, come configurato dall'amministratore di rete,
- Tutti i parametri specifici per la classe di questo client (come identificato dal contenuto dell'opzione 'Identificatore di classe fornitore' nel messaggio DHCPDISCOVER o DHCPREQUEST), ad esempio, come configurato dall'amministratore di rete; i parametri devono essere identificati da una corrispondenza esatta tra gli identificatori di classe fornitore del client e la classe del client identificata nel server,
- I parametri con valori non predefiniti sulla sottorete del client.
Il server PUÒ scegliere di restituire l''identificatore di classe fornitore' utilizzato per determinare i parametri nel messaggio DHCPOFFER per aiutare il client a selezionare quale DHCPOFFER accettare. Il server inserisce il campo 'xid' dal messaggio DHCPDISCOVER nel campo 'xid' del messaggio DHCPOFFER e invia il messaggio DHCPOFFER al client richiedente.
4.3.2 Messaggio DHCPREQUEST
Un messaggio DHCPREQUEST può provenire da un client che risponde a un messaggio DHCPOFFER da un server, da un client che verifica un indirizzo IP precedentemente assegnato o da un client che estende il lease su un indirizzo di rete. Se il messaggio DHCPREQUEST contiene un'opzione 'identificatore di server', il messaggio è in risposta a un messaggio DHCPOFFER. Altrimenti, il messaggio è una richiesta di verifica o estensione di un lease esistente. Se il client utilizza un 'identificatore di client' in un messaggio DHCPREQUEST, DEVE utilizzare quello stesso 'identificatore di client' in tutti i messaggi successivi. Se il client ha incluso un elenco di parametri richiesti in un messaggio DHCPDISCOVER, DEVE includere quell'elenco in tutti i messaggi successivi.
Tutti i parametri di configurazione nel messaggio DHCPACK NON DOVREBBERO essere in conflitto con quelli nel messaggio DHCPOFFER precedente a cui il client sta rispondendo. Il client DOVREBBE utilizzare i parametri nel messaggio DHCPACK per la configurazione.
I client inviano messaggi DHCPREQUEST come segue:
DHCPREQUEST generato durante lo stato SELECTING:
Il client inserisce l'indirizzo del server selezionato in 'identificatore di server', 'ciaddr' DEVE essere zero, 'indirizzo IP richiesto' DEVE essere riempito con il valore yiaddr del DHCPOFFER scelto.
Si noti che il client può scegliere di raccogliere più messaggi DHCPOFFER e selezionare l'offerta "migliore". Il client indica la sua selezione identificando il server offerente nel messaggio DHCPREQUEST. Se il client non riceve offerte accettabili, il client può scegliere di provare un altro messaggio DHCPDISCOVER. Pertanto, i server potrebbero non ricevere una DHCPREQUEST specifica da cui possono decidere se il client ha accettato l'offerta. Poiché i server non hanno impegnato alcuna assegnazione di indirizzo di rete in base a un DHCPOFFER, i server sono liberi di riutilizzare gli indirizzi di rete offerti in risposta a richieste successive. Come dettaglio di implementazione, i server non dovrebbero riutilizzare gli indirizzi offerti e possono utilizzare un meccanismo di timeout specifico dell'implementazione per decidere quando riutilizzare un indirizzo offerto.
DHCPREQUEST generato durante lo stato INIT-REBOOT:
'Identificatore di server' NON DEVE essere riempito, l'opzione 'indirizzo IP richiesto' DEVE essere riempita con la nozione del client del suo indirizzo precedentemente assegnato. 'ciaddr' DEVE essere zero. Il client sta cercando di verificare una configurazione precedentemente assegnata e memorizzata nella cache. Il server DOVREBBE inviare un messaggio DHCPNAK al client se l''indirizzo IP richiesto' è errato o si trova sulla rete sbagliata.
La determinazione se un client nello stato INIT-REBOOT si trova sulla rete corretta viene effettuata esaminando 'giaddr', il contenuto dell'opzione 'indirizzo IP richiesto' e una ricerca nel database. Se il server DHCP rileva che il client si trova sulla rete sbagliata (cioè, il risultato dell'applicazione della maschera di sottorete locale o della maschera di sottorete remota (se 'giaddr' non è zero) al valore dell'opzione 'indirizzo IP richiesto' non corrisponde alla realtà), allora il server DOVREBBE inviare un messaggio DHCPNAK al client.
Se la rete è corretta, allora il server DHCP dovrebbe verificare se la nozione del client del suo indirizzo IP è corretta. Se non lo è, allora il server DOVREBBE inviare un messaggio DHCPNAK al client. Se il server DHCP non ha alcuna registrazione di questo client, allora DEVE rimanere in silenzio e PUÒ emettere un avviso all'amministratore di rete. Questo comportamento è necessario per la coesistenza pacifica di server DHCP non comunicanti sulla stessa linea.
Se 'giaddr' è 0x0 nel messaggio DHCPREQUEST, il client si trova sulla stessa sottorete del server. Il server DEVE trasmettere il messaggio DHCPNAK all'indirizzo broadcast 0xffffffff perché il client potrebbe non avere un indirizzo di rete o una maschera di sottorete corretti, e il client potrebbe non rispondere alle richieste ARP.
Se 'giaddr' è impostato nel messaggio DHCPREQUEST, il client si trova su una sottorete diversa. Il server DEVE impostare il bit broadcast nel DHCPNAK, in modo che l'agente relay trasmetta il DHCPNAK al client, perché il client potrebbe non avere un indirizzo di rete o una maschera di sottorete corretti, e il client potrebbe non rispondere alle richieste ARP.
DHCPREQUEST generato durante lo stato RENEWING:
'Identificatore di server' NON DEVE essere riempito, l'opzione 'indirizzo IP richiesto' NON DEVE essere riempita, 'ciaddr' DEVE essere riempito con l'indirizzo IP del client. In questa situazione, il client è completamente configurato e sta tentando di estendere il suo lease. Questo messaggio sarà inviato in unicast, quindi nessun agente relay sarà coinvolto nella sua trasmissione. Poiché 'giaddr' non è quindi riempito, il server DHCP si fiderà del valore in 'ciaddr' e lo utilizzerà quando risponde al client.
Un client PUÒ scegliere di rinnovare o estendere il suo lease prima di T1. Il server può scegliere di non estendere il lease (come decisione politica dell'amministratore di rete), ma dovrebbe restituire un messaggio DHCPACK in ogni caso.
DHCPREQUEST generato durante lo stato REBINDING:
'Identificatore di server' NON DEVE essere riempito, l'opzione 'indirizzo IP richiesto' NON DEVE essere riempita, 'ciaddr' DEVE essere riempito con l'indirizzo IP del client. In questa situazione, il client è completamente configurato e sta tentando di estendere il suo lease. Questo messaggio DEVE essere trasmesso all'indirizzo broadcast IP 0xffffffff. Il server DHCP DOVREBBE verificare l'accuratezza di 'ciaddr' prima di rispondere alla DHCPREQUEST.
La DHCPREQUEST da un client REBINDING è destinata ad accogliere i siti che hanno più server DHCP e un meccanismo per mantenere la coerenza dei binding tra i lease gestiti da più server. Un server DHCP PUÒ estendere il lease di un client solo se ha l'autorità amministrativa locale per farlo.
4.3.3 Messaggio DHCPDECLINE
Se il server riceve un messaggio DHCPDECLINE, il client ha scoperto tramite altri mezzi che l'indirizzo di rete suggerito è già in uso. Il server DEVE contrassegnare l'indirizzo di rete come non disponibile e DOVREBBE notificare all'amministratore di sistema locale un possibile problema di configurazione.
4.3.4 Messaggio DHCPRELEASE
Dopo aver ricevuto un messaggio DHCPRELEASE, il server contrassegna l'indirizzo di rete come non assegnato. Il server DOVREBBE conservare una registrazione dei parametri di inizializzazione del client per un possibile riutilizzo in risposta a richieste successive dal client.
4.3.5 Messaggio DHCPINFORM
Il server risponde a un messaggio DHCPINFORM inviando un messaggio DHCPACK direttamente all'indirizzo fornito nel campo 'ciaddr' del messaggio DHCPINFORM. Il server NON DEVE inviare un tempo di scadenza del lease al client e NON DOVREBBE riempire 'yiaddr'. Il server include altri parametri nel messaggio DHCPACK come definito nella sezione 4.3.1.
4.3.6 Messaggi dei client
La tabella 4 dettaglia le differenze tra i messaggi dei client in vari stati.
| INIT-REBOOT | SELECTING | RENEWING | REBINDING | |
|---|---|---|---|---|
| Broadcast/unicast | Broadcast | Broadcast | Unicast | Broadcast |
| server-ip | NON DEVE | DEVE | NON DEVE | NON DEVE |
| requested-ip | DEVE | DEVE | NON DEVE | NON DEVE |
| ciaddr | zero | zero | Indirizzo IP | Indirizzo IP |
Tabella 4: Messaggi dei client da diversi stati
4.4 Comportamento del client DHCP (DHCP client behavior)
La figura 5 fornisce il diagramma di transizione di stato per un client DHCP. Un client può ricevere i seguenti messaggi da un server:
- DHCPOFFER
- DHCPACK
- DHCPNAK
Il messaggio DHCPINFORM non è mostrato nella figura 5. Un client invia semplicemente il DHCPINFORM e attende messaggi DHCPACK. Una volta che il client ha selezionato i suoi parametri, ha concluso il processo di configurazione.
La tabella 5 fornisce l'uso dei campi e delle opzioni in un messaggio DHCP da parte di un client. Il resto di questa sezione descrive l'azione del client DHCP per ogni possibile messaggio in arrivo. La descrizione nella sezione successiva corrisponde alla procedura di configurazione completa descritta precedentemente nella sezione 3.1, e il testo della sezione seguente corrisponde alla procedura di configurazione abbreviata descritta nella sezione 3.2.
Diagramma di transizione di stato per i client DHCP
-------- -------
| | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Riavvio | | ------- | |
-------- | DHCPNAK/ | | |
| Scarta offerta | -/Invia DHCPDISCOVER |
-/Invia DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (non accettare)/ ----------- | |
| | | Invia DHCPDECLINE | | |
| REBOOTING | | | | SELECTING |<----+ |
| | | / | | |DHCPOFFER/ |
----------- | / ----------- | |Raccogliere |
| | / | | | risposte |
DHCPACK/ | / +----------------+ +-------+ |
Registra lease, imposta| | v Seleziona offerta/ |
timer T1, T2 ------------ Invia DHCPREQUEST | |
| +----->| | DHCPNAK, Lease scaduto/ |
| | | REQUESTING | Interrompi rete |
DHCPOFFER/ | | | |
Scarta ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Registra lease, imposta -----| REBINDING | |
| timer T1, T2 / | | |
| | DHCPACK/ ----------- |
| v Registra lease, ^ |
+----------------> ------- /imposta T1,T2 | |
+----->| |<---+ | |
| | BOUND |<---+ | |
DHCPOFFER, DHCPACK, | | | T2 scade/ DHCPNAK/
DHCPNAK/Scarta ------- | Trasmetti Interrompi rete
| | | | DHCPREQUEST |
+-------+ | DHCPACK/ | |
T1 scade/ Registra lease, imposta | |
Invia DHCPREQUEST timer T1, T2 | |
al server di leasing | | |
| ---------- | |
| | |------------+ |
+->| RENEWING | |
| |----------------------------+
----------
Figura 5: Diagramma di transizione di stato per client DHCP
4.4.1 Inizializzazione e assegnazione di indirizzo di rete
Il client inizia nello stato INIT e forma un messaggio DHCPDISCOVER. Il client DOVREBBE attendere un tempo casuale tra uno e dieci secondi per desincronizzare l'uso di DHCP all'avvio. Il client imposta 'ciaddr' a 0x00000000. Il client PUÒ richiedere parametri specifici includendo l'opzione 'elenco richieste parametri'. Il client PUÒ suggerire un indirizzo di rete e/o un tempo di lease includendo le opzioni 'indirizzo IP richiesto' e 'durata lease indirizzo IP'. Il client DEVE includere il suo indirizzo hardware nel campo 'chaddr', se necessario per la consegna dei messaggi di risposta DHCP. Il client PUÒ includere un identificatore univoco diverso nell'opzione 'identificatore di client', come discusso nella sezione 4.2. Se il client ha incluso un elenco di parametri richiesti in un messaggio DHCPDISCOVER, DEVE includere quell'elenco in tutti i messaggi successivi.
Il client genera e registra un identificatore di transazione casuale e inserisce quell'identificatore nel campo 'xid'. Il client registra il proprio tempo locale per un uso successivo nel calcolo della scadenza del lease. Il client quindi trasmette il DHCPDISCOVER sull'indirizzo broadcast hardware locale all'indirizzo broadcast IP 0xffffffff e alla porta UDP 'server DHCP'.
Se l''xid' di un messaggio DHCPOFFER in arrivo non corrisponde all''xid' del messaggio DHCPDISCOVER più recente, il messaggio DHCPOFFER deve essere scartato silenziosamente. Tutti i messaggi DHCPACK in arrivo devono essere scartati silenziosamente.
Il client raccoglie messaggi DHCPOFFER per un periodo di tempo, seleziona un messaggio DHCPOFFER dai (possibilmente molti) messaggi DHCPOFFER in arrivo (ad esempio, il primo messaggio DHCPOFFER o il messaggio DHCPOFFER da un server precedentemente utilizzato) ed estrae l'indirizzo del server dall'opzione 'identificatore di server' nel messaggio DHCPOFFER. Il tempo per cui il client raccoglie messaggi e il meccanismo utilizzato per selezionare un DHCPOFFER sono dipendenti dall'implementazione.
Tabella dei campi e delle opzioni utilizzati dai client DHCP
| Campo | DHCPDISCOVER DHCPINFORM | DHCPREQUEST | DHCPDECLINE, DHCPRELEASE |
|---|---|---|---|
| op | BOOTREQUEST | BOOTREQUEST | BOOTREQUEST |
| htype | (da RFC "Assigned Numbers") | ||
| hlen | (lunghezza indirizzo hardware in ottetti) | ||
| hops | 0 | 0 | 0 |
| xid | selezionato dal client | 'xid' dal messaggio DHCPOFFER del server | selezionato dal client |
| secs | 0 o secondi dall'inizio del processo DHCP | 0 o secondi dall'inizio del processo DHCP | 0 |
| flags | Imposta flag 'BROADCAST' se il client richiede risposta broadcast | Imposta flag 'BROADCAST' se il client richiede risposta broadcast | 0 |
| ciaddr | 0 (DHCPDISCOVER) indirizzo di rete del client (DHCPINFORM) | 0 o indirizzo di rete del client (BOUND/RENEW/REBIND) | 0 (DHCPDECLINE) indirizzo di rete del client (DHCPRELEASE) |
| yiaddr | 0 | 0 | 0 |
| siaddr | 0 | 0 | 0 |
| giaddr | 0 | 0 | 0 |
| chaddr | indirizzo hardware del client | indirizzo hardware del client | indirizzo hardware del client |
| sname | opzioni (se indicato nell'opzione 'sname/file'); altrimenti inutilizzato | opzioni (se indicato nell'opzione 'sname/file'); altrimenti inutilizzato | (inutilizzato) |
| file | opzioni (se indicato nell'opzione 'sname/file'); altrimenti inutilizzato | opzioni (se indicato nell'opzione 'sname/file'); altrimenti inutilizzato | (inutilizzato) |
| options | opzioni | opzioni | (inutilizzato) |
| Opzione | DHCPDISCOVER DHCPINFORM | DHCPREQUEST | DHCPDECLINE, DHCPRELEASE |
|---|---|---|---|
| Indirizzo IP richiesto | PUÒ (DISCOVER) NON DEVE (INFORM) | DEVE (in SELECTING o INIT-REBOOT) NON DEVE (in BOUND o RENEWING) | DEVE (DHCPDECLINE), NON DEVE (DHCPRELEASE) |
| Durata lease indirizzo IP | PUÒ (DISCOVER) NON DEVE (INFORM) | PUÒ | NON DEVE |
| Usa campi 'file'/'sname' | PUÒ | PUÒ | PUÒ |
| Tipo messaggio DHCP | DHCPDISCOVER/ DHCPINFORM | DHCPREQUEST | DHCPDECLINE/ DHCPRELEASE |
| Identificatore di client | PUÒ | PUÒ | PUÒ |
| Identificatore di classe fornitore | PUÒ | PUÒ | NON DEVE |
| Identificatore di server | NON DEVE | DEVE (dopo SELECTING) NON DEVE (dopo INIT-REBOOT, BOUND, RENEWING o REBINDING) | DEVE |
| Elenco richieste parametri | PUÒ | PUÒ | NON DEVE |
| Dimensione massima messaggio | PUÒ | PUÒ | NON DEVE |
| Messaggio | NON DOVREBBE | NON DOVREBBE | DOVREBBE |
| Specifico del sito | PUÒ | PUÒ | NON DEVE |
| Tutti gli altri | PUÒ | PUÒ | NON DEVE |
Tabella 5: Campi e opzioni utilizzati dai client DHCP
Se i parametri sono accettabili, il client registra l'indirizzo del server che ha fornito i parametri dal campo 'identificatore di server' e invia quell'indirizzo nel campo 'identificatore di server' di un messaggio DHCPREQUEST broadcast. Una volta che il messaggio DHCPACK dal server arriva, il client è inizializzato e si sposta nello stato BOUND. Il messaggio DHCPREQUEST contiene lo stesso 'xid' del messaggio DHCPOFFER. Il client registra la scadenza del lease come somma del tempo in cui è stata inviata la richiesta originale e la durata del lease dal messaggio DHCPACK. Il client DOVREBBE eseguire un controllo sull'indirizzo suggerito per assicurarsi che l'indirizzo non sia già in uso. Ad esempio, se il client si trova su una rete che supporta ARP, il client può emettere una richiesta ARP per la richiesta suggerita. Quando trasmette una richiesta ARP per l'indirizzo suggerito, il client deve riempire il proprio indirizzo hardware come indirizzo hardware del mittente e riempire 0 come indirizzo IP del mittente, per evitare di confondere le cache ARP in altri host sulla stessa sottorete. Se l'indirizzo di rete sembra essere in uso, il client DEVE inviare un messaggio DHCPDECLINE al server. Il client DOVREBBE trasmettere una risposta ARP per annunciare il nuovo indirizzo IP del client e cancellare eventuali voci della cache ARP obsolete negli host sulla sottorete del client.
4.4.2 Inizializzazione con indirizzo di rete noto
Il client inizia nello stato INIT-REBOOT e invia un messaggio DHCPREQUEST. Il client DEVE inserire il suo indirizzo di rete noto come opzione 'indirizzo IP richiesto' nel messaggio DHCPREQUEST. Il client PUÒ richiedere parametri di configurazione specifici includendo l'opzione 'elenco richieste parametri'. Il client genera e registra un identificatore di transazione casuale e inserisce quell'identificatore nel campo 'xid'. Il client registra il proprio tempo locale per un uso successivo nel calcolo della scadenza del lease. Il client NON DEVE includere un 'identificatore di server' nel messaggio DHCPREQUEST. Il client quindi trasmette il DHCPREQUEST sull'indirizzo broadcast hardware locale alla porta UDP 'server DHCP'.
Una volta che un messaggio DHCPACK con un campo 'xid' corrispondente a quello del messaggio DHCPREQUEST del client arriva da qualsiasi server, il client è inizializzato e si sposta nello stato BOUND. Il client registra la scadenza del lease come somma del tempo in cui è stato inviato il messaggio DHCPREQUEST e la durata del lease dal messaggio DHCPACK.
4.4.3 Inizializzazione con un indirizzo di rete assegnato esternamente
Il client invia un messaggio DHCPINFORM. Il client PUÒ richiedere parametri di configurazione specifici includendo l'opzione 'elenco richieste parametri'. Il client genera e registra un identificatore di transazione casuale e inserisce quell'identificatore nel campo 'xid'. Il client inserisce il proprio indirizzo di rete nel campo 'ciaddr'. Il client NON DOVREBBE richiedere parametri del tempo di lease.
Il client quindi invia in unicast il DHCPINFORM al server DHCP se conosce l'indirizzo del server, altrimenti trasmette il messaggio all'indirizzo broadcast limitato (tutti uno). I messaggi DHCPINFORM DEVONO essere diretti alla porta UDP 'server DHCP'.
Una volta che un messaggio DHCPACK con un campo 'xid' corrispondente a quello del messaggio DHCPINFORM del client arriva da qualsiasi server, il client è inizializzato.
Se il client non riceve un DHCPACK entro un tempo ragionevole (60 secondi o 4 tentativi se si utilizza il timeout suggerito nella sezione 4.1), allora DOVREBBE visualizzare un messaggio che informa l'utente del problema, quindi DOVREBBE iniziare l'elaborazione di rete utilizzando valori predefiniti appropriati come indicato nell'Appendice A.
4.4.4 Uso di broadcast e unicast
I client DHCP trasmettono messaggi DHCPDISCOVER, DHCPREQUEST e DHCPINFORM, a meno che il client non conosca l'indirizzo di un server DHCP. Il client invia in unicast messaggi DHCPRELEASE al server. Poiché il client sta rifiutando l'uso dell'indirizzo IP fornito dal server, il client trasmette messaggi DHCPDECLINE.
Quando il client DHCP conosce l'indirizzo di un server DHCP, nello stato INIT o REBOOTING, il client può utilizzare quell'indirizzo nel DHCPDISCOVER o DHCPREQUEST piuttosto che l'indirizzo broadcast IP. Il client può anche utilizzare unicast per inviare messaggi DHCPINFORM a un server DHCP noto. Se il client non riceve alcuna risposta ai messaggi DHCP inviati all'indirizzo IP di un server DHCP noto, il client DHCP ritorna all'uso dell'indirizzo broadcast IP.
4.4.5 Riacquisizione e scadenza
Il client mantiene due tempi, T1 e T2, che specificano i tempi in cui il client tenta di estendere il suo lease sul suo indirizzo di rete. T1 è il tempo in cui il client entra nello stato RENEWING e tenta di contattare il server che ha originariamente emesso l'indirizzo di rete del client. T2 è il tempo in cui il client entra nello stato REBINDING e tenta di contattare qualsiasi server. T1 DEVE essere precedente a T2, che, a sua volta, DEVE essere precedente al tempo in cui il lease del client scade.
Per evitare la necessità di orologi sincronizzati, T1 e T2 sono espressi nelle opzioni come tempi relativi [2].
Al tempo T1, il client si sposta nello stato RENEWING e invia (tramite unicast) un messaggio DHCPREQUEST al server per estendere il suo lease. Il client imposta il campo 'ciaddr' nel DHCPREQUEST al suo indirizzo di rete corrente. Il client registra il tempo locale in cui viene inviato il messaggio DHCPREQUEST per il calcolo della scadenza del lease. Il client NON DEVE includere un 'identificatore di server' nel messaggio DHCPREQUEST.
Tutti i messaggi DHCPACK che arrivano con un 'xid' che non corrisponde all''xid' del messaggio DHCPREQUEST del client vengono scartati silenziosamente. Quando il client riceve un DHCPACK dal server, il client calcola la scadenza del lease come somma del tempo in cui il client ha inviato il messaggio DHCPREQUEST e la durata del lease dal messaggio DHCPACK. Il client ha riacquisito con successo il suo indirizzo di rete, ritorna allo stato BOUND e può continuare l'elaborazione di rete.
Se nessun DHCPACK arriva prima del tempo T2, il client si sposta nello stato REBINDING e invia (tramite broadcast) un messaggio DHCPREQUEST per estendere il suo lease. Il client imposta il campo 'ciaddr' nel DHCPREQUEST al suo indirizzo di rete corrente. Il client NON DEVE includere un 'identificatore di server' nel messaggio DHCPREQUEST.
I tempi T1 e T2 sono configurabili dal server tramite opzioni. T1 predefinito è (0,5 * duration_of_lease). T2 predefinito è (0,875 * duration_of_lease). I tempi T1 e T2 DOVREBBERO essere scelti con un po' di "fuzziness" casuale attorno a un valore fisso, per evitare la sincronizzazione della riacquisizione da parte dei client.
Un client PUÒ scegliere di rinnovare o estendere il suo lease prima di T1. Il server può scegliere di estendere il lease del client secondo la politica impostata dall'amministratore di rete. Il server DOVREBBE restituire T1 e T2, e i loro valori DOVREBBERO essere adeguati dai loro valori originali per tenere conto del tempo rimanente nel lease.
Negli stati RENEWING e REBINDING, se il client non riceve alcuna risposta al suo messaggio DHCPREQUEST, il client DOVREBBE attendere metà del tempo rimanente fino a T2 (nello stato RENEWING) e metà del tempo di lease rimanente (nello stato REBINDING), fino a un minimo di 60 secondi, prima di ritrasmettere il messaggio DHCPREQUEST.
Se il lease scade prima che il client riceva un DHCPACK, il client si sposta nello stato INIT, DEVE fermare immediatamente tutta l'altra elaborazione di rete e richiedere parametri di inizializzazione di rete come se il client non fosse inizializzato. Se il client riceve successivamente un DHCPACK allocando a quel client il suo indirizzo di rete precedente, il client DOVREBBE continuare l'elaborazione di rete. Se al client viene assegnato un nuovo indirizzo di rete, NON DEVE continuare a utilizzare l'indirizzo di rete precedente e DOVREBBE notificare gli utenti locali del problema.
4.4.6 DHCPRELEASE
Se il client non ha più bisogno di utilizzare il suo indirizzo di rete assegnato (ad esempio, il client viene arrestato normalmente), il client invia un messaggio DHCPRELEASE al server. Si noti che il corretto funzionamento di DHCP non dipende dalla trasmissione di messaggi DHCPRELEASE.