Objectifs du chapitre

Ce chapitre est destiné à présenter la structure du paquet IPv6 et de ses options/en-têtes. Des comparaisons avec son équivalent en IPv4 permettront de constater que cette structure a été nettement simplifiée et améliorée en IPv6.

Structure des paquets IPv6

Voici tout d’abord la structure de l’en-tête principal d’un paquet IPv6 :

Cet en-tête de base présente une longueur fixe de 320 bits soit 40 octets.

Examinons maintenant les différents champs le constituant :

Version (4 bits) désigne évidemment la version d’IP utilisée. Ici, ce sera 6 au lieu de 4 dans les versions antérieures.
Traffic Class (8 bits) remplace le champ TOS (Type of Service) qui classifie les données à faire circuler, et donc les priorités qui leur sont affectées. Les valeurs sont définies par les RFC 0791 et 1349. Son utilisation est la même qu’en IPv4.
Flow Label (20 bits) est un champ nouveau. Son rôle est de permettre aux équipements intermédiaires de routage de pouvoir identifier un type de flux et le traiter en conséquence sans avoir à analyser les flux en détail (notamment sans ouvrir les en-têtes de la couche IP ni les en-têtes de la couche transport sur chaque routeur). Il permet donc potentiellement d’améliorer les performances des routeurs tout au long du parcours. De nombreux RFC documentent l’utilisation de ce champ, principalement le RFC 6437.
Payload Length (16 bits) : contrairement à IPv4, l’en-tête est de taille fixe (20 octets), ce qui implique que ce champ longueur désigne la longueur totale du datagramme...

Présentation des principaux headers (en-têtes)

Les en-têtes d’extension sont totalement optionnels. Ils ne sont présents que s’ils sont nécessaires. Par contre, il est souhaitable qu’ils apparaissent toujours dans un ordre précis afin d’optimiser leur traitement par le destinataire ou par les nœuds intermédiaires (routeurs).

L’ordre recommandé est le suivant :

Hop-by-Hop Options Header
Destination Options Header (dans le cas où le Routing Header existe c’est-à-dire pour les routeurs intermédiaires)
Routing Header
Fragment Header
Authentication Header
Encapsulating Security Payload Header
Destination Options Header (seulement si destination finale)
En-têtes de niveau supérieur (TCP, UDP, ICMP…)

Néanmoins, les nœuds sont supposés accepter les en-têtes dans n’importe quel ordre, sauf le Hop-by-Hop qui doit impérativement être placé en premier.

Le champ Next Header qui est présent dans le paquet de base mais également dans chaque en-tête d’extension permet de savoir quel est l’en-tête qui suit.

Les principales valeurs possibles pour ce champ sont :

Valeurs	Type d’en-tête
0	Hop-by-Hop Options
43	Routing
44	Fragment
50	ESP
51	AH
59	No Next Header
60	Destination Options
135	Mobility Header

Quant à celles de Next Header pour les couches de niveau supérieur :

Valeurs	Type d’en-tête
6	TCP
17	UDP
41	IPv6 encapsulé
58	ICMPv6

Avant de détailler les différents en-têtes voici trois exemples d’enchaînements :

Chaque en-tête d’extension ne peut apparaître qu’une fois dans un paquet, sauf l’extension Destination Options qui peut apparaître une fois avant Routing et une fois avant les en-têtes des couches supérieures.

Les en-têtes contiennent des options qui définissent quelles sont les informations apportées.

Un en-tête peut comporter un nombre variable d’options, chaque option ayant le format général suivant :

Option Type sur 1 octet : identifie l’option qui suit mais aussi les traitements possibles sur une option donnée.

Les deux premiers bits définissent ce qui se passe si un type d’option n’est pas reconnu par le nœud IPv6 qui traite...

Fragmentation des paquets

Un médium donné ne peut faire circuler que des paquets (ou des trames) respectant une taille maximale, cette dernière étant variable d’un support à un autre.

Par exemple, si je veux envoyer 3000 octets sur un circuit qui n’acceptera que 1500 octets sur le premier brin puis 1480 sur le saut suivant, cela ne sera pas possible sans procéder au découpage du paquet d’origine pour le faire passer en plus petits paquets. C’est ce que l’on appelle la fragmentation.

En IPv4, la fragmentation peut intervenir à chaque saut. Par exemple, il y aurait dans notre cas une première fragmentation pour passer de 3000 octets à 1500, puis une autre au deuxième saut pour passer de 1500 à 1480 octets.

Cela multiplie les opérations de fragmentation, ce qui n’est pas bon ni pour les routeurs intermédiaires qui ont à gérer ces opérations, ni pour les performances globales.

En IPv6, un changement fondamental intervient : c’est l’expéditeur et lui seul qui peut fragmenter. Il doit donc y avoir un mécanisme qui lui permet de connaître la taille maximale de données qu’il peut transmettre en une fois sur le chemin entre lui et le destinataire. Cette taille désignée par le terme PMTU (Path Maximum Transmission Unit) et le mécanisme qui permet de la connaître...

Exemples de captures en IPv6

1. Exemples avec paquets simples

Pour illustrer à la fois l’adressage et le format des paquets IPv6, voici quelques exemples de paquets capturés lors d’un dialogue entre un poste et une imprimante en IPv6.

D’abord, un simple ping depuis l’adresse fe80::129a:ddff:fe57:90e7 vers l’adresse de notre imprimante fe80::21b:a9ff:fe3a:4066 :


MacMini:~ root# ping6 FE80::21B:A9FF:FE3A:4066%en0 
PING6(56=40+8+8 bytes) fe80::129a:ddff:fe57:90e7%en0 --> 
fe80::21b:a9ff:fe3a:4066%en0 
16 bytes from fe80::21b:a9ff:fe3a:4066%en0, icmp_seq=0 hlim=64 
time=964.409 ms 
16 bytes from fe80::21b:a9ff:fe3a:4066%en0, icmp_seq=1 hlim=64 
time=1.793 ms

Ce qui, si l’on analyse avec tshark (équivalent en ligne de commande de wireshark) les paquets transmis, donne le résultat suivant avec nos commentaires en gras et en italique (pour alléger la sortie, nous avons supprimé les lignes non indispensables et les avons remplacées par .../...). À noter que dans cette sortie, les éléments en gras (mais sans italique) représentent des valeurs remarquables et non des saisies comme dans d’autres exemples.


Frame 1 (86 bytes on wire, 86 bytes captured) 
Arrival Time: Jan 29, 2012 19:17:36.810489000 
.../... 
À l'origine, nous cherchons à atteindre une adresse IPv6 précise, 
mais comme notre poste ne connaît pas l'adresse MAC à utiliser, il 
est nécessaire de passer par un multicast pour trouver celle-ci. 
Ethernet II, Src: 10:9a:dd:57:90:e7 (10:9a:dd:57:90:e7), Dst: 
IPv6mcast_ff:3a:40:66 (33:33:ff:3a:40:66) 
    Destination: IPv6mcast_ff:3a:40:66 (33:33:ff:3a:40:66) 
        Address: IPv6mcast_ff:3a:40:66 (33:33:ff:3a:40:66) 
        .../... 
    Source: 10:9a:dd:57:90:e7 (10:9a:dd:57:90:e7) 
        Address: 10:9a:dd:57:90:e7 (10:9a:dd:57:90:e7) 
        .../... 
Commence alors le décodage du paquet Internet Protocol Version 6 
    0110 .... = Version: 6 
Puis le champ Traffic Class et Flow label (tous les deux à zéro car 
pas de traitement particulier nécessaire en termes de priorité ou 
de services). 
    Traffic class: 0x00000000 ...

Pour aller plus loin

1. Quelques documents

RFC 0791,1349, 2460 pour les champs des paquets IPv6.
RFC 2711, 2675, 2473, 6554 pour les en-têtes d’extension.

2. Quelques liens

http://www.ietf.org qui est le site de référence pour les documents RFC.
http://www.rfc-editor.org pour obtenir ces mêmes documents avec une interface de recherche plus souple et avec la possibilité d’avoir les versions PDF des RFC, ce qui est parfois bien utile pour les imprimer correctement.
http://www.iana.org/assignments/protocol-numbers/ pour récupérer la liste la plus récente des protocoles reconnus.