4. IPv6 Extension Headers (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 d'un paquet. Il existe un petit nombre de tels en-têtes d'extension (Extension Headers), chacun identifié par une valeur Next Header distincte.

Les numéros d'en-têtes d'extension proviennent des numéros de protocole IP de l'IANA [IANA-PN], les mêmes valeurs utilisées par IPv4 et IPv6. Lors du traitement d'une séquence de valeurs Next Header dans un paquet, la première valeur qui n'est pas un en-tête d'extension [IANA-EH] indique que l'élément suivant dans le paquet est l'en-tête de couche supérieure correspondant. S'il n'y a pas d'en-tête de couche supérieure, une valeur spéciale "No Next Header" est utilisée.

Comme l'illustrent ces exemples, un paquet IPv6 peut transporter 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       |
+---------------+----------------+-----------------+-----------------

Les en-têtes d'extension (à l'exception de l'en-tête Hop-by-Hop Options) ne doivent pas (MUST NOT) être traités, insérés ou supprimés par un nœud sur le chemin de livraison du paquet, jusqu'à ce que le paquet atteigne le nœud (ou chaque nœud dans le groupe, dans le cas de multicast) identifié dans le champ Destination Address de l'en-tête IPv6.

L'en-tête Hop-by-Hop Options n'est pas inséré ou supprimé, mais peut être examiné ou traité par tout nœud sur le chemin de livraison du paquet, jusqu'à ce que le paquet atteigne le nœud (ou chaque nœud dans le groupe, dans le cas de multicast) identifié dans le champ Destination Address de l'en-tête IPv6. L'en-tête Hop-by-Hop Options (s'il est présent) doit (MUST) suivre immédiatement 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.

Note : Bien que [RFC2460] exigeait que tous les nœuds examinent et traitent l'en-tête Hop-by-Hop Options, il est maintenant attendu que les nœuds sur le chemin de livraison du paquet n'examinent et ne traitent l'en-tête Hop-by-Hop Options que lorsqu'ils sont explicitement configurés pour le faire.

Au nœud de destination, 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 ou non à traiter l'en-tête suivant. Par conséquent, les en-têtes d'extension doivent (MUST) être traités strictement dans l'ordre où ils apparaissent dans le paquet ; un récepteur ne doit pas (MUST NOT), par exemple, scanner le paquet à la recherche d'un type particulier d'en-tête d'extension et le traiter avant de traiter tous les en-têtes précédents.

Si, en résultat du traitement d'un en-tête, le nœud de destination doit continuer à traiter l'en-tête suivant mais que la valeur Next Header dans l'en-tête actuel n'est pas reconnue par le nœud, il devrait (SHOULD) rejeter le paquet et envoyer un message ICMP Parameter Problem au nœud source, avec un code ICMP de 1 ("Type Next Header non reconnu rencontré") et le champ ICMP Pointer contenant le décalage de la valeur non reconnue dans le paquet d'origine. La même action devrait (SHOULD) être prise si un nœud rencontre une valeur Next Header de zéro dans tout en-tête autre que l'en-tête IPv6.

Chaque en-tête d'extension a une longueur qui est un multiple entier de 8 octets, afin de maintenir 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 limites naturelles, c'est-à-dire, les champs de largeur n octets sont placés à un multiple entier de n octets du début de l'en-tête, pour n = 1, 2, 4 ou 8.

Une implémentation complète d'IPv6 inclut l'implémentation des en-têtes d'extension suivants :

• Hop-by-Hop Options (Options saut par saut)
• Fragment
• Destination Options (Options de destination)
• Routing (Routage)
• Authentication (Authentification)
• Encapsulating Security Payload (Charge utile de sécurité encapsulante)

Les quatre premiers sont spécifiés dans ce document ; les deux derniers sont spécifiés respectivement dans [RFC4302] et [RFC4303]. La liste actuelle des en-têtes d'extension IPv6 peut être trouvée dans [IANA-EH].

4.1 Extension Header Order (Ordre des en-têtes d'extension)

Lorsque plusieurs en-têtes d'extension sont utilisés dans le même paquet, il est recommandé (RECOMMENDED) que ces en-têtes apparaissent dans l'ordre suivant :

IPv6 header
Hop-by-Hop Options header
Destination Options header (note 1)
Routing header
Fragment header
Authentication header (note 2)
Encapsulating Security Payload header (note 2)
Destination Options header (note 3)
Upper-Layer header

Note 1 : Pour les options à traiter par le premier nœud de destination qui apparaît dans le champ Destination Address de l'en-tête IPv6, plus les destinations suivantes listées dans l'en-tête de routage.

Note 2 : Des recommandations supplémentaires sur l'ordre relatif des en-têtes Authentication et Encapsulating Security Payload sont données dans [RFC4303].

Note 3 : Pour les options à traiter uniquement par la destination finale du paquet.

Chaque en-tête d'extension devrait (SHOULD) apparaître au maximum une fois, sauf l'en-tête Destination Options, qui devrait (SHOULD) apparaître au maximum deux fois (une fois avant un en-tête de routage et une fois avant l'en-tête de couche supérieure).

Si l'en-tête de couche supérieure est un autre en-tête IPv6 (dans le cas de tunnelisation IPv6-dans-IPv6 ou d'encapsulation), il peut être suivi de ses propres en-têtes d'extension, qui obéissent séparément aux mêmes recommandations d'ordre.

Si d'autres en-têtes d'extension sont définis, leurs contraintes d'ordre par rapport aux en-têtes listés ci-dessus doivent (MUST) être spécifiées.

Les nœuds IPv6 doivent (MUST) accepter et tenter de traiter les en-têtes d'extension dans n'importe quel ordre et apparaissant n'importe quel nombre de fois dans le même paquet, à l'exception de l'en-tête Hop-by-Hop Options qui est limité à apparaître immédiatement après un en-tête IPv6 uniquement. Néanmoins, il est fortement conseillé (STRONGLY ADVISED) que les sources de paquets IPv6 adhèrent à l'ordre recommandé ci-dessus jusqu'à ce que et à moins que des spécifications ultérieures ne révisent cette recommandation.

4.2 Options

Les deux en-têtes d'extension actuellement définis et spécifiés dans ce document -- l'en-tête Hop-by-Hop Options et l'en-tête Destination Options -- transportent un nombre variable d'« options » qui sont encodées de type-longueur-valeur (TLV) dans le format suivant :

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
|  Option Type  |  Opt Data Len |  Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

Option Type Identificateur sur 8 bits du type d'option.

Opt Data Len Entier non signé sur 8 bits. Longueur du champ Option Data de cette option, en octets.

Option Data Données spécifiques à l'option de longueur variable.

Les deux bits de poids fort du champ Option Type spécifient l'action qui doit être prise par un nœud IPv6 qui ne reconnaît pas le type d'option :

00 - ignorer cette option et continuer le traitement
01 - rejeter le paquet
10 - rejeter le paquet et envoyer un message ICMP Parameter Problem code 2 à l'adresse source du paquet,
     que l'adresse de destination soit ou non une adresse multicast
11 - rejeter le paquet et envoyer un message ICMP Parameter Problem code 2 à l'adresse source du paquet uniquement
     si l'adresse de destination n'est pas une adresse multicast

Le troisième bit de poids fort du champ Option Type (bit 2) spécifie si les données d'option de cette option peuvent changer en route vers la destination du paquet :

0 - Les données d'option ne changent pas en route
1 - Les données d'option peuvent changer en route

Les options individuelles n'ont pas besoin d'être alignées sur des limites d'octets dans l'en-tête d'extension. Cependant, un remplissage utilisant les options Pad1 ou PadN est nécessaire pour que la longueur totale de l'en-tête d'extension soit un multiple de 8 octets.

---

4.3 Hop-by-Hop Options Header

L'en-tête Hop-by-Hop Options est utilisé pour transporter des informations d'option qui doivent être examinées par chaque nœud le long du chemin de livraison. L'en-tête Hop-by-Hop Options est identifié par une valeur Next Header de 0 dans l'en-tête IPv6.

4.4 Routing Header

L'en-tête de routage est utilisé par un nœud source IPv6 pour lister un ou plusieurs nœuds intermédiaires à « router » sur le chemin vers la destination d'un paquet.

4.5 Fragment Header

L'en-tête de fragment est utilisé par une source IPv6 pour envoyer un datagramme plus grand que le MTU du chemin.

4.6 Destination Options Header

L'en-tête Destination Options est utilisé pour transporter des informations d'option qui doivent être examinées uniquement par le(s) nœud(s) de destination du paquet.

4.7 No Next Header

La valeur 59 indique « No Next Header » et peut être utilisée dans le champ Next Header d'un en-tête IPv6 ou de tout en-tête d'extension.

4.8 Defining New Extension Headers and Options

Les spécifications définissant de nouveaux en-têtes d'extension ou options doivent (MUST) spécifier :

• Les contraintes d'ordre par rapport aux en-têtes d'extension existants
• Le comportement des nœuds lorsqu'ils ne sont pas reconnus
• La mutabilité (peuvent-ils être modifiés en route)
• Les exigences d'alignement
• L'interaction avec l'en-tête Fragment (le cas échéant)

---