3. Il protocollo client-server (The Client-Server Protocol)
DHCP utilizza il formato di messaggio BOOTP definito nella RFC 951 e riportato nella tabella 1 e nella figura 1. Il campo 'op' di ogni messaggio DHCP inviato da un client a un server contiene BOOTREQUEST. BOOTREPLY viene utilizzato nel campo 'op' di ogni messaggio DHCP inviato da un server a un client.
I primi quattro ottetti del campo 'options' del messaggio DHCP contengono i valori (decimali) 99, 130, 83 e 99, rispettivamente (questo è lo stesso magic cookie definito nella RFC 1497 [17]). Il resto del campo 'options' consiste in un elenco di parametri contrassegnati chiamati "options". Tutte le "vendor extensions" elencate nella RFC 1497 sono anche opzioni DHCP. La RFC 1533 fornisce il set completo di opzioni definite per l'uso con DHCP.
Finora sono state definite diverse opzioni. Un'opzione particolare - l'opzione "tipo di messaggio DHCP (DHCP Message Type)" - deve essere inclusa in ogni messaggio DHCP. Questa opzione definisce il "tipo" del messaggio DHCP. Opzioni aggiuntive possono essere consentite, richieste o non consentite, a seconda del tipo di messaggio DHCP.
In tutto questo documento, i messaggi DHCP che includono un'opzione 'tipo di messaggio DHCP' saranno indicati dal tipo del messaggio; ad esempio, un messaggio DHCP con opzione 'tipo di messaggio DHCP' tipo 1 sarà indicato come messaggio "DHCPDISCOVER".
3.1 Interazione client-server - allocazione di un indirizzo di rete (Client-server interaction - allocating a network address)
Il seguente riepilogo dello scambio di protocollo tra client e server fa riferimento ai messaggi DHCP descritti nella tabella 2. Il diagramma temporale nella figura 3 mostra le relazioni temporali in una tipica interazione client-server. Se il client conosce già il suo indirizzo, alcuni di questi passaggi possono essere omessi; questa interazione abbreviata è descritta nella sezione 3.2.
1. Il client trasmette un messaggio DHCPDISCOVER sulla sua subnet fisica locale. Il messaggio DHCPDISCOVER PUÒ includere opzioni che suggeriscono valori per l'indirizzo di rete e la durata del lease. Gli agenti relay BOOTP possono trasmettere il messaggio ai server DHCP che non si trovano sulla stessa subnet fisica.
2. Ogni server può rispondere con un messaggio DHCPOFFER che include un indirizzo di rete disponibile nel campo 'yiaddr' (e altri parametri di configurazione nelle opzioni DHCP). I server non hanno bisogno di riservare l'indirizzo di rete offerto, sebbene il protocollo funzionerà in modo più efficiente se il server evita di allocare l'indirizzo di rete offerto a un altro client. Quando si alloca un nuovo indirizzo, i server DOVREBBERO verificare che l'indirizzo di rete offerto non sia già in uso; ad esempio, il server può sondare l'indirizzo offerto con una richiesta echo ICMP. I server DOVREBBERO essere implementati in modo che gli amministratori di rete POSSANO scegliere di disabilitare il sondaggio degli indirizzi appena allocati. Il server trasmette il messaggio DHCPOFFER al client, utilizzando l'agente relay BOOTP se necessario.
Messaggi DHCP (DHCP messages)
| Messaggio | Utilizzo |
|---|---|
| DHCPDISCOVER | Broadcast del client per localizzare i server disponibili. |
| DHCPOFFER | Dal server al client in risposta a DHCPDISCOVER con offerta di parametri di configurazione. |
| DHCPREQUEST | Messaggio del client ai server o (a) richiedendo i parametri offerti da un server e rifiutando implicitamente le offerte da tutti gli altri, (b) confermando la correttezza di un indirizzo precedentemente allocato dopo, ad esempio, il riavvio del sistema, o (c) estendendo il lease su un particolare indirizzo di rete. |
| DHCPACK | Dal server al client con parametri di configurazione, incluso l'indirizzo di rete impegnato. |
| DHCPNAK | Dal server al client indicando che la nozione di indirizzo di rete del client è errata (ad esempio, il client si è spostato su una nuova subnet) o il lease del client è scaduto. |
| DHCPDECLINE | Dal client al server indicando che l'indirizzo di rete è già in uso. |
| DHCPRELEASE | Dal client al server rinunciando all'indirizzo di rete e annullando il lease rimanente. |
| DHCPINFORM | Dal client al server, chiedendo solo i parametri di configurazione locali; il client ha già un indirizzo di rete configurato esternamente. |
Tabella 2: Messaggi DHCP
Diagramma temporale (Timeline diagram)
Server Client Server
(not selected) (selected)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/ |
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Figura 3: Diagramma temporale dei messaggi scambiati tra client
e server DHCP durante l'allocazione di un nuovo indirizzo
di rete
3. Il client riceve uno o più messaggi DHCPOFFER da uno o più server. Il client può scegliere di attendere più risposte. Il client sceglie un server da cui richiedere i parametri di configurazione, in base ai parametri di configurazione offerti nei messaggi DHCPOFFER. Il client trasmette un messaggio DHCPREQUEST che DEVE includere l'opzione 'server identifier' per indicare quale server ha selezionato, e che PUÒ includere altre opzioni che specificano i valori di configurazione desiderati. L'opzione 'requested IP address' DEVE essere impostata sul valore di 'yiaddr' nel messaggio DHCPOFFER dal server. Questo messaggio DHCPREQUEST viene trasmesso e inoltrato tramite agenti relay DHCP/BOOTP. Per aiutare a garantire che qualsiasi agente relay BOOTP inoltri il messaggio DHCPREQUEST allo stesso set di server DHCP che hanno ricevuto il messaggio DHCPDISCOVER originale, il messaggio DHCPREQUEST DEVE utilizzare lo stesso valore nel campo 'secs' dell'intestazione del messaggio DHCP ed essere inviato allo stesso indirizzo di broadcast IP del messaggio DHCPDISCOVER originale. Il client scade e ritrasmette il messaggio DHCPDISCOVER se il client non riceve messaggi DHCPOFFER.
4. I server ricevono il broadcast DHCPREQUEST dal client. I server non selezionati dal messaggio DHCPREQUEST utilizzano il messaggio come notifica che il client ha rifiutato l'offerta di quel server. Il server selezionato nel messaggio DHCPREQUEST impegna il binding del client in archiviazione persistente e risponde con un messaggio DHCPACK contenente i parametri di configurazione per il client richiedente. La combinazione di 'client identifier' o 'chaddr' e indirizzo di rete assegnato costituisce un identificatore univoco per il lease del client ed è utilizzata sia dal client che dal server per identificare un lease riferito in qualsiasi messaggio DHCP. 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 server NON DOVREBBE controllare l'indirizzo di rete offerto in questo punto. Il campo 'yiaddr' nei messaggi DHCPACK viene compilato con l'indirizzo di rete selezionato.
Se il server selezionato non è in grado di soddisfare il messaggio DHCPREQUEST (ad esempio, l'indirizzo di rete richiesto è stato allocato), il server DOVREBBE rispondere con un messaggio DHCPNAK.
Un server PUÒ scegliere di contrassegnare gli indirizzi offerti ai client nei messaggi DHCPOFFER come non disponibili. Il server DOVREBBE contrassegnare un indirizzo offerto a un client in un messaggio DHCPOFFER come disponibile se il server non riceve alcun messaggio DHCPREQUEST da quel client.
5. Il client riceve il messaggio DHCPACK con i parametri di configurazione. Il client DOVREBBE eseguire un controllo finale sui parametri (ad esempio, ARP per l'indirizzo di rete allocato), e annota la durata del lease specificata nel messaggio DHCPACK. A questo punto, il client è configurato. Se il client rileva che l'indirizzo è già in uso (ad esempio, attraverso l'uso di ARP), il client DEVE inviare un messaggio DHCPDECLINE al server e riavvia il processo di configurazione. Il client DOVREBBE attendere almeno dieci secondi prima di riavviare il processo di configurazione per evitare un traffico di rete eccessivo in caso di loop.
Se il client riceve un messaggio DHCPNAK, il client riavvia il processo di configurazione.
Se il client non riceve né un messaggio DHCPACK né un messaggio DHCPNAK, il client scade e ritrasmette il messaggio DHCPREQUEST, secondo l'algoritmo di ritrasmissione nella sezione 4.1. Il client DOVREBBE scegliere di ritrasmettere il DHCPREQUEST un numero di volte sufficiente per fornire una probabilità adeguata di contattare il server senza far attendere eccessivamente a lungo il client (e l'utente di quel client) prima di arrendersi; ad esempio, un client che ritrasmette come descritto nella sezione 4.1 potrebbe ritrasmettere il messaggio DHCPREQUEST quattro volte, per un ritardo totale di 60 secondi, prima di riavviare la procedura di inizializzazione. Se il client non riceve né un messaggio DHCPACK né un messaggio DHCPNAK dopo aver impiegato l'algoritmo di ritrasmissione, il client torna allo stato INIT e riavvia il processo di inizializzazione. Il client DOVREBBE notificare all'utente che il processo di inizializzazione è fallito e sta riavviando.
6. Il client può scegliere di rinunciare al suo lease su un indirizzo di rete inviando un messaggio DHCPRELEASE al server. Il client identifica il lease da rilasciare con il suo 'client identifier' o 'chaddr' e l'indirizzo di rete nel messaggio DHCPRELEASE. Se il client ha utilizzato un 'client identifier' quando ha ottenuto il lease, DEVE utilizzare lo stesso 'client identifier' nel messaggio DHCPRELEASE.
3.2 Interazione client-server - riutilizzo di un indirizzo di rete precedentemente allocato (Client-server interaction - reusing a previously allocated network address)
Se un client ricorda e desidera riutilizzare un indirizzo di rete precedentemente allocato, un client può scegliere di omettere alcuni dei passaggi descritti nella sezione precedente. Il diagramma temporale nella figura 4 mostra le relazioni temporali in una tipica interazione client-server per un client che riutilizza un indirizzo di rete precedentemente allocato.
1. Il client trasmette un messaggio DHCPREQUEST sulla sua subnet locale. Il messaggio include l'indirizzo di rete del client nell'opzione 'requested IP address'. Poiché il client non ha ancora ricevuto il suo indirizzo di rete, NON DEVE compilare il campo 'ciaddr'. Gli agenti relay BOOTP trasmettono il messaggio ai server DHCP che non si trovano sulla stessa subnet. Se il client ha utilizzato un 'client identifier' per ottenere il suo indirizzo, il client DEVE utilizzare lo stesso 'client identifier' nel messaggio DHCPREQUEST.
2. I server con conoscenza dei parametri di configurazione del client rispondono con un messaggio DHCPACK al client. I server NON DOVREBBERO controllare che l'indirizzo di rete del client sia già in uso; il client può rispondere ai messaggi di richiesta echo ICMP in questo punto.
Server Client Server
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQUEST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
Figura 4: Diagramma temporale dei messaggi scambiati tra client
e server DHCP durante il riutilizzo di un indirizzo di
rete precedentemente allocato
Se la richiesta del client non è valida (ad esempio, il client si è spostato su una nuova subnet), i server DOVREBBERO rispondere al client con un messaggio DHCPNAK. I server NON DOVREBBERO rispondere se le loro informazioni non sono garantite come accurate. Ad esempio, un server che identifica una richiesta per un binding scaduto di proprietà di un altro server NON DOVREBBE rispondere con un DHCPNAK a meno che i server non stiano utilizzando un meccanismo esplicito per mantenere la coerenza tra i server.
Se 'giaddr' è 0x0 nel messaggio DHCPREQUEST, il client si trova sulla stessa subnet del server. Il server DEVE trasmettere il messaggio DHCPNAK all'indirizzo di broadcast 0xffffffff perché il client potrebbe non avere un indirizzo di rete o una maschera di subnet corretti, e il client potrebbe non rispondere alle richieste ARP. Altrimenti, il server DEVE inviare il messaggio DHCPNAK all'indirizzo IP dell'agente relay BOOTP, come registrato in 'giaddr'. L'agente relay, a sua volta, inoltrerà il messaggio direttamente all'indirizzo hardware del client, in modo che il DHCPNAK possa essere consegnato anche se il client si è spostato su una nuova rete.
3. Il client riceve il messaggio DHCPACK con i parametri di configurazione. Il client esegue un controllo finale sui parametri (come nella sezione 3.1), e annota la durata del lease specificata nel messaggio DHCPACK. Il lease specifico è implicitamente identificato dal 'client identifier' o 'chaddr' e dall'indirizzo di rete. A questo punto, il client è configurato.
Se il client rileva che l'indirizzo IP nel messaggio DHCPACK è già in uso, il client DEVE inviare un messaggio DHCPDECLINE al server e riavvia il processo di configurazione richiedendo un nuovo indirizzo di rete. Questa azione corrisponde al client che si sposta allo stato INIT nel diagramma di stato DHCP, descritto nella sezione 4.4.
Se il client riceve un messaggio DHCPNAK, non può riutilizzare il suo indirizzo di rete memorizzato. Deve invece richiedere un nuovo indirizzo riavviando il processo di configurazione, questa volta utilizzando la procedura (non abbreviata) descritta nella sezione 3.1. Anche questa azione corrisponde al client che si sposta allo stato INIT nel diagramma di stato DHCP.
Se il client non riceve né un messaggio DHCPACK né un messaggio DHCPNAK, il client scade e ritrasmette il messaggio DHCPREQUEST, secondo l'algoritmo di ritrasmissione nella sezione 4.1. Il client DOVREBBE scegliere di ritrasmettere il DHCPREQUEST un numero di volte sufficiente per fornire una probabilità adeguata di contattare il server senza far attendere eccessivamente a lungo il client (e l'utente di quel client) prima di arrendersi; ad esempio, un client che ritrasmette come descritto nella sezione 4.1 potrebbe ritrasmettere il messaggio DHCPREQUEST quattro volte, per un ritardo totale di 60 secondi, prima di riavviare la procedura di inizializzazione. Se il client non riceve né un messaggio DHCPACK né un messaggio DHCPNAK dopo aver impiegato l'algoritmo di ritrasmissione, il client PUÒ scegliere di utilizzare l'indirizzo di rete precedentemente allocato e i parametri di configurazione per il resto del lease non scaduto. Ciò corrisponde allo spostamento allo stato BOUND nel diagramma di transizione di stato del client mostrato nella figura 5.
4. Il client può scegliere di rinunciare al suo lease su un indirizzo di rete inviando un messaggio DHCPRELEASE al server. Il client identifica il lease da rilasciare con il suo 'client identifier' o 'chaddr' e l'indirizzo di rete nel messaggio DHCPRELEASE.
Si noti che in questo caso, in cui il client conserva il suo indirizzo di rete localmente, il client normalmente non rinuncerà al suo lease durante uno spegnimento corretto. Solo nel caso in cui il client abbia bisogno esplicitamente di rinunciare al suo lease, ad esempio, il client sta per essere spostato su una subnet diversa, il client invierà un messaggio DHCPRELEASE.
3.3 Interpretazione e rappresentazione dei valori temporali (Interpretation and representation of time values)
Un client acquisisce un lease per un indirizzo di rete per un periodo fisso (che può essere per sempre). In tutto il protocollo, i tempi devono essere rappresentati in unità di secondi. Il valore temporale 0xffffffff è riservato per rappresentare "infinito".
Poiché client e server potrebbero non avere orologi sincronizzati, i tempi sono rappresentati nei messaggi DHCP come tempi relativi, da interpretare rispetto all'orologio locale del client. Rappresentare i tempi relativi in unità di secondi in una parola a 32 bit senza segno fornisce un intervallo di tempi relativi da 0 a circa 100 anni, il che è sufficiente per i tempi relativi da misurare utilizzando DHCP.
L'algoritmo per l'interpretazione della durata del lease fornito nel paragrafo precedente presuppone che gli orologi del client e del server siano stabili l'uno rispetto all'altro. Se c'è una deriva tra i due orologi, il server può considerare il lease scaduto prima che lo faccia il client. Per compensare, il server può restituire una durata del lease più breve al client rispetto a quella che il server impegna nel suo database locale di informazioni sul client.
3.4 Ottenimento di parametri con indirizzo di rete configurato esternamente (Obtaining parameters with externally configured network address)
Se un client ha ottenuto un indirizzo di rete attraverso altri mezzi (ad esempio, configurazione manuale), può utilizzare un messaggio di richiesta DHCPINFORM per ottenere altri parametri di configurazione locali. I server che ricevono un messaggio DHCPINFORM costruiscono un messaggio DHCPACK con tutti i parametri di configurazione locali appropriati per il client senza: allocare un nuovo indirizzo, controllare un binding esistente, compilare 'yiaddr' o includere parametri di tempo del lease. I server DOVREBBERO inviare in unicast la risposta DHCPACK all'indirizzo fornito nel campo 'ciaddr' del messaggio DHCPINFORM.
Il server DOVREBBE controllare la coerenza dell'indirizzo di rete in un messaggio DHCPINFORM, ma NON DEVE controllare l'esistenza di un lease esistente. Il server forma un messaggio DHCPACK contenente i parametri di configurazione per il client richiedente e invia il messaggio DHCPACK direttamente al client.
3.5 Parametri del client in DHCP (Client parameters in DHCP)
Non tutti i client richiedono l'inizializzazione di tutti i parametri elencati nell'Appendice A. Due tecniche vengono utilizzate per ridurre il numero di parametri trasmessi dal server al client. In primo luogo, la maggior parte dei parametri ha valori predefiniti definiti nelle RFC sui requisiti degli host; se il client non riceve parametri dal server che sovrascrivono i valori predefiniti, un client utilizza quei valori predefiniti. In secondo luogo, nel suo messaggio DHCPDISCOVER o DHCPREQUEST iniziale, un client può fornire al server un elenco di parametri specifici a cui il client è interessato. Se il client include un elenco di parametri in un messaggio DHCPDISCOVER, DEVE includere quell'elenco in tutti i messaggi DHCPREQUEST successivi.
Il client DOVREBBE includere l'opzione 'maximum DHCP message size' per far sapere al server quanto grande il server può rendere i suoi messaggi DHCP. I parametri restituiti a un client possono ancora superare lo spazio allocato per le opzioni in un messaggio DHCP. In questo caso, due flag di opzione aggiuntivi (che devono apparire nel campo 'options' del messaggio) indicano che i campi 'file' e 'sname' devono essere utilizzati per le opzioni.
Il client può informare il server quali parametri di configurazione interessano al client includendo l'opzione 'parameter request list'. La porzione di dati di questa opzione elenca esplicitamente le opzioni richieste per numero di tag.
Inoltre, il client può suggerire valori per l'indirizzo di rete e il tempo del lease nel messaggio DHCPDISCOVER. Il client può includere l'opzione 'requested IP address' per suggerire che venga assegnato un particolare indirizzo IP, e può includere l'opzione 'IP address lease time' per suggerire il tempo del lease che desidera. Altre opzioni che rappresentano "suggerimenti" ai parametri di configurazione sono consentite in un messaggio DHCPDISCOVER o DHCPREQUEST. Tuttavia, opzioni aggiuntive possono essere ignorate dai server e più server potrebbero non restituire gli stessi valori per alcune opzioni. L'opzione 'requested IP address' deve essere compilata solo in un messaggio DHCPREQUEST quando il client sta verificando parametri di rete precedentemente allocati e memorizzati nella cache. Il client compila il campo 'ciaddr' solo quando è correttamente configurato con un indirizzo IP nello stato BOUND, RENEWING o REBINDING.
Se un server riceve un messaggio DHCPREQUEST con un 'requested IP address' non valido, il server DOVREBBE rispondere al client con un messaggio DHCPNAK e può scegliere di segnalare il problema all'amministratore di sistema. Il server può includere un messaggio di errore nell'opzione 'message'.
3.6 Uso di DHCP in client con più interfacce (Use of DHCP in clients with multiple interfaces)
Un client con più interfacce di rete DEVE utilizzare DHCP tramite ciascuna interfaccia indipendentemente per ottenere i parametri di informazioni di configurazione per quelle interfacce separate.
3.7 Quando i client dovrebbero utilizzare DHCP (When clients should use DHCP)
Un client DOVREBBE utilizzare DHCP per riacquisire o verificare il suo indirizzo IP e i parametri di rete ogni volta che i parametri di rete locali potrebbero essere cambiati; ad esempio, all'avvio del sistema o dopo una disconnessione dalla rete locale, poiché la configurazione della rete locale può cambiare senza la conoscenza del client o dell'utente.
Se un client ha conoscenza di un indirizzo di rete precedente e non è in grado di contattare un server DHCP locale, il client può continuare a utilizzare l'indirizzo di rete precedente fino a quando il lease per quell'indirizzo scade. Se il lease scade prima che il client possa contattare un server DHCP, il client deve immediatamente interrompere l'uso dell'indirizzo di rete precedente e può informare gli utenti locali del problema.