• Hop by hop option header
• Routing header
• Destination option header
• Fragmentation header
• Authentication header ed encrypted security payload header

Il campo options di IPv4 è stato eliminato poiché poco usato a causa delle complicazioni che introduce: con le opzioni cioè, il tempo di elaborazione dei pacchetti IPv4 aumenta, in quanto ogni router attraversato deve processarle tutte prima di inoltrare il pacchetto.
Per soddisfare l'esigenza di poter specificare comunque delle opzioni in modo più efficiente rispetto al passato, si è pensato al meccanismo degli extension header. Per ora ne sono stati specificati sei, ma in futuro se ne potranno aggiungere altri. Gli extension header sono inseriti subito dopo l'header IPv6, in questo modo per i router che non li devono processare essi fanno parte del payload del pacchetto e non sono analizzati. Per questo motivo si ha un miglioramento delle prestazioni di forwarding.

Figura 4 - Catena di header.
Ogni pacchetto può contenere più di una intestazione, come mostrato in figura 4; ognuna deve specificare, nel campo next header, il tipo della successiva, formando quella che viene chiamata "catena di header". Nel formare tale catena occorre rispettare il seguente ordine:

• header IPv6;
  
• hop by hop option header
  
• destination option header
  
• routing header
  
• fragmentation header
  
• authentication header
  
• encrypted security payload header
  
• destination option header
  
• upper layer header (es. TCP o UDP).

in cui il destination option header può comparire in due posizioni distinte.

Deve essere elaborato da ogni nodo della rete attraversato dal pacchetto. Il formato è mostrato in figura 5, dove si può notare che il campo option ha lunghezza variabile quindi è necessario specificarne la lunghezza in hdr ext len. Il formato delle opzioni è illustrato in figura 6: ognuna deve iniziare con un campo di 8 bit che ne specifica il tipo, seguito da un campo di 8 bit per la lunghezza.

Le opzioni che possono interessare tutti i nodi lungo il cammino coinvolgono in genere funzioni di gestione o debugging. Fino ad ora sono state definite le seguenti opzioni hop-by-hop:

• 2 opzioni di padding per garantire dati allineati su 64 bit (type =0);
  
• opzione di payload jumbogram (type=194);
  
• opzione di Router Alert. Essa è di tipo generico ed avverte il router che quel pacchetto contiene informazioni specifiche, che devono essere esaminate in modo accurato. Un esempio in cui può essere utile tale opzione è il protocollo RSVP in cui la sorgente ha bisogno di prestabilire un cammino per i pacchetti che genera. Il formato è mostrato in figura 7.

Il routing header è usato da una sorgente per elencare l'insieme dei nodi che un pacchetto deve attraversare prima di giungere a destinazione. E' identificato da un valore del campo next header nell'intestazione che lo precede pari a 43.
Il formato di questo extension header è mostrato in figura 8 Mediante il campo Routing Type è possibile specificare più di una variante per questa intestazione e, per ogni tipo, vi saranno dati diversi inseriti nel campo type-specific data. Per ora è stato definito solo il caso illustrato in figura 9, in cui il Routing Type è nullo. In questo caso il campo segment left, indica il numero di segmenti ancora da raggiungere prima di arrivare alla destinazione, reserved (32 bit), non è ancora utilizzato e Address [1..n] è la lista degli indirizzi che rappresentano le tappe del cammino.

Quando si usa questo tipo di routing header l'header IPv6 iniziale contiene come indirizzo di destinazione il primo indirizzo della lista. A ogni hop il nodo intermedio lo sostituisce con quello del successivo scritto nella lista e decrementa segment left.
Questo tipo di routing header deriva dall'opzione di source routing di IPv4, ma per questa vi è la possibilità di precisare se il pacchetto sarà inviato direttamente (e solo), al nodo con quell'indirizzo (strict), o potrà passare anche per router intermedi (loose); in IPv6 si è scelto di non specificare la scelta tra strict e loose poiché non facilmente attuabile in

pratica, soprattutto in caso di tunnel. Essi infatti, ai fini dell'instradamento, contano come un singolo hop anche quando i router attraversati sono più di uno; di conseguenza la scelta di considerare l'estremità di un tunnel strict o loose è soggettiva.

Destination option header

Il formato è uguale a quello dell'hop by hop extension header poiché anche in questo caso vengono definite delle opzioni (si veda la figura 5). E´ l'unico extension header che può comparire due volte nello stesso pacchetto, anche se in due posizioni diverse.
Se è posto prima di routing header sarà elaborato dal primo nodo che compare nel campo Destination dell'intestazione IPv6. Altrimenti è visibile solo agli estremi. Per ora sono state definite solo due opzioni di padding, al fine di rendere i pacchetti di lunghezza pari a multipli di 64 byte.

Fragmentation header

Una novità introdotta da IPv6 è l'eliminazione della frammentazione hop by hop del pacchetto. Col nuovo protocollo la frammentazione è gestita dagli estremi, mediante un apposito extension header.
Se le dimensioni del pacchetto superano quella della MTU massima consentita per il link sul quale tale pacchetto deve essere trasmesso, il nodo lo scarica e invia indietro verso la sorgente un messaggio ICMP di errore.
Nel caso in cui sia necessario inviare un datagramma il cui payload supera le dimensioni consentite su quel link dal valore di MTU, IPv6 fornisce alla stazione mittente la possibilità di frammentare il pacchetto: l'uso del fragmentation header permette alla destinazione di ricostruirlo correttamente.
Il formato di fragmentation header è illustrato in figura 10.

Figura 10 - Fragmentation header.

Ogni pacchetto è composto da una parte non frammentabile e una frammentabile, come mostrato in figura 11. La prima, che comprende l'header IPv6 e gli altri header che devono essere elaborati a ogni nodo, deve essere ripetuta uguale per ogni frammento. Vi sono solo due eccezioni: occorre aggiornare il payload length e l'ultimo Next Header che deve ora segnalare la presenza del Fragment Header.

Figura 11 - Pacchetto prima della frammentazione

Figura 12 - Pacchetti risultanti dalla frammentazione.
La seconda parte comprende il resto del pacchetto e viene divisa in blocchi multipli di 8 ottetti a ciascuno dei quali viene anteposta la parte non frammentabile aggiornata, come rappresentato in figura 12.
Nel caso in cui un cambiamento nelle tabelle di instradamento provochi la variazione di alcuni valori per le MTU dei link, è prevista la possibilità di far gestire la frammentazione ai router mediante l'uso di tunnel IPv6 in IPv6, ma fino ad ora si sono avute poche implementazioni di questo tipo.

Authentication header ed encrypted security payload header

IPv6 fornisce un servizio standard di autenticazione e cifratura end-to-end attraverso due extension header il cui formato è mostrato nelle figure 13 e 14.
L'Authentication Header (AH), ha lo scopo di garantire l'autenticità e l'integrità del pacchetto in cui è posto, ossia controlla che tale pacchetto non sia modificato in transito o sia stato generato da chi non ha il permesso di accedere a quella determinata risorsa.
L'Encrypted Security Payload header (ESP), invece, fornisce un meccanismo per trattare i dati in modo che possano essere letti solo al termine del percorso.
In entrambi i casi sorgente e destinazione devono accordarsi circa la chiave segreta, l'algoritmo da usare e quali valori assegnare ai suoi parametri. L'insieme di queste informazioni forma una associazione di sicurezza (Security Association SA), identificata dal campo SPI (security parameter index) insieme agli indirizzi di sorgente e destinazione.
La negoziazione di una security association è parte integrante del protocollo di scambio delle chiavi.
Le implementazioni di IPv6 devono supportare l'algoritmo MD5 per l'autenticazione e controllo di integrità e DES_CBC come algoritmo per la crittografia, ma siccome le specifiche non dipendono da tali algoritmi possono essere usate altre tecniche una volta stabilita un'associazione di sicurezza.

Figura 13 Authentication header

Figura 14 - ESP header.

In base alla scelta dell'algoritmo di autenticazione, può variare la lunghezza del campo authentication data (si veda la figura 13). Esso contiene il valore di autenticazione generato dal mittente, corrispondente al risultato di un calcolo che usa come dati la chiave segreta, il campo dati e l'intestazione del pacchetto IP. Il destinatario, alla ricezione di un pacchetto in cui è presente l'extension header AH, calcola il valore di autenticazione nello stesso modo in cui è stato calcolato dalla sorgente e lo confronta con quello ricevuto. Se i due valori sono uguali il pacchetto è integro e il mittente autentico.
E' importante notare che sia sorgente che destinazione effettuano il calcolo sul pacchetto IP normalizzato al quale viene concatenata la chiave segreta. Un pacchetto si dice normalizzato quando il next hop e tutte le opzioni che devono essere modificate lungo il cammino sono poste a zero e l'eventuale Routing Header è posto al valore che avrà a destinazione.
ESP è l'extension header che porta end-to-end i parametri e le chiavi usati per la crittografia.
Quando usato, deve essere l'ultimo della catena perché nasconde completamente sia i dati di livello superiore che gli header successivi ad esso.
Sono possibili due scelte: transport mode e tunnel mode (si veda la figura 15 ). Nel primo caso ciò che viene cifrato è solo il payload del pacchetto IPv6. Per avere un grado più elevato di sicurezza si può ricorrere al tunnel mode in cui l'intero pacchetto è criptato ed è poi incapsulato in un altro pacchetto. In questo modo è visibile solo agli estremi ed è per questo che l'efficacia della cifratura è maggiore, ma per contro aumenta l'overhead.

Figura 15 - Transport mode e tunnel mode.

---