Justification des extentions

Figure : Enchaînement d'extentions La figure "Enchaînement d'extentions" montre la souplesse avec laquelles plusieurs extentions peuvent être chaînées. Chaque extention contient dans son en-tête un champ en-tête suivant et longueur. Le premier paquet ne contient pas d'extention, le champ en-tête suivant pointe sur TCP. Le second paquet contient une extention de routage qui pointe sur TCP. Dans le dernier paquet, une extention de fragmentation est ajoutée après celle de routage.

Si cet enchaînement d'extention offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port, il faut en effet lire tout l'enchaînement d'extention pour arriver au protocole de niveau 4. Ceci a servi de justification au l'identificateur de flux qui permettait de refleter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports.

Les extentions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extention de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extentions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).

Si d'un point de vue théorique les extentions sont supérieurs aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.

En-tête suivant 

Ce champ a une fonction similaire au champ protocole du paquet IPv4. Il identifie le prochain en-tête. Il peut s'agir d'un protocole (de niveau supérieur ICMP, UDP, TCP...) ou de la désignation d'extensions (cf. tableau Valeurs du champ en-tête suivant).

Les extensions contiennent aussi ce champ pour permettre un chaînage.

Proche-en-proche

Figure 4-6 Format générique des options "proche-en-proche" et "destination"

Cette extension (en anglais : hop-by-hop) se situe toujours en première position et est traitée par tous les routeurs que le paquet traverse. Le type associé (contenu dans le champ d'en-tête en-tête suivant de l'en-tête précédent) est 0 et le champ longueur de l'extension contient le nombre de mots de 64 bits moins 1.

L'extension est composée d'options. Pour l'instant, seules quatre options, dont deux de bourrage, sont définies (cf. Format des options IPv6). Chaque option est une suite d'octets. Le premier octet est un type, le deuxième (sauf pour l'option 0) contient la longueur de l'option moins 2. Les deux premiers bits de poids fort du type définissent le comportement du routeur quand il rencontre une option inconnue :

• 00 : le routeur ignore l'option ;
• 01 : le routeur rejette le paquet ;
• 10 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité ;
• 11 : le routeur rejette le paquet et retourne un message ICMPv6 d'inaccessibilité si l'adresse de destination n'est pas multicast.

Le bit suivant du type indique que le routeur peut modifier le contenu du champ option (valeur à 1) ou non (valeur à 0).

Figure 4-7 Format des options IPv6

Les quatre options de proche-en-proche sont :

• Pad1 (type 0). Cette option est utilisée pour introduire un octet de bourrage.
• Padn (type 1). Cette option est utilisée pour introduire plus de 2 octets de bourrage. Le champ longueur indique le nombre d'octets qui suivent.

Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu'un champ longueur pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits ; le RFC 2460 discute en annexe de la manière d'optimiser le traitement tout en minimisant la place prise par les options.

• Jumbogramme (type 194 ou 0xc2, RFC 2675). Cette option est utilisée quand le champ longueur des données du paquet IPv6 n'est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l'option jumbogramme est utilisée, le champ longueur des données utiles dans l'en-tête IPv6 vaut 0.
  Noter que le type commence par la séquence binaire 11, ce qui permet au routeur ne traitant pas les jumbogrammes d'en informer la source. Celle-ci pourra réémettre l'information sans utiliser cette option.

• L'option Router Alert (RFC 2711) demande à un routeur d'examiner le contenu des données qu'il relaie (Router Alert existe également en IPv4, RFC 2113). En principe, le processus de relayage (recopier le paquet sur une interface de sortie en fonction de l'adresse destination et des tables de routage) doit être le plus rapide possible. Mais pour des protocoles comme la gestion des groupes de multicast avec MLD (Multicast Listener Discovery) ou la signalisation des flux avec RSVP, tous les routeurs intermédiaires doivent tenir compte des données.
  L'émetteur envoie les données à la destination, mais s'il précise l'option Router Alert, les routeurs intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le paquet. Ce mécanisme est efficace puisque les routeurs n'ont pas à analyser le contenu de tous les paquets d'un flux.
  Le type de l'option vaut 5. Il commence par la séquence binaire 00, puisqu'un routeur qui ne connaît pas cette option doit relayer le paquet sans le modifier. Le champ valeur de l'option contient :
  • 0 : pour les messages du protocole MLD de gestion des groupes multicast ;
  • 1 : pour les messages RSVP ;
  • 2 : pour les réseaux actifs ;

les autres valeurs sont réservées.