2. Riepilogo del protocollo (Protocol Summary)
Dal punto di vista di un client, DHCP è un'estensione del meccanismo BOOTP. Questo comportamento consente ai client BOOTP esistenti di interoperare con i server DHCP senza richiedere alcuna modifica al software di inizializzazione dei client. RFC 1542 [2] descrive in dettaglio le interazioni tra client e server BOOTP e DHCP [9]. Esistono alcune nuove transazioni opzionali che ottimizzano l'interazione tra client e server DHCP, descritte nelle sezioni 3 e 4.
La Figura 1 mostra il formato di un messaggio DHCP e la Tabella 1 descrive ciascuno dei campi in un messaggio DHCP. I numeri tra parentesi indicano la dimensione di ciascun campo in ottetti. I nomi dei campi indicati nella figura saranno utilizzati in tutto questo documento per fare riferimento ai campi nei messaggi DHCP.
Ci sono due differenze principali tra DHCP e BOOTP. In primo luogo, DHCP definisce meccanismi attraverso i quali ai client può essere assegnato un indirizzo di rete per un lease finito, consentendo la riassegnazione seriale di indirizzi di rete a diversi client. In secondo luogo, DHCP fornisce il meccanismo per un client per acquisire tutti i parametri di configurazione IP di cui ha bisogno per operare.
DHCP introduce un piccolo cambiamento terminologico destinato a chiarire il significato di uno dei campi. Quello che era il campo "vendor extensions" in BOOTP è stato rinominato campo "options" in DHCP. Allo stesso modo, gli elementi di dati contrassegnati che venivano utilizzati all'interno del campo "vendor extensions" di BOOTP, precedentemente denominati "vendor extensions", sono ora semplicemente chiamati "options".
Formato di un messaggio DHCP (Format of a DHCP message)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | htype (1) | hlen (1) | hops (1) |
+---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+
Figura 1: Formato di un messaggio DHCP
DHCP definisce una nuova opzione "client identifier" che viene utilizzata per passare un identificatore di client esplicito a un server DHCP. Questa modifica elimina il sovraccarico del campo "chaddr" nei messaggi BOOTP, dove "chaddr" veniva utilizzato sia come indirizzo hardware per la trasmissione dei messaggi di risposta BOOTP sia come identificatore di client. Il "client identifier" è una chiave opaca, da non interpretare dal server; ad esempio, il "client identifier" può contenere un indirizzo hardware, identico al contenuto del campo "chaddr", oppure può contenere un altro tipo di identificatore, come un nome DNS. Il "client identifier" scelto da un client DHCP DEVE essere univoco per quel client all'interno della subnet a cui il client è collegato. Se il client utilizza un "client identifier" in un messaggio, DEVE utilizzare lo stesso identificatore in tutti i messaggi successivi, per garantire che tutti i server identifichino correttamente il client.
DHCP chiarisce l'interpretazione del campo "siaddr" come indirizzo del server da utilizzare nel prossimo passo del processo di bootstrap del client. Un server DHCP può restituire il proprio indirizzo nel campo "siaddr", se il server è pronto a fornire il prossimo servizio di bootstrap (ad esempio, la consegna di un'immagine eseguibile del sistema operativo). Un server DHCP restituisce sempre il proprio indirizzo nell'opzione "server identifier".
Descrizione dei campi in un messaggio DHCP (Description of fields in a DHCP message)
| Campo | Ottetti | Descrizione |
|---|---|---|
| op | 1 | Codice operazione del messaggio / tipo di messaggio. 1 = BOOTREQUEST, 2 = BOOTREPLY |
| htype | 1 | Tipo di indirizzo hardware, vedere la sezione ARP nella RFC "Assigned Numbers"; ad esempio, '1' = 10mb ethernet. |
| hlen | 1 | Lunghezza dell'indirizzo hardware (ad esempio, '6' per 10mb ethernet). |
| hops | 1 | Impostato a zero dal client, utilizzato opzionalmente dagli agenti relay durante l'avvio tramite un agente relay. |
| xid | 4 | ID di transazione, un numero casuale scelto dal client, utilizzato dal client e dal server per associare messaggi e risposte tra un client e un server. |
| secs | 2 | Compilato dal client, secondi trascorsi da quando il client ha iniziato il processo di acquisizione o rinnovo dell'indirizzo. |
| flags | 2 | Flag (vedere figura 2). |
| ciaddr | 4 | Indirizzo IP del client; compilato solo se il client è nello stato BOUND, RENEW o REBINDING e può rispondere alle richieste ARP. |
| yiaddr | 4 | Indirizzo IP 'tuo' (client). |
| siaddr | 4 | Indirizzo IP del prossimo server da utilizzare nel bootstrap; restituito in DHCPOFFER, DHCPACK dal server. |
| giaddr | 4 | Indirizzo IP dell'agente relay, utilizzato durante l'avvio tramite un agente relay. |
| chaddr | 16 | Indirizzo hardware del client. |
| sname | 64 | Nome host del server opzionale, stringa terminata con null. |
| file | 128 | Nome del file di avvio, stringa terminata con null; nome "generico" o null in DHCPDISCOVER, nome di percorso di directory completamente qualificato in DHCPOFFER. |
| options | var | Campo di parametri opzionali. Vedere i documenti delle opzioni per un elenco delle opzioni definite. |
Tabella 1: Descrizione dei campi in un messaggio DHCP
Il campo "options" è ora di lunghezza variabile. Un client DHCP deve essere preparato a ricevere messaggi DHCP con un campo "options" di almeno 312 ottetti di lunghezza. Questo requisito implica che un client DHCP deve essere preparato a ricevere un messaggio fino a 576 ottetti, la dimensione minima del datagramma IP che un host IP deve essere preparato ad accettare [3]. I client DHCP possono negoziare l'uso di messaggi DHCP più grandi attraverso l'opzione "maximum DHCP message size". Il campo options può essere ulteriormente esteso nei campi "file" e "sname".
Nel caso di un client che utilizza DHCP per la configurazione iniziale (prima che il software TCP/IP del client sia completamente configurato), DHCP richiede un uso creativo del software TCP/IP del client e un'interpretazione liberale della RFC 1122. Il software TCP/IP DOVREBBE accettare e inoltrare al livello IP tutti i pacchetti IP consegnati all'indirizzo hardware del client prima che l'indirizzo IP sia configurato; i server DHCP e gli agenti relay BOOTP potrebbero non essere in grado di consegnare messaggi DHCP ai client che non possono accettare datagrammi unicast hardware prima che il software TCP/IP sia configurato.
Per aggirare alcuni client che non possono accettare datagrammi unicast IP prima che il software TCP/IP sia configurato come discusso nel paragrafo precedente, DHCP utilizza il campo "flags" [21]. Il bit più a sinistra è definito come flag BROADCAST (B). La semantica di questo flag è discussa nella sezione 4.1 di questo documento. I bit rimanenti del campo flags sono riservati per uso futuro. Essi DEVONO essere impostati a zero dai client e ignorati dai server e dagli agenti relay. La Figura 2 mostra il formato del campo "flags".
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: Flag BROADCAST
MBZ: DEVE ESSERE ZERO (MUST BE ZERO) (riservato per uso futuro)
Figura 2: Formato del campo 'flags'
2.1 Repository dei parametri di configurazione (Configuration parameters repository)
Il primo servizio fornito da DHCP è quello di fornire un'archiviazione persistente dei parametri di rete per i client di rete. Il modello di archiviazione persistente di DHCP è che il servizio DHCP memorizza una voce chiave-valore per ogni client, dove la chiave è un identificatore univoco (ad esempio, un numero di subnet IP e un identificatore univoco all'interno della subnet) e il valore contiene i parametri di configurazione per il client.
Ad esempio, la chiave potrebbe essere la coppia (IP-subnet-number, hardware-address), consentendo il riutilizzo seriale o simultaneo di un indirizzo hardware su diverse subnet, e per indirizzi hardware che potrebbero non essere globalmente univoci. In alternativa, la chiave potrebbe essere la coppia (IP-subnet-number, hostname), consentendo al server di assegnare in modo intelligente i parametri a un client DHCP che è stato spostato in una subnet diversa o ha cambiato il proprio indirizzo hardware (forse a causa di un guasto dell'interfaccia di rete e di una sostituzione dell'hardware). Il protocollo definisce che la chiave sarà (IP-subnet-number, hardware-address) a meno che il client non fornisca esplicitamente un identificatore utilizzando l'opzione "client identifier". Un client può interrogare il servizio DHCP per recuperare i propri parametri di configurazione. L'interfaccia del client al repository dei parametri di configurazione consiste in messaggi di protocollo per richiedere parametri di configurazione e risposte dal server che trasportano i parametri di configurazione.
2.2 Allocazione dinamica degli indirizzi di rete (Dynamic allocation of network addresses)
Il secondo servizio fornito da DHCP è l'allocazione di indirizzi di rete (IP) temporanei o permanenti ai client. Il meccanismo di base per l'allocazione dinamica degli indirizzi di rete è semplice: un client richiede l'uso di un indirizzo per un certo periodo di tempo. Il meccanismo di allocazione (un insieme di server DHCP) garantisce di non riallocare quell'indirizzo entro il tempo richiesto e tenta di restituire lo stesso indirizzo di rete ogni volta che il client richiede un indirizzo. In questo documento, il periodo durante il quale un indirizzo di rete è allocato a un client è chiamato "lease" [11]. Il client può estendere il proprio lease con richieste successive. Il client può emettere un messaggio per rilasciare l'indirizzo al server quando il client non ha più bisogno dell'indirizzo. Il client può richiedere un'assegnazione permanente richiedendo un lease infinito. Anche quando si assegnano indirizzi "permanenti", un server può scegliere di fornire lease lunghi ma non infiniti per consentire il rilevamento del fatto che un client è stato dismesso.
In alcuni ambienti sarà necessario riassegnare gli indirizzi di rete a causa dell'esaurimento degli indirizzi disponibili. In tali ambienti, il meccanismo di allocazione riutilizzerà gli indirizzi il cui lease è scaduto. Il server dovrebbe utilizzare qualsiasi informazione disponibile nel repository di informazioni di configurazione per scegliere un indirizzo da riutilizzare. Ad esempio, il server può scegliere l'indirizzo assegnato meno di recente. Come controllo di coerenza, il server di allocazione DOVREBBE sondare l'indirizzo riutilizzato prima di allocare l'indirizzo, ad esempio, con una richiesta di echo ICMP, e il client DOVREBBE sondare l'indirizzo appena ricevuto, ad esempio, con ARP.