Activité 23 : La taille des paquets IPv6

Introduction

La notion de datagramme, sur laquelle repose le protocole IP, implique un découpage des données provenant de la couche transport afin que ces données puissent être transportées. En effet, un paquet est une unité de transfert de taille variable et limitée. Les paquets ainsi constitués sont ensuite encapsulés dans des trames avant d’être transmis sur le support physique. Aussi les datagrammes sont transportés dans des systèmes de transmissions mettant en oeuvre des supports physiques qui peuvent être de natures différentes. Ces systèmes ont des tailles de trames de longueur maximale variable. La gestion de la taille du paquet sur le chemin est donc nécessaire pour permettre le transfert des données de manière indépendante du support d'un bout à l'autre de l'Internet. Ce problème de la taille du paquet à transférer existe tout aussi bien en IPv4 qu'en IPv6. La solution pour régler le problème est différente entre IPv4 et IPv6 ^[1].

Dans cette activité vous allez commencer par définir les notions de MTU et PMTU qui posent les contrainte de la taille maximale du paquet. Vous verrez comment en IPv6 découvrir la taille maximale du paquet pour un transfert. Le protocole IPv6 gère aussi la fragmentation. Vous aurez les explication du quand et du comment elle est mise en oeuvre. Enfin vous verrez la description d'un paquet IPv6 jumbogramme.

MTU et PMTU

La couche de réseau doit placer les messages provenant de la couche de transport dans des paquets. Un message de transport se définit comme un bloc de données provenant de l'application complété par un en-tête de transport. Les paquets ainsi constitués sont ensuite encapsulés dans des trames adaptées au support physique utilisé (cf. Figure 1). Cette combinaison de format de trame et de support physique constitue ce que l'on pourra qualifier de système de transmission. Chaque système de transmission définit une taille maximale du champ de données de la trame. Cette taille du champ de données de la trame limite la taille maximale du paquet et par conséquent des données que peut contenir un paquet. La taille maximale du champ de données de la trame est appelée MTU Maximum Transmission Unit. Comme exemple, on peut citer les systèmes de transmission Ethernet avec une MTU de 1500 octets, ou Wifi avec une MTU de 2304 octets.

Figure 1 : Encapsulation IP dans Ethernet.

Un paquet IP peut être amené à transiter par des systèmes de transmission de natures différentes, chacun imposant une MTU différente. Pour pouvoir parcourir son chemin jusqu'à sa destination, le paquet doit donc avoir une taille inférieure ou égale à la plus petite taille autorisée par l'ensemble des liens traversés (cf. Figure 2). Cette taille est appelée PMTU (Path Maximum Transmission Unit) ou unité maximale de taille de transfert sur le chemin.

Figure 2 : Path MTU.

Pour des considérations d'efficacité, il est généralement préférable que les informations échangées entre noeuds soient contenues dans des datagrammes de taille maximale. Les paquets de petite taille ont pour effet d'augmenter le coût des en-têtes par rapport aux données transportées, et d'augmenter le nombre de paquets à traiter dans les routeurs.

Toujours dans un soucis d'efficacité, IPv6 impose une valeur minimale pour la MTU de 1280 octets (et donc pour la PMTU aussi). Cette valeur a pour objectif d'éviter qu'un lien imposant une MTU plus faible n'implique la transmission de petits paquets qui serait imposée à tous les chemins empruntant ce lien. Si un support de transmission utilise des trames de taille inférieure à 1280 octets, il est nécessaire de mettre en place une couche d'adaptation dans ce système afin que la MTU atteigne la valeur demandée. C'est le cas par exemple pour les réseaux personnels sans fil de type LR WPAN (Low Rate Wireless Personal Area Network) comme IEEE 802.15.4 qui véhicule des trames avec des blocs d'au maximum de 81 octets. Dans ce cas, une couche d'adaptation a du être spécifiée au moyen du RFC 4944 afin de rendre cette technologie utilisable dans le contexte IPv6 (6LowPAN). L'imposition d'une taille mimimale de MTU et de sa non fragmentation par IPv6 est une nouveauté en IPv6.

Pour conclure, retenez que la bonne taille du paquet IPv6 dépend du protocole de transport. Pour TCP, la valeur de 1280 octets montre de bons résultat^[2].

Découverte de la PMTU

Cependant, la valeur de la PMTU n'est pas forcément connue à l'envoi d'un premier paquet vers une destination quelconque. L'émetteur du paquet fait alors la supposition que la taille maximale vers cette destination est égale à celle du support physique sur lequel il est connecté, c'est-à-dire la MTU du réseau d’accès.

L'acheminement du paquet IPv6 s'effectue normalement jusqu'au premier routeur rencontrant une incompatibilité entre la taille du paquet à transmettre et la taille maximale autorisée sur le support physique. Le routeur est alors dans l'incapacité de traiter correctement le paquet. Le routeur supprime le paquet et utilise alors un message de signalisation (reposant sur ICMPv6, qui sera décrit dans la séquence 3) pour informer, l'émetteur du paquet, du problème d'acheminement. Ce message indique également la taille recommandée pour que les paquets soient acheminés correctement.

Figure 3 : Négociation pour la Path MTU Discovery.

La couche réseau de l'émetteur, à la réception de ce message, enregistre la valeur recommandée de taille de paquet (cf. Figure 3). Cette valeur est la PMTU pour tous les prochains paquets vers cette même destination. La couche de transport comme TCP retransmet les données perdues ou l'application produit des nouvelles données à transmettre dans un paquet à la taille adaptée.

Ce processus peut être répété si d'autres liens imposent des tailles maximales de transmission encore inférieures. L'émetteur enregistrera les valeurs recommandées successives jusqu'à arriver à la taille maximale autorisée sur le chemin. Les paquets suivants qui respecteront cette taille seront alors acheminés sans problème. Ce mécanisme de découverte de la taille maximale de transmission sur le chemin est spécifié dans le RFC 8201.

NOTA : Attention au filtrage d'ICMPv6 ! Contrairement à une pratique couramment répandue en IPv4, il ne faut jamais filtrer l'ensemble des messages ICMPv6 en entrée d'un réseau (en particulier le message "Paquet trop grand"). Le filtrage peut introduire des effets néfastes sur le fonctionnement du réseau.

Cas où taille paquet supérieure à la PMTU : besoin de fragmentation IPv6

Il existe cependant des cas où la couche réseau ne peut pas adapter la taille des données à transmettre à la taille maximale autorisée sur le chemin. C'est le cas par exemple des messages transportés sur UDP pour le système de fichiers NFS. Ces messages peuvent avoir une taille supérieure à celle autorisée sur le support.

La couche réseau n'a alors d'autre choix que de fragmenter ces données. Le principe de la fragmentation est de séparer un paquet, devant être émis avec une taille trop importante, en plusieurs paquets respectant la taille maximale autorisée. Ces paquets (ou fragments) sont émis et acheminés vers la destination comme n'importe quel autre paquet IP (cf. Figure 4). La couche réseau du destinataire se charge alors de reconstruire le paquet IP original pour que les données puissent être traitées.

Figure 4 : Fragmentation.

L'identification d'un fragment (à quel paquet appartient-il ? quelle est la position relative de ce fragment ?) est transmise dans une extension de fragmentation de l'en-tête IPv6. Le format de l'extension de fragmentation est donné figure 5.

Figure 5 : Format de l'extension de fragmentation.

• Le champ Fragment offset indique, lors du réassemblage, où les données doivent être insérées. Ceci permet de parer les problèmes dus au dé-séquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.
• Le bit M, s'il vaut 1, indique qu'il y aura d'autres fragments émis.
• Le champ identification permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet et recopié dans ses fragments.

Note : la fragmentation est permise en IPv4 au niveau des routeurs intermédiaires, leur donnant ainsi la possibilité de transmettre un paquet, même s'il est de taille supérieure à la MTU du lien suivant. Mais, dans ce cas, le mécanisme est jugé inefficace car il augmente la tâche des routeurs. En IPv6, grâce au mécanisme de découverte de la taille maximale de transmission, les routeurs intermédiaires ne fragmentent plus les paquets. Si la fragmentation est cependant nécessaire, cette tâche est déléguée aux extrémités de la communication.

Jumbogrammes

Une autre fonction optionnelle d'IPv6 est l'option "jumbogramme" dans une extension d'en-tête Hop-by-Hop, qui permet l'échange de paquets ayant une charge utile jusqu'à 4 Gio moins un (2^32 − 1 = 4 294 967 295 octets), en permettant l'utilisation d'un champ longueur de 32 bits. De tels paquets sont appelés "jumbogrammes".

Étant donné que TCP et UDP disposent de champs limités à 16 bits (longueur, pointeur urgent), le support des "jumbogrammes" IPv6 nécessite des modifications sur l'implémentation des couches de protocoles Transport. Les "jumbogrammes" sont intéressants sur des liens qui disposent d'une MTU plus grande que 65583 octets (plus de 65535 octets de charge utile, plus 40 octets pour la taille fixe de l'en-tête, plus 8 octets pour l'en-tête d'extension Hop-by-Hop). Mais, à la date de rédaction de ce texte, aucun support de transmission ne permet une taille de trame aussi importante.

Conclusion

Cette activité vous a présenté les différents cas nécessitant une gestion particulière de la taille du paquet IPv6. Cette gestion est conditionnée à la valeur de l'unité maximale de transfert sur le chemin, ou PMTU. Si la taille du paquet à envoyer est inférieure à cette taille, le paquet pourra être transmis vers sa destination sans problème. Si par contre la taille du paquet est plus grande que la valeur de PMTU, soit un ajustement de la taille du segment de donnée est nécessaire au niveau de la couche transport, soit la fragmentation est obligatoire. Dans l'article en ligne^[3], l'auteur rapporte une autre idée : ne pas envoyer des paquets de plus de 1280 octets en dehors du réseau local. Ainsi en transmettant des paquets à la taille minimale de la PMTU, il n'y a plus de besoin de fragmenter et donc d'utiliser la découverte de la PMTU. C'est une solution un peu extrême pour contourner la non mise en oeuvre de la fragmentation. Et lorsqu'elle est mise en oeuvre, la fragmentation IPv6 peut avoir des effets néfastes^[4] du fait que certains équipements jettent les fragments de paquet IPv6. Nous reviendrons sur le problème de la taille de la MTU lors de la séquence suivante.

Références bibliographiques

1. ↑ Huston, G. (2016), January. Blog of AFNIC. http://blog.apnic.net/2016/01/28/evaluating-ipv4-and-ipv6-packet-frangmentation/
   Evaluating IPv4 and IPv6 packet fragmentation.
2. ↑ Huston, G. (2016), May. http://blog.apnic.net/2016/05/19/fragmenting-ipv6/ Fragmenting IPv6.
3. ↑ Bortzmeyer, S. (2010) Fragmentation IPv6 : se résigner à couper à 1280 octets ?
4. ↑ Huston, G. (2018) The Internet Protocol Journal. Vol 21. N° 1. IPv6 and Packet Fragmentation

Pour aller plus loin

Vous pouvez approfondir vos connaissances en consultant les liens suivants :

• RFC 4821 : Packetization Layer Path MTU Discovery (Analyse par S.Bortzmeyer)
• RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks
• RFC 6946 : Processing of IPv6 "atomic" fragments (Analyse par S.Bortzmeyer)
• RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World (Analyse par S.Bortzmeyer)
• RFC 8200 : IP version 6, Section 4.5 Fragment header (Analyse par S.Bortzmeyer)
• RFC 8201 : Path MTU Discovery for IP version 6 (Analyse par S.Bortzmeyer)