Guida completa al protocollo DHCP – Prima parte

Questa guida, nella parte, cercherà di spiegarvi il funzionamento del protocollo DHCP (Dynamic Host Configuration Protocol – Protocollo per la configurazione dinamica degli host). Nella seconda parte verranno forniti degli esempi di configurazione, sotto Cisco IOS.

Caratteristiche del DHCP

Come spiegato nell’RFC 2131, il Dynamic Host Configuration Protocol, fornisce i parametri di configurazione agli host Internet. DHCP utilizza il modello client/server, dove un server DHCP fornisce i parametri di rete ai client, i quali, a loro volta devono essere configurati in modo tale da ricevere in maniera dinamica gli stessi.

I client posso ricevere molteplici parametri, comunque quello più significativo è l’indirizzo IP.

DHCP supporta tre meccanismi per l’allocazione degli indirizzi IP:

• Allocazione automatica – DHCP assegna in modo permanente un indirizzo IP al client;
• Allocazione dinamica – DHCP assegna l’indirizzo IP al client per un periodo di tempo limitato (o finchè il client non richiede l’esplicitamente il rinnovo del indirizzo);
• Allocazione manuale – L’amministratore di rete assegna un indirizzo IP al client e utilizza il DHCP soltanto per “trasmettere” questo parametro al client.

La comunità Internet originariamente sviluppò il protocollo chiamato Bootstrap Protocol, conosciuto meglio come BOOTP, per permettere ai cosiddetti Thin Client, delle Workstation senza il disco, di ottenere parametri iniziali di rete, per poter accedere ai server e caricare il sistema operativo nella memoria. Il protocollo BOOTP è stato originariamente definito nel 1985 nell’RFC 951. BOOTP è il predecessore del protocollo DHCP e come tale condivide alcune caratteristiche con esso. Come già accennato in precedenza, anche BOOTP come il DHCP, è basato su un architettura client/server. Entrambi i protocolli utilizzano User Datagram Protocol (UDP) come loro protocollo di trasporto. I client inviano i messaggi al server sulla porta 67 mentre il server invia i messaggi ai client sulla porta 68; entrambe, tutt’ora, sono conosciute come porte BOOTP.

Il formato dei messaggi DHCP è basato sul formato dei messaggi del Bootstrap Protocol (BOOTP) e questo garantisce l’interoperabilità tra i client BOOTP e i server DHCP.

Non mi dilungherò troppo sul protocollo BOOTP. Le cose principali da sapere sono: primo, il protocollo BOOTP non alloca automaticamente gli indirizzi IP ai client. Quando un client BOOTP richiede un indirizzo IP, il server BOOTP cerca in una tabella se l’indirizzo MAC di quel client è presente. Nel caso venisse trovato, restituisce l’indirizzo IP indicato per quel client, altrimenti non restituisce alcun parametro. Questo significa che deve già essere impostata una relazione MAC-IP nella configurazione del server BOOTP. Secondo, BOOTP a differenza del DHCP, fornisce solo i parametri IP base che possono essere considerati, l’indirizzo IP, l’indirizzo del Default Gateway, la maschera di sottorete e l’indirizzo del server DNS.

Il dialogo tra il client e il server DHCP

1. Il client invia una richiesta al server richiedendo dei parametri per la configurazione IP. A volte il client può suggerire l’indirizzo IP che desidera e solitamente ciò accade quando un client richiede il prolungamento del lease. La richiesta riesce a raggiungere il server in quanto essa viene inviata in broadcast sull’indirizzo 255.255.255.255. Questo tipo di richiesta/pacchetto viene chiamato DHCPDISCOVER.
2. Quando un DHCP server riceve un broadcast, per prima cosa cerca di determinare se riesce a soddisfare la richiesta basandosi sul proprio database. Se questo si verifica, il server DHCP offre dei parametri di configurazione al client sotto forma di un messaggio unicast chiamato DHCPOFFER, nel caso contrario, il server può inoltrare la richiesta ad un altro server DHCP. Il pacchetto DHCPOFFER contiene una configurazione proposta dal server la quale può contenere ad esempio l’indirizzo IP, l’indirizzo del server DNS e il tempo di lease.
3. Se per il client l’offerta ricevuta è accettabile, invierà un altro broadcast, chiamato DHCPREQUEST, nel quale richiederà quello specifico indirizzo e altri parametri ricevuti via DHCPOFFER. Sicuramente vi chiederete il perché di questo fatto. Molti di voi probabilmente penseranno per quale motivo il client deve inviare un altro broadcast… non poteva semplicemente accettare l’indirizzo e comunicare successivamente al server via messaggio unicast l’avvenuta accettazione del indirizzo? Questa soluzione è utilizzata perché il messaggio DHCPDISCOVER inviato in multicast, potrebbe aver raggiunto più di un server DHCP. Se più di un server DHCP effettua un’offerta, il pacchetto DHCPREQUEST inviato in via broadcast permette a tutti gli altri server DHCP di sapere quale DHCPOFFER è stato accettato e conseguentemente permettere agli altri server DHCP di considerare libero l’indirizzo proposto e riutilizzarlo per le successive richieste. Normalmente dal client viene accettata la prima offerta ricevuta.
4. Il server che riceve DHCPREQUEST corrispondente alla sua offerta, “ufficializza” la configurazione mandando via unicast la conferma sotto forma di un pacchetto DHCPACK. E’ possibile, ma improbabile, che il server non invii il DHCPACK. Questo potrebbe succedere nel caso in cui il server, nel frattempo, ha assegnato i parametri ad un altro client. Il ricevimento del pacchetto DHCPACK permette al client di iniziare ad utilizzare quei parametri da subito.
5. Se il client determina che l’indirizzo assegnatogli è già utilizzato nella sua rete, invierà un messaggio DHCPDECLINE e il processo ricomincerà da capo. Lo stesso succederà nel caso in cui il client dovesse ricevere un messaggio DHCPNACK dal server dopo aver inviato il DHCPREQUEST.
6. Se il client non ha più bisogno dell’ indirizzo assegnatogli invierà un messaggio DHCPRELEASE al server.

Nell’immagine sottostante potete osservare graficamente il processo della richiesta DHCP.

Una delle caratteristiche del server DHCP integrato in Cisco IOS è che il server prima di offrire un indirizzo al client si assicura che questo non sia effettivamente utilizzato emettendo una richiesta ICMP Echo, comunemente detta “ping”, verso l’indirizzo in questione.

Per il momento il lato teorico è finito. Come al solito, tutti i commenti sono benvenuti.

A presto la seconda parte della guida, riguardo alla configurazione del Cisco IOS come un server DHCP, con delle tip “piccanti”.

Saluti.