Difference between revisions of "MOOC:Verb21"
From Livre IPv6
| (19 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | __NOTOC__ | ||
| + | <!--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 | ||
| + | A21.9_WireShark_IPv6.mp4 => https://drive.google.com/file/d/1teYsVtaYIyxZYPwQ2lAIlgiuGEPXqPDF/view?usp=sharing | ||
| + | --> | ||
| + | =Activité 21: L'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. | |
| − | ==Version== | + | 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. | Commençons par les premiers champs. | ||
| Line 19: | Line 29: | ||
Evident. Facile à retenir. | 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 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. | ||
| Line 25: | Line 36: | ||
Puis sur 2 bits nous trouvons l'ECN, "Explicit Congestion Notification". | Puis sur 2 bits nous trouvons l'ECN, "Explicit Congestion Notification". | ||
| − | + | == Flow Label == | |
Vient ensuite le codage des 20 bits du champ "Flow Label". | Vient ensuite le codage des 20 bits du champ "Flow Label". | ||
| Line 31: | Line 42: | ||
Ce champ est conçu pour accélérer le traitement de la QoS. | Ce champ est conçu pour accélérer le traitement de la QoS. | ||
| − | En effet, 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. | + | 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, la source choisira une valeur aléatoire de Flow Label afin de faciliter et de soulager le traitement des routeurs intermédiaires. | + | 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 identifié, le traitement est optimisé, le routeur n'ayant plus à consulter cinq champs pour déterminer l'appartenance d'un paquet. | + | 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. | Passons à la deuxième ligne. | ||
| Line 53: | Line 64: | ||
Dans ce cas, la taille de la charge utile peut être portée à 4 Go. | Dans ce cas, la taille de la charge utile peut être portée à 4 Go. | ||
| − | À condition, évidemment, de disposer au niveau inférieur | + | À 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. | Ce champ identifie le prochain en-tête de protocole porté par ce paquet. | ||
| Line 63: | Line 74: | ||
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. | 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". | Voici le codage sur 8 bits du champ "Hop Limit". | ||
| Line 81: | Line 92: | ||
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. | 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. | Enfin, voici les champs "adresse" sur 128 bits. | ||
| Line 87: | Line 98: | ||
16 octets pour l'adresse IP source, 16 octets pour l'adresse IP destination. | 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 | + | 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'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. | Enfin, voyons le décodage détaillé d'un premier paquet IPv6 par le fameux outil Wireshark. | ||
| Line 101: | Line 112: | ||
Voyons le codage détaillé des champs. | Voyons le codage détaillé des champs. | ||
| − | Version : 6 | + | Version : 6 = IPv6. |
| − | + | ||
| − | IPv6. | + | |
Traffic Class : 00. | Traffic Class : 00. | ||
| − | |||
Donc, c'est un paquet qui ne bénéficiera pas d'un traitement de QoS. | Donc, c'est un paquet qui ne bénéficiera pas d'un traitement de QoS. | ||
| − | |||
C'est la classe "Best effort". | C'est la classe "Best effort". | ||
ECN-Capable Transport : 00. | ECN-Capable Transport : 00. | ||
| − | |||
Donc, pas d'aide à la résolution de congestion. | Donc, pas d'aide à la résolution de congestion. | ||
Flow Label : 00. | Flow Label : 00. | ||
| − | |||
Donc, pas de prise en charge d'aide à la QoS. | Donc, pas de prise en charge d'aide à la QoS. | ||
| Line 124: | Line 129: | ||
Hop Limit : 63. | Hop Limit : 63. | ||
| − | |||
Donc, ce paquet a probablement déjà traversé un routeur. | Donc, ce paquet a probablement déjà traversé un routeur. | ||
| Line 133: | Line 137: | ||
Au niveau supérieur, nous voyons le décodage de l'en-tête ESP. | 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. | Nous venons donc de parcourir le décodage détaillé du protocole IPv6. | ||
| Line 141: | Line 145: | ||
Les traitements particuliers optionnels seront traités grâce à des extensions. | 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. | + | 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: DSCP == | ||
| + | |||
| + | -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. | ||
| + | |||
| + | == Traffic Class: ECN == | ||
| + | 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é. | ||
| + | |||
| + | == Contrôle de congestion == | ||
| + | |||
| + | 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. | ||
| + | --> | ||
Latest revision as of 16:43, 28 February 2022
Activité 21: L'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 .
