Revision as of 04:47, 13 April 2017

Activité 25 : 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 dans des paquets. Ces paquets sont ensuite encapsulés dans des trames avant d’être émis sur le support physique. Le protocole IP est lui-même transporté par la couche liaison sur des supports physiques qui peuvent être de natures différentes, impliquant des tailles de trames de longueur variable. La gestion de la taille du paquet sur le chemin est donc nécessaire pour permettre la transmission des données de manière transparente 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].

Cas nominal (taille paquet inférieure à la PMTU)

La couche réseau a pour tâche de placer les segments provenant de la couche transport (données utiles + en-tête transport) dans des paquets. Ces paquets sont ensuite encapsulés dans des trames (PDU de niveau 2) sur le support physique (cf. Figure 1). Ce support, selon sa nature, définit une taille maximale du champ données de la trame :

• Ethernet (1500 octets),
• PPPoA (1468 octets),
• MPLS (de 1500 à 65535 octets),
• etc.

Cette taille fixe donc, pour la couche réseau, la taille maximale de données pouvant être placées dans un paquet. Elle est appelée MTU Maximum Transmission Unit.

Figure 1 : Encapsulation IP dans Ethernet.

Un paquet IP est cependant amené à voyager sur plusieurs supports de natures différentes, chacun imposant une taille maximale (ou 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 de ce fait appelée PMTU Path Maximum Transmission Unit ou unité maximale de taille de transfert sur le chemin.

Pour des considérations d'efficacité, il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Une trop petite taille de paquet a pour effet d'augmenter la charge supplémentaire des en-têtes par rapport aux données transportées, ainsi que d'augmenter le nombre de paquets à traiter dans les routeurs. Au moment de créer des paquets, la couche réseau essaie donc de respecter au maximum la PMTU.

Figure 2 : Path MTU.

Il est à noter qu'IPv6 impose une valeur minimale pour la MTU au niveau réseau (et donc pour la PMTU pour un chemin), valeur fixée à 1280. Cette limite a pour objectif d'éviter qu'un lien imposant une MTU très faible n'implique la transmission de petits paquets pour tous les chemins empruntant ce lien. Si un support physique impose une taille inférieure à 1280, il est nécessaire de mettre en place une couche d'adaptation pour la couche réseau. C'est le cas par exemple pour les réseaux IEEE 802.15.4, imposant une MTU de 81 octets, pour lesquels la couche d'adaptation pour IPv6 6LowPAN (RFC 4944) a dû être spécifiée. L'imposition d'une taille mimimale de MTU qui ne doit pas être fragmentée est une nouveauté en IPv6. 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 1981.

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 place du fragment 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 grand 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 a envoyé est inférieure à cette taille, le paquet pourra être transmis vers sa destination sans problème dû à sa taille. 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. Nous reviendrons sur ce problème 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 ?

Pour aller plus loin

Vous pouvez approfondir vos connaissances en consultant les liens suivants :

• RFC 1981 : Path MTU Discovery for IP version 6 (Analyse par S.Bortzmeyer)
• RFC 2460 : IP version 6, Section 4.5 Fragment header
• 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)