Network Working Group J. Postel Request for Comments: 792 ISI September 1981 Updates: RFCs 777, 760 Updates: IENs 109, 128 PROTOCOLLO DI CONTROLLO DEI MESSAGGI INTERNET (ICMP) PROGRAMMA DARPA INTERNET SPECIFICA DI PROTOCOLLO Traduzione a cura di ComiSAT Brescia, Lug. 2003 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Introduzione Il Protocollo Internet (IP) [1] viene utilizzato per un servizio di datagramma host-a-host in un sistema di reti interconnesse chiamato Catenet [2]. I dispositivi di connessione di rete sono denominati Gateways. Tali gateways comunicano tra loro con finalita’ di controllo tramite un Protocollo Gateway a Gateway (GGP) [3,4]. Occasionalmente un gateway o un host di destinazione comunichera’ con un host sorgente, per esempio per riportare un errore di elaborazione di un datagramma. Questo protocollo, l’Internet Control Message Protocol (ICMP), viene utilizzato per tali obiettivi. L’ICMP utilizza il supporto di base dell’IP come se fosse un protocollo di alto livello, tuttavia l’ICMP e’ attualmente parte integrante dell’IP e dev’essere implementato in ogni modulo IP. I messaggi ICMP sono inviati in svariate situazioni: per esempio quando un datagramma non puo’ raggiungere la sua destinazione, quando un gateway non ha capacita’ di buffering per inoltrare un datagramma, o quando il gateway puo’ dirigere l’host ad inviare il traffico su un route piu’ breve. L’Internet Protocol non e’ stato disegnato per essere assolutamente affidabile. Gli obiettivi di questi messaggi di controllo sono fornire feedback relativi a problemi in ambiente di comunicazione, e non rendere affidabile l’IP. Non vi sono inoltre garanzie affinche’ un datagramma venga consegnato o un messaggio di controllo ritornato. Alcuni datagrammi possono anche essere non consegnati senza alcun rapporto che indichi la loro perdita. I protocolli di livello piu’ alto che utilizzano l’IP devono implementare le proprie procedure di affidabilita’ qualora sia richiesta una comunicazione affidabile. I messaggi ICMP riportano generalmente errori di elaborazione dei datagrammi. Per evitare l’infinita regressione di messaggi relativi a messaggi ecc., non viene inviato alcun messaggio ICMP per i messaggi ICMP. Ancora, i messaggi ICMP sono inviati solamente per errori di gestione del frammento zero di datagrammi frammentati (il frammento zero ha l’offset di frammento uguale a zero). [Page 1] September 1981 RFC 792 Formati del Messaggio I messaggi ICMP sono inviati usando l’header (intestazione) IP di base. Il primo ottetto della porzione di dati del datagramma e’ un campo ICMP tipo; il valore di tale campo determina il formato dei dati rimanenti. Ogni campo etichettato come “inutilizzato” viene riservato per estensioni future e dev’essere pari a zero quando inviato, ma i riceventi non dovrebbero utilizzare tali campi (tranne che per includerli del checksum). A meno che’ diversamente specificato nelle descrizioni individuali dei formati, i valori del campo di intestazione sono i seguenti: Versione 4 IHL (Internet Header Length) La lunghezza dell’intestazione internet in words a 32 bit. Tipo di servizio 0 Lunghezza totale La lunghezza dell’intestazione internet e dei dati in ottetti. Identificazione, Flags, Offset del frammento Utilizzati nella frammentazione, vedasi [1]. Durata La durata in secondi; poiche’ tale campo viene decrementato in ciascuna macchina nella quale il datagramma viene processato, il valore in questo campo dovrebbe essere grande almeno quanti sono i gateways che il datagramma attraversera’. Protocollo ICMP = 1 Header Checksum (controllo d’intestazione) Il complemento a 16 bit della relativa somma dei complementi di tutte le words 16 bit nell’intestazione. Per il calcolo del checksum, il campo checksum dovrebbe essere zero. Tale checksum potrebbe essere sostituito in futuro. [Page 2] September 1981 RFC 792 Indirizzo sorgente L’indirizzo del gateway o dell’host che compone il messaggio ICMP. Se non diversamente specificato, questo puo’ essere l’indirizzo di un qualsiasi gateway. Indirizzo di destinazione L’indirizzo del gateway o dell’host al quale il messaggio deve essere inviato. [Page 3] September 1981 RFC 792 Messaggio di Destinazione Non Raggiungibile 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Codice | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | non utilizzato | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Intestazione Internet + 64bit dei Dati del Datagramma Originale| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campi IP: Indirizzo di Destinazione La rete sorgente e l’indirizzo dai dati del datagramma originale. Campi ICMP: Tipo 3 Codice 0 = rete non raggiungibile; 1 = host non raggiungibile; 2 = protocollo non raggiungibile; 3 = porta non raggiungibile; 4 = frammentazione necessaria e DF set; 5 = route sorgente fallito. Checksum Il complemento a 16 bit della relativa somma dei complementi del messaggio ICMP che inizia con il Tipo ICMP. Per il calcolo del checksum, il campo checksum dovrebbe essere zero. Tale checksum potrebbe essere sostituito in futuro. Intestazione Internet + 64bit dei Dati del Datagramma Originale L’intestazione internet piu’ i primi 64 bit dei dati del datagramma [Page 4] September 1981 RFC 792 originale. Tali dati sono utilizzati dall’host per abbinare il messaggio al processo corretto. Se un protocollo di livello elevato utilizza numeri di porta, si presume che essi si trovino nei primi 64 bit dei dati del datagramma originale. Descrizione Se, secondo le informazioni delle tavole di routing del gateway, la rete specificata nel campo di destinazione internet di un datagramma non e’ raggiungibile, ad esempio la distanza della rete e’ infinita, il gateway puo’ spedire un messaggio di destinazione non raggiungibile all’host sorgente del datagramma. In piu’, in alcune reti, il gateway potrebbe essere in grado di determinare se l’host internet di destinazione non e’ raggiungibile. I gateways in tali reti possono inviare messaggi di destinazione non raggiungibile all’host sorgente qualora l’host di destinazione non sia raggiungibile. Se, nell’host di destinazione, il modulo IP non puo’ consegnare il datagramma perche’ il modulo del protocollo indicato o la porta del processo non sono attivi, l’host di destinazione puo’ spedire un messaggio di destinazione non raggiungibile all’host sorgente. Un altro caso si ha quando un datagramma, per essere inoltrato da un gateway, dev’essere frammentato e il flag (attributo di impostazione) Non Frammentare e’ attivo. In questo caso il gateway deve liberarsi del datagramma e ritornare un messaggio di destinazione non raggiungibile. I codici 0, 1, 4 e 5 possono essere ricevuti da un gateway. I codici 2 e 3 possono essere ricevuti da un host. [Page 5] September 1981 RFC 792 Messaggio di Tempo Scaduto 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Codice | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | non utilizzato | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Intestazione Internet + 64bit dei Dati del Datagramma Originale| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campi IP: Indirizzo di Destinazione La rete sorgente e l’indirizzo dai dati del datagramma originale. Campi ICMP: Tipo 11 Codice 0 = durata ecceduta nel transito 1 = durata di riassemblaggio del frammento oltrepassata Checksum Il complemento a 16 bit della relativa somma dei complementi del messaggio ICMP che inizia con il Tipo ICMP. Per il calcolo del checksum, il campo checksum dovrebbe essere zero. Tale checksum potrebbe essere sostituito in futuro. Intestazione Internet + 64bit dei Dati del Datagramma Originale L’intestazione internet piu’ i primi 64 bit dei dati del datagramma originale. Tali dati sono utilizzati dall’host per abbinare il messaggio al processo corretto. Se un protocollo di livello elevato utilizza numeri di porta, si presume che essi si trovino nei primi 64 bit dei dati del datagramma originale. Descrizione Se il gateway che sta processando un datagramma riscontra che il campo [Page 6] September 1981 RFC 792 del tempo rimasto e’ zero deve abbandonare il datagramma. Il gateway puo’ anche notificarlo all’host sorgente mediante un messaggio di tempo scaduto. Se un host che sta riassemblando un datagramma frammentato non puo’ completare il riassemblaggio a causa di una perdita di frammenti entro il limite di tempo esso scarta il datagramma e puo’ inviare un messaggio di tempo scaduto. Se il frammento zero non e’ disponibile allora non dev’essere inviato alcun tempo scaduto. Il codice 0 puo’ essere ricevuto da un gateway. Il codice 1 puo’ essere ricevuto da un host. [Page 7] September 1981 RFC 792 Messaggio di Problema Di Parametro 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Codice | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Puntatore | non utilizzato | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Intestazione Internet + 64bit dei Dati del Datagramma Originale| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campi IP: Indirizzo di Destinazione La rete sorgente e l’indirizzo dai dati del datagramma originale. Campi ICMP: Tipo 12 Codice 0 = il puntatore indica l’errore. Checksum Il complemento a 16 bit della relativa somma dei complementi del messaggio ICMP che inizia con il Tipo ICMP. Per il calcolo del checksum, il campo checksum dovrebbe essere zero. Tale checksum potrebbe essere sostituito in futuro. Pointer Se il codice = 0 identifica l’ottetto ove e’ stato rilevato l’errore. Intestazione Internet + 64bit dei Dati del Datagramma Originale L’intestazione internet piu’ i primi 64 bit dei dati del datagramma originale. Tali dati sono utilizzati dall’host per abbinare il messaggio al processo corretto. Se un protocollo di livello elevato utilizza numeri di porta, si presume che essi si trovino nei primi 64 bit dei dati del datagramma originale. [Page 8] September 1981 RFC 792 Descrizione Se il gateway o l’host che processa il datagramma riscontra un problema con i parametri d’intestazione tale che non possa essere completata l’elaborazione del datagramma esso dev’essere scartato. Una fonte potenziale di tale problema si ha con argomenti non corretti in una opzione. Il gateway o l’host puo’ anche notificare l’host sorgente tramite il messaggio di problema coi parametri. Tale messaggio viene spedito solo se l’errore ha fatto si’ che il datagramma sia stato scartato. Il puntatore identifica l’ottetto dell’intestazione del datagramma originale dove e’ stato rilevato l’errore (puo’ essere al centro di un’opzione). Ad esempio, 1 indica qualcosa che non va con il Tipo di Servizio, e (se sono presenti opzioni) 20 indica qualcosa che non va con il tipo di codice della prima opzione. Il codice 0 puo’ essere ricevuto da un gateway o da un host. [Page 9] September 1981 RFC 792 Messaggio Sorgente Estinta 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Codice | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | non utilizzato | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Intestazione Internet + 64bit dei Dati del Datagramma Originale| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campi IP: Indirizzo di Destinazione La rete sorgente e l’indirizzo dai dati del datagramma originale. Campi ICMP: Tipo 4 Codice 0 Checksum Il complemento a 16 bit della relativa somma dei complementi del messaggio ICMP che inizia con il Tipo ICMP. Per il calcolo del checksum, il campo checksum dovrebbe essere zero. Tale checksum potrebbe essere sostituito in futuro. Intestazione Internet + 64bit dei Dati del Datagramma Originale L’intestazione internet piu’ i primi 64 bit dei dati del datagramma originale. Tali dati sono utilizzati dall’host per abbinare il messaggio al processo corretto. Se un protocollo di livello elevato utilizza numeri di porta, si presume che essi si trovino nei primi 64 bit dei dati del datagramma originale. Descrizione Un gateway puo’ scartare datagrammi internet se non ha uno spazio di buffer sufficiente a mettere in coda i datagrammi per l’uscita alla prossima rete nel percorso verso la rete di destinazione. Se un gateway [Page 10] September 1981 RFC 792 scarta un datagramma puo’ inviare un messaggio di sorgente estinta all’host internet sorgente del datagramma. Un host di destinazione puo’ anche inviare tale messaggio qualora i datagrammi arrivino troppo velocemente per essere processati. Il messaggio di sorgente estinta e’ una richiesta all’host di ridurre il rate col quale sta trasmettendo traffico alla destinazione. Il gateway puo’ inviare tale messaggio per ogni messaggio che scarta. Ricevendo un messaggio di sorgente estinta l’host sorgente dovrebbe ridurre il rate col quale sta trasmettendo traffico alla destinazione specificata fino a quando non riceve piu’ tali messaggi dal gateway. L’host sorgente puo’ quindi incrementare gradualmente il rate fino a quando non ricevera’ nuovamente un messaggio di sorgente estinta. Il gateway o l’host possono inviare il messaggio di sorgente estinta quando si avvicinano al proprio limite di capienza piuttosto che attendere che tale limite venga oltrepassato. Cio’ significa che i datagramma di dati che hanno comportato il messaggio possono essere consegnati. Il codice 0 puo’ essere ricevuto da un gateway o da un host. [Page 11] September 1981 RFC 792 Messaggio di Reindirizzamento 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Codice | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | indirizzo internet del gateway | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Intestazione Internet + 64bit dei Dati del Datagramma Originale| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campi IP: Indirizzo di Destinazione La rete sorgente e l’indirizzo dai dati del datagramma originale. Campi ICMP: Tipo 5 Codice 0 = Reindirizza datagrammi per la Rete 1 = Reindirizza datagrammi per l’Host. 2 = Reindirizza datagrammi per il Tipo di Servizio e per la Rete. 3 = Reindirizza datagrammi per il Tipo di Servizio e per l’Host. Checksum Il complemento a 16 bit della relativa somma dei complementi del messaggio ICMP che inizia con il Tipo ICMP. Per il calcolo del checksum, il campo checksum dovrebbe essere zero. Tale checksum potrebbe essere sostituito in futuro. Indirizzo Internet del Gateway L’indirizzo del gateway al quale il traffico per la rete specificata nel campo internet rete di destinazione dei dati del datagramma originale dovrebbe essere inviato. [Page 12] September 1981 RFC 792 Intestazione Internet + 64bit dei Dati del Datagramma Originale L’intestazione internet piu’ i primi 64 bit dei dati del datagramma originale. Tali dati sono utilizzati dall’host per abbinare il messaggio al processo corretto. Se un protocollo di livello elevato utilizza numeri di porta, si presume che essi si trovino nei primi 64 bit dei dati del datagramma originale. Descrizione Il gateway invia un messaggio di reindirizzamento ad un host nel seguente caso. Un gateway, G1, riceve un datagramma Internet da un host su una rete al quale il gateway e’ attaccato. Il gateway, G1, controlla la propria tavola di routing e ottiene l’indirizzo del gateway successivo, G2, lungo la strada alla rete di destinazione del datagramma, X. Se G2 e l’host identificato dall’indirizzo sorgente del datagramma sono sulla stessa rete, un messaggio di reindirizzamento viene spedito all’host. Il messaggio di reindirizzamento raccomanda l’host di inviare il proprio traffico per la rete X direttamente al gateway G2 come se questo fosse il percorso piu’ breve verso la destinazione. Il gateway inoltra i dati del datagramma originale alla sua destinazione internet. Per i datagrammi con le opzioni di route sorgente IP e l’indirizzo del gateway nel campo dell’indirizzo di destinazione, non viene inviato un messaggio di reindirizzamento anche se vi e’ un route migliore verso la destinazione definitiva rispetto all’indirizzo successivo nel route sorgente. I codici 0,1,2 e 3 possono essere ricevuti da un gateway. [Page 13] September 1981 RFC 792 Messaggio di Eco o di Risposta ad un Eco 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Codice | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificatore | Numero di Sequenza | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dati ... +-+-+-+-+- Campi IP: Indirizzi In un messaggio di eco l’indirizzo del sorgente sara’ la destinazione del messaggio di risposta eco. Per costituire in messaggio di risposta eco gli indirizzi sorgente e destinazione sono semplicemente invertiti, il tipo di codice cambiato a 0 e il checksum ricomputato. Campi ICMP: Tipo 8 per il messaggio di eco; 0 per il messaggio di risposta eco. Codice 0 Checksum Il complemento a 16 bit della relativa somma dei complementi del messaggio ICMP che inizia con il Tipo ICMP. Per il calcolo del checksum, il campo checksum dovrebbe essere zero. Tale checksum potrebbe essere sostituito in futuro. Identificatore Se il codice = 0 un identificatore per aiutare nella corrispondeza di echi e risposte puo’ essere zero. Numero di Sequenza [Page 14] September 1981 RFC 792 Se il codice = 0 un numero di sequenza per aiutare nella corrispondeza di echi e risposte puo’ essere zero. Descrizione I dati ricevuti nel messaggio eco devono essere ritornati nel messaggio di risposta eco. L’identificatore e il numero di sequenza possono essere usati dal mittente dell’eco come aiuto nelle corrispondenze delle risposte con le richieste eco. Ad esempio, l’identificatore potrebbe essere utilizzato come una porta TCP o UDP per identificare una sessione, e il numero di sequenza potrebbe essere incrementato ad ogni richiesta eco spedita. L’eco ritorna questi stessi valori nella risposta di eco. Il codice 0 puo’ essere ricevuto da un gateway o da un host. [Page 15] September 1981 RFC 792 Messaggio di Visualizzazione Orario o di Risposta ad una Visualizzazione Orario 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Codice | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificatore | Numero di Sequenza | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Orario di Origine | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Orario di Ricezione | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Orario di Trasmissione | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Addresses In un messaggio di visualizzazione orario l’indirizzo del sorgente sara’ la destinazione del messaggio di risposta ad una visualizzazione orario. Per costituire in messaggio di risposta gli indirizzi sorgente e destinazione sono semplicemente invertiti, il tipo di codice cambiato a 14 e il checksum ricomputato. Campi ICMP: Tipo 13 per il messaggio di visualizzazione orario; 14 per il messaggio di risposta ad una visualizzazione orario. Codice 0 Checksum Il complemento a 16 bit della relativa somma dei complementi del messaggio ICMP che inizia con il Tipo ICMP. Per il calcolo del checksum, il campo checksum dovrebbe essere zero. Tale checksum potrebbe essere sostituito in futuro. Identificatore [Page 16] September 1981 RFC 792 Se il codice = 0 un identificatore per aiutare nella corrispondeza di visualizzazioni orari e risposte puo’ essere zero. Numero di Sequenza Se il codice = 0 un numero di sequenza per aiutare nella corrispondeza di visualizzazioni orari e risposte puo’ essere zero. Descrizione I dati ricevuti (un orario) nel messaggio sono ritornati nella risposta insieme ad un orario addizionale. L’orario sono 32 bit di millisecondi dalla mezzanotte UT. Un utilizzo di questi orari e’ descrittto da Mills [5]. L’Orario di Origine e’ l’orario in cui il mittente ha toccato per l’ultima volta il messaggio prima di inviarlo, l’Orario di Ricezione e’ l’orario in cui il rispondente ha toccato per la prima volta il messaggio nella ricezione, mentre l’Orario di Trasmissione e’ l’orario in cui il rispondente ha toccatto per l’ultima volta il messaggio nell’inviarlo. Se l’orario non e’ disponibile in millisecondi o non puo’ essere fornito rispetto alla mezzanotte UT allora puo’ essere inserito qualsiasi orario nella stringa d’orario; il bit di alto ordine dell’orario e’ inoltre settato per indicare questo valore non-standard. L’identificatore e il numero di sequenza possono essere usati dal mittente dell’eco come aiuto nelle corrispondenze delle risposte con le richieste. Ad esempio, l’identificatore potrebbe essere utilizzato come una porta TCP o UDP per identificare una sessione, e il numero di sequenza potrebbe essere incrementato ad ogni richiesta eco spedita. La destinazione ritorna questi stessi valori nella risposta. Il codice 0 puo’ essere ricevuto da un gateway o da un host. [Page 17] September 1981 RFC 792 Messaggio di Richiesta Informazioni e di Risposta ad una Richiesta Informazioni 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tipo | Codice | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificatore | Numero di Sequenza | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Campi IP: Indirizzi In un messaggio di richiesta informazioni l’indirizzo del sorgente sara’ la destinazione del messaggio di risposta ad una richiesta informazioni. Per costituire in messaggio di risposta gli indirizzi sorgente e destinazione sono semplicemente invertiti, il tipo di codice cambiato a 16 e il checksum ricomputato. Campi ICMP: Tipo 15 per il messaggio di richiesta informazioni; 16 per il messaggio di risposta alla richiesta informazioni. Codice 0 Checksum Il complemento a 16 bit della relativa somma dei complementi del messaggio ICMP che inizia con il Tipo ICMP. Per il calcolo del checksum, il campo checksum dovrebbe essere zero. Tale checksum potrebbe essere sostituito in futuro. Identificatore Se il codice = 0 un identificatore per aiutare nella corrispondeza di richieste e risposte puo’ essere zero. Numero di Sequenza Se il codice = 0 un numero di sequenza per aiutare nella corrispondeza di richieste e risposte puo’ essere zero. [Page 18] September 1981 RFC 792 Descrizione Questo messaggio puo’ essere inviato con la rete sorgente nell’intestazione IP sorgente e il campo di indirizzi di destinazione zero (il che significa “questa” rete). Il modulo IP di risposta dovrebbe inviare la risposta con gli indirizzi pienamente specificati. Questo messaggio e’ un modo per un host di trovare il numero della rete in cui si trova. L’identificatore e il numero di sequenza possono essere usati dal mittente dell’eco come aiuto nelle corrispondenze delle risposte con le richieste. Ad esempio, l’identificatore potrebbe essere utilizzato come una porta TCP o UDP per identificare una sessione, e il numero di sequenza potrebbe essere incrementato ad ogni richiesta eco spedita. La destinazione ritorna questi stessi valori nella risposta. Il codice 0 puo’ essere ricevuto da un gateway o da un host. [Page 19] September 1981 RFC 792 Riepilogo dei Tipi di Messaggio 0 Risposta ad un eco 3 Destinazione non raggiungibile 4 Sorgente estinta 5 Reindirizzamento 8 Eco 11 Tempo scaduto 12 Problema di parametro 13 Orario 14 Risposta ad una richiesta di orario 15 Richiesta di informazioni 16 Risposta ad una richiesta informazioni [Page 20] September 1981 RFC 792 Riferimenti [1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification," RFC 791, USC/Information Sciences Institute, September 1981. [2] Cerf, V., "The Catenet Model for Internetworking," IEN 48, Information Processing Techniques Office, Defense Advanced Research Projects Agency, July 1978. [3] Strazisar, V., "Gateway Routing: An Implementation Specification", IEN 30, Bolt Beranek and Newman, April 1979. [4] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979. [5] Mills, D., "DCNET Internet Clock Service," RFC 778, COMSAT Laboratories, April 1981. [Page 21]