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

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.

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 retransmission ou de l'application de s'adapter à la perte.

Cette procédure peut être répétée 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. Ce mécanisme de découverte de la PMTU 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.

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 va alors adapter la taille des paquets pour leur transfert Elle va procéder à une fragmentation des données. Le principe de la fragmentation est de découper les données reçu de la couche de transport, en blocs 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 (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.

The IPv6 packet header has a 16 bit unsigned Payload Length field, indicating the length of the packet, less the 40 byte IPv6 packet header. This allows for a maximum "normal" IPv6 packet size of 65575 octets. IPv6 may include a jumbogram header that permits larger packets of up to 4G bytes in size, although router support for such large packets is optional.

All IPv6 hosts and routers must pass packets up to 1280 octets in length.

Fragmentation of a IPv6 packet may only be performed at the source point of the packet. No further fragmentation, nor any form of fragment reassembly, is attempted by any intermediate device. Once fragmented at the source, an IPv6 packet is reassembled only at the point of the final destination, as per the IPv6 packet's destination address.

As with IPv4, IPv6 uses three control fields, the Packet Identification, More Fragments Flag, and Fragment Offset fields. These fields are formatted into an 8-byte IPv6 Fragmentation Header, referenced using the IPv6 Next Header code of 44.

When a host fragments an IPv6 packet is adds a Fragmentation Header to the IPv6 packet. The header has three control fields: Identification, More Fragments, and Fragmentation Offset:

Identification: A 32-bit value used to identify all the fragments of a packet, allowing the destination host to perform packet reassembly.

More Fragments Flag: When a packet is fragmented, all packets except the final fragment have the More Fragments flag set. The fragmentation algorithm operates such that only the final fragment of the original IP packet has this field clear (set to zero).

Fragmentation Offset Value: This 13-bit value counts the offset of the start of this payload fragment from the start of the orignoinal packet. The unit used by this counter is octa-bytes, implying that fragmentation must align to 64-bit boundaries.

The fields altered by fragmentation are shown in the figure above, where a 1500-byte IP packet has been fragmented into a 1280-byte packet and one 316-byte packet. The IP packet length has been altered to reflect the fragment size, and the Fragmentation Offset Value field has been set to 154 respectively. The final fragment has the More Fragments Flag cleared to show that it is the final fragment of the original packet.

IPv6 defines an explicit ordering of IPv6 packet headers:

IPv6 packet header Hop-by-Hop Options header Destination Options headers (intermediate destinations) Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header (final destination) upper-layer header The first four header types form the "unfragmentable part" of the packet, and are reproduced in the headers of every fragment packet, while the final four header types are treated by the IPv6 fragmentation algorithm as a part of the payload, and are not reproduced in every fragment's header.

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)