2. ICMPv6 (ICMP for IPv6)
ICMPv6 è utilizzato dai nodi IPv6 per segnalare errori incontrati durante l'elaborazione dei pacchetti e per eseguire altre funzioni di livello Internet, come la diagnostica (ICMPv6 "ping"). ICMPv6 è parte integrante di IPv6, e il protocollo base (tutti i messaggi e i comportamenti richiesti da questa specifica) deve essere completamente implementato da ogni nodo IPv6.
2.1. Formato generale dei messaggi (Message General Format)
Ogni messaggio ICMPv6 è preceduto da un'intestazione IPv6 e zero o più intestazioni di estensione IPv6. L'intestazione ICMPv6 è identificata da un valore Next Header di 58 nell'intestazione immediatamente precedente.
I messaggi ICMPv6 hanno il seguente formato generale:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Message Body +
| |
I messaggi ICMPv6 sono raggruppati in due classi: messaggi di errore (Error Message) e messaggi informativi (Informational Message). I messaggi di errore sono identificati come tali da uno zero nel bit di ordine superiore dei valori del campo Type del messaggio. Pertanto, i messaggi di errore hanno tipi di messaggio da 0 a 127; i messaggi informativi hanno tipi di messaggio da 128 a 255.
Questo documento definisce i formati dei messaggi per i seguenti messaggi ICMPv6:
Messaggi di errore ICMPv6:
- 1 - Destination Unreachable (vedere la Sezione 3.1)
- 2 - Packet Too Big (vedere la Sezione 3.2)
- 3 - Time Exceeded (vedere la Sezione 3.3)
- 4 - Parameter Problem (vedere la Sezione 3.4)
- 100 - Private experimentation
- 101 - Private experimentation
- 127 - Reserved for expansion of ICMPv6 error messages
Messaggi informativi ICMPv6:
- 128 - Echo Request (vedere la Sezione 4.1)
- 129 - Echo Reply (vedere la Sezione 4.2)
- 200 - Private experimentation
- 201 - Private experimentation
- 255 - Reserved for expansion of ICMPv6 informational messages
I valori di tipo 100, 101, 200 e 201 sono riservati per esperimenti privati. Non sono destinati a un uso generale. È previsto che più esperimenti concorrenti vengano condotti con gli stessi valori di tipo. Qualsiasi uso su larga scala e/o non controllato dovrebbe ottenere allocazioni reali come definito nella Sezione 6.
I valori di tipo 127 e 255 sono riservati per una futura espansione dell'intervallo dei valori di tipo in caso di future carenze. I dettagli di ciò sono lasciati a lavori futuri. Un possibile modo per farlo che non causerebbe problemi con le implementazioni attuali è che, se il tipo è uguale a 127 o 255, il campo Code dovrebbe essere utilizzato per la nuova assegnazione. Le implementazioni esistenti ignorerebbero le nuove assegnazioni come specificato nella Sezione 2.4, (b). I nuovi messaggi che utilizzano questi valori di tipo espansi potrebbero assegnare campi nel corpo del messaggio per i propri valori di codice.
Le Sezioni 3 e 4 descrivono i formati dei messaggi per i tipi di messaggio di errore ICMPv6 da 1 a 4 e per i tipi di messaggio informativi 128 e 129.
L'inclusione, almeno, dell'inizio del pacchetto richiamante è intesa a consentire all'originatore di un pacchetto che ha causato un messaggio di errore ICMPv6 di identificare il protocollo di livello superiore e il processo che ha inviato il pacchetto.
2.2. Determinazione dell'indirizzo di origine del messaggio (Message Source Address Determination)
Un nodo che origina un messaggio ICMPv6 deve determinare sia l'indirizzo IPv6 di origine che quello di destinazione nell'intestazione IPv6 prima di calcolare il checksum. Se il nodo ha più di un indirizzo unicast, deve scegliere l'indirizzo di origine del messaggio come segue:
(a) Se il messaggio è una risposta a un messaggio inviato a uno degli indirizzi unicast del nodo, l'indirizzo di origine della risposta deve essere lo stesso indirizzo.
(b) Se il messaggio è una risposta a un messaggio inviato a un qualsiasi altro indirizzo, come - un indirizzo di gruppo multicast, - un indirizzo anycast implementato dal nodo, oppure - un indirizzo unicast che non appartiene al nodo
l'indirizzo di origine del pacchetto ICMPv6 deve essere un indirizzo unicast appartenente al nodo. L'indirizzo dovrebbe essere scelto secondo le regole che sarebbero utilizzate per selezionare l'indirizzo di origine per qualsiasi altro pacchetto originato dal nodo, dato l'indirizzo di destinazione del pacchetto. Tuttavia, può essere selezionato in modo alternativo se ciò portasse a una scelta di indirizzo più informativa raggiungibile dalla destinazione del pacchetto ICMPv6.
2.3. Calcolo del checksum del messaggio (Message Checksum Calculation)
Il checksum è il complemento a uno a 16 bit della somma in complemento a uno dell'intero messaggio ICMPv6, a partire dal campo Type del messaggio ICMPv6, preceduto da un "pseudo-header" di campi dell'intestazione IPv6, come specificato in [IPv6, Sezione 8.1]. Il valore Next Header utilizzato nel pseudo-header è 58. (L'inclusione di un pseudo-header nel checksum ICMPv6 è una modifica rispetto a IPv4; vedere [IPv6] per la motivazione di questa modifica.)
Per il calcolo del checksum, il campo checksum viene prima impostato a zero.
2.4. Regole di elaborazione dei messaggi (Message Processing Rules)
Le implementazioni devono osservare le seguenti regole durante l'elaborazione dei messaggi ICMPv6 (da [RFC-1122]):
(a) Se un messaggio di errore ICMPv6 di tipo sconosciuto viene ricevuto alla sua destinazione, deve essere passato al processo di livello superiore che ha originato il pacchetto che ha causato l'errore, laddove questo possa essere identificato (vedere la Sezione 2.4, (d)).
(b) Se un messaggio informativo ICMPv6 di tipo sconosciuto viene ricevuto, deve essere scartato silenziosamente.
(c) Ogni messaggio di errore ICMPv6 (tipo < 128) deve includere quanto più possibile del pacchetto IPv6 offensore (richiamante) (il pacchetto che ha causato l'errore) senza fare sì che il pacchetto del messaggio di errore superi la MTU minima IPv6 [IPv6].
(d) Nei casi in cui il protocollo di livello Internet è tenuto a passare un messaggio di errore ICMPv6 al processo di livello superiore, il tipo di protocollo di livello superiore viene estratto dal pacchetto originale (contenuto nel corpo del messaggio di errore ICMPv6) e utilizzato per selezionare il processo di livello superiore appropriato per gestire l'errore.
Nei casi in cui non è possibile recuperare il tipo di protocollo di livello superiore dal messaggio ICMPv6, il messaggio ICMPv6 viene scartato silenziosamente dopo qualsiasi elaborazione a livello IPv6. Un esempio di tale caso è un messaggio ICMPv6 con una quantità insolitamente grande di intestazioni di estensione che non ha il tipo di protocollo di livello superiore a causa del troncamento del pacchetto originale per rispettare il limite della MTU minima IPv6 [IPv6]. Un altro esempio è un messaggio ICMPv6 con un'intestazione di estensione ESP per il quale non è possibile decifrare il pacchetto originale a causa del troncamento o dell'indisponibilità dello stato necessario per decifrare il pacchetto.
(e) Un messaggio di errore ICMPv6 non deve essere originato a seguito della ricezione di quanto segue:
(e.1) Un messaggio di errore ICMPv6.
(e.2) Un messaggio ICMPv6 redirect [IPv6-DISC].
(e.3) Un pacchetto destinato a un indirizzo multicast IPv6. (Ci sono due eccezioni a questa regola: (1) il messaggio Packet Too Big (Sezione 3.2) per consentire il funzionamento del Path MTU discovery per il multicast IPv6, e (2) il messaggio Parameter Problem, Code 2 (Sezione 3.4) che segnala un'opzione IPv6 non riconosciuta (vedere la Sezione 4.2 di [IPv6]) che ha i due bit di ordine superiore dell'Option Type impostati a 10).
(e.4) Un pacchetto inviato come multicast a livello di collegamento (le eccezioni di e.3 si applicano anche a questo caso).
(e.5) Un pacchetto inviato come broadcast a livello di collegamento (le eccezioni di e.3 si applicano anche a questo caso).
(e.6) Un pacchetto il cui indirizzo di origine non identifica in modo univoco un singolo nodo -- ad esempio, l'IPv6 Unspecified Address, un indirizzo multicast IPv6, o un indirizzo noto all'originatore del messaggio ICMP come indirizzo anycast IPv6.
(f) Infine, per limitare la larghezza di banda e i costi di inoltro derivanti dall'origination di messaggi di errore ICMPv6, un nodo IPv6 deve limitare la frequenza dei messaggi di errore ICMPv6 che origina. Questa situazione può verificarsi quando una sorgente che invia un flusso di pacchetti errati non presta attenzione ai messaggi di errore ICMPv6 risultanti.
Il rate-limiting dei messaggi ICMP inoltrati è al di fuori dello scopo di questa specifica.
Un metodo raccomandato per implementare la funzione di rate-limiting è un token bucket, che limita la frequenza media di trasmissione a N, dove N può essere sia pacchetti/secondo sia una frazione della banda del collegamento collegato, ma consente l'invio di fino a B messaggi di errore in una raffica, purché la media a lungo termine non sia superata.
I meccanismi di rate-limiting che non sono in grado di gestire il traffico a raffica (ad esempio, traceroute) non sono raccomandati; ad esempio, una semplice implementazione basata su timer, che consente un messaggio di errore ogni T millisecondi (anche con valori bassi di T), non è ragionevole.
I parametri di rate-limiting dovrebbero essere configurabili. Nel caso di un'implementazione token bucket, i valori predefiniti migliori dipendono da dove l'implementazione è previsto che venga distribuita (ad esempio, un router di fascia alta rispetto a un host embedded). Ad esempio, in un dispositivo piccolo/medio, i possibili valori predefiniti potrebbero essere B=10, N=10/s.
NOTA: LE RESTRIZIONI DI CUI SOPRA IN (e) E (f) PREVALGONO SU QUALSIASI REQUISITO ALTROVE IN QUESTO DOCUMENTO PER L'ORIGINATION DI MESSAGGI DI ERRORE ICMP.
Le sezioni seguenti descrivono i formati dei messaggi per i suddetti messaggi ICMPv6.