Revision as of 20:27, 8 April 2016

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 placé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.

Cas nominal (taille paquet < 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 placés dans des trames sur le support physique (cf. Figure 1). Ce support, selon sa nature, définit une taille maximale de 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 grande 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é de transfert de taille maximale 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.

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 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 transmettre le paquet. Dans le cas d'un paquet IPv6, le routeur utilise alors un message de signalisation (basé sur ICMPv6, qui sera décrit dans la séquence 3) pour informer l'émetteur du paquet du problème d'acheminement, ainsi que de la taille recommandée pour que les paquets soient retransmis.

Figure 3 : Négociation Path MTU Discovery

La couche réseau de l'émetteur doit alors, à la réception de ce message, émettre de nouveau les données, mais dans un paquet ayant pour taille celle recommandée dans le message (cf. Figure 3). Cette valeur est alors enregistrée comme la PMTU pour tous les prochains paquets vers cette même destination. 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.

Cas où taille paquet > 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 fichier NFS. Ces messages peuvent avoir une taille supérieure à celle autorisée sur le support.

La couche réseau n'a alors d'autres 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 ? Quel 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 GB moins un (2^32 − 1 = 4294967295 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'un 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.

Références bibliographiques

Vous pouvez approfondir vos connaissances en consultant les liens suivants :

• RFC 1981 : Path MTU Discovery for IP version 6
• RFC 2460 : IP version 6, Section 4.5 Fragment header
• RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks