Revision as of 16:25, 22 September 2021

Storyboard sur Googledoc => https://docs.google.com/presentation/d/1L5lRwha8U8cAQM4SxarfgVUjrKshMzOa/edit?usp=sharing&ouid=106484440432771135779&rtpof=true&sd=true

Verbatim sur Googledoc => https://drive.google.com/file/d/1Mu8r0JcbLVlI8cyVfVXz0x1pMlI3lJI2/view?usp=sharing

Script 21: En-tête IPv6

-Dans cette deuxième séquence du MOOC "IPv6", nous aborderons les différents aspects du protocole IPv6.

Mais pourquoi comprendre IP est si important pour nous?

IP c'est un des protocoles les plus importants d'Internet car il permet de découper l'information à transmettre en paquets, de les adresser et de les transporter indépendamment les uns des autres, enfin à l'arrivée on peut recomposer le message original, ces paquets de données sont appelés datagrammes.

Un paquet de données et composé d'un entête et de données Dans cette activité, nous allons nous focalisez sur le format de l'en-tête des paquets IPv6.

Version

Commençons par les premiers champs.

Chaque ligne représentée sur ce schéma représente 32 bits de codage.

Le premier champ de l'en-tête IPv6, codé sur 4 bits, représente la version du protocole : 6 pour IPv6.

Evident. Facile à retenir.

Traffic Class - DSCP

Le deuxième champ, codé sur 8 bits, représente la classe de trafic et sert à contrôler la qualité de service. Ce champ est décomposé en deux blocs.

Le premier, codé sur 6 bits, le DSCP, "Differentiated Services Code Point".

Puis sur 2 bits nous trouvons l'ECN, "Explicit Congestion Notification".

Flow Label

Vient ensuite le codage des 20 bits du champ "Flow Label".

Ce champ est conçu pour accélérer le traitement de la QoS.

En effet, traditionnellement le traitement de la qualité de service nécessite la reconnaissance de plusieurs champs disséminés dans les en-têtes IP et transport, comme adresse source et destination, protocole de transport, numéro de port, origine, destination.

Pour une suite de paquets IPv6, la source choisira une valeur aléatoire de Flow Label afin de faciliter et de soulager le traitement des routeurs intermédiaires.

Pour la gestion de ce flux IPv6 identifié, le traitement est optimisé, le routeur n'ayant plus à consulter cinq champs pour déterminer l'appartenance d'un paquet.

Payload Length

Passons à la deuxième ligne.

Voici le codage sur 16 bits du champ "Payload Length".

Ce champ indique la longueur de la charge utile du paquet, jusqu'à 65 535 octets.

En IPv6, on ne prend pas en compte la longueur de l'en-tête.

Pour des tailles de paquets supérieures à 64 ko, le codage du champ sera mis à zéro.

Et l'option jumbogramme de l'extension de proche en proche pourra être utilisée.

Dans ce cas, la taille de la charge utile peut être portée à 4 Go.

À condition, évidemment, de disposer au niveau inférieur d'une taille maximum de trame adaptée.

Next Header

Vient ensuite le codage des 8 bits du champ "Next Header".

Ce champ identifie le prochain en-tête de protocole porté par ce paquet.

Classiquement, on retrouve les flux ICMPv6 ou les flux utilisant des couches transport TCP, UDP, d'autres cas particuliers de tunnels IPv4 ou IPv6, voire des en-têtes sécurisés et des mécanismes d'extension que l'on détaillera plus tard.

Hop Limit

Voici le codage sur 8 bits du champ "Hop Limit".

Certaines implémentations prennent actuellement la valeur conseillée pour IPv6 : 64. La valeur par défaut peut être dynamiquement attribuée aux équipements par les annonces des routeurs.

On peut donc la modifier en fonction de l'évolution de la topologie du réseau.

Comme il s'agit d'un nombre de sauts, lors de la traversée d'un routeur, la décrémentation est toujours de 1.

Dans cette animation, nous voyons que les paquets issus de A disposent d'une valeur Hop Limit de 64 au départ.

Cette valeur est décrémentée lors de la traversée de chaque routeur intermédiaire.

Si un paquet atteint un routeur avec une valeur Hop Limit à 1, ce routeur le détruit.

Et il va renvoyer à la source un message ICMPv6 de type 3, "Time Exceeded", ce qui permet d'identifier un problème de routage pour cette destination.

IP Address

Enfin, voici les champs "adresse" sur 128 bits.

16 octets pour l'adresse IP source, 16 octets pour l'adresse IP destination.

Moralité : les champs "adresse" occupent 32 octets sur les 40 octets minimum nécessaires à un en-tête IPv6.

D'autres mécanismes, comme les extensions, viendront éventuellement gonfler l'encapsulation. On en reparlera.

Décodage

Enfin, voyons le décodage détaillé d'un premier paquet IPv6 par le fameux outil Wireshark.

L'affichage est décomposé en trois zones résumées, détaillées, et en codage hexadécimal ASCII.

Nous voyons ici que l'analyseur a bien détecté une trame Ethernet transportant le protocole IPv6 grâce au champ "EtherType" 0x86DD.

Voyons le codage détaillé des champs.

Version : 6 = IPv6.

Traffic Class : 00. Donc, c'est un paquet qui ne bénéficiera pas d'un traitement de QoS. C'est la classe "Best effort".

ECN-Capable Transport : 00. Donc, pas d'aide à la résolution de congestion.

Flow Label : 00. Donc, pas de prise en charge d'aide à la QoS.

Taille de la charge utile : 8 octets.

Next Header : en-tête ESP.

Hop Limit : 63. Donc, ce paquet a probablement déjà traversé un routeur.

Vient ensuite l'adresse source sur 16 octets.

Adresse destination, sur 16 octets.

Au niveau supérieur, nous voyons le décodage de l'en-tête ESP.

Conclusion

Nous venons donc de parcourir le décodage détaillé du protocole IPv6.

Observons que dans ce standard, les efforts ont porté sur la nécessité d'optimiser le traitement des paquets lors de la traversée des réseaux et du transport.

Les traitements particuliers optionnels seront traités grâce à des extensions.

Contrairement à IPv4, il n'y a pas de calcul de CRC au niveau 3, la fiabilité étant dorénavant assurée par la couche de protocole de niveau 2 .

== en option ? ==

Traffic Class

-Le codage des 6 bits du champ DSCP est très particulier.

Nous remarquons que 2 puissance 6, soit 32 possibilités, ne sont pas toutes exploitées.

Le codage des 3 bits de poids fort a repris pour un besoin de compatibilité ascendante le codage IP Precedence, exploité dans les premières mises en oeuvre d'IPv4.

Nous découvrons, en haut du tableau, les codages avec priorité stricte : Expedited Forwarding, EF, et Voice Admit.

Ces codages serviront à protéger la qualité des flux temps réel : voix, vidéo.

Nous disposons ensuite d'une grande souplesse pour classifier finement d'autres catégories.

AF, Assured Forwarding : quatre classes sont définies de 1 à 4.

À l'intérieur de chacune de ces quatre classes, une priorité est spécifiée.

Par exemple, sur la classe AF numéro 1, on va disposer de trois niveaux de priorité : AF11, AF12, AF13.

Plus le chiffre est élevé, plus la priorité du flux est faible.

Donc, si on imagine une saturation des files d'attente de la classe de trafic AF1, les paquets marqués AF13 seront écartés avant AF12, puis avant AF11.

Idem pour une autre classe de service comme l'AF4, par exemple.

Vient ensuite le codage des 2 bits du champ ECN.

ECN comme "Explicit Congestion Notification".

Quatre valeurs sont définies.

Les trois premières indiquent si l'équipement est capable ou pas de gérer la congestion, ECN-Capable Transport.

C'est-à-dire qu'il faut s'appuyer sur une couche TCP pour réguler le trafic.

Et nous avons le codage, CE, Congestion Experience, qui indique que les paquets ont traversé un équipement saturé.

Dans cette animation, nous voyons que le trafic entre A et B traverse trois routeurs intermédiaires.

Tant que le trafic est fluide, les équipements réseau supportent la charge qui est imposée.

Puis le routeur central subit une saturation, les paquets s'accumulent dans les files d'attente, le routeur indique la saturation en marquant "CE" dans les quelques paquets qui peuvent encore être transmis, le mécanisme de régulation se met en oeuvre en B grâce à sa couche de transport TCP.

Les accusés de réception que B renvoie vers A disposeront du marquage du champ ECE, ECN Echo.

Ce champ est disponible dans TCP.

Une fois que la source A interprète cette indication de congestion, elle l'indique en marquant à son tour le bit CWR, "Congestion Window Reduced".

Une fois que A réduit donc sa fenêtre d'anticipation, on doit constater que cette réduction de flux soulage le routeur saturé préalablement. De fait, ce mécanisme permet au routeur d'évacuer ses files d'attentes, puis de reprendre une activité normale.