Per poter co­mu­ni­ca­re tra loro in una rete, come Internet, i sistemi par­te­ci­pan­ti ri­chie­do­no un indirizzo IP. Anche se questo si può ef­fet­tua­re ma­nual­men­te, in pratica alla maggior parte dei di­spo­si­ti­vi vengono assegnati gli indirizzi in modo au­to­ma­ti­co. Alla base di questo processo c’è il pro­to­col­lo di co­mu­ni­ca­zio­ne DHCP, che supporta i sistemi che ricercano una con­nes­sio­ne al fine di ottenere le in­for­ma­zio­ni ne­ces­sa­rie. Agli albori di computer, rete, ecc., il pro­to­col­lo Bootstrap, noto anche come BOOTP, svolgeva ancora la funzione di gestore degli indirizzi.

Cos’è BOOTP (il pro­to­col­lo Bootstrap)?

Nel settembre del 1985, lo Stanford Uni­ver­si­ty Network Group ha pub­bli­ca­to la specifica RFC 951, la prima versione del pro­to­col­lo Bootstrap (BOOTP). Questo pro­to­col­lo di co­mu­ni­ca­zio­ne, svi­lup­pa­to in col­la­bo­ra­zio­ne con un team del pro­dut­to­re di computer Sun Mi­cro­sy­stems, ha permesso ai terminali e alle work­sta­tion senza disco rigido dell’epoca di uti­liz­za­re, oltre all’indirizzo IP, anche in­for­ma­zio­ni quali l’indirizzo del gateway, l’indirizzo del boot server e la cartella in cui è contenuto il file di avvio (ne­ces­sa­ria per caricare il sistema operativo). Questo pro­to­col­lo ha so­sti­tui­to il Reverse Address Re­so­lu­tion Protocol (RRP) uti­liz­za­to fino ad allora, che forniva esclu­si­va­men­te indirizzi di rete e poteva essere uti­liz­za­to solo nelle sottoreti.

Il pro­to­col­lo Bootstrap fa parte della famiglia dei pro­to­col­li Internet e funziona, come molti altri pro­to­col­li dello stack, secondo il modello client-server. Lo scambio di messaggi nella tra­smis­sio­ne di in­for­ma­zio­ni di rete avviene, dunque, tra un BOOTP client e un BOOTP server. Come pro­to­col­lo per il trasporto dei pacchetti di dati richiesti viene uti­liz­za­to lo User Datagram Protocol (UDP) (porte 67 e 68).   In confronto al TCP non solo risulta meno complesso, ma rispetto al pro­to­col­lo standard supporta anche il broa­d­ca­sting. Siccome durante la con­nes­sio­ne il client non conosce né il proprio indirizzo né quello del BOOTP server, questo sistema di scambio dei messaggi, uti­liz­za­to da tutti coloro che con­di­vi­do­no la rete, è l’unica soluzione per l’iden­ti­fi­ca­zio­ne au­to­ma­ti­ca degli indirizzi.

Come scambiare in­for­ma­zio­ni in rete con BOOTP

La mappatura degli indirizzi tramite BOOTP si basa su un semplice scambio di messaggi in due fasi tra client e server, in cui la parte client è l’ini­zia­to­re. Poiché il client all’inizio non conosce né il proprio indirizzo né l’indirizzo del BOOTP server, esso invia una richiesta generale (“BOO­TRE­QUE­ST”) all’indirizzo broadcast 255.255.255.255. Il server in ascolto sulla porta 67 riceve ed elabora la richiesta. Il compito prin­ci­pa­le è quello di assegnare all’indirizzo MAC di sistema del client il cor­ri­spon­den­te indirizzo IP. In seguito, la risposta (“BOOTREPLY”), comprese ulteriori in­for­ma­zio­ni di rete, viene quindi inviata tramite broadcast al client, che può così con­fi­gu­ra­re il sistema operativo in rete.

N.B.

Se il client conosce già l’indirizzo del BOOTP server, può anche inviare la richiesta di­ret­ta­men­te tramite con­nes­sio­ne unicast.

Questa è la struttura dei messaggi che client e server inviano nella co­mu­ni­ca­zio­ne tramite il pro­to­col­lo Bootstrap:

Ogni messaggio BOOTP inizia con il campo “op” di 8 bit, che definisce il tipo di ope­ra­zio­ne o di messaggio. Per le richieste del client viene impostato il valore 1 (per BOO­TRE­QUE­ST), mentre le risposte del server hanno il valore 2 (per BOOTREPLY). Seguono ri­spet­ti­va­men­te 8 bit che iden­ti­fi­ca­no il tipo (“htype”) e la lunghezza dell’indirizzo hardware (“hlen”). Il campo “hops”, sempre di 8 bit, indica il numero delle stazioni in­ter­me­die, at­tra­ver­so le quali passa il pacchetto durante il suo percorso verso il de­sti­na­ta­rio. Nelle richieste del client il valore è sempre 0.

Il blocco suc­ces­si­vo contiene una tran­sa­zio­ne ID casuale di 32 bit, generata dal client, che viene suc­ces­si­va­men­te uti­liz­za­ta nella risposta del server in modo che il client possa as­so­ciar­la in modo univoco. Il client compila, inoltre, il campo “secs” (16 bit), che indica i secondi trascorsi dal tentativo di avvio da parte del client. Le in­for­ma­zio­ni in­tro­dut­ti­ve sono com­ple­ta­te da un altro campo di 16 bit, che rimane com­ple­ta­men­te vuoto. Le altre voci del pacchetto BOOTP con­ten­go­no in­for­ma­zio­ni di rete, che vengono il­lu­stra­te nell’elenco seguente:

  • Indirizzo IP del client (ciaddr): l’etichetta “ciaddr” (client ip address) individua il campo di 32 bit in cui il client inserisce il proprio indirizzo IP, se lo conosce già. In caso contrario, al campo viene assegnato il valore 0.
  • Indirizzo IP del client (yiaddr): il campo “yiaddr” (your ip address) è sempre riservato all’indirizzo IP del client. A dif­fe­ren­za della sezione pre­ce­den­te del pacchetto, questo campo di 32 bit viene compilato dal server se il client non conosce il suo indirizzo IP nel momento in cui viene creata la richiesta di rete.
  • Indirizzo IP del server (siaddr): nella sequenza di 32 bit “siaddr” (server ip address) il BOOTP server comunica al client il proprio indirizzo IP.
  • Indirizzo IP del gateway (giaddr): se un gateway (ad esempio un router) è incluso nel processo di co­mu­ni­ca­zio­ne, il suo indirizzo viene inserito nel campo “giaddr” (gateway ip address).
  • Indirizzo hardware del client (chaddr): l’indirizzo hardware (128 bit) è uno dei valori ob­bli­ga­to­ri del client quando si utilizza il pro­to­col­lo Bootstrap per lo scambio di messaggi. Senza questo ID, detto anche indirizzo del di­spo­si­ti­vo o MAC, il server non può assegnare al client l’indirizzo corretto, né i parametri di rete ap­pro­pria­ti.
  • Nome host del server (sname): fa­col­ta­ti­va­men­te il server può anche spe­ci­fi­ca­re il proprio nome host nella risposta BOOTP. A tale scopo è di­spo­ni­bi­le un campo fino a 512 bit, nel quale è possibile inserire una stringa di caratteri con de­li­mi­ta­to­re zero (un carattere zero segna la fine della stringa).
  • Nome del file di avvio (file): la spe­ci­fi­ca­zio­ne di un file di avvio concreto, di cui il client ha bisogno per avviare il sistema operativo sul ri­spet­ti­vo terminale o sulla ri­spet­ti­va work­sta­tion, è ugual­men­te opzionale. Anche questo campo prevede una stringa con de­li­mi­ta­to­re zero, che in questo caso re­sti­tui­sce il percorso completo del file. La sequenza di caratteri può essere lunga fino a 1024 bit. Nella richiesta del client questo campo contiene il valore 0 o un nome generico.
  • In­for­ma­zio­ni spe­ci­fi­che del pro­dut­to­re (vend): nella parte finale del messaggio del pro­to­col­lo BOOTP si possono trovare in­for­ma­zio­ni spe­ci­fi­che del pro­dut­to­re che non sono previste dal pro­to­col­lo, come le spe­ci­fi­che e i numeri di serie hardware. Inoltre, quest’area in­for­ma­ti­va di 512 bit può essere riservata a un processo di bootstrap esterno o del kernel.

I messaggi BOOTP possono avere una lunghezza com­ples­si­va fino a 2400 bit (300 byte). Il pacchetto completo UDP/IP, con la richiesta o la risposta del pro­to­col­lo Bootstrap, presenta la seguente struttura:

BOOTP vs DHCP: perché il pro­to­col­lo Bootstrap non è più uti­liz­za­to oggi

Per i terminali client e le work­sta­tion senza disco rigido, BOOTP era la soluzione perfetta per ricevere un indirizzo IP privato sulla rete de­si­de­ra­ta e con­fi­gu­ra­re in questo modo il sistema operativo. Poiché l’iden­ti­fi­ca­zio­ne dell’indirizzo tramite il pro­to­col­lo di co­mu­ni­ca­zio­ne poteva essere ef­fet­tua­to durante il processo di booting, per i computer fissi, che erano uti­liz­za­ti in reti con di­men­sio­ni più gestibili, risultava pratico e semplice. Ad esempio, non era un problema che l’am­mi­ni­stra­to­re dovesse con­fi­gu­ra­re ma­nual­men­te le tabelle in­for­ma­ti­ve di rete del server BOOTP.

Tuttavia, con la crescita delle reti e la dif­fu­sio­ne di computer sempre più autonomi e mobili, grazie allo sviluppo di di­spo­si­ti­vi portatili, l’im­pos­si­bi­li­tà di au­to­ma­tiz­za­re il processo di con­fi­gu­ra­zio­ne diventava uno svan­tag­gio e cominciò perciò a nascere l’esigenza di un nuovo pro­to­col­lo. Tale suc­ces­so­re è stato in­di­vi­dua­to nel Dynamic Host Con­fi­gu­ra­tion Protocol (DHCP) nel 1993 (spe­ci­fi­che de­fi­ni­ti­ve nel RFC 2131). Anche se il DHCP si basa in gran parte sulla struttura del pro­to­col­lo bootstrap, im­ple­men­ta diverse opzioni di con­fi­gu­ra­zio­ne ag­giun­ti­ve e fornisce la pos­si­bi­li­tà di assegnare indirizzi di rete riu­ti­liz­za­bi­li ai client che ricercano una con­nes­sio­ne. Inoltre, l’as­se­gna­zio­ne delle in­for­ma­zio­ni dell’indirizzo con DHCP funziona anche durante l’ese­cu­zio­ne del sistema, senza che sia ne­ces­sa­rio un riavvio come avviene con BOOTP.

BOOTP vs DHCP: le dif­fe­ren­ze più im­por­tan­ti

  BOOTP DHCP
Au­to­con­fi­gu­ra­zio­ne L’as­se­gna­zio­ne degli indirizzi IP richiede la con­fi­gu­ra­zio­ne manuale delle tabelle degli indirizzi Supporta l’as­se­gna­zio­ne au­to­ma­ti­ca e l’iden­ti­fi­ca­zio­ne au­to­ma­ti­ca degli indirizzi IP (ma anche la con­fi­gu­ra­zio­ne manuale)
Indirizzi IP tem­po­ra­nei Non possibile Possibile per un periodo di tempo limitato
Supporto di di­spo­si­ti­vi mobili La con­fi­gu­ra­zio­ne IP e l’accesso alle in­for­ma­zio­ni di rete non sono possibili Supporta la mobilità dei client di rete
Pos­si­bi­li­tà di errori Elevata a causa della con­fi­gu­ra­zio­ne manuale Quasi privo di errori grazie alla con­fi­gu­ra­zio­ne au­to­ma­ti­ca dei com­po­nen­ti di rete
Requisiti di sistema Nessuno Richiede un disco rigido per l’ar­chi­via­zio­ne e l’inoltro delle in­for­ma­zio­ni

Grazie alle varie ot­ti­miz­za­zio­ni, il DHCP è diventato ra­pi­da­men­te il pro­to­col­lo standard per la gestione degli IP nelle reti, mentre il pro­to­col­lo BOOTP ha soltanto valore storico. Tuttavia, poiché DHCP supporta il pro­to­col­lo Bootstrap, i server DHCP possono in linea di principio anche ri­spon­de­re a qualsiasi richiesta fatta da un client BOOTP.

Vai al menu prin­ci­pa­le