4. En-têtes d'extension IPv6
Dans IPv6, les informations optionnelles de couche Internet sont encodées dans des en-têtes séparés qui peuvent être placés entre l'en-tête IPv6 et l'en-tête de couche supérieure dans un paquet. Il existe un petit nombre de tels en-têtes d'extension, chacun identifié par une valeur Next Header distincte. Comme illustré dans les exemples suivants, un paquet IPv6 peut porter zéro, un ou plusieurs en-têtes d'extension, chacun identifié par le champ Next Header de l'en-tête précédent :
+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
À une exception près, les en-têtes d'extension ne sont pas examinés ni traités par aucun nœud sur le chemin de livraison du paquet, jusqu'à ce que le paquet atteigne le nœud (ou, dans le cas du multicast, l'ensemble de nœuds) identifié dans le champ Destination Address de l'en-tête IPv6. Là, le démultiplexage normal du champ Next Header de l'en-tête IPv6 invoque le module pour traiter le premier en-tête d'extension, ou l'en-tête de couche supérieure s'il n'y a pas d'en-tête d'extension. Le contenu et la sémantique de chaque en-tête d'extension déterminent s'il faut continuer à traiter l'en-tête suivant. Par conséquent, les en-têtes d'extension DOIVENT être traités strictement dans l'ordre où ils apparaissent dans le paquet ; par exemple, un récepteur NE DOIT PAS parcourir le paquet à la recherche d'un type particulier d'en-tête d'extension et traiter cet en-tête avant d'avoir traité tous les en-têtes précédents.
L'exception mentionnée dans le paragraphe précédent est le Hop-by-Hop Options header (en-tête d'options saut par saut), qui porte des informations devant être examinées et traitées par chaque nœud sur le chemin de livraison du paquet, y compris les nœuds source et destination. Lorsqu'il est présent, le Hop-by-Hop Options header DOIT immédiatement suivre l'en-tête IPv6. Sa présence est indiquée par la valeur zéro dans le champ Next Header de l'en-tête IPv6.
Si, à la suite du traitement d'un en-tête, un nœud est amené à continuer le traitement de l'en-tête suivant mais que la valeur Next Header dans l'en-tête courant n'est pas reconnue par le nœud, il DEVRAIT rejeter le paquet et envoyer un message ICMP Parameter Problem à l'adresse source du paquet, avec une valeur ICMP Code de 1 (« unrecognized Next Header type encountered »), le champ ICMP Pointer contenant le décalage dans le paquet original de la valeur non reconnue. La même action DEVRAIT être entreprise si un nœud rencontre une valeur Next Header de zéro dans un en-tête autre que l'en-tête IPv6.
La longueur de chaque en-tête d'extension est un multiple entier de 8 octets, afin de conserver l'alignement sur 8 octets pour les en-têtes suivants. Les champs multi-octets dans chaque en-tête d'extension sont alignés sur leurs frontières naturelles, c'est-à-dire qu'un champ de largeur n octets est placé à un multiple entier de n octets depuis le début de l'en-tête, pour n = 1, 2, 4 ou 8.
Une implémentation complète d'IPv6 comprend l'implémentation des en-têtes d'extension suivants :
Hop-by-Hop Options
Routing (Type 0)
Fragment
Destination Options
Authentication
Encapsulating Security Payload
Les quatre premiers sont spécifiés dans ce document ; les deux derniers sont spécifiés respectivement dans [RFC-2402] et [RFC-2406].