Scarica Il Protocollo ICMP e più Tesi di laurea in PDF di Reti Di Calcolatori solo su Docsity!
1. IL PROTOCOLLO ICMP
1. INTRODUZIONE
Lo scopo di TCP/IP è la facilitazione delle comunicazioni di rete tra host. Il livello di rete si occupa del trasferimento di pacchetti a livello di rete(i datagrammi) da un host ad un altro. A questo livello lavora il protocollo IP, il quale fornisce una comunicazione logica fra host e offre un servizio best-effort:
- è senza connessione
- c’è la possibilità che i datagrammi vengono perduti o alterati durante il percorso
- si possono creare dei duplicati dei datagrammi
- …
Questo vuol dire che IP fa del suo meglio per consegnare pacchetti , ma non offre garanzie. La limitazione di IP è proprio il fatto che si tratta di un sistema di consegna best-effort, non è quindi sviluppato per essere affidabile. Saranno i protocolli di livello più alto che si appoggiano ad esso a doverne garantire l’affidabilità, se richiesta nella comunicazione(per esempio TCP). IP non ha quindi strumenti per garantire che i dati vengano consegnati, indipendentemente da qualsiasi problema incontrato nella rete. Sono diverse le cause per cui un pacchetto non arrivi a destinazione:
- Guasto hardware
- Configurazione sbagliata o informazioni di routing scorrette
- (^) Dispositivo intermedio(per esempio un router) che smette di funzionare
- Dispositivo di destinazione scollegato dalla rete.
Non avendo i meccanismi di controllo per l'affidabilità di TCP, le applicazioni che utilizzeranno IP saranno più veloci. Come già accennato, ci penseranno i protocolli a livello superiore a garantire la correttezza della comunicazione.
- INTERNET CONTROL MESSAGE PROTOCOL (ICMP)
ICMP è il componente dello stack di protocolli TCP/IP che soddisfa l’esigenza di un meccanismo per la consegna affidabile dei dati quando si usa IP. ICMP non corregge la scarsa affidabilità tipica di IP, ma si limita a mandare messaggi di errore al mittente dei dati se si verificano errori che ne impediscono la consegna. È quindi soltanto un protocollo di rapporto degli errori per IP: quando questi si verificano nella consegna di datagrammi, ICMP li riferisce al mittente, ma non corregge il problema della rete che ha incontrato. Esempio 1. Supponiamo che la postazione 1 della figura sottostante stia mandando un datagramma alla postazione 6. Supponiamo quindi che l’interfaccia corrispondente del router C vada down: ICMP
23
Il router C usa ICMP per mandare indietro un messaggio alla postazione 1 e segnalare che il datagramma non può essere consegnato. Tuttavia ICMP non tenta di risolvere il problema all’interfaccia del router C, deve solo limitarsi a riferire gli errori alla postazione 1. Inoltre il router C non notifica l’errore di consegna ai dispositivi intermedi, quindi non spedisce messaggi ICMP ai router A e B. Il router non sa nemmeno che percorso ha compiuto il datagramma per arrivare, perché i datagrammi contengono solo gli indirizzi IP di sorgente e destinazione. Il dispositivo che prepara il rapporto conosce solo l’indirizzo IP del mittente. Occorre precisare che, anche se i router A e B non ricevono una notifica diretta, possono venire a conoscenza dello stato down dell’interfaccia sul router C, ma bisogna sottolineare che tra i compiti dell’ICMP non c’è la propagazione d’informazioni sui cambiamenti della rete.
3. FORMATO DEL MESSAGGIO ICMP
ICMP
23
Formato datagramma IP
- (^) Il campo versione specifica la versione del protocollo IP nel datagramma ed è impostato a 4
- H.Len rappresenta la lunghezza dell’intestazione in parole di 32 bit, indica dove effettivamente iniziano i dati del datagramma
- Il tipo di servizio(TOS) serve per distinguere i vari tipi di datagramma ed è impostato a 0
- Total length rappresenta la lunghezza totale del datagramma(intestazione + dati) misurata in byte
- Identification, flags, fragment offset sono usati per la frammentazione
- Il TTL serve per assicurare che i datagrammi non restino in circolazione per sempre. Dato che viene decrementato da ogni macchina che elabora il datagramma, il valore di questo campo dovrebbe essere grande almeno come il numero di gateway che il datagramma stesso attraverserà
- Il campo Type indica lo specifico protocollo di livello superiore ed è impostato a 1(ICMP=1)
- Il campo Header Checksum consente ai router di rilevare gli errori sui bit nei datagrammi ricevuti ed è calcolato trattando ogni coppia di byte dell’intestazione come numeri che sono poi sommati in complemento a 1
- Il campo Source Address sarà impostato con l’indirizzo del router o dell’host che compone il messaggio ICMP
- (^) Il campo Destination Address sarà impostato con l’indirizzo del router o dell’host a cui il messaggio dovrebbe essere inviato
- Il campo options consente di estendere le intestazioni IP
- Il campo Data rappresenta l’effettivo carico utile del datagramma(il messaggio ICMP) I dati vengono quindi incapsulati all’interno di un datagramma nel momento in cui raggiungono il livello Network, e da qui il datagramma viene ulteriormente incapsulato in un frame di livello Data Link. Visto che le informazioni d’intestazione e i dati ICMP sono incapsulati nel datagramma, inviati e trasmessi come qualsiasi altro dato, saranno soggetti alle stesse ICMP
23
possibilità di errori nella consegna. Verrebbe da dire che i rapporti d’errore possono creare altri rapporti d’errore, ma non è così! Uno scenario del genere sarebbe sicuramente dannoso per la rete, in quanto farebbe crescere ulteriormente la congestione. Per questo motivo, gli errori creati dai messaggi ICMP non generano a loro volta messaggi ICMP, e si potranno di conseguenza verificare errori nella consegna dei datagrammi non riportati al mittente. Come per qualsiasi tipo di pacchetto, i messaggi ICMP hanno un proprio formato. Ogni tipo di messaggio ha caratteristiche differenti, ma tutti i formati di messaggio ICMP iniziano con i tre campi seguenti:
- Tipo: indica il tipo di messaggio ICMP spedito
- Codice: fornisce ulteriori informazioni specifiche del tipo di messaggio
- Checksum: verifica l’integrità dei dati
0 8 16 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Content dependent on Type and Code | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1.4 TIPI DI MESSAGGI ICMP
Elenchiamo adesso tutti i tipo di messaggi ICMP, con relativo significato:
TYPE CODE MEANING 0 0 Echo Reply 3 0 Net Unreachable 1 Host Unreachable 2 Protocol Unreachable 3 Port Unreachable
ICMP
23
30 0 Traceroute (tracert) 31 Datagram conversion error 32 Mobile host redirect 33 IPv6 Where are you 34 IPv6 I am here 35 Mobile registration request 36 Mobile registration reply 39 SKIP 40 0 Photuris reserved 1 Photuris unknown security parameters index 2 Photuris valid security parameters, but auth. Failed 3 Photuris valid security parameters, but decrypt. failed
Possiamo dividere i messaggi ICMP in:
- Messaggi di errore: sono il risultato di pacchetti persi o condizioni di errore che si verificano durante la trasmissione del pacchetto.
- Messaggi di controllo: servono semplicemente a informare gli host di situazioni come la congestione di rete o l’esistenza di un gateway migliore verso una rete remota.
Adesso andremo ad esaminare dettagliatamente alcuni di questi messaggi ICMP(sia di errore che di controllo), analizzando come questi possono essere utilizzati per: individuare route troppo lunghe, fornire controllo per pacchetti persi o altre condizioni di errore, richieste di maschera dell’indirizzo, segnalare la presenza di congestione della rete ecc.
- Messaggio time exceeded 0 8 16 31
Type(11) Code(0) Checksum Unused(must be 0) Internet header + 64 bits of original data datagram(used by the host to match the message to the appropriate process)
Cerchiamo prima di capire l’utilità di questo tipo di messaggio discutendo il problema delle route troppo lunghe. Nella comunicazione in una rete locale, si possono verificare molte situazioni critiche. Un esempio può essere quello di un datagramma che viaggia in un loop o anello, senza mai raggiungere la sua destinazione. Una situazione del genere può accadere quando sono coinvolti molti router: ognuno di essi invia il datagramma ad un router successivo credendo che esso lo inoltri alla giusta destinazione; questo, a
ICMP
23
sua volta, lo inoltra al successivo dell’anello con la stessa convinzione, fino a quando il pacchetto ritorna al router da cui è partito, chiudendo l’anello. Una possibile causa di questo problema sono informazioni di routing sbagliate. I protocolli di routing hanno comunque dei limiti sulla distanza che un pacchetto può percorrere(ad esempio il protocollo RIP impone un massimo di 15 salti, ovvero impone che un pacchetto non attraversi più di 15 router) e questo limite è stabilito nel campo TTL del pacchetto stesso. L’esempio sopra è un tipico caso in cui esiste una route troppo lunga: il pacchetto prima o poi raggiungerà la fine della sua vita, cioè scadrà il suo Time To Live(TTL), e non potrà essere consegnato correttamente alla destinazione. Ogni volta che un router riceve un pacchetto, il campo TTL è decrementato di un’unità e se il router che sta processando il datagramma trova il TTL a 0, allora lo scarterà. ICMP utilizzerà il messaggio time exceeded per avvisare il dispositivo sorgente che è stato superato il TTL.
Inoltre questo tipo di messaggio ICMP può essere utilizzato anche quando, durante il processo di frammentazione del datagramma, un frammento viene perduto(per questo messaggio il campo code è impostato a 1). In particolare avviene che, quando un host destinatario deve riassemblare un datagramma frammentato e non può completare il processo di riassemblaggio a causa di frammenti mancanti, scarterà l’intero datagramma. Il destinatario butterà quindi via tutti i frammenti fino a quel momento bufferizzati dopo un certo intervallo di tempo e invierà un messaggio di time exceeded al mittente.
1.4.2 Messaggio di destinazione irraggiungibile 0 8 16 31
Type(3) Code(0-5) Checksum Unused(must be 0) Internet header + 64 bits of original data datagram(used by the host to match the message to the appropriate process)
La comunicazione nella rete dipende da alcune condizioni di base:
- Lo stack di protocolli TCP/IP deve essere correttamente configurata nei dispositivi trasmettente e ricevente: devono essere configurati correttamente l’indirizzo IP, la maschera, eventualmente il default gateway.
- Devono esistere i dispositivi intermedi (i router) per inoltrare i datagrammi dal dispositivo sorgente verso la rete di destinazione.
- Il router deve avere il protocollo TCP/IP correttamente configurato sulle sue interfacce e deve usare un protocollo di routing appropriato.
ICMP
23
In questo esempio, viene mostrato un router che riceve un pacchetto da un certo host, ma che non può consegnare alla sua destinazione finale. Il pacchetto potrebbe non essere consegnabile perché non c’è un percorso noto verso la destinazione. Il router B invia pertanto alla sorgente un messaggio ICMP host unreachable.
1.4.3 Messaggio di errore parametro 0 8 16 31
Type(12) Code(0-2) Checksum Pointer Unused(must be 0) Internet header + 64 bits of original data datagram(used by the host to match the message to the appropriate process)
Un router potrebbe essere impossibilitato nel consegnare un datagramma a causa di un errore di un parametro dell’intestazione, che non è in relazione con lo stato dell’host o della rete di destinazione, ma comunque ne impedisce la consegna. A causa dell’errore il datagramma viene scartato, e viene inviato alla sorgente del datagramma un messaggio di errore parametro ICMP. Il campo Pointer identifica l’ottetto dell’intestazione del datagramma originale dove l’errore è stato rilevato. Ad esempio:
- 1 indica che c’è qualcosa di sbagliato con il TOS
- 20 indica che c’è qualcosa di sbagliato con il tipo della prima opzione(se le opzioni sono presenti).
ICMP
23
- Messaggi di Echo Request o Echo Reply 0 8 16 31
Type(0 or 8) Code(0) Checksum
Identifier Sequence Number Data
Il protocollo ICMP può essere usato per controllare la raggiungibilità di una specifica rete di destinazione: un host mittente può inviare un messaggio echo request verso un host di destinazione che, quando riceve la richiesta, crea un messaggio echo reply da inviare alla sorgente del messaggio di richiesta. Se il mittente riceve il messaggio di risposta echo, può essere sicuro che il dispositivo di destinazione è raggiungibile. Il messaggio di echo request viene normalmente generato usando il comando ping , che verrà descritto più avanti nel capitolo. I campi Identifier e Sequence Number di questo messaggio servono se il campo Code è 0, in tal caso facilitano l’abbinamento tra richieste e risposte echo.
Esempio 1.4. In questo esempio, viene mostrato l’utilizzo di ICMP per inviare un messaggio di richiesta echo:
ICMP
23
Esempio 1.4. In questo esempio viene configurato come gateway predefinito per un certo host A, l’indirizzo IP dell’interfaccia fast ehternet0/0 di un certo router A:
A questo punto l’host A potrà utilizzare l’indirizzo IP del gateway di default per raggiunger e qualsiasi rete non direttamente connessa. Normalmente l’host A si collega ad un solo gateway ma, in alcune situazioni, un host è collegato a un segmento che ha due o più router direttamente connessi. In questo caso il gateway predefinito dell’host può aver bisogno di usare il messaggio di richiesta redirect/change per informare l’host sul percorso migliore verso una rete. In particolare, l’ICMP redirect mandato dal router A all’host A, avrà un gateway internet address 192.168.12.1, che è l’indirizzo IP dell’interfaccia del router A.
1.4.6 Messaggi di Timestamp 0 8 16 31
Type(13 or 14) Code(0) Checksum
ICMP
23
Identifier Sequence Number Originate Timestamp Receive Timestamp Transmit Timestamp
Dato che ogni singola rete fornisce la sincronizzazione del clock a modo proprio, si possono creare problemi quando gli host di reti differenti tentano di comunicare usando software che richiede la sincronizzazione dei tempi. Il messaggio ICMP timestamp serve a ridurre questo problema.
Un host usa questo messaggio per richiedere il tempo attuale a un host remoto, che usa a sua volta il messaggio di risposta timestamp per soddisfare la richiesta. Analizziamo il significato dei campi di questo messaggio e come vengono utilizzati per risolvere il problema della sincronizzazione del clock:
- Il timestamp d’origine contiene l’ora dell’host richiedente all’istante che precede l’emissione della richiesta.
- Il timestamp ricezione contiene l’ora in cui l’host ricevente all’istante in cui ha ricevuto la richiesta timestamp ICMP.
- Il timestamp trasmissione è riempito appena prima di spedire la risposta timestamp ICMP e contiene e contiene l’ora dell’host ricevente all’istante in cui la risposta è stata inviata.
Tutti i messaggi di risposta timestamp contengono i timestamp origine, ricezione e trasmissione, e l’host che riceve il messaggio può sfruttarli per:
- Stimare il tempo di trasmissione attraverso la rete sottraendo il tempo di origine da quello di trasmissione.
- (^) Calcolare il tempo di trasmissione della direzione di rientro sottraendo il tempo di trasmissione da quello attuale.
- Stimare il tempo di transito sottraendo il tempo di origine da quello di trasmissione. C’è da osservare che questa stima può essere imprecisa, in quanto il tempo di transito reale può cambiare notevolmente in relazione al traffico della congestione della rete.
- Valutare l’ora locale per il computer remoto.
I messaggi ICMP timestamp offrono un modo semplice per stimare l’ora di un host remoto e il tempo totale di transito, ma non è il modo migliore per ottenere questa informazione. I protocolli come Network Time Protocol(NTP) ai livelli superiori dello stack TCP/IP eseguono la sincronizzazione del clock in modo più affidabile.
•.7. Messaggi di richiesta informazione e di risposta 0 8 16 31
Type(15 or 16) Code(0) Checksum Identifier Sequence Number
ICMP
23
- Richiesta broadcast: se l’indirizzo del router locale non è noto
Il valore del campo tipo nel caso di richiesta messaggio è 17, mentre nel caso di risposta è 18. L’identificatore e il numero di sequenza servono sempre per facilitare l’abbinamento fra richieste e risposte. Quando il router riceve la richiesta emette un messaggio di risposta maschera d’indirizzo, che contiene la maschera di sottorete opportuna: esso contiene una maschera a 32 bit che identifica rete e sottorete corrette per la sottorete da cui è stata ricevuta la richiesta. È interessante osservare il caso in cui un host non conosca il proprio indirizzo IP: in tal caso il messaggio di richiesta viene inviato lasciando l’indirizzo sorgente a 0.0.0.0, ad indicare “questo host”, e la risposta sarà inviata con l’IP di destinazione broadcast 255.255.255.255. In questo caso non c’è necessità di abbinare richieste con risposte, dato che esiste una sola possibile maschera per una data sottorete. Questa soluzione deve comunque essere il più possibile evitata, perché aumenta il numero di broadcast superflui nella rete. Vediamo un semplice esempio di messaggio di richiesta e messaggio di risposta per capire l’utilizzo di questo messaggio ICMP.
Esempio 1.4. Supponiamo di avere un host collocato in una rete di classe B, con indirizzo IP 172.16.5.3, che non conosce la maschera di sottorete e quindi emette con broadcast una richiesta di maschera d’indirizzo:
Source address 172.16.5. Destinarion address 255.255.255. Protocol ICMP= Type Address Mask Reqeust = AM Code 0 Mask 0
Questo broadcast sarà ricevuto dal router locale, supponiamo abbia indirizzo IP 168.5.5.1, il quale risponderà con la risposta di maschera dell’indirizzo: Source address 172.16.5. Destinarion address 172.16.5. Protocol ICMP= Type Address Mask Reply = AM Code 0 ICMP
23
Mask 255.255.255.
1.4.9 Messaggi di ricerca dei router (router discovery) 0 8 16 31
Type(9) Code(0) Checksum Number of addresses Size of the address field
Time To Live
Router 1 address Preference level 1 Router 2 address Preference level 2
Un’host, se non è stato configurato manualmente con un gateway di default, può venire a conoscenza dei router disponibili con il procedimento di ricerca di router discovery. Prima di inviare questo tipo di messaggio, viene inviato un messaggio multicast di sollecito dei router usando l’indirizzo 224.0.0.2. C’è da notare che non tutti i router supporteranno questo procedimento di ricerca, in tal caso i messaggi di sollecito inviati a questi router non otterranno risposta. Se invece un router supporta il procedimento di ricerca e riceve un messaggio di sollecito del router(router solicitation), emette in risposta un annuncio di presenza di router(router advertisement):
- Il campo Number of addresser indica il numero degli indirizzi di router annunciati dal messaggio
- Il campo Size of the address field indica il numero di parole a 32 bit d’informazione per ciascun indirizzo di router
ICMP
23
Nella maggior parte dei casi la congestione si risolve in breve tempo, e la sorgente inizia lentamente ad aumentare la cadenza di trasmissione fino a quando non sono più ricevuti altri messaggi source quench. Sono diversi gli algoritmi che il mittente utilizza per regolare la frequenza d’invio(per esempio AIMD o slow start – congestion avoidance); non venendo discussi in questo capitolo, si rimanda il lettore alla bibliografia [2] per vedere il testo in cui vengono studiati dettagliatamente.
Bisogna però notare che, per default, la maggior parte dei router Cisco non manda messaggi source quench perché essi contribuiscono a peggiorare la congestione di rete. Questo tipo di messaggi può essere usato produttivamente in un piccolo ufficio o rete domestica (Small Office, Home Office, SOHO).
4. ESEMPI DI UTILIZZO DEL PROTOCOLLO ICMP
Analizzeremo adesso dei casi importanti in cui viene utilizzato il protocollo ICMP, in particolar modo vedremo com’esso viene usato nei comandi Ping e Traceroute e come può essere utile quando la frammentazione dei datagrammi IP viene disattivata.
1.5.1 Il comando Ping Il comando Ping viene tipicamente usato per verificare l’esistenza di un percorso tra due host, in particolare all’esecuzione del comando avviene che:
- Un host trasmette una echo request ICMP verso un host destinatario e attende la sua risposta
- Se la risposta non arriva entro un tempo prefissato, viene visualizzata la scritta “ risposta scaduta”
- L’host destinatario risponde con un messaggio di echo reply ICMP
L’host mittente estrae così dalla risposta alcune informazioni utili sul percorso
ICMP
23
Nell’esempio è stato effettuato un Ping verso www.ing.unipi.it , e vengono mostrati il numero di pacchetti inviati, la percentuale di quelli persi e i valori statistici del round trip time (RTT). Nell’output possiamo leggere valore minimo, massimo e medio del RTT, i quali risulteranno più precisi solo se il numero di richieste inviate con il comando ping è sufficientemente alto. 1.5.2 Il comando Traceroute
A differenza del comando ping che verifica l’esistenza di un percorso tra due host, il comando traceroute consente di conoscere e mostrare il percorso tra due host. Serve quindi a far vedere qual è la sequenza di router che i datagrammi potrebbero seguire per andare da una certa sorgente ad una certa destinazione. Traceroute viene solitamente implementato attraverso la trasmissione di una serie di datagrammi IP con TTL crescente, dove ognuno di essi trasporta un segmento UDP con un numero di porta improbabile(il primo con TTL pari a 1, il secondo con TTL pari a 2 e così via). Traceroute trasmetterà quindi il primo datagramma con TTL=1, il primo router lo scarterà perché il TTL risulterà scaduto e invierà alla sorgente un messaggio di errore ICMP di tipo 11 (time exceeded), in modo che l’host mittente venga a conoscenza del primo router e di altre informazioni come il RTT. Successivamente traceroute trasmetterà un secondo datagramma con TTL=2, e il procedimento è lo stesso. Ogni router sul percorso scarta un datagramma fino a quando il suo TTL non diventa abbastanza grande per farlo inoltrare verso la destinazione. È interessante notare che alcuni sistemi usano pacchetti ICMP di echo request invece di segmenti UDP per implementare traceroute, ma entrambi i pacchetti(UDP e ICMP) sono incapsulati all’interno di un datagramma IP e quindi hanno un campo TTL che può essere utilizzato come abbiamo appena visto. Come si fa a scoprire la fine del percorso? Abbiamo detto che i datagrammi inviati trasportano messaggi UDP destinati ad un’applicazione inesistente presso il destinatario finale, pertanto uno di questi datagrammi alla fine completerà il percorso verso la destinazione. L’host di destinazione, dato che il datagramma contiene un segmento IP con numero di porta improbabile, invia al mittente un messaggio ICMP di tipo 3 e codice 3 (port unreachable) , in modo tale che quest’ultimo capisca che è stato raggiunto il destinatario finale e che non deve inviare ulteriori pacchetti. ICMP
23
