Difference between revisions of "MOOC:Verb24"
From Livre IPv6
(→"Principe des extensions") |
|||
| (8 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | = | + | __NOTOC__ |
| + | <!--Storyboard sur Googledoc => https://docs.google.com/presentation/d/1MkwcFJrJKljPFW93u2oAyeZQDdBsana0/edit?usp=sharing&ouid=106484440432771135779&rtpof=true&sd=true | ||
| − | + | Verbatim sur Googledoc => https://drive.google.com/file/d/1N9n5X3TasqE3E_66fO25F-LeCZCTuZoZ/view?usp=sharing | |
| + | --> | ||
| + | = Activité 24 : La taille des paquets IPv6 = | ||
| − | + | Dans cette quatrième activité : | |
| + | Nous allons passer en revue les mécanismes d’adaptation à la taille des paquets IPv6. | ||
| − | + | Mais comment faire pour adapter la taille des paquets aux réseaux de transport intermédiaires ? | |
| + | Comme pour le courrier postal, nous devons respecter un format pour que les enveloppes puissent glisser dans la fente des boites aux lettres !!! | ||
| − | + | == Path Maximum Transmission Unit: == | |
| − | + | La taille des paquets IPv6 est conditionnée par le type de liaison mis à disposition au niveau 2 | |
| − | + | Les paquets sont placés dans des trames avant d’être émis sur le support physique | |
| + | Selon la nature de la liaison, une taille maximale de trame est définie: 1500 octets pour Ethernet, 1468 octets pour PPPoA, de 1500 à 65535 octets pour MPLS, 81 octets pour 6LoWPAN etc... | ||
| − | + | La couche réseau prends en compte cette contrainte en limitant la taille maximale de données pouvant être placées dans un paquet, | |
| + | Cette taille est appelée MTU : Maximum Transmission Unit | ||
| − | + | == Path Maximum Transmission Unit: == | |
| + | Un paquet IP peut cependant être amené à voyager sur plusieurs supports de natures différentes, chacun imposant ses tailles maximales. | ||
| − | + | Pour pouvoir parcourir sans encombres son chemin jusqu'à sa destination, le paquet doit donc avoir une taille inférieure ou égale à la plus petite taille maximum autorisée par l'ensemble des liens traversés. | |
| + | 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 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 entêtes par rapport aux données transportées, ainsi que d'augmenter le nombre de paquet à traiter dans les routeurs. | ||
| + | Au moment de créer des paquets, la couche réseau essaie donc de respecter au maximum la PMTU. | ||
| + | Cependant la valeur de la PMTU n'est pas forcément connue à l'envoi d'un premier paquet vers une destination quelconque. | ||
| − | + | == Path Maximum Transmission Unit: == | |
| − | + | Nous observons ici : | |
| + | que l'émetteur du paquet fait alors la supposition que la MTU vers cette destination est égale à celle 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 reçu et la taille maximale qu’il est autorisé à retransmettre. | ||
| − | + | Si le routeur est dans l'incapacité de transmettre le paquet, il utilise alors un message de signalisation ICMPv6 pour informer l'émetteur du paquet du problème d'acheminement, ainsi que de la taille recommandée pour que les paquets puissent être retransmis. | |
| + | L’émetteur reprends la transmission en utilisant le nouveau MTU recommandé, | ||
| + | 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 maximale 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 encombre. | ||
| + | Ce mécanisme de découverte de la taille maximale de transmission sur le chemin est spécifié dans le RFC 1981. | ||
| + | |||
| + | == Fragmentation == | ||
| + | |||
| + | La fragmentation est utile dans les cas où la couche réseau ne peut pas adapter la MTU des données à transmettre, | ||
| + | C'est le cas par exemple des segments 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. | ||
| − | Le | + | La couche réseau n'a alors d'autres choix que de fragmenter ces données. |
| + | Le principe est de séparer un paquet devant être émis avec une taille trop importante en plusieurs paquets respectant la taille maximale autorisée. | ||
| + | Ces fragments sont émis et acheminés vers la destination comme n'importe quel autre paquet | ||
| + | La couche réseau du destinataire se charge alors de réassembler le paquet IP original pour que les données puissent être traitées. | ||
| − | + | == Extension de Fragmentation: == | |
| + | |||
| + | L'identification d'un fragment est transmise dans une extension de fragmentation de l'entête IPv6. | ||
| + | On retrouve l'indication "Fragment" dans le champ Next Header , | ||
| + | Le champ Fragment offset indique la place du fragment, ce qui sera utile lors du réassemblage. | ||
| + | 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 un multiple de 8 octets. | ||
| − | + | Le bit M à la valeur 1 indique qu'il y aura d'autres fragments à suivre. | |
| − | + | Enfin le champ identification permet de repérer les fragments appartenant à un même paquet initial. | |
| + | Il est différent pour chaque paquet original et recopié dans ses fragments. | ||
| − | + | == Mécanisme de Fragmentation: == | |
| − | + | Notons que le datagramme original est découpé en autant de fragments que nécessaire, | |
| + | Chaque fragment intermédiaire avec le bit M=1 dispose de son encapsulation propre | ||
| + | On retrouve dans le premier fragment l’entête transport et les premières données du segment, | ||
| + | Dans les fragments suivant la suite des données fragmentées, | ||
| + | Et enfin dans le dernier fragment repérable avec le bit M=0 , les dernières données utiles | ||
| − | |||
| − | + | == Extension Jumbogramme == | |
| + | |||
| + | L'identification d'un super-paquet est transmise dans une extension jumbogramme de l'entête IPv6. | ||
| + | le champ Next Header à la valeur 194 correspond au Jumbogramme | ||
| + | La taille admissible va jusqu'à 4 Gigaoctets, c'est vraiment énorme ! | ||
| + | reste qu'une telle taille de paquet n'est pas possible sans une MTU de niveau 2 adaptée, | ||
| + | mais sachant que les volumes de données croissent constamment, à l'avenir nous en aurons bien besoin ! | ||
| − | |||
| − | == | + | == Conclusion == |
| + | |||
| + | Nous venons de passer en revue les mécanismes d’adaptation à la taille des paquets IPv6. | ||
| + | L'intérêt majeur est de permettre la traversée sans encombres de réseaux indépendants, de s'y adapter si la fragmentation est nécessaire, | ||
| + | cependant cela augmente l'encapsulation et donc diminue d'autant l'efficacité, car toute la chaine de communication subie cette fragmentation. | ||
| − | + | La notion de jumbogramme IPv6 réponds aux besoins d'efficacité pour le transport de volumes importants de données, | |
| − | + | on en rencontre déjà dans les environnements Datacenter, réseau de stockage, réplication d'infrastructures de virtualisation, Big Data... | |
| − | + | ||
| − | + | Yes but ! | |
| − | + | si IPv6 est déjà prêt au niveau 3, les couches de protocoles de niveau 2 doivent encore évoluer ! | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 16:41, 28 February 2022
Activité 24 : La taille des paquets IPv6
Dans cette quatrième activité : Nous allons passer en revue les mécanismes d’adaptation à la taille des paquets IPv6.
Mais comment faire pour adapter la taille des paquets aux réseaux de transport intermédiaires ? Comme pour le courrier postal, nous devons respecter un format pour que les enveloppes puissent glisser dans la fente des boites aux lettres !!!
Path Maximum Transmission Unit:
La taille des paquets IPv6 est conditionnée par le type de liaison mis à disposition au niveau 2
Les paquets sont placés dans des trames avant d’être émis sur le support physique Selon la nature de la liaison, une taille maximale de trame est définie: 1500 octets pour Ethernet, 1468 octets pour PPPoA, de 1500 à 65535 octets pour MPLS, 81 octets pour 6LoWPAN etc...
La couche réseau prends en compte cette contrainte en limitant la taille maximale de données pouvant être placées dans un paquet, Cette taille est appelée MTU : Maximum Transmission Unit
Path Maximum Transmission Unit:
Un paquet IP peut cependant être amené à voyager sur plusieurs supports de natures différentes, chacun imposant ses tailles maximales.
Pour pouvoir parcourir sans encombres son chemin jusqu'à sa destination, le paquet doit donc avoir une taille inférieure ou égale à la plus petite taille maximum autorisée par l'ensemble des liens traversés. 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 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 entêtes par rapport aux données transportées, ainsi que d'augmenter le nombre de paquet à traiter dans les routeurs. Au moment de créer des paquets, la couche réseau essaie donc de respecter au maximum la PMTU. Cependant la valeur de la PMTU n'est pas forcément connue à l'envoi d'un premier paquet vers une destination quelconque.
Path Maximum Transmission Unit:
Nous observons ici : que l'émetteur du paquet fait alors la supposition que la MTU vers cette destination est égale à celle 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 reçu et la taille maximale qu’il est autorisé à retransmettre.
Si le routeur est dans l'incapacité de transmettre le paquet, il utilise alors un message de signalisation ICMPv6 pour informer l'émetteur du paquet du problème d'acheminement, ainsi que de la taille recommandée pour que les paquets puissent être retransmis. L’émetteur reprends la transmission en utilisant le nouveau MTU recommandé, 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 maximale 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 encombre. Ce mécanisme de découverte de la taille maximale de transmission sur le chemin est spécifié dans le RFC 1981.
Fragmentation
La fragmentation est utile dans les cas où la couche réseau ne peut pas adapter la MTU des données à transmettre, C'est le cas par exemple des segments 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 est de séparer un paquet devant être émis avec une taille trop importante en plusieurs paquets respectant la taille maximale autorisée. Ces fragments sont émis et acheminés vers la destination comme n'importe quel autre paquet La couche réseau du destinataire se charge alors de réassembler le paquet IP original pour que les données puissent être traitées.
Extension de Fragmentation:
L'identification d'un fragment est transmise dans une extension de fragmentation de l'entête IPv6. On retrouve l'indication "Fragment" dans le champ Next Header , Le champ Fragment offset indique la place du fragment, ce qui sera utile lors du réassemblage. 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 un multiple de 8 octets.
Le bit M à la valeur 1 indique qu'il y aura d'autres fragments à suivre.
Enfin le champ identification permet de repérer les fragments appartenant à un même paquet initial. Il est différent pour chaque paquet original et recopié dans ses fragments.
Mécanisme de Fragmentation:
Notons que le datagramme original est découpé en autant de fragments que nécessaire, Chaque fragment intermédiaire avec le bit M=1 dispose de son encapsulation propre On retrouve dans le premier fragment l’entête transport et les premières données du segment, Dans les fragments suivant la suite des données fragmentées, Et enfin dans le dernier fragment repérable avec le bit M=0 , les dernières données utiles
Extension Jumbogramme
L'identification d'un super-paquet est transmise dans une extension jumbogramme de l'entête IPv6. le champ Next Header à la valeur 194 correspond au Jumbogramme La taille admissible va jusqu'à 4 Gigaoctets, c'est vraiment énorme ! reste qu'une telle taille de paquet n'est pas possible sans une MTU de niveau 2 adaptée, mais sachant que les volumes de données croissent constamment, à l'avenir nous en aurons bien besoin !
Conclusion
Nous venons de passer en revue les mécanismes d’adaptation à la taille des paquets IPv6. L'intérêt majeur est de permettre la traversée sans encombres de réseaux indépendants, de s'y adapter si la fragmentation est nécessaire, cependant cela augmente l'encapsulation et donc diminue d'autant l'efficacité, car toute la chaine de communication subie cette fragmentation.
La notion de jumbogramme IPv6 réponds aux besoins d'efficacité pour le transport de volumes importants de données, on en rencontre déjà dans les environnements Datacenter, réseau de stockage, réplication d'infrastructures de virtualisation, Big Data...
Yes but ! si IPv6 est déjà prêt au niveau 3, les couches de protocoles de niveau 2 doivent encore évoluer !
