Address Resolution Protocol

Consideriamo dunque brevemente la ridondanza che si viene a creare tra indirizzi data link ed IP: qui la trattiamo nel caso del protocollo Ethernet, ma presenta caratteristiche simili in altri protocolli data link.

In qualunque strato, di un messaggio si conosce l’indirizzo del mittente ed del destinatario in quello strato. In particolare, quando il modulo IP tratta un pacchetto IP `e noto l’indirizzo IP del destinatario finale del pacchetto.

In qualunque strato, per ottenere il recapito di un messaggio `e necessario invocare la funzione di spedizione predisposta dallo strato sottostante. Que-sta funzione deve essere a sua volta in grado di determinare l’indirizzo da uti-lizzare nel proprio strato. In particolare, `e necessario che il modulo Ethernet conosca anche l’indirizzo data link del destinatario o di un nodo intermedio nel percorso verso il nodo destinatario. Infatti la tecnologia Ethernet `e in grado di produrre una comunicazione tra due nodi collegati allo stesso cavo, cio`e alla stessa sottorete fisica.

Dunque al modulo Ethernet deve essere comunicato l’indirizzo data link, che sappiamo essere correlato all’indirizzo IP. Ma la corrispondenza non pu`o essere in alcun modo codificata in un algoritmo, cos`ı come non esiste modo di determinare che il CAP di Aosta `e 11100, se non consultando una tabella.

Bisogna dunque gestire una tabella che associ indirizzi IP ad indirizzi data link, nel caso in esame indirizzi Ethernet, come descritti nel paragrafo 3.1.1.

La tabella 4.1 ne `e un esempio.

Il modulo software che cura l’aggiornamento di questa tabella utilizza il protocollo ARP, ed assume la stessa denominazione. Il modulo ARP pu`o es-sere realizzato come parte del driver Ethernet stesso o come modulo separato collegato al driver Ethernet ([15]).

Quando il driver Ethernet riceve un pacchetto da incapsulare e spedire, conosce l’indirizzo IP del destinatario: per poter costruire il frame da conse-gnare al dispositivo hardware deve conoscere l’indirizzo Ethernet del

destina-Tabella 4.1La tabella ARP di conversione IP → Ethernet

Indirizzo IP Indirizzo Ethernet 223.1.2.1 08:00:39:00:2F:C3 223.1.2.3 08:00:5A:21:A7:22 223.1.2.4 08:00:10:99:AC:54

tario (intermedio o finale). Quindi accede alla tabella ARP tramite il modulo ARP stesso, cercando la riga corrispondente all’indirizzo IP desiderato.

Ma chi costruisce la tabella ARP?

Salvo rare eccezioni, non pu`o essere l’amministratore della rete a gesti-re la tabella ARP: sagesti-rebbe un lavoro troppo impegnativo e richiedegesti-rebbe interventi troppo tempestivi, per far fronte a eventi di routine come lo spe-gnimento del nodo, o la sostituzione della scheda Ethernet. La tabella invece viene compilata automaticamente dal modulo ARP stesso.

L’inserimento di una nuova voce nella tabella viene innescata dalla ri-chiesta di un indirizzo Ethernet corrispondente ad un IP non presente in tabella. In questo caso il modulo ARP trasmette in rete un frame broadcast contenente, nella parte riservata ai dati, l’indirizzo IP da risolvere.

Il campo destinatario di un frame broadcast `e FF:FF:FF:FF:FF:FF, ed il campo mittente contiene l’indirizzo Ethernet del mittente. Il modulo ARP indicher`a nel tipo del frame che si tratta di un frame ARP. In tabella 4.2 viene rappresentato il contenuto del frame di richiesta spedito da ARP.

Tabella 4.2Frame di richiesta ARP

Tipo Richiesta ARP

Indirizzo IP Mittente 223.1.2.1

Indirizzo Ethernet Mittente 08:00:39:00:2F:C3 Indirizzo IP Destinatario 223.1.2.2

Indirizzo Ethernet Destinatario FF:FF:FF:FF:FF:FF

Una volta spedito il frame di richiesta ARP, il frame la cui spedizione richiedeva l’indirizzo Ethernet richiesto (il frame “in sospeso”) viene messo in coda. Ogni driver Ethernet, ricevendo il frame in broadcast, riconoscer`a il tipo del frame e lo consegner`a al proprio modulo ARP. Ma solo il modu-lo ARP che riconoscer`a l’indirizzo IP destinatario come quelmodu-lo del nodo su cui risiede risponder`a, con un frame che avr`a come mittente se stesso, ora

completo del proprio indirizzo Ethernet, e come destinatario il mittente del precedente messaggio (v. tabella 4.3).

Tabella 4.3Frame di risposta ARP

Tipo Risposta ARP

Indirizzo IP Mittente 223.1.2.2

Indirizzo Ethernet Mittente 08:00:28:00:38:A9 Indirizzo IP Destinatario 223.1.2.1

Indirizzo Ethernet Destinatario 08:00:39:00:2F:C3

Ora il frame verr`a ricevuto solo dal driver Ethernet interessato, e passato al modulo ARP residente, che completer`a la tabella con il nuovo indirizzo (v.

tabella 4.4).

Tabella 4.4La tabella ARP di conversione IP → Ethernet

Indirizzo IP Indirizzo Ethernet 223.1.2.1 08:00:39:00:2F:C3 223.1.2.2 08:00:28:00:38:A9 223.1.2.3 08:00:5A:21:A7:22 223.1.2.4 08:00:10:99:AC:54

Una possibile accortezza consiste nel memorizzare l’indirizzo Ethernet del mittente della richiesta anche nella tabella ARP del nodo che spedisce la risposta. Infatti, `e probabile che i due nodi debbano successivamente scam-biare pacchetti in entrambi i sensi, e quindi la predisposizione di entrambi gli indirizzi pu`o risparmiare una successiva richiesta.

Affidabilit`a delle tabelle di ARP

Ogni protocollo Internet deve essere in grado di sopportare un funzionamento imperfetto, in particolare il guasto di nodi. Nel caso di ARP, se nessuno dei nodi che riceve la richiesta riconosce il proprio IP (ci`o accade se il nodo in questione `e guasto, o semplicemente spento), il messaggio ARP di richiesta rimarr`a senza risposta.

Per fronteggiare questa evenienza, il mittente della richiesta predispone un timeout, in modo da rimuovere il pacchetto in sospeso dalla coda, se questo era stato accodato. Ma secondo una implementazione alternativa ugualmente

accettabile, il driver non accoda il pacchetto in sospeso, ma lo distrugge quando rileva che l’indirizzo ARP non `e presente in tabella. Dipender`a dal protocollo allo strato trasporto rilevare la perdita del pacchetto e riproporne la trasmissione. Prima di allora il protocollo ARP avr`a completato la tabella con l’indirizzo necessario (ma vedere anche [10], paragrafo 2.3.2.2).

Ci`o corrisponde alle specifiche di IP, in quanto a IP non `e richiesto di garantire il recapito dei dati che gli vengono consegnati dallo strato trasporto.

Ma le informazioni registrate nella tabella ARP possono essere invalidate da altri eventi, come lo spegnimento o la rimozione di un nodo.

Esistono alcune tecniche utili a fare fronte a questi eventi [10]:

• timeout – Scartare una voce nella tabella quando non viene utilizzata per un certo periodo, che si aggira intorno al minuto;

• polling – Interpellare periodicamente l’host, e rimuovere la sua voce in tabella se non risponde;

• rilevazione di errore – Se la successiva comunicazione con quell’host re-stituisce un errore, rimuovere la voce;

• rilevazione di errore – Come sopra ma tenendo conto di segnalazioni di errore dagli strati superiori.