Protocollo DHCP

Quando a un'organizzazione viene assegnato un blocco di indirizzi (Livello di rete e indirizzamento IPIl livello di rete (network layer) porta i datagrammi da host a host attraverso i router: incapsula (framing), sceglie il percorso (routing) e sposta il pacchetto da un ingresso a un'uscita del router (forwarding); in Internet lascia ai livelli superiori controllo d'errore, di flusso e di congestione. Un indirizzo IPv4 è di 32 bit, diviso in prefisso (rete, $n$ bit) e suffisso (host, $32-n$ bit). L'indirizzamento a classi (A, B, C, D, E) è obsoleto; oggi si usa quello senza classi (CIDR): data una notazione $a.b.c.d/n$ si ricavano $N=2^{32-n}$ indirizzi, indirizzo di rete (suffisso tutto 0) e di broadcast (suffisso tutto 1), oppure con la netmask: rete $=$ indirizzo AND maschera, broadcast $=$ indirizzo OR (NOT maschera).Livello di rete e indirizzamento IP →, Subnetting e supernettingIl subnetting divide un blocco di indirizzi in sottoblocchi più piccoli allungando la maschera ($n_{\text{sub}}=n_{\text{rete}}+s$, con $2^s$ sottoreti); il supernetting (aggregazione CIDR) fa l'opposto, accorciando il prefisso per unire blocchi contigui in uno più grande. Regole di progetto: ogni sottorete ha un numero di indirizzi potenza di 2 ($M=2^k\ge$ host richiesti $+2$), prefisso $n=32-k$, indirizzo iniziale multiplo di $M$; si assegnano prima le sottoreti più grandi. Per aggregare $2^j$ blocchi di prefisso $n$ servono blocchi contigui il cui primo indirizzo sia multiplo della dimensione dell'aggregato, e il nuovo prefisso è $n-j$.Subnetting e supernetting →), l'amministratore di rete potrebbe assegnare a mano a ogni host e router indirizzo IP e netmask: poco efficiente e soggetto a errori. Per automatizzare la configurazione sono nati due protocolli:

• BOOTP (Bootstrap Protocol), oggi deprecato;
• DHCP (Dynamic Host Configuration Protocol).

BOOTP e DHCP a confronto

BOOTP: indirizzamento statico. Il server BOOTP contiene una tabella con gli indirizzi MAC e l'indirizzo IP da assegnare a ciascun MAC. Quando arriva una richiesta, il server cerca nella tabella e restituisce l'IP corrispondente. Che cosa succede se arrivano host nuovi? Non sono nella tabella: vanno aggiunti a mano.

DHCP: indirizzamento dinamico.

• gli host possono essere più degli indirizzi disponibili (per esempio in una rete Wi-Fi in cui molti utenti si collegano a turno);
• utile quando gli host non richiedono IP permanenti;
• l'indirizzo è dato in prestito (lease) per un tempo limitato: scaduto il tempo, l'host deve restituirlo (o rinnovarlo);
• quando gli indirizzi sono tutti assegnati, le nuove richieste vengono rifiutate;
• è un protocollo client-server: il client invia un messaggio di richiesta e il server risponde.

Le fasi del protocollo

DHCP usa UDP (Protocollo UDPUDP (User Datagram Protocol) è il protocollo di trasporto senza connessione e inaffidabile: rispetto a IP aggiunge soltanto la comunicazione processo-processo (numeri di porta) e un controllo d'errore facoltativo. L'intestazione è di soli 8 byte (porta sorgente, porta destinazione, lunghezza, checksum). Il checksum copre pseudo-intestazione (indirizzi IP, protocollo 17, lunghezza), intestazione e dati, ed è il complemento a uno della somma a 16 bit; se vale 0 significa "non calcolato", e un risultato 0 si trasmette come 0xFFFF. UDP non ha connessione, numeri di sequenza, controllo di flusso, di errore né di congestione: si sceglie per i messaggi brevi (DNS, DHCP, RIP, SNMP) e per le applicazioni in tempo reale, dove conta non aggiungere ritardo.Protocollo UDP →): la porta del server è 67, quella del client è 68 (eccezione alla regola secondo cui i client hanno porte effimere: il client DHCP ha una porta ben nota). Il motivo di usare broadcast e UDP è che il client, all'inizio, non ha né indirizzo IP né conoscenza del server: non può aprire una connessione TCP, che richiede un indirizzo di destinazione preciso e uno scambio di segmenti tra due indirizzi già configurati. Anche il frame che trasporta il DISCOVER esce con indirizzo MAC di destinazione di broadcast (ff:ff:ff:ff:ff:ff, tutti i bit a 1), perché il client non conosce il MAC del server e non può usare Protocollo ARPUn host ha tre «nomi»: nome DNS, indirizzo IP (rete) e indirizzo MAC (collegamento). Per spedire un datagramma IP in un frame serve il MAC del prossimo nodo, che si ottiene da quel nodo con ARP: richiesta in broadcast (MAC destinazione FF:FF:FF:FF:FF:FF, contiene IP e MAC del mittente e l'IP cercato) e risposta unicast con il MAC richiesto, memorizzata nella cache ARP. ARP risolve sempre il prossimo salto (host di destinazione o router), non la destinazione finale. Un broadcast non esce dalla sottorete: il proxy ARP del router risponde con il proprio MAC.Protocollo ARP → senza un IP. I due broadcast sono su livelli diversi: $255.255.255.255$ è il broadcast di rete, il MAC tutto a 1 è quello di collegamento.

1. Discovery (scoperta). L'host (client) che deve configurare la sua interfaccia invia in broadcast un messaggio DHCPDISCOVER, contenente il suo indirizzo MAC. Il campo transaction ID è un numero casuale (serve ad abbinare le risposte alla richiesta). Gli altri campi non si possono impostare, perché l'host non sa ancora niente.

• IP sorgente: $0.0.0.0$ (tutti 0);
• IP destinazione: $255.255.255.255$ (tutti 1, broadcast limitato).

2. Offer (offerta). Ogni server DHCP intercetta la richiesta e risponde in broadcast con un DHCPOFFER che contiene il proprio identificativo, l'indirizzo IP proposto e il tempo di lease. Possono esserci più server DHCP (ciascuno risponde).

• IP sorgente: IP del server DHCP;
• IP destinazione: $255.255.255.255$.

3. Request (richiesta). Il client riceve una o più offerte e sceglie la migliore. Accetta l'offerta inviando in broadcast un DHCPREQUEST che contiene l'identificativo del server la cui offerta ha scelto (così gli altri server capiscono di non essere stati scelti).

• IP sorgente: il nuovo IP assegnato al client;
• IP destinazione: $255.255.255.255$.

(Precisazione: così scrivono le slide. Nella pratica, finché il client non ha ricevuto l'ACK non può ancora usare l'indirizzo offerto, e di solito il REQUEST parte ancora con sorgente $0.0.0.0$, con l'IP proposto scritto nel contenuto del messaggio; la sorgente è il nuovo IP solo nei rinnovi. Nei tracciati d'esame si segue la tabella delle slide.)

4. ACK (conferma). Il server associa l'IP all'host e risponde in broadcast con un DHCPACK, che contiene tutte le informazioni per configurare l'interfaccia:

• netmask (da cui si ricava la parte NetID/HostID, Livello di rete e indirizzamento IPIl livello di rete (network layer) porta i datagrammi da host a host attraverso i router: incapsula (framing), sceglie il percorso (routing) e sposta il pacchetto da un ingresso a un'uscita del router (forwarding); in Internet lascia ai livelli superiori controllo d'errore, di flusso e di congestione. Un indirizzo IPv4 è di 32 bit, diviso in prefisso (rete, $n$ bit) e suffisso (host, $32-n$ bit). L'indirizzamento a classi (A, B, C, D, E) è obsoleto; oggi si usa quello senza classi (CIDR): data una notazione $a.b.c.d/n$ si ricavano $N=2^{32-n}$ indirizzi, indirizzo di rete (suffisso tutto 0) e di broadcast (suffisso tutto 1), oppure con la netmask: rete $=$ indirizzo AND maschera, broadcast $=$ indirizzo OR (NOT maschera).Livello di rete e indirizzamento IP →);

• default gateway (il router a cui spedire i pacchetti per le reti diverse da quella locale, Instradamento e inoltroL'inoltro (forwarding) mette il pacchetto sulla strada verso la destinazione, un salto alla volta (hop by hop). Se la destinazione è nella stessa rete del mittente l'inoltro è diretto (si usa l'ARP per il MAC del destinatario), altrimenti è indiretto: il pacchetto va al router successivo (next hop) indicato dalla tabella di instradamento, o al default gateway. Con le netmask: l'inoltro è diretto attraverso l'interfaccia $x$ se $\text{IP(dst)}\ \text{AND}\ \text{NM}(x)=\text{IP}(x)\ \text{AND}\ \text{NM}(x)$; altrimenti si scorre la tabella dalla maschera più lunga (longest prefix match) e si usa il primo match. La riga con rete $0.0.0.0$ e maschera $0.0.0.0$ (default route) corrisponde sempre. L'aggregazione di rotte (route aggregation) riduce la tabella, e nell'inoltro con etichette (MPLS) la tabella si consulta per indice.Instradamento e inoltro →);

• server DNS (per tradurre i nomi in indirizzi IP);

• e, nelle slide, anche il percorso da cui ottenere altre informazioni di configurazione (con FTP/TFTP).

• IP sorgente: IP del server DHCP;

• IP destinazione: $255.255.255.255$.

5. Release (rilascio). Quando l'indirizzo non serve più (per esempio l'interfaccia viene spenta), il client invia in unicast un DHCPRELEASE al server selezionato. L'indirizzo torna nel pool.

• IP sorgente: IP del client;
• IP destinazione: IP del server DHCP scelto.

Riassunto dei messaggi:

Esempio. Un laptop entra in una rete Wi-Fi che usa il blocco $192.168.1.0/24$ con un server DHCP in $192.168.1.1$ e un pool da $.100$ a $.200$ (101 indirizzi). Il laptop manda DISCOVER ($0.0.0.0\to255.255.255.255$, UDP $68\to67$); il server propone $192.168.1.123$ con lease di un'ora; il laptop risponde con REQUEST; il server conferma con ACK e comunica netmask $255.255.255.0$, gateway $192.168.1.1$ e un server DNS. Da quel momento il laptop può usare l'IP. A fine sessione invia RELEASE e l'indirizzo $.123$ torna disponibile per un altro dispositivo: con 101 indirizzi si possono servire anche più di 101 dispositivi, purché non siano collegati tutti insieme.

Diagramma di stato del client e rinnovo del lease

Il client DHCP è una macchina a stati:

Se il server non risponde alla richiesta di rinnovo, la richiesta viene ripetuta; se risponde con DHCPNACK il client deve ricominciare da capo, se risponde con DHCPACK ottiene un nuovo lease.

Esempio. Lease di 24 ore: il client tenta il rinnovo (Renewing) dopo $0{,}5\cdot24=12$ ore, e se non ha ottenuto risposta passa a Rebinding dopo $0{,}875\cdot24=21$ ore; a 24 ore l'indirizzo scade e il client deve ripartire da DHCPDISCOVER. Con un lease di 1 ora (come nel laptop dell'esempio precedente) le soglie sono 30 minuti e $0{,}875\cdot60=52{,}5$ minuti. Il 50% lascia al client mezzo lease di tempo per provare a rinnovare dal server originale; l'87,5% ($7/8$) è la soglia oltre la quale, se quel server non risponde, si chiede a qualunque server in broadcast: rimane solo $1/8$ del lease (nell'esempio $7{,}5$ minuti su 60) per trovare un altro server prima di perdere l'indirizzo.

Quanti indirizzi servono: un conto con la formula di Little

La durata del lease e la dimensione del pool sono legate. Se in media arrivano $\lambda$ dispositivi al secondo e ciascuno tiene l'indirizzo per un tempo medio $T$, il numero medio di indirizzi occupati è $N=\lambda T$ (formula di Littleil numero medio di elementi nel sistema è il tasso di arrivo per il tempo medio di permanenzaSistemi a coda - processo di Poisson, M/M/1 e formula di Little →). Esempio. In un'aula entrano in media $120$ dispositivi all'ora e ognuno resta collegato in media $2$ ore: $N=120\cdot2=240$ indirizzi occupati. Con un pool $/24$ da $254$ indirizzi assegnabili resta un margine di solo $254-240=14$ indirizzi: in media va bene, ma nei momenti di punta le richieste verrebbero rifiutate. Con un lease più corto gli indirizzi dei dispositivi già usciti tornano prima nel pool, ma il client deve rinnovare più spesso (messaggi in più).

Client e server su reti diverse

Un messaggio di broadcast limitato non attraversa i router: se il server DHCP non è nella stessa rete del client, la richiesta non lo raggiunge. In pratica si installa sul router di quella rete un agente di inoltro (relay agent), che riceve il broadcast del client e lo inoltra in unicast al server DHCP (che può stare in un'altra rete) e poi riporta la risposta al client. (Questo meccanismo non è sviluppato nelle slide, che si limitano a porre la domanda.)

Il DHCP si collega a ciò che si è visto sull'inoltro: nel caso di inoltro indiretto (indirect forwarding) il mittente deve conoscere l'indirizzo IP del default gateway, ed è proprio il DHCPACK a comunicarglielo (Instradamento e inoltroL'inoltro (forwarding) mette il pacchetto sulla strada verso la destinazione, un salto alla volta (hop by hop). Se la destinazione è nella stessa rete del mittente l'inoltro è diretto (si usa l'ARP per il MAC del destinatario), altrimenti è indiretto: il pacchetto va al router successivo (next hop) indicato dalla tabella di instradamento, o al default gateway. Con le netmask: l'inoltro è diretto attraverso l'interfaccia $x$ se $\text{IP(dst)}\ \text{AND}\ \text{NM}(x)=\text{IP}(x)\ \text{AND}\ \text{NM}(x)$; altrimenti si scorre la tabella dalla maschera più lunga (longest prefix match) e si usa il primo match. La riga con rete $0.0.0.0$ e maschera $0.0.0.0$ (default route) corrisponde sempre. L'aggregazione di rotte (route aggregation) riduce la tabella, e nell'inoltro con etichette (MPLS) la tabella si consulta per indice.Instradamento e inoltro →). Gli indirizzi che un server DHCP distribuisce in una rete locale sono spesso privati (NAT e indirizzi privatiUna rete privata (intranet) usa il protocollo TCP/IP con indirizzi privati ($10.0.0.0/8$, $172.16.0.0/12$, $192.168.0.0/16$), riutilizzabili da intranet diverse ma da non instradare in Internet: i router di bordo scartano i pacchetti con indirizzi privati. Per accedere a Internet servono un proxy applicativo (uno per applicazione) o il NAT (Network Address Translation): un router che traduce indirizzi privati in indirizzi pubblici di un pool, con una tabella NAT e un'associazione dinamica per sessione. Il NAT tradizionale è outbound: Basic NAT traduce solo l'IP (uno a uno, quindi servono tanti indirizzi pubblici quante le sessioni contemporanee), NAPT traduce anche la porta ([IP privato, porta] $\to$ [IP pubblico, porta del NAT]) e permette a molte sessioni di condividere un solo IP pubblico. Il Twice NAT permette sessioni anche dall'esterno, con un DNS interno e associazioni statiche.NAT e indirizzi privati →).