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 transmis dans des systèmes de transmissions mettant en oeuvre des supports physiques qui peuvent être de natures différentes. Ces systèmes ont une taille de trame de valeur 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 contraintes 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 explications du quand et du comment la fragmentation est mise en oeuvre. Enfin le paquet IPv6 jumbogramme sera présenté.

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é. 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. La Figure 1 illustre les encapsulations successives qui se produisent pour la transmission de données sur Ethernet. Ce qu'il faut retenir de la notion de MTU, c'est qu'elle donne la taille maximale du paquet IP pouvant être transmis par un hôte sur le lien sur lequel il est raccordée.

Figure 1 : Les encapsulations.

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 taille de la MTU sur la route entre deux hôtes. Littéralement, la PMTU c'est l'unité de transmission maximum sur le chemin elle indique la taille maximale du paquet pour arriver à l'hôte de destination sans jamais excéder le MTU de chaque lien traversé. Ainsi un paquet émis à la taille PMTU de sa route n'aura pas un problème d'acheminement lié à une impossibilité d'encapsuler ce paquet dans une trame quelque part sur sa route.

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.

Découverte de la PMTU

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 système de transmission à utiliser en sortie. Autrement dit lorsque le paquet à transmettre est plus grand que la taille de la MTU offerte par le système de transmission. Comme le routeur en IPv6 n'est pas habilité à faire la fragmentation, le routeur est alors dans l'incapacité de traiter correctement le paquet. Le routeur supprime le paquet et signale l'émetteur du paquet par un message de signalisation. Ce message repose sur le protocole ICMPv6 et sera décrit dans la séquence 3. L'objectif du message est d'informer du problème d'acheminement mais aussi d'indiquer la taille maximale à retenir pour que les paquets soient acheminés correctement. Cette procédure de découverte de la PMTU est spécifié dans le RFC 8201.

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 la taille de paquet (cf. Figure 3). Cette valeur est la PMTU pour tous les prochains paquets vers cette même destination. Pour ce qui concerne les données perdues avec le paquet trop grand supprimé par le routeur, c'est du ressort de la couche de transport comme TCP de gérer la fiabilité de la communication en retransmettant si nécessaire ou de l'application de s'adapter à la perte.

Plusieurs itérations peuvent être nécessaires avant d'obtenir la PMTU notamment si d'autres systèmes de transmission imposent des MTU 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. En tout état de cause, le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de 1 280 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU.

L'exploitation de l'information de PMTU se fait de plusieurs façons suivant la couche en charge de la fragmentation des données. Si un protocole de type TCP est utilisé, celui-ci assurera la segmentation des données de façon transparente pour les applications, en fonction des informations de PMTU que pourra lui communiquer la couche IPv6. Si un protocole de type UDP est utilisé, alors cette fragmentation devra être assurée par une couche supérieure, éventuellement par l'application elle-même. SI l'application n'est pas en mesure d'assurer cette fragmentation. Alors il revient à la couche IPv6 de faire cette fragmentation. C'est ce que nous allons voir dans la section suivante.

Dans le cas de TCP, le terme approprié est segmentation. Car  l'unité de protocole de TCP se nomme segment. Ainsi la fragmentation forme des fragmente et donc la segmentation des segments!

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.

Fragmentation IPv6

Il existe des cas où les données passées à la couche de réseau ne sont pas adaptés à la PMTU. 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 système de transmission.

La couche de réseau de l'hôte va alors adapter la taille du paquet pour son transfert. Elle va procéder à une fragmentation du paquet. Le principe de la fragmentation est de découper le paquet IPv6 en fragments pour constituer des 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. La figure 4 illustre ce principe. Le paquet IPv6 original est découpé en fragment. Le premier fragment avec l'en-tête IPv6 est complété par l'extension de fragmentation. Les fragments suivant reprennent l'en-tête du paquet original et sont complétés avec l'extension de fragmentation. L'hôte destinataire se charge alors de rassembler les fragments et de reconstituer le paquet IP original pour le traiter comme si il avait été transféré sans fragmentation.

Figure 4 : Principe de la fragmentation en IPv6.

Lorsqu'il y a une fragmentation se pose alors les problèmes de l'identification d'un fragment et de la position relative du fragment. L'identification du fragment vise à répondre à la question que peut se poser la destination : à quel paquet appartient-il  ? Ce sont ce genre d'informations qui seront mises dans l'extension de fragmentation de l'en-tête IPv6. Cette extension est identifiée par le code d'en-tête 44. Le format de l'extension de fragmentation est présenté par la Figure 5. Elle comporte trois champs de contrôle:

• Le champ Fragment offset indique, lors du réassemblage, où placer le fragment dans le datagramme initiale. Ce champ est sur 13 bits. L'unité de comptage est 8 octets. Aussi la taille de tous les fragments, sauf le dernier, doit être multiple de 8 octets.
• Le bit M (More Fragments) vaut 1, lorsqu'il indique qu'il y aura d'autres fragments. Seul le dernier fragment aura ce bit à zéro.
• Le champ identification est utilisé pour identifier tous les fragments d'un même paquet initial. La valeur est différente pour chaque paquet et elle est recopiée dans chacun des fragments d'un paquet.

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, avec la découverte de la PMTU, les routeurs intermédiaires n'ont plus besoin de fragmenter les paquets. Si la fragmentation est toujours nécessaire, elle est réservée aux hôtes.

Figure 5 : Format de l'extension de fragmentation.

D'un point de vue opérationnel, la fragmentation en IPv6 et plus généralement l'ajout d'une extension d'en-tête fragilise le transfert du paquet dans l'Internet. Le risque qu'il n'arrive pas à destination est augmenté. C'est ce que rapporte en substance le RFC 7872. Ce dernier essaie de quantifier l'ampleur exacte du problème. Trop de noeuds intermédiaires ne respectent pas le principe de bout en bout et les paquets inhabituels sont supprimés en cours de route. Devant un tel paquet, ces noeuds se permettent de supprimer le paquet. Cela peut être le résultat d'une politique délibérée (pare-feu appliquant le principe « dans le doute, on jette ») ou bien, souvent, de mises en oeuvre incomplète de spécifications décrites dans les RFC.

La procédure de découverte de la PMTU et la fragmentation IPv6 ont des effets de bord indésirable. Le RFC 6946 présente les risques associés au fragment atomique. Le fragment atomique est un paquet IPv6 avec un en-tête de fragmentation sans être fragmenté du tout. Il n'a aucun intérêt pratique mais est engendré par certains systèmes lorsqu'ils reçoivent un message ICMP Packet too big indiquant une MTU inférieure à 1280 octets (la taille miminale pour une MTU IPv6). Le problème est que les fragments atomiques sont ensuite traités par bien des systèmes comme des vrais fragments, permettant ainsi certaines attaques subtiles. Le RFC 8021 estime qu'ils ne servent à rien et sont dangereux. Ce RFC demande d'abandonner la génération et le traitement des fragments atomiques. Pour cela, les hôtes doivent désormais ignorer les messages ICMP Packet Too Big lorsqu'ils indiquent une MTU inférieure à 1 280 octets.

Jumbogrammes

Pour être complet sur la taille des paquets, il faut rappeler que IPv6 offre la notion de "jumbogramme" pour des paquets ayant une charge utile jusqu'à 4 Gio. Ceci est possible avec un champ Payload Length codé sur 32 bits comme nous l'avons déjà indiqué dans l'activité "Le format de l’en-tête IPv6". Le jumbogramme est essentiellement prévu pour la transfert à haut débit entre deux noeuds.

La mise en oeuvre d'un jumbogramme demande des modifications dans la mise en oeuvre de la couche de transport. Par exemple, le protocole UDP utilise un champ de longueur de 16 bits pour le codage de la longueur totale du message UDP. On voit bien qu'il va falloir faire des adaptations car la longueur maximum d'un message UDP n'est pas du même ordre de grandeur que celle du jumbogrammme. Ces adaptations sont détaillées dans le RFC 2675. Si les "jumbogrammes" sont intéressants sur des liens qui disposent d'une MTU supérieure à 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), il n'y a pas à ce jour de système de transmission utilisant des trames aussi importante.

Conclusion

Cette activité vous a présenté les différents éléments qui vont servir à définir la taille du paquet IPv6 à utiliser. Tout d'abord IPv6 impose que tous les systèmes de transmission utilisés transfère un paquet jusqu'à 1280 octets sans qu'il soit besoin de le fragmenter au niveau d'IP. C'est la taille maximum d'un paquet pour être transféré sans fragmentation et sans problème lié à la taille. Au delà ce cette taille, il y a des risques de problème. Dans ce cas la taille du paquet à transférer est conditionnée à la taille indiquée par la 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ées est nécessaire au niveau de la couche transport, soit la fragmentation par l'hôte est obligatoire. Dans l'article en ligne^[2], 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^[3] du fait que certains noeuds jettent les fragments de paquet IPv6. Nous reviendrons sur le problème de la taille de la PMTU lors de la séquence suivante.

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^[4].

Références bibliographiques

1. ↑ Huston, G. (2016), January. Blog of AFNIC. Evaluating IPv4 and IPv6 packet fragmentation.
2. ↑ Bortzmeyer, S. (2010) Fragmentation IPv6 : se résigner à couper à 1280 octets ?
3. ↑ Huston, G. (2018) The Internet Protocol Journal. Vol 21. N° 1. IPv6 and Packet Fragmentation
4. ↑ Huston, G. (2016), May. Fragmenting IPv6.

Pour aller plus loin

Vous pouvez approfondir vos connaissances en consultant les liens suivants :

• RFC 2675 : IPv6 Jumbograms
• 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 8021: Generation of IPv6 Atomic Fragments Considered Harmful (Analyse par S.Bortzmeyer)
• RFC 8201 : Path MTU Discovery for IP version 6 (Analyse par S.Bortzmeyer)