DHCP (Dynamic Host Configuration Protocol) – Teoria, DORA, lease e relay

DHCP: cos’è e cosa distribuisce

DHCP è un protocollo di rete che permette a un host di ottenere automaticamente una configurazione IP. In pratica, al client vengono assegnati parametri fondamentali per comunicare in rete senza configurazione manuale.

Parametri tipici forniti da DHCP

Indirizzo IP del client
Subnet mask
Default gateway (router)
DNS server (uno o più)
Durata della lease (prestito dell’IP)

Idea chiave: DHCP non fa routing e non “crea” la rete. Distribuisce parametri; poi il traffico IP segue le regole normali di switching e routing.

Errore concettuale frequente: “Ho messo DHCP quindi Internet funziona”. No: serve un gateway corretto, routing/NAT dove necessario e DNS funzionanti.

DORA: Discover, Offer, Request, Acknowledge

La prima configurazione avviene tipicamente con la sequenza DORA. Il client parte senza indirizzo valido, quindi deve “scoprire” un server DHCP nella rete locale.

DHCPDISCOVER: il client invia una richiesta di ricerca (broadcast).
DHCPOFFER: uno o più server rispondono proponendo un IP e opzioni.
DHCPREQUEST: il client dichiara quale offerta accetta.
DHCPACK: il server conferma e concede la lease.

Nota operativa: se arrivano più OFFER, il client ne sceglie una e lo comunica nel REQUEST.

DHCP usa UDP e le porte tipiche sono 67 (server) e 68 (client). La fase iniziale è spesso in broadcast perché il client non sa ancora a chi inviare unicast.

Lease: durata, rinnovo e perché non è “per sempre”

L’indirizzo assegnato dal DHCP è in lease, cioè un prestito temporaneo. Questo consente di riutilizzare indirizzi quando i dispositivi cambiano (laboratori, Wi-Fi, ospiti).

Rinnovi: T1 e T2

T1 (Renewal): il client prova a rinnovare la lease (tipicamente unicast al server).
T2 (Rebinding): se il server non risponde, il client prova a rinnovare via broadcast.
Scadenza: se non rinnova, l’IP non è più valido e va richiesta una nuova configurazione.

Scelta pratica della lease: in un laboratorio conviene una lease breve/moderata per evitare indirizzi “bloccati” da PC spenti. In una rete stabile puoi allungare.

APIPA (169.254.x.x): tipico segnale che il client non ha ricevuto risposta dal DHCP e si è auto-assegnato un IP locale.

DHCP Relay: quando server e client sono su reti diverse

I messaggi DHCP iniziali sono spesso broadcast nella LAN. Un router, per definizione, non inoltra broadcast tra reti diverse. Quindi un server DHCP in un’altra subnet non “vede” i client, a meno di usare un relay.

Regola da ricordare: client in VLAN/subnet diversa dal server DHCP → serve un DHCP Relay (o un server DHCP locale su quella rete).

Cosa fa il relay

Riceve il broadcast DHCP nella LAN dei client
Inoltra la richiesta in unicast verso il server remoto
Permette al server di capire da quale rete proviene la richiesta

Esempi minimi (Cisco IOS)

ip dhcp excluded-address 192.168.10.1 192.168.10.20
ip dhcp pool LAN10
 network 192.168.10.0 255.255.255.0
 default-router 192.168.10.1
 dns-server 8.8.8.8 1.1.1.1
 lease 1 0 0

interface g0/0
 ip address 192.168.20.1 255.255.255.0
 ip helper-address 192.168.100.10
 no shutdown

Troubleshooting rapido: se vedi Discover ma non vedi Offer, il problema è quasi sempre: relay mancante, server non raggiungibile, o pool non configurato per quella rete.

Client Windows

ipconfig /release
ipconfig /renew
ipconfig /all

Client Linux

sudo dhclient -r
sudo dhclient -v
ip a
ip r

Sicurezza essenziale: un “rogue DHCP” può distribuire gateway/DNS falsi. Su switch gestiti si limita il rischio con DHCP snooping (porte trusted vs untrusted).

Riepilogo rapido (da ripetere a voce)

DHCP distribuisce automaticamente IP, mask, gateway, DNS e opzioni.
La sequenza tipica è DORA: Discover → Offer → Request → ACK.
L’IP è in lease: si rinnova (T1/T2) e può scadere.
Tra subnet diverse serve un relay: i broadcast DHCP non attraversano i router.
In reti reali va considerata la sicurezza: rogue DHCP e mitigazioni lato switch.