I protocolli classici: RARP e BOOTP

In genere, al momento del collegamento con una rete TCP/IP, un computer deve conoscere tutta una serie di informazioni, di cui la pi∙ importante Φ sicuramente l'indirizzo IP, altrimenti non sarα in grado di interagire correttamente con gli altri sistemi. In realtα non tutti i sistemi che sono collegati in rete possiedono queste informazioni fin dall'inizio. Ad esempio, esistono periferiche che non possiedono una propria memoria di massa su cui memorizzare i dati, come i network computer oppure i terminali cosiddetti "stupidi". In molti ambienti sono poi comuni computer a cui Φ stato rimosso il disco fisso per ragioni di sicurezza, e che dipendono da altre macchine per la memorizzazione di dati ed informazioni. Questi sistemi sono detti diskless. Spesso questi computer non hanno neanche un vero e proprio sistema operativo ma lo devono caricare direttamente dalla rete al momento dell'accensione.

Ma come fa una macchina che non ha un sistema operativo ed una memoria di massa a collegarsi ad una rete internet? In genere queste macchine possiedono un piccolo programma di attivazione memorizzato su una ROM programmabile. Questo programma Φ in grado di ottenere dalla rete stessa le informazioni che servono al collegamento e quindi, una volta stabilita la connessione, Φ capace di scaricare da un server un pezzo di sistema operativo o comunque un'applicazione client in grado di farlo operare in rete.

Il protocollo RARP (Reverse Address Resolution Protocol) si basa su due considerazioni. La prima Φ che in effetti un computer sa come comunicare in rete, sa cioΦ come spedire e ricevere bit utilizzando i protocolli della rete fisica a cui Φ collegato, e sa come identificarsi in modo univoco, dato che possiede comunque un indirizzo fisico di rete, generalmente corrispondente all'identificativo della scheda di comunicazione utilizzata. La seconda Φ che anche se un sistema non conosce l'indirizzo di rete di un altro sistema con cui desidera comunicare, pu≥ sempre mandare un messaggio a tutti i sistemi collegati localmente utilizzando la tecnica del broadcasting.

Vediamo allora come avviene il collegamento via RARP. Non appena il computer viene accesso, il programma memorizzato nella PROM viene mandato in esecuzione. La prima cosa che fa Φ quella di ricavare dalla scheda di rete l'indirizzo fisico del sistema. Questo identificativo Φ memorizzato nella memoria della scheda di rete, ed Φ quindi sempre disponibile. Esso inoltre non dipende dal tipo o dal modello di computer utilizzato, ma solo dalla scheda, e quindi Φ sicuramente univoco. Questi identificativi infatti, sono costruiti un po' come i numeri di telefono o gli indirizzi IP. Ogni marca registra un proprio insieme di identificativi, all'interno del quale si assicura che, indipendentemente dal modello della scheda, tutte le schede abbiano un indirizzo differente. A questo punto il programma spedisce a tutte le macchine giα collegate in rete un messaggio in cui fornisce il proprio indirizzo fisico e chiede che gli venga mandato indietro quello IP. PerchΘ ci≥ avvenga Φ necessario che nella rete fisica esista almeno un server RARP in grado di soddisfare la richiesta.

Esistono due differenti schemi che permettono ad un server di ricavare l'indirizzo IP a fronte di quello fisico. O il server possiede una tabella di conversione che fornisce gli indirizzi IP di un certo numero di macchine a partire da quelli fisici, oppure esiste una formula di conversione che genera l'indirizzo richiesto direttamente da quello fornito.

In realtα nella rete pu≥ esserci anche pi∙ di un server RARP, anche perchΘ se l'unico server dovesse cadere, nessun computer potrebbe pi∙ ottenere il proprio indirizzo IP all'accensione. Per evitare che il client venga bombardato dalle risposte di tutti i server RARP presenti in rete, per ogni client viene definito un server primario. Tutti gli altri server saranno quindi secondari. Quando parte la richiesta, solo il server primario risponde subito, gli altri la ignorano. Pu≥ tuttavia succedere che il messaggio si perda od arrivi danneggiato, oppure che il primario non funzioni o che sia sovraccarico. In tal caso il client rimanda la sua richiesta dopo un certo periodo di tempo. A quel punto, come arriva la seconda richiesta, ogni secondario in grado di risolvere l'indirizzo fisico fornito spedirα indietro l'indirizzo IP corrispondente. In ogni caso il client utilizzerα la prima risposta che arriva, anche se non ignorerα le altre, ma le utilizzerα come controprova per maggior sicurezza.

A questo punto, ricevuto l'indirizzo IP, il programma di accensione potrα comunicare in rete e ricevere dallo stesso o da un altro server tutte le informazioni che necessita, incluso l'indirizzo da cui scaricarsi il sistema operativo o l'applicativo client che gli permetterα di operare correttamente. Questo tuttavia avverrα tramite altri protocolli, come il TFTP.

In realtα il protocollo RARP non serve solo ad ottenere il proprio indirizzo IP, ma permette a qualunque sistema di chiedere ad un server RARP l'indirizzo IP che corrisponde ad un certo indirizzo fisico. In tal caso, il primo sistema sarα detto "richiedente" (sender), il secondo "bersaglio" (target). La struttura del messaggio RARP sarα allora la seguente:

Il protocollo appena visto ha alcuni svantaggi. Innanzi tutto il programma di accensione deve essere in grado di operare a livello di rete fisica. Questo vuol dire che la stessa macchina non pu≥ essere collegata a reti fisiche differenti. Ad esempio, se la PROM Φ stata programmata per operare su una rete Ethernet, essa non potrα essere utilizzata su una Token Ring, e viceversa. In secondo luogo, RARP permette di ottenere solo l'indirizzo IP corrispondente all'indirizzo fisico fornito. Per operare in rete Φ spesso necessario avere molte altre informazioni, come ad esempio l'indirizzo IP del router oppure la maschera della sottorete.

Per ovviare a ci≥ Φ stato sviluppato un altro protocollo che, sorprendentemente, si poggia sull'UDP – di cui abbiamo giα parlato – e che quindi Φ indipendente dalla rete fisica. Dico sorprendentemente perchΘ l'UDP, per operare, utilizza gli indirizzi IP, proprio come il suo fratello maggiore TCP. Questo protocollo si chiama BOOTP (Bootstrap Protocol), e risolve molti dei problemi caratteristici del RARP. Non solo: un server BOOTP pu≥ persino trovarsi su una rete fisica differente da quella del richiedente o del bersaglio. Il protocollo BOOTP utilizza due porte riservate UDP, e cioΦ la 68 per il client e la 67 per il server. Ma come fa una macchina che non conosce il proprio indirizzo IP ad utilizzare un protocollo basato proprio sull'IP?

Il meccanismo utilizzato dal BOOTP segue quindi pi∙ o meno la stessa traccia giα vista per il RARP, con la differenza che l'indirizzo fisico non Φ coinvolto direttamente e quindi il collegamento pu≥ avvenire senza bisogno che il programma di accensione sappia operare a livello di rete fisica. Anche nel caso del BOOTP esiste un'architettura basata su server primari e secondari e sulla ritrasmissione della richiesta in caso di perdita dei dati o caduta del primario. Per evitare che un server BOOTP sia bombardato da un numero ingestibile di richieste in caso di caduta e ripristino di tutta la rete locale, ogni client utilizzerα un ritardo casuale da 0 a 4 secondi massimo prima di ritrasmettere la propria richiesta. Questo intervallo di tempo sarα raddoppiato nel caso di una successiva ritrasmissione qualora anche quella precedente non abbia dato risposta, e cos∞ via.

Il protocollo BOOTP Φ molto pi∙ evoluto di quello RARP, e permette di fornire al richiedente un maggior numero di informazioni che non semplicemente l'indirizzo IP, come ad esempio l'indirizzo del gateway pi∙ vicino, l'indirizzo di un file server per la memorizzazione dei dati, la maschera della sottorete (subnet mask) ed altre informazioni opzionali riportate nel riquadro a parte.

La struttura del messaggio Φ la seguente:

Da qui in poi vengono i dati veri e propri. Se il client sta usando BOOTP per conoscere il proprio indirizzo IP, il primo campo di questo blocco sarα zero. Se invece la richiesta riguarda altre informazioni, il client memorizzerα qui il proprio indirizzo IP. Il campo successivo conterrα l'indirizzo IP risolto dal server. Ovviamente quali campi siano riempiti e quali siano nulli dipende dal tipo di messaggio. I due indirizzi IP successivi sono relativi al server BOOTP ed al gateway pi∙ vicino.

Da notare che il client pu≥ richiedere che a rispondere alla sua richiesta sia un ben preciso server, e non uno qualunque. Questo pu≥ essere fatto specificando nella richiesta l'indirizzo IP od il nome del server preferito. Quest'ultima informazione segue immediatamente l'indirizzo fisico del richiedente.

L'ultimo campo pu≥ contenere una lista di ulteriori informazioni che il client desidera ricevere dal server BOOTP, come riportato nel riquadro a lato.

Il protocollo BOOTP Φ molto importante, anche perchΘ su di esso si basa un altro protocollo, molto attuale ed utilizzato da chiunque si colleghi in rete via modem tramite un ISP, chiamato DHCP, e di cui parleremo nel prossimo numero.

Per saperne di pi∙ (RFCs)

Home Page:

http://www.cis.ohio-state.edu/hypertext/information/rfc.html

0913 Simple File Transfer Protocol. M. Lottor. Sep-01-1984.

2090 TFTP Multicast Option. A. Emberson. February 1997.

1533 DHCP Options and BOOTP Vendor Extensions. S. Alexander & R. Droms.