RARP: Reverse Adress Re­so­lu­tion Protocol

Cosa succede quando un computer non conosce il proprio indirizzo IP perché, ad esempio, non ha capacità di memoria? In un caso del genere, il Reverse Address Re­so­lu­tion Protocol (RARP) può aiutare in qualità di pro­to­col­lo per la ri­so­lu­zio­ne inversa dell’indirizzo. Quindi il RARP è la con­tro­par­te dell’ARP, il pro­to­col­lo di ri­so­lu­zio­ne degli indirizzi.

At­tual­men­te il Reverse ARP è stato superato e pro­to­col­li più recenti, come Bootstrap (BOOTP) o il Dynamic Host Con­fi­gu­ra­tion-Protocol (DHCP) l’hanno so­sti­tui­to. Tuttavia, è opportuno conoscere anche la tec­no­lo­gia pre­ce­den­te. Se è vero che oggi non ci sono più ap­pli­ca­zio­ni che fun­zio­na­no con RARP, resta comunque utile conoscere le tecniche del passato per com­pren­de­re meglio le tec­no­lo­gie che si basano su di esse.

Per prima cosa RARP è un pro­to­col­lo ri­la­scia­to nel 1984 e inglobato nello stack del pro­to­col­lo TCP/IP. RARP si trova nel livello di rete (il livello più basso ed ele­men­ta­re dell’ar­chi­tet­tu­ra) e rap­pre­sen­ta, quindi, una tec­no­lo­gia di tra­smis­sio­ne tra due punti in una rete. Ogni par­te­ci­pan­te di una rete dispone di due indirizzi più o meno univoci: uno logico, l’indirizzo IP, e uno fisico, l’indirizzo MAC. Mentre l’indirizzo IP è legato al software, l’indirizzo MAC è collegato all’hardware. Il pro­dut­to­re fornitore della vostra scheda di rete vi avrà si­cu­ra­men­te già fornito l’indirizzo Media Access Control.

Può accadere, però, che l’indirizzo IP non sia noto, ad esempio quando il di­spo­si­ti­vo cor­ri­spon­den­te non possiede una propria memoria in grado di salvare l’indirizzo. In questo caso in­ter­vie­ne il pro­to­col­lo Reverse ARP. Uti­liz­zan­do l’indirizzo MAC a di­spo­si­zio­ne, il pro­to­col­lo può de­ter­mi­na­re il relativo indirizzo IP. In questo modo si realizza un obiettivo com­ple­ta­men­te diverso rispetto a quello dell’ARP. Con quest’ultimo, l’indirizzo IP è noto e tramite ARP si determina l’indirizzo dell’hardware.

Nei singoli campi si trovano le seguenti in­for­ma­zio­ni:

• Hardware Address Space: in questi 2 byte viene spe­ci­fi­ca­to il tipo di indirizzo hardware.
• Protocol Address Space: questo campo di 2 byte indica il tipo di pro­to­col­lo di rete.
• Hardware Address Length: questi 8 bit de­fi­ni­sco­no la lunghezza n dell’indirizzo hardware.
• Protocol Address Length: questo campo determina la lunghezza m dell’indirizzo di rete.
• Opcode: il campo di 2 byte indica di che tipo di ope­ra­zio­ne si tratta. Una richiesta RARP ha il valore 3 e la risposta cor­ri­spon­den­te ha il valore 4.
• Source Hardware Address: qui viene me­mo­riz­za­to l’indirizzo MAC del mittente. La lunghezza effettiva di questo campo è n e viene spe­ci­fi­ca­ta dall’in­for­ma­zio­ne data nell’Hardware Adress Length. In una rete Ethernet classica è di 6 byte.
• Source Protocol Adress: in questo campo in teoria dovrebbe essere indicato l’indirizzo IP del mittente, ma se questo non è noto al momento della richiesta, il campo non viene definito. La risposta, invece, contiene l’indirizzo IP del server. La lunghezza di questo campo è m e dipende dalla lunghezza dell’indirizzo del pro­to­col­lo. In genere il campo ha la lunghezza di un indirizzo IPv4, ovvero 4 byte.
• Target Hardware Address: questo campo contiene l’indirizzo MAC di de­sti­na­zio­ne. Poiché nella richiesta RARP non esiste una de­sti­na­zio­ne specifica, qui viene vi­sua­liz­za­to anche l’indirizzo del mittente. Nella risposta il server inserisce anche l’indirizzo del client ri­chie­den­te. Questo campo ha la lunghezza n e nel caso di una rete Ethernet ha una di­men­sio­ne di 6 byte.
• Target Protocol Adress: l’ultimo campo non viene definito durante una richiesta per contenere poi, alla risposta del server, l’in­for­ma­zio­ne ricercata: l’indirizzo IP dell’utente di rete. Questo campo ha la lunghezza m, di solito 4 bytes.

Tra i pro­to­col­li ARP e RARP esistono, tuttavia, dif­fe­ren­ze im­por­tan­ti: in prima linea questi si dif­fe­ren­zia­no per quanto riguarda le in­for­ma­zio­ni. Mentre una richiesta RARP conosce il proprio indirizzo MAC, ma chiede l’indirizzo IP cor­ri­spon­den­te, nella richiesta ARP avviene esat­ta­men­te il contrario: l’indirizzo IP è noto ed è l’indirizzo MAC a essere richiesto. I due pro­to­col­li dif­fe­ri­sco­no anche per quanto riguarda i contenuti dei loro campi operativi: ARP riconosce i valori 1 (per la richiesta) e 2 (per la risposta). RARP, invece, utilizza i valori 3 e 4. In questo modo il server è in grado di ri­co­no­sce­re già dal codice dell’ope­ra­zio­ne se si tratta di ARP o RARP.

Il Reverse Address Re­so­lu­tion Protocol presenta alcuni svantaggi che alla fine hanno portato alla sua so­sti­tu­zio­ne con un pro­to­col­lo più moderno. Per uti­liz­za­re il pro­to­col­lo in modo efficace, il server RARP, ad esempio, deve essere collocato nella stessa rete fisica. Il computer invia la richiesta RARP al livello più basso della rete. Per un router, quindi, non è possibile inoltrare il pacchetto. Inoltre, il pro­to­col­lo RARP non è in grado di gestire le sottoreti, poiché non vengono sup­por­ta­te le maschere di sottorete. Se la rete viene suddivisa in più sottoreti, per ognuna di esse deve essere pre­di­spo­sto un server RARP.

Con tale richiesta, l’utente della rete viene così a co­no­scen­za del proprio indirizzo IP. Come già spiegato, con Reverse ARP non si possono tra­smet­te­re maschere di sottorete, né in­for­ma­zio­ni sul gateway. Non è possibile, dunque, con­fi­gu­ra­re il computer in una rete moderna. Queste mancanze hanno portato allo sviluppo di BOOTP e DHCP.