Revision as of 10:42, 23 April 2019

Activité 21: Le format de l’en-tête IPv6

Introduction

Comme rappelé en introduction de la séquence, la fonction principale du protocole IP est d'acheminer un paquet d'un point à un autre de l'Internet. Un paquet se définit comme une unité de transfert dans un réseau composé d'un bloc de données de taille variable mais limitée et identifié par un en-tête. Le mode d'acheminement par datagramme impose que chaque paquet soit traité indépendamment, sans avoir besoin d'informations issues d'autres paquets déjà transmis. L'en-tête IP doit donc comporter toutes les informations pour réaliser cet acheminement. C'est la raison pour laquelle chaque paquet doit contenir l'adresse globale du noeud émetteur ainsi que celle du noeud destinataire du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.

L'adresse du destinataire est fondamentale pour les noeuds intermédiaires réalisant la fonction de relayage. C'est en effet à partir de cette adresse que le noeud décide vers quelle interface le paquet doit sortir. La lecture de l'adresse du destinataire dans l'en-tête IP est donc une étape cruciale pour la performance globale de l'acheminement du paquet. Afin d'accélérer cette étape, deux principes ont été appliqués dans la spécification de l'en-tête IP :

• Une adresse IP est de taille fixe, permettant ainsi d'être récupérée dans l'en-tête directement en lisant un nombre de bits prédéterminé, sans avoir à lire ni interpréter au préalable un champ de longueur d'adresse ;
• L'adresse IP destination est à un emplacement fixe dans l'en-tête, emplacement aligné en mémoire, facilitant ainsi son extraction de l'en-tête par un simple décalage en mémoire, qui est une opération simple au niveau matériel.

Format de l'en-tête du datagramme IPv6

Le format d'en-tête du datagramme IPv6 est spécifié par le RFC 8200 (page 5). Cet en-tête, avec les champs le composant, est représenté par la figure 1. L'en-tête IPv6 est de taille fixe et se compose de 5 mots de 64 bits (contre 5 mots de 32 bits pour IPv4). La taille de l'en-tête IPv6 est donc de 40 octets.

Figure 1 : Format de l'en-tête d'un paquet IPv6.

Signification des champs de l'en-tête

Version

Le champ Version est au même emplacement et de même longueur, quelle que soit la version du protocole IP (IPv4 ou IPv6). Cette similarité permet de vérifier que le paquet reçu est au format attendu. Dans le cas d'IPv6, sa valeur est de 6 ; elle est de 4 pour IPv4. Le numéro de version 5 avait déjà été attribué au protocole Stream qui finalement n'a pas eu le succès attendu [RFC 1190, RFC 1819].

Classe de trafic (Traffic Class)

Dans la version du document de spécification du protocole IPv6 [RFC 8200], le champ Classe de trafic, sur 8 bits reprend la spécification pour le codage de la différenciation de services RFC 2474.

Le champ Classe de trafic est défini de façon similaire au champ Differentiated Services (DS, ou DiffServ) de l'en-tête IPv4, qui a lui-même pris la place de l'octet Type of Service de la spécification initiale d'IPv4. Ce champ est découpé en deux parties (cf. figure 2). Le sous-champ DSCP (Differentiated Services Code Point) contient les valeurs identifiant les différents traitements demandés aux routeurs. La valeur par défaut 000000 correspond au service classique dit au mieux (ou best effort). Les deux derniers bits du champ, notés ECN (Explicit congestion Notification), servent aux routeurs à rapporter un risque de congestion [RFC 8311].

Figure 2 : Format de l'octet classe de trafic.

Pour le lecteur qui veut en savoir plus, l'annexe 1 décrit l'utilisation du champ classe de trafic dans l'objectif de fournir des services de transfert à qualité différente.

Identificateur de flux (Flow Label)

Ce champ, contient un numéro unique, choisi par la source, pour identifier le flux de données d'une application comme par exemple l'ensemble des paquets d'une application de voix sur IP. L'utilisation de ce champ est spécifiée par le RFC 6437

Ce champ vise à faciliter la classification des flux par les routeurs afin de différencier le traitement paquets et donc notamment la mise en oeuvre des fonctions de qualité de service. En ayant une même valeur, les datagrammes d'un même flux, le routeur peut alors les identifier et leur appliquer un traitement particulier : choix d'une route, traitement en "temps réel" de l'information.

Habituellement, les routeurs se basent sur les valeurs de cinq champs pour identifier le même flux de paquets : adresses de la source et de la destination, numéros de port de la source et de la destination, et protocole. Cette identification implique l'analyse d'en-têtes de niveau 3 pour les adresses et de niveau 4 pour les informations de protocoles et de port source et destination.

Avec IPv6, l'identification du flux n'implique que le niveau 3. Ainsi l'identification est faite indépendamment du protocole de niveau 4. Le champ Identificateur de flux peut être rempli avec une valeur aléatoire. La source gardera cette valeur pour tous les paquets qu'elle émettra pour cette application et cette destination. Le traitement est simplifié puisque le routeur n'a plus à consulter cinq champs pour déterminer l'appartenance d'un paquet à un flux, mais un seul. De plus, la confidentialité peut être préservée, les informations concernant les numéros de port peuvent être masquées aux routeurs intermédiaires.

À la date de rédaction de ce document, l'utilisation de l'identificateur de flux reste encore floue. Les micro-flux, c'est-à-dire les flux applicatifs, ne sont pas analysés dans le coeur du réseau pour des raisons de passage à l'échelle. De plus, MPLS a repris la notion de "routage spécifique en fonction d'une étiquette". Pour l'instant, ce champ peut être vu comme réservé. Son utilisation pourra être détaillée dans le futur.

Longueur des données utiles (Payload Length)

Ce champ indique la quantité d'octets, de ce qui suit l'en-tête du datagramme (en-tête exclus, donc), c'est-à-dire la charge utilise du paquet autrement dit les données. Les éventuelles extensions à l'en-tête IPv6 sont incluses dans ces données. Ce champ, sur 16 bits, peut donc indiquer une taille des données utiles, allant jusqu'à 64 kibioctets (64 * 1024 octets). Pour des paquets dont la taille serait supérieure, ce champ vaut 0 et l'émetteur ajoute une extension d'en-tête de "proche en proche" avec l'option jumbogramme définie par le RFC 2675. Cette extension est essentiellement prévue pour la transmission à haut débit entre deux noeuds.

En-tête suivant (Next Header)

Ce champ identifie le prochain en-tête se trouvant à la suite de l'en-tête IPv6. Il peut s'agir d'un protocole de niveau supérieur (ICMP, UDP, TCP...) ou de la désignation d'une extension (cf. tableau Valeurs du champ en-tête suivant pour IPv6).

Nombre maximal de sauts (Hop Limit)

Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par la noeud source du paquet, et ensuite, décrémenté à chaque routeur traversé. Si la valeur, après décrémentation, atteint 0, le datagramme est supprimé et un message d'erreur ICMPv6 est émis pour la source de ce paquet. Ce champ vise à limiter le nombre de relayages (ou traversés de routeur) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ce champ est à la base de l'outil traceroute pour identifier la suite des routeurs traversés jusqu'à une destination.

La valeur initiale de ce champ, à l'émission du paquet, devrait être donnée dans un document annexe de l'IANA (http://www.iana.org/) ; ce qui permettrait de la modifier en fonction de l'évolution de la topologie du réseau. La valeur n'est pas encore officiellement attribuée mais certaines implantations prennent actuellement la valeur conseillée pour IPv4 : 64.

La valeur par défaut peut être dynamiquement attribuée aux hôtes émetteurs par les annonces des routeurs en configuration automatique. Une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation puisque ce champ, codé sur 8 bits, n'autorise la traversée que de 255 routeurs. En réalité, dans l'Internet actuel, le nombre maximal de routeurs traversés est d'une quarantaine, ce qui laisse une bonne marge pour l'évolution du réseau.

Adresses source et destination

Ces adresses sont renseignées par le noeud source du paquet pour désigner l'émetteur et le destinataire du paquet. Pour renseigner l'adresse source, l'émetteur choisit de préférence une adresse IPv6 parmi celles configurées sur l'interface utilisée pour transmettre le paquet sur le réseau. Cette adresse est choisie pour avoir une portée compatible avec l'adresse de destination et, ainsi, permettre au destinataire de répondre. Par exemple, il serait problématique d'essayer de joindre une machine de l'Internet en donnant comme adresse source une adresse lien-local. Le choix de l'adresse source est spécifié dans le RFC 6724.

L'adresse destination, elle aussi, peut être choisie dans la liste des adresses valables pour le destinataire ; liste pouvant provenir de la résolution d'un nom en adresses par le DNS. L'adresse choisie doit être compatible avec la portée des adresses disponibles au niveau de l'émetteur. Par exemple, si l'émetteur ne possède que des adresses de type ULA, et que le destinataire est connu avec des adresses globales et ULA, ces dernières adresses seront à préférer. Le RFC 6724 précise l'algorithme du choix de l'adresse destination.

Extensions à l'en-tête IPv6

L'ajout de nouvelles fonctionnalités est problématique quand l'en-tête est de taille fixe comme c'est le cas d'IPv6. La solution proposée consiste à ajouter des en-têtes spécifiques pour chaque fonctionnalité. Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par l'émetteur afin que le récepteur puisse rassembler les morceaux correctement. Les extensions sont ajoutées par l'émetteur du paquet pour signaler un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet. Il existe plusieurs types d'extensions selon le traitement demandé. Elles se placent après l'en-tête IPv6 et avant la charge utile du paquet (voir la figure 3). La présence d'une extension est signalée par le champ En-tête suivant (Next Header) de l'en-tête IPv6 qui possède alors la valeur correspondant à cette extension. Ainsi, elle est traitée par les routeurs intermédiaires comme un protocole de niveau supérieur à IP. L'utilisation des différents types d'extensions d'en-tête IPv6 sera abordé dans l'activité 24.

Figure 3: Format d'un paquet IPv6.

Evolution de l'en-tête depuis IPv4

Hormis la modification de la taille des adresses, ce qui conduit à une taille d'en-tête de 40 octets (le double d'un en-tête IPv4 sans options), le protocole IP a subi un toilettage^[2], reprenant l'expérience acquise au fil d’une trentaine d’années avec IPv4, défini en 1981 (!) par le RFC 791. Le format des en-têtes IPv6 est ainsi simplifié et permet aux routeurs de meilleures performances dans leurs traitements. L'idée est de retirer du cœur de réseau les traitements compliqués. Les routeurs ne font que retransmettre les paquets vers la destination, les autres traitements sont faits par l'émetteur et le destinataire du paquet.

L'en-tête ne contient plus de contrôle d'erreur (checksum), qui devait être ajusté, pour IPv4, par chaque routeur en raison, entre autres, de la décrémentation du champ durée de vie. Par contre, pour éviter qu'un paquet, dont le contenu est erroné -- en particulier sur l'adresse de destination --, ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en œuvre un mécanisme de contrôle d'erreur de bout en bout, incluant un pseudo-en-tête qui prend en compte les adresses source et destination. Le contrôle d'erreur d'UDP, facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le contrôle d'erreur intègre le pseudo-en-tête alors que, pour ICMPv4, il ne portait que sur le message ICMP.

La fonction de fragmentation a aussi été retirée des routeurs. Les champs de l'en-tête IPv4 qui s'y reportent (Identification, Drapeau, Place du fragment) ont été supprimés. Normalement, les algorithmes de découverte du PMTU (Path MTU) évitent d'avoir recours à la fragmentation. Si celle-ci s'avère nécessaire, une extension est prévue et le découpage en fragments est réalisé uniquement au niveau de l'émetteur.

Une autre évolution majeure depuis l'en-tête IPv4 est la spécification des extensions d'en-tête pour remplacer les options. En effet, dans le cas d'IPv4, les options sont incluses dans l'en-tête. Celui-ci est donc de taille variable (taille indiquée dans le champ Internet Header Length), ce qui peut compliquer le traitement dans les routeurs intermédiaires. Les extensions à l'en-tête IPv6 simplifient la mise en œuvre de ces fonctionnalités et permettent de garder la taille de l'en-tête IPv6 fixe à 40 octets.

Conclusion

Cette activité a présenté l'en-tête IPv6, définissant une nouvelle version du protocole IP. Cette version reprend les caractéristiques communes du protocole : des adresses de taille fixe, un en-tête définissant une position fixe pour l'adresse de destination, position de plus alignée en mémoire. L'objectif reste toujours le traitement optimal de l'en-tête dans les routeurs. IPv6 garde donc ces principes et va même plus loin que son prédécesseur IPv4 en reconsidérant des mécanismes jugés coûteux, comme la fragmentation, le checksum ou les options. Certains de ces mécanismes ont été éliminés dans la nouvelle version du protocole, d'autres remplacés par mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page^[3]. Ceci peut vous être utile pour la suite.

Références bibliographiques

1. ↑ Wikipedia.Définition de la scalabilité
2. ↑ Lee, D.C.; Lough, D.L.; Midkiff, S.F.et al. (1998). IEEE Network, Vol. 12, No. 1, January. The next generation of the Internet: aspects of the Internet protocol version 6.
3. ↑ Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. IPv6

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 791 Internet protocol (IPv4)
• RFC 1190 Experimental Internet Stream Protocol, Version 2 (ST-II)
• RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+
• RFC 2205 Resource ReSerVation Protocol (RSVP)
• RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers Analyse
• RFC 2675 IPv6 Jumbograms
• RFC 6040 Tunnelling of Explicit Congestion Notification
• RFC 6437 IPv6 Flow Label Specification
• RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) Analyse
• RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms Analyse
• RFC 8200 Internet Protocol, Version 6 (IPv6) Specification Analyse

Annexe 1: la gestion de la qualité de service

L'Internet différencié permet aux fournisseurs d'accès de gérer différemment les congestions qui surviennent dans le réseau. Sans différenciation, les paquets ont la même probabilité de rejet. Avec la différenciation, plusieurs classes de trafic sont définies. Les paquets appartenant aux classes les plus élevées ont une probabilité de rejet plus faible. Bien entendu, pour que l'introduction de telles classes de trafic soit efficace, il faut introduire une gestion des ressources différente pour chacune des classes, et des mécanismes de contrôle pour vérifier que les flux des utilisateurs n'utilisent pas que les classes les plus élevées ou qu'ils ne dépassent pas leur contrat. Par exemple, un client peut établir un contrat de niveau de services appelé SLA (Service Level Agreement) avec son fournisseur d’accès.

L'intérêt principal de la différenciation de services est qu'elle ne casse pas le modèle initial de l'Internet (version 4 ou version 6). Les flux sont toujours traités en Best Effort même si certains sont plus Best que d'autres. Il n'y a aucune garantie qu'un trafic d'une classe haute arrive à destination, mais la probabilité est plus importante. L'autre intérêt des classes de trafic vient de la possibilité d'agrégation des flux. La classe d'appartenance est indiquée dans l'en-tête du paquet. Les applications peuvent marquer les paquets en fonction de paramètres locaux (flux multimédia, flux interactif, trafic priorisé...). Le fournisseur d'accès qui récupère le trafic n'a plus à se préoccuper des applicatifs. Il vérifie que le trafic d'une classe ne dépasse pas le contrat préalablement établi.

Dans le cœur du réseau, les routeurs prennent en compte les différentes classes. Le fournisseur d'accès devra également passer des accords avec les autres opérateurs pour pouvoir faire transiter les flux avec un traitement approprié. Cet aspect de dimensionnement de réseau et de négociation d'accords d'échange est au coeur du métier d'opérateur.

Pour signifier l'appartenance d'un paquet à une certaine classe de trafic, une valeur est renseigné au niveau de l'en-tête IP dans l'octet Traffic Class afin qu'elle puisse être analysée par tous les routeurs mettant en oeuvre le traitement différencié. Le format de ce champ est rappelé en Figure 2.

Le tableau 1 présente les différentes valeurs définies pour le champ DSCP (Differential Service Code Point). Les valeurs sont présentées en format binaire avec les 6 bits les plus significatifs de l’octet Traffic Class, puis leur conversion en décimal, leur nommage, la probabilité d’écartement, et l’équivalence avec les anciennes valeurs du champ TOS de l’IPv4 :

Tableau 1 : Format du champ DSCP.

Pour l'instant, deux types de comportement sont standardisés :

• Assured Forwarding [RFC 2597] : Ce comportement définit quatre classes de trafic et trois priorités, suivant que l'utilisateur respecte son contrat, le dépasse légèrement, ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le réseau. La priorité, par contre, peut être modifiée dans le réseau par les opérateurs en fonction du respect ou non des contrats. Par exemple, pour la classe AF n°2, on dispose des 3 priorités suivantes : AF21, AF22 et AF23. Plus le chiffre est élevé, plus la priorité est faible. C'est-à-dire qu'en cas de saturation de cette classe de trafic, les paquets AF23 seront écartés avant AF22, puis AF21.
• Expedited Forwarding [RFC 2598] : Ce comportement est comparable à un circuit à débit constant réservé dans le réseau. Le trafic est mis en forme à l'entrée du réseau, en retardant l'émission des paquets qui sont hors contrat. En plus de ces comportements, l'octet DS a gardé, pour des raisons de compatibilité avec les équipements existants, les valeurs du bit ToS qui étaient le plus fréquemment utilisées. La valeur est 0xB8 (1011 1000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 46 en décimal).

• Voice Admit : Cette autre valeur a été par la suite proposée dans le RFC 5865 pour affiner le traitement de flux temps réel de différentes natures : voix, vidéo, signalisation temps réel… (La valeur est 0xB0 soit 1011 0100 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 44 en décimal).

• Network Control : Autre particularité : la valeur 0xE0 (1110 0000 en binaire, et en tenant compte uniquement des 6 bits de poids forts : 56 en décimal) correspond à CS7, la classe de contrôle du réseau (Network Control). Elle est utilisée dans des mises en oeuvre d'IPv6 pour l'émission de certains paquets ICMPv6. Cette valeur est dépréciée. Il est conseillé d'utiliser la valeur CS6 comme spécifié dans le RFC 4594.

Références bibliographiques

• RFC 2597 Assured Forwarding PHB Group
• RFC 2598 An Expedited Forwarding PHB
• RFC 4594 Configuration Guidelines for DiffServ Service Classes
• RFC 5865 A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic