MOOC:Compagnon Act21-s7

2022-02-18T16:45:58Z

Jprioual: /* Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 */

__NOTOC__

= Activité 21: 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. Il est 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, utilisé dans l'Internet, 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 nœud source ainsi que celle du nœud de destination du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.

L'adresse du destinataire est fondamentale pour le routage du paquet effectué par les nœuds intermédiaires. C'est en effet à partir de cette adresse que le nœud 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.

<center>
[[Image:21-fig1.png|400px|thumb|center|Figure 1 : Format de l'en-tête d'un paquet IPv6.]]
</center>

== Signification des champs de l'en-tête ==

=== Version ===
Le champ <tt>Version</tt> 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 <tt>Classe de trafic</tt>, sur 8 bits reprend la spécification pour le codage de la différenciation de services [http://tools.ietf.org/html/rfc2474#page6 RFC 2474].

Le champ <tt>Classe de trafic</tt> est défini de façon similaire au champ <tt>Differentiated Services</tt> (DS, ou ''DiffServ'') de l'en-tête IPv4, qui a lui-même pris la place de l'octet <tt>Type of Service</tt> 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].
<center>
[[Image:2015_10_10_TrafficClass.jpg|200px|thumb|center|Figure 2 : Format de l'octet <tt>classe de trafic</tt>.]]
</center>
Pour le lecteur qui veut en savoir plus, l'[[#Annexe_1:_la_gestion_de_la_qualit.C3.A9_de_service|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'unicité de l'identificateur de flux se comprend dans le contexte de l'adresse source. 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 des paquets et donc notamment la mise en œuvre des fonctions de qualité de service. Les datagrammes d'un même flux ayant un même identifiant, le routeur peut alors les reconnaitre et leur appliquer un traitement particulier comme le choix d'une route ou une priorité à l'accès à la transmission.

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 autres informations.

Avec IPv6, l'identification du flux n'implique plus que le niveau 3. Ainsi, l'identification est faite indépendamment du protocole de niveau 4. Le champ <tt>Identificateur de flux</tt> peut être rempli avec une valeur aléatoire mais qui doit être unique. 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.

{{HorsTexte|Passage à l'échelle|Le passage à l'échelle désigne la capacité d'un produit ou d'un mécanisme à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande<ref>Wikipedia.[https://fr.wikipedia.org/wiki/Scalability Définition de la scalabilité]</ref>. Il faut donc comprendre qu'une difficulté à passer à l'échelle signifie que la propriété d'extensibilité n'est pas acquise.}}

À 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 cœur du réseau pour des raisons de passage à l'échelle. De plus, l'idée d'utiliser une étiquette pour acheminer des paquets est déjà utilisée par la technologie MPLS<ref> MultiProtocol Label Switching https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching </ref> de l'Internet, ce qui retire tout sens à utiliser ce champ du paquet IPv6 pour cette fonction. Pour l'instant, ce champ peut être vu comme réservé. Son utilisation devra être détaillée dans le futur.

=== Longueur de la charge du paquet (''Payload Length'') ===

Ce champ indique la quantité d'octets qui suit l'en-tête du datagramme (en-tête exclu donc), c'est-à-dire la charge 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 la 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. Avec l'option jumbogramme, la quantité de données transportée est codée sur 32 bits. La taille maximale des données utiles du paquet monte alors jusqu'à 4 gibioctets (4* 2^30 octets). Nous reviendrons sur le jumbogramme dans l'activité "Taille des paquets IPv6".

=== En-tête suivant (''Next Header'')===
Ce champ identifie le prochain en-tête de protocole 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'').

<center>
{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

=== Nombre maximal de sauts (''Hop Limit'') ===

Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par le nœud 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ées de routeurs) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ainsi, un paquet ne peut pas circuler indéfiniment dans l'Internet.
Ce champ est à la base de l'outil <tt>traceroute</tt> 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 nœud 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 un nœud 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é.
Les extensions sont ajoutées par le nœud source du paquet pour demander un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet.
Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par le nœud source afin que le destinataire puisse rassembler les morceaux correctement.

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 <tt>En-tête suivant</tt> (''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 une activité ultérieure de ce cours.

<center>
[[Image:21-fig2.jpg|400px|center|thumb|Figure 3: Format d'un paquet IPv6.]]
</center>

== 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<ref>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.</ref>, 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 <tt>durée de vie</tt>. 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 (<tt>Identification, Drapeau, Place du fragment</tt>) 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 <tt>Internet Header Length</tt>), 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 IPv4 : 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 est d'avoir un traitement simple et donc rapide 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 des mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page<ref>Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. [http://packetlife.net/media/library/8/IPv6.pdf IPv6]</ref>. Ceci peut vous être utile pour la suite.

== Références bibliographiques ==
<references />

== 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 [http://www.bortzmeyer.org/2474.html 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) [http://www.bortzmeyer.org/6724.html Analyse]
* RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms [http://www.bortzmeyer.org/7098.html Analyse]
* RFC 8200 Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 9098 Operational Implications of IPv6 Packets with Extension Headers [https://www.bortzmeyer.org/9098.html 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ée au niveau de l'en-tête IP dans l'octet <tt>Traffic Class</tt> afin qu'elle puisse être analysée par tous les routeurs mettant en œuvre 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 <tt>Traffic Class</tt>, 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 :

<center>
[[Image:2015_10_07_dscp_ipv6_v01.jpg|600px|thumb|center|Tableau 1 : Format du champ DSCP.]]
</center>

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

* Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 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 [[https://tools.ietf.org/html/rfc2598#page-1 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 [https://tools.ietf.org/html/rfc5865#page-10 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 œuvre 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 [https://tools.ietf.org/html/rfc4594#section-3 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

== Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==

Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.

De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc.

Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.

Cette annexe décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.

L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.

== Principe des extensions IPv6==

Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).
Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ <tt>Next header</tt> qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.

Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.

'''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.''

Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco<ref>Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]</ref>.

== Le champ ''Next Header'' ==

<center>
[[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ <tt>Next Header</tt> dans l'en-tête IPv6.]]
</center>
Le champ <tt>Next Header</tt> de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :
<center>{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

== Intégration des extensions d’en-tête dans le paquet IPv6==
Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée :
* extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;
* extensions impliquant seulement certains routeurs désignés : ''Routing'' ;
* extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.

La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ <tt>en-tête suivant</tt> et un champ <tt>longueur</tt>. Le premier paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6.
* L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (''Hop-by-Hop'') devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension ''Destination'', elle ne pourrait être lue, l'extension ''Destination'' n'étant interprétée que par le destinataire du paquet.
* Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports.
* Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de "proche en proche", qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (''i.e.'' celui spécifié dans le champ <tt>adresse de destination</tt> du paquet IPv6).

<center>
[[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]
</center>

== Quelques exemples ==

=== Fragmentation ===

Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44.
D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant "proche en proche" et "routage par la source") sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.

La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.

Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.

=== Extensions d'authentification (AH) et de confidentialité (ESP) ===

L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.

Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message <ref>Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]</ref> est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.

L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.

Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre<ref>G. Cizault. livre "IPv6, Théorie et Pratique". [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]</ref>.

=== Segment Routing Header (SRH) ===

Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE<ref>Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]</ref>. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.

<center>
[[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]
</center>

L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots <ref>Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]</ref>.

Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête <ref> Previdi & al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]</ref>. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.

<center>
[[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]]
</center>

Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ <tt>Hdr Ext Len</tt> qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ <tt>Segments Left</tt> qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ <tt>Segments Left</tt> est décrementé.

<center>
[[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 6 : Extension de routage par la source.]]
</center>

L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. <ref>P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]</ref>.

Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.

== Références bibliographiques ==
<references />

== Pour aller plus loin==
Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.

RFC et leur analyse par S. Bortzmeyer :

* RFC 4302 : IP Authentication Header
* RFC 4303 : IP Encapsulating Security Payload (ESP)
* RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]
* RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]
* RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]
* RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]

MOOC:Compagnon Act21-s7

2022-02-18T16:44:41Z

Jprioual: /* Conclusion */

__NOTOC__

= Activité 21: 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. Il est 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, utilisé dans l'Internet, 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 nœud source ainsi que celle du nœud de destination du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.

L'adresse du destinataire est fondamentale pour le routage du paquet effectué par les nœuds intermédiaires. C'est en effet à partir de cette adresse que le nœud 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.

<center>
[[Image:21-fig1.png|400px|thumb|center|Figure 1 : Format de l'en-tête d'un paquet IPv6.]]
</center>

== Signification des champs de l'en-tête ==

=== Version ===
Le champ <tt>Version</tt> 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 <tt>Classe de trafic</tt>, sur 8 bits reprend la spécification pour le codage de la différenciation de services [http://tools.ietf.org/html/rfc2474#page6 RFC 2474].

Le champ <tt>Classe de trafic</tt> est défini de façon similaire au champ <tt>Differentiated Services</tt> (DS, ou ''DiffServ'') de l'en-tête IPv4, qui a lui-même pris la place de l'octet <tt>Type of Service</tt> 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].
<center>
[[Image:2015_10_10_TrafficClass.jpg|200px|thumb|center|Figure 2 : Format de l'octet <tt>classe de trafic</tt>.]]
</center>
Pour le lecteur qui veut en savoir plus, l'[[#Annexe_1:_la_gestion_de_la_qualit.C3.A9_de_service|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'unicité de l'identificateur de flux se comprend dans le contexte de l'adresse source. 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 des paquets et donc notamment la mise en œuvre des fonctions de qualité de service. Les datagrammes d'un même flux ayant un même identifiant, le routeur peut alors les reconnaitre et leur appliquer un traitement particulier comme le choix d'une route ou une priorité à l'accès à la transmission.

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 autres informations.

Avec IPv6, l'identification du flux n'implique plus que le niveau 3. Ainsi, l'identification est faite indépendamment du protocole de niveau 4. Le champ <tt>Identificateur de flux</tt> peut être rempli avec une valeur aléatoire mais qui doit être unique. 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.

{{HorsTexte|Passage à l'échelle|Le passage à l'échelle désigne la capacité d'un produit ou d'un mécanisme à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande<ref>Wikipedia.[https://fr.wikipedia.org/wiki/Scalability Définition de la scalabilité]</ref>. Il faut donc comprendre qu'une difficulté à passer à l'échelle signifie que la propriété d'extensibilité n'est pas acquise.}}

À 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 cœur du réseau pour des raisons de passage à l'échelle. De plus, l'idée d'utiliser une étiquette pour acheminer des paquets est déjà utilisée par la technologie MPLS<ref> MultiProtocol Label Switching https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching </ref> de l'Internet, ce qui retire tout sens à utiliser ce champ du paquet IPv6 pour cette fonction. Pour l'instant, ce champ peut être vu comme réservé. Son utilisation devra être détaillée dans le futur.

=== Longueur de la charge du paquet (''Payload Length'') ===

Ce champ indique la quantité d'octets qui suit l'en-tête du datagramme (en-tête exclu donc), c'est-à-dire la charge 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 la 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. Avec l'option jumbogramme, la quantité de données transportée est codée sur 32 bits. La taille maximale des données utiles du paquet monte alors jusqu'à 4 gibioctets (4* 2^30 octets). Nous reviendrons sur le jumbogramme dans l'activité "Taille des paquets IPv6".

=== En-tête suivant (''Next Header'')===
Ce champ identifie le prochain en-tête de protocole 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'').

<center>
{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

=== Nombre maximal de sauts (''Hop Limit'') ===

Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par le nœud 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ées de routeurs) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ainsi, un paquet ne peut pas circuler indéfiniment dans l'Internet.
Ce champ est à la base de l'outil <tt>traceroute</tt> 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 nœud 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 un nœud 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é.
Les extensions sont ajoutées par le nœud source du paquet pour demander un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet.
Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par le nœud source afin que le destinataire puisse rassembler les morceaux correctement.

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 <tt>En-tête suivant</tt> (''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 une activité ultérieure de ce cours.

<center>
[[Image:21-fig2.jpg|400px|center|thumb|Figure 3: Format d'un paquet IPv6.]]
</center>

== 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<ref>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.</ref>, 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 <tt>durée de vie</tt>. 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 (<tt>Identification, Drapeau, Place du fragment</tt>) 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 <tt>Internet Header Length</tt>), 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 IPv4 : 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 est d'avoir un traitement simple et donc rapide 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 des mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page<ref>Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. [http://packetlife.net/media/library/8/IPv6.pdf IPv6]</ref>. Ceci peut vous être utile pour la suite.

== Références bibliographiques ==
<references />

== 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 [http://www.bortzmeyer.org/2474.html 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) [http://www.bortzmeyer.org/6724.html Analyse]
* RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms [http://www.bortzmeyer.org/7098.html Analyse]
* RFC 8200 Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 9098 Operational Implications of IPv6 Packets with Extension Headers [https://www.bortzmeyer.org/9098.html 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ée au niveau de l'en-tête IP dans l'octet <tt>Traffic Class</tt> afin qu'elle puisse être analysée par tous les routeurs mettant en œuvre 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 <tt>Traffic Class</tt>, 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 :

<center>
[[Image:2015_10_07_dscp_ipv6_v01.jpg|600px|thumb|center|Tableau 1 : Format du champ DSCP.]]
</center>

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

* Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 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 [[https://tools.ietf.org/html/rfc2598#page-1 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 [https://tools.ietf.org/html/rfc5865#page-10 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 œuvre 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 [https://tools.ietf.org/html/rfc4594#section-3 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

== Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==

Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.

De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc.

Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.

== Principe des extensions IPv6==

Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).
Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ <tt>Next header</tt> qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.

Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.

'''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.''

Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco<ref>Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]</ref>.

== Le champ ''Next Header'' ==

<center>
[[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ <tt>Next Header</tt> dans l'en-tête IPv6.]]
</center>
Le champ <tt>Next Header</tt> de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :
<center>{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

== Intégration des extensions d’en-tête dans le paquet IPv6==
Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée :
* extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;
* extensions impliquant seulement certains routeurs désignés : ''Routing'' ;
* extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.

La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ <tt>en-tête suivant</tt> et un champ <tt>longueur</tt>. Le premier paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6.
* L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (''Hop-by-Hop'') devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension ''Destination'', elle ne pourrait être lue, l'extension ''Destination'' n'étant interprétée que par le destinataire du paquet.
* Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports.
* Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de "proche en proche", qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (''i.e.'' celui spécifié dans le champ <tt>adresse de destination</tt> du paquet IPv6).

<center>
[[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]
</center>

== Quelques exemples ==

=== Fragmentation ===

Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44.
D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant "proche en proche" et "routage par la source") sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.

La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.

Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.

=== Extensions d'authentification (AH) et de confidentialité (ESP) ===

L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.

Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message <ref>Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]</ref> est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.

L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.

Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre<ref>G. Cizault. livre "IPv6, Théorie et Pratique". [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]</ref>.

=== Segment Routing Header (SRH) ===

Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE<ref>Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]</ref>. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.

<center>
[[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]
</center>

L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots <ref>Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]</ref>.

Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête <ref> Previdi & al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]</ref>. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.

<center>
[[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]]
</center>

Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ <tt>Hdr Ext Len</tt> qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ <tt>Segments Left</tt> qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ <tt>Segments Left</tt> est décrementé.

<center>
[[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 6 : Extension de routage par la source.]]
</center>

L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. <ref>P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]</ref>.

Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.

== Références bibliographiques ==
<references />

== Pour aller plus loin==
Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.

RFC et leur analyse par S. Bortzmeyer :

* RFC 4302 : IP Authentication Header
* RFC 4303 : IP Encapsulating Security Payload (ESP)
* RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]
* RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]
* RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]
* RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]

MOOC:Compagnon Act21-s7

2022-02-18T16:41:49Z

Jprioual: /* Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 */

__NOTOC__

= Activité 21: 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. Il est 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, utilisé dans l'Internet, 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 nœud source ainsi que celle du nœud de destination du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.

L'adresse du destinataire est fondamentale pour le routage du paquet effectué par les nœuds intermédiaires. C'est en effet à partir de cette adresse que le nœud 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.

<center>
[[Image:21-fig1.png|400px|thumb|center|Figure 1 : Format de l'en-tête d'un paquet IPv6.]]
</center>

== Signification des champs de l'en-tête ==

=== Version ===
Le champ <tt>Version</tt> 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 <tt>Classe de trafic</tt>, sur 8 bits reprend la spécification pour le codage de la différenciation de services [http://tools.ietf.org/html/rfc2474#page6 RFC 2474].

Le champ <tt>Classe de trafic</tt> est défini de façon similaire au champ <tt>Differentiated Services</tt> (DS, ou ''DiffServ'') de l'en-tête IPv4, qui a lui-même pris la place de l'octet <tt>Type of Service</tt> 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].
<center>
[[Image:2015_10_10_TrafficClass.jpg|200px|thumb|center|Figure 2 : Format de l'octet <tt>classe de trafic</tt>.]]
</center>
Pour le lecteur qui veut en savoir plus, l'[[#Annexe_1:_la_gestion_de_la_qualit.C3.A9_de_service|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'unicité de l'identificateur de flux se comprend dans le contexte de l'adresse source. 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 des paquets et donc notamment la mise en œuvre des fonctions de qualité de service. Les datagrammes d'un même flux ayant un même identifiant, le routeur peut alors les reconnaitre et leur appliquer un traitement particulier comme le choix d'une route ou une priorité à l'accès à la transmission.

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 autres informations.

Avec IPv6, l'identification du flux n'implique plus que le niveau 3. Ainsi, l'identification est faite indépendamment du protocole de niveau 4. Le champ <tt>Identificateur de flux</tt> peut être rempli avec une valeur aléatoire mais qui doit être unique. 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.

{{HorsTexte|Passage à l'échelle|Le passage à l'échelle désigne la capacité d'un produit ou d'un mécanisme à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande<ref>Wikipedia.[https://fr.wikipedia.org/wiki/Scalability Définition de la scalabilité]</ref>. Il faut donc comprendre qu'une difficulté à passer à l'échelle signifie que la propriété d'extensibilité n'est pas acquise.}}

À 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 cœur du réseau pour des raisons de passage à l'échelle. De plus, l'idée d'utiliser une étiquette pour acheminer des paquets est déjà utilisée par la technologie MPLS<ref> MultiProtocol Label Switching https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching </ref> de l'Internet, ce qui retire tout sens à utiliser ce champ du paquet IPv6 pour cette fonction. Pour l'instant, ce champ peut être vu comme réservé. Son utilisation devra être détaillée dans le futur.

=== Longueur de la charge du paquet (''Payload Length'') ===

Ce champ indique la quantité d'octets qui suit l'en-tête du datagramme (en-tête exclu donc), c'est-à-dire la charge 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 la 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. Avec l'option jumbogramme, la quantité de données transportée est codée sur 32 bits. La taille maximale des données utiles du paquet monte alors jusqu'à 4 gibioctets (4* 2^30 octets). Nous reviendrons sur le jumbogramme dans l'activité "Taille des paquets IPv6".

=== En-tête suivant (''Next Header'')===
Ce champ identifie le prochain en-tête de protocole 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'').

<center>
{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

=== Nombre maximal de sauts (''Hop Limit'') ===

Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par le nœud 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ées de routeurs) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ainsi, un paquet ne peut pas circuler indéfiniment dans l'Internet.
Ce champ est à la base de l'outil <tt>traceroute</tt> 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 nœud 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 un nœud 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é.
Les extensions sont ajoutées par le nœud source du paquet pour demander un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet.
Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par le nœud source afin que le destinataire puisse rassembler les morceaux correctement.

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 <tt>En-tête suivant</tt> (''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 une activité ultérieure de ce cours.

<center>
[[Image:21-fig2.jpg|400px|center|thumb|Figure 3: Format d'un paquet IPv6.]]
</center>

== 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<ref>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.</ref>, 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 <tt>durée de vie</tt>. 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 (<tt>Identification, Drapeau, Place du fragment</tt>) 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 <tt>Internet Header Length</tt>), 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 IPv4 : 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 est d'avoir un traitement simple et donc rapide 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 des mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page<ref>Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. [http://packetlife.net/media/library/8/IPv6.pdf IPv6]</ref>. Ceci peut vous être utile pour la suite.

== Références bibliographiques ==
<references />

== 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 [http://www.bortzmeyer.org/2474.html 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) [http://www.bortzmeyer.org/6724.html Analyse]
* RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms [http://www.bortzmeyer.org/7098.html Analyse]
* RFC 8200 Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 9098 Operational Implications of IPv6 Packets with Extension Headers [https://www.bortzmeyer.org/9098.html 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ée au niveau de l'en-tête IP dans l'octet <tt>Traffic Class</tt> afin qu'elle puisse être analysée par tous les routeurs mettant en œuvre 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 <tt>Traffic Class</tt>, 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 :

<center>
[[Image:2015_10_07_dscp_ipv6_v01.jpg|600px|thumb|center|Tableau 1 : Format du champ DSCP.]]
</center>

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

* Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 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 [[https://tools.ietf.org/html/rfc2598#page-1 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 [https://tools.ietf.org/html/rfc5865#page-10 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 œuvre 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 [https://tools.ietf.org/html/rfc4594#section-3 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

== Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==

Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.

De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc.

Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.

== Principe des extensions IPv6==

Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).
Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ <tt>Next header</tt> qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.

Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.

'''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.''

Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco<ref>Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]</ref>.

== Le champ ''Next Header'' ==

<center>
[[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ <tt>Next Header</tt> dans l'en-tête IPv6.]]
</center>
Le champ <tt>Next Header</tt> de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :
<center>{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

== Intégration des extensions d’en-tête dans le paquet IPv6==
Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée :
* extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;
* extensions impliquant seulement certains routeurs désignés : ''Routing'' ;
* extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.

La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ <tt>en-tête suivant</tt> et un champ <tt>longueur</tt>. Le premier paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6.
* L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (''Hop-by-Hop'') devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension ''Destination'', elle ne pourrait être lue, l'extension ''Destination'' n'étant interprétée que par le destinataire du paquet.
* Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports.
* Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de "proche en proche", qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (''i.e.'' celui spécifié dans le champ <tt>adresse de destination</tt> du paquet IPv6).

<center>
[[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]
</center>

== Quelques exemples ==

=== Fragmentation ===

Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44.
D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant "proche en proche" et "routage par la source") sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.

La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.

Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.

=== Extensions d'authentification (AH) et de confidentialité (ESP) ===

L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.

Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message <ref>Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]</ref> est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.

L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.

Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre<ref>G. Cizault. livre "IPv6, Théorie et Pratique". [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]</ref>.

=== Segment Routing Header (SRH) ===

Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE<ref>Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]</ref>. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.

<center>
[[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]
</center>

L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots <ref>Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]</ref>.

Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête <ref> Previdi & al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]</ref>. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.

<center>
[[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]]
</center>

Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ <tt>Hdr Ext Len</tt> qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ <tt>Segments Left</tt> qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ <tt>Segments Left</tt> est décrementé.

<center>
[[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 6 : Extension de routage par la source.]]
</center>

L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. <ref>P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]</ref>.

Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.

== Conclusion ==
Cette activité vous a décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.

L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.

== Références bibliographiques ==
<references />

== Pour aller plus loin==
Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.

RFC et leur analyse par S. Bortzmeyer :

* RFC 4302 : IP Authentication Header
* RFC 4303 : IP Encapsulating Security Payload (ESP)
* RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]
* RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]
* RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]
* RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]

MOOC:Compagnon Act21-s7

2022-02-18T16:41:34Z

Jprioual: /* Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 */

__NOTOC__

= Activité 21: 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. Il est 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, utilisé dans l'Internet, 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 nœud source ainsi que celle du nœud de destination du paquet. Pour marquer cette spécificité, ces paquets auto-descriptifs sont appelés des datagrammes.

L'adresse du destinataire est fondamentale pour le routage du paquet effectué par les nœuds intermédiaires. C'est en effet à partir de cette adresse que le nœud 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.

<center>
[[Image:21-fig1.png|400px|thumb|center|Figure 1 : Format de l'en-tête d'un paquet IPv6.]]
</center>

== Signification des champs de l'en-tête ==

=== Version ===
Le champ <tt>Version</tt> 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 <tt>Classe de trafic</tt>, sur 8 bits reprend la spécification pour le codage de la différenciation de services [http://tools.ietf.org/html/rfc2474#page6 RFC 2474].

Le champ <tt>Classe de trafic</tt> est défini de façon similaire au champ <tt>Differentiated Services</tt> (DS, ou ''DiffServ'') de l'en-tête IPv4, qui a lui-même pris la place de l'octet <tt>Type of Service</tt> 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].
<center>
[[Image:2015_10_10_TrafficClass.jpg|200px|thumb|center|Figure 2 : Format de l'octet <tt>classe de trafic</tt>.]]
</center>
Pour le lecteur qui veut en savoir plus, l'[[#Annexe_1:_la_gestion_de_la_qualit.C3.A9_de_service|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'unicité de l'identificateur de flux se comprend dans le contexte de l'adresse source. 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 des paquets et donc notamment la mise en œuvre des fonctions de qualité de service. Les datagrammes d'un même flux ayant un même identifiant, le routeur peut alors les reconnaitre et leur appliquer un traitement particulier comme le choix d'une route ou une priorité à l'accès à la transmission.

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 autres informations.

Avec IPv6, l'identification du flux n'implique plus que le niveau 3. Ainsi, l'identification est faite indépendamment du protocole de niveau 4. Le champ <tt>Identificateur de flux</tt> peut être rempli avec une valeur aléatoire mais qui doit être unique. 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.

{{HorsTexte|Passage à l'échelle|Le passage à l'échelle désigne la capacité d'un produit ou d'un mécanisme à s'adapter à un changement d'ordre de grandeur de la demande (montée en charge), en particulier sa capacité à maintenir ses fonctionnalités et ses performances en cas de forte demande<ref>Wikipedia.[https://fr.wikipedia.org/wiki/Scalability Définition de la scalabilité]</ref>. Il faut donc comprendre qu'une difficulté à passer à l'échelle signifie que la propriété d'extensibilité n'est pas acquise.}}

À 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 cœur du réseau pour des raisons de passage à l'échelle. De plus, l'idée d'utiliser une étiquette pour acheminer des paquets est déjà utilisée par la technologie MPLS<ref> MultiProtocol Label Switching https://fr.wikipedia.org/wiki/Multiprotocol_Label_Switching </ref> de l'Internet, ce qui retire tout sens à utiliser ce champ du paquet IPv6 pour cette fonction. Pour l'instant, ce champ peut être vu comme réservé. Son utilisation devra être détaillée dans le futur.

=== Longueur de la charge du paquet (''Payload Length'') ===

Ce champ indique la quantité d'octets qui suit l'en-tête du datagramme (en-tête exclu donc), c'est-à-dire la charge 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 la 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. Avec l'option jumbogramme, la quantité de données transportée est codée sur 32 bits. La taille maximale des données utiles du paquet monte alors jusqu'à 4 gibioctets (4* 2^30 octets). Nous reviendrons sur le jumbogramme dans l'activité "Taille des paquets IPv6".

=== En-tête suivant (''Next Header'')===
Ce champ identifie le prochain en-tête de protocole 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'').

<center>
{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

=== Nombre maximal de sauts (''Hop Limit'') ===

Ce champ représente le nombre maximal de routeurs que le paquet peut traverser. Il est initialisé par le nœud 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ées de routeurs) que peut subir un paquet suite à des problèmes dans le réseau comme des boucles de routage. Ainsi, un paquet ne peut pas circuler indéfiniment dans l'Internet.
Ce champ est à la base de l'outil <tt>traceroute</tt> 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 nœud 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 un nœud 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é.
Les extensions sont ajoutées par le nœud source du paquet pour demander un traitement spécifique à réaliser, soit par les routeurs intermédiaires, soit par le destinataire du paquet.
Par exemple, si un paquet doit être fragmenté, une extension de fragmentation sera ajoutée par le nœud source afin que le destinataire puisse rassembler les morceaux correctement.

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 <tt>En-tête suivant</tt> (''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 une activité ultérieure de ce cours.

<center>
[[Image:21-fig2.jpg|400px|center|thumb|Figure 3: Format d'un paquet IPv6.]]
</center>

== 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<ref>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.</ref>, 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 <tt>durée de vie</tt>. 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 (<tt>Identification, Drapeau, Place du fragment</tt>) 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 <tt>Internet Header Length</tt>), 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 IPv4 : 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 est d'avoir un traitement simple et donc rapide 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 des mécanismes plus performants. Enfin, nous pouvons signaler ce formulaire qui présente l'essentiel du paquet IPv6 en une seule page<ref>Stretch, J. (2009) packetlife.net. Aide-mémoire tout en une page. [http://packetlife.net/media/library/8/IPv6.pdf IPv6]</ref>. Ceci peut vous être utile pour la suite.

== Références bibliographiques ==
<references />

== 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 [http://www.bortzmeyer.org/2474.html 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) [http://www.bortzmeyer.org/6724.html Analyse]
* RFC 7098: Using the IPv6 Flow Label for Load Balancing in Server Farms [http://www.bortzmeyer.org/7098.html Analyse]
* RFC 8200 Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 9098 Operational Implications of IPv6 Packets with Extension Headers [https://www.bortzmeyer.org/9098.html 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ée au niveau de l'en-tête IP dans l'octet <tt>Traffic Class</tt> afin qu'elle puisse être analysée par tous les routeurs mettant en œuvre 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 <tt>Traffic Class</tt>, 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 :

<center>
[[Image:2015_10_07_dscp_ipv6_v01.jpg|600px|thumb|center|Tableau 1 : Format du champ DSCP.]]
</center>

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

* Assured Forwarding [[https://tools.ietf.org/html/rfc2597#page-6 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 [[https://tools.ietf.org/html/rfc2598#page-1 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 [https://tools.ietf.org/html/rfc5865#page-10 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 œuvre 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 [https://tools.ietf.org/html/rfc4594#section-3 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

== Annexe 2: Le mécanisme d’extension de l'en-tête IPv6 ==

Les extensions de l'en-tête IPv6 visent à ajouter des fonctionnalités supplémentaires à l'acheminement d'un paquet dans l'Internet. Ces extensions vont impliquer le traitement de ces fonctionnalités au niveau réseau, soit par le destinataire du paquet IPv6, soit par les routeurs intermédiaires en charge de l’acheminement du paquet IPv6.

De nombreuses extensions ont été définies, afin d'assurer des fonctions comme le routage par la source, la gestion de la fragmentation, la confidentialité des communications (mécanisme ''ipsec''), etc.

Le mécanisme d'extension de l'en-tête IPv6 est assez souple pour pouvoir inclure d'autres fonctionnalités futures. Dans cette activité, nous allons nous intéresser au principe du traitement des extensions au moyen d'exemples simples et démonstratifs de ce mécanisme.

== Principe des extensions IPv6==

Les extensions peuvent être vues comme un protocole 3.5, entre les couches 3 (réseau) et 4 (transport) du modèle OSI. En effet, à part l'extension de proche-en-proche, qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (i.e. celui spécifié dans le champ adresse de destination du paquet IPv6).
Une extension a une longueur multiple de 8 octets (64 bits). Elle commence par un champ <tt>Next header</tt> qui définit, sur un octet, le type d'extension ou de protocole qui suit. Pour les extensions de longueur variable, l'octet suivant contient la longueur de l'extension en mots de 8 octets, le premier mot n'étant pas compté. Par exemple, une extension de 16 octets aura une longueur de 1.

Si, d'un point de vue théorique, les extensions sont supérieures aux options d'IPv4, dans la réalité très peu sont utilisées à grande échelle et restent du domaine de la recherche.

'''''Nota :''''' ''dans la pratique, l'extension la plus couramment rencontrée est probablement l'option de fragmentation à la source. En effet, certains protocoles applicatifs sur UDP, tel que NFS, supposant que la fragmentation existe au niveau réseau, produisent des messages de taille quelconque sans se soucier du MTU. Comme il n'est pas envisageable de modifier ces applications largement déployées, la couche réseau IPv6 doit être capable de gérer la fragmentation. IPv6 impose simplement que cette dernière se fasse à la source.''

Une présentation illustrée des extensions IPv6 peut être consultée sur le site de Cisco<ref>Cisco (2006) White paper.[http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html IPv6 Extension Headers Review and Considerations]</ref>.

== Le champ ''Next Header'' ==

<center>
[[image:2015_10_14_ipv6_header_next-header_v02.jpg|thumb|right|300px|Figure 1 : Localisation du champ <tt>Next Header</tt> dans l'en-tête IPv6.]]
</center>
Le champ <tt>Next Header</tt> de l'en-tête IPv6, comme illustré sur la figure 1, identifie généralement le protocole de niveau supérieur comme, par exemple, le transport TCP/UDP. Mais, dans le cas des extensions, plusieurs mécanismes particuliers sont également disponibles parmi la liste suivante :
<center>{{MOOC_Valeurs_du_champ_en-tête_suivant}}
</center>

== Intégration des extensions d’en-tête dans le paquet IPv6==
Quand il y a plusieurs extensions dans un même datagramme, les extensions sont placées selon un ordre qui dépend de leur portée :
* extensions impliquant tous les routeurs intermédiaires : ''Hop-by-Hop'' ;
* extensions impliquant seulement certains routeurs désignés : ''Routing'' ;
* extension impliquant le destinataire : ''Authentication'', ''Encapsulating Security Payload'', Fragmentation, Destination.

La figure 2 montre la souplesse avec laquelle plusieurs extensions peuvent être chaînées. Chaque extension contient dans son en-tête un champ <tt>en-tête suivant</tt> et un champ <tt>longueur</tt>. Le premier paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur ICMPv6. Le second paquet ne contient pas d'extension ; le champ <tt>en-tête suivant</tt> pointe sur TCP. Le troisième paquet contient une extension de protection qui pointe ensuite sur UDP. Dans le dernier paquet, une extension de routage, qui pointe sur une extension de fragmentation, pointe finalement sur ICMPv6.
* L'enchaînement des extensions se fait dans un ordre bien déterminé. Par exemple, une extension concernant tous les routeurs sur le chemin (''Hop-by-Hop'') devra forcément se trouver en première position. Si elle se trouvait à la suite d'une extension ''Destination'', elle ne pourrait être lue, l'extension ''Destination'' n'étant interprétée que par le destinataire du paquet.
* Si cet enchaînement d'extension offre beaucoup plus de souplesse que les options d'IPv4, il rend difficile la lecture des numéros de port. Il faut en effet lire tout l'enchaînement d'extension pour arriver au protocole de niveau 4. Ceci a servi de justification à l'identificateur de flux qui permettait de refléter au niveau 3 un flux particulier et évitait de dérouler l'enchaînement. Bien entendu, les pare-feux devront vérifier les numéros de ports.
* Les extensions peuvent être vues comme un protocole 3.5 (entre la couche 3 et la couche 4). En effet, à part l'extension de "proche en proche", qui est traitée par tous les routeurs traversés, les autres extensions ne sont traitées que par le destinataire du paquet (''i.e.'' celui spécifié dans le champ <tt>adresse de destination</tt> du paquet IPv6).

<center>
[[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]
</center>

== Quelques exemples ==

=== Fragmentation ===

Nous avons vu la fragmentation en détail lors de l'activité consacrée à la taille des paquets IPv6. Les points essentiels à rappeler sont que la fragmentation en IPv6 est une fonction d'hôtes exclusivement, et que par souci d'efficacité, l'adaptation de la taille de l'unité de données applicatives en unité de transfert est du ressort de la couche de transport. Cependant, lorsque ce n'est pas possible, en dernier ressort, la fragmentation est faite par IPv6. Les informations pour la fragmentation sont placées dans une extension d'en-tête IPv6 identifiée par la valeur 44.
D'un point de vue du codage, l'en-tête et les extensions qui concernent les routeurs intermédiaires (pour l'instant "proche en proche" et "routage par la source") sont recopiées dans chaque fragment, tandis que les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.

La fragmentation en IPv4 n'est pas très performante. Quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, il doit le transmettre en fragments. Comme l'Internet n'est pas fiable, un fragment peut se perdre. Le destinataire ne peut rassembler les fragments. Cela revient à perdre tous les fragments. Il est donc plus efficace de faire les fragments avant la couche IP. Ainsi le fragment devient un paquet IP à la bonne taille. Maintenant, en cas de perte, seul le paquet perdu sera retransmis, évitant ainsi la retransmission de gros blocs de données.

Il est plus intéressant d'adapter la taille des paquets à l'émission. Ceci est fait en utilisant les techniques de découverte du MTU (voir RFC 8201 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de MTU 1280 octets est une bonne garantie d'acheminement du paquet.

=== Extensions d'authentification (AH) et de confidentialité (ESP) ===

L'extension d'authentification (AH : Authentication Header) décrite dans le RFC 4302 permet de s'assurer que l'émetteur du message est bien celui qu'il prétend être. Elle sert aussi au contrôle d'intégrité pour garantir au récepteur que personne n'a modifié le contenu d'un message lors de son transfert sur le réseau. Elle peut optionnellement être utilisée pour détecter les rejeux.

Le principe de l'authentification est relativement simple. L'émetteur calcule un authentificateur sur un datagramme et l'émet avec le datagramme sur lequel il porte. Le récepteur récupère cette valeur et vérifie qu'elle est correcte. Si un code d'authentification de message <ref>Code d'authentification de message, [https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message Article Wikipedia]</ref> est utilisé, il suffit au récepteur de calculer de son côté le code sur le même datagramme à l'aide de la clé symétrique partagée et de le comparer avec le code reçu. Si le mécanisme de signature numérique est employé, le récepteur doit alors récupérer la signature, la déchiffrer avec la clé publique de l'émetteur et comparer le condensat ainsi obtenu avec celui calculé de son côté sur le datagramme reçu. Si les deux codes, ou les deux condensats diffèrent, soit l'émetteur ne possède pas la bonne clé, soit le message a subi des modifications en chemin.

L'extension ESP ''Encapsulating Security Payload'' décrite dans le RFC 4303 permet de chiffrer l'ensemble des paquets ou leur partie transport et de garantir l'authentification et l'intégrité de ces paquets. Cette extension permet optionnellement de détecter les rejeux (à condition que le service d'authentification soit assuré) et garantit de façon limitée la confidentialité du flux.

Pour obtenir ces services de sécurité, il est nécessaire, avant d'émettre un paquet IP sur le réseau, de chiffrer les données à protéger, de calculer un authentificateur, et d'encapsuler ces informations dans l'en-tête de confidentialité ESP. Cela nécessite bien entendu l'existence d'une association de sécurité précisant, entre autres, le ou les algorithmes de chiffrement, la ou les clés, et un indice de paramètres de sécurité. Pour en savoir plus sur les extensions de sécurité, nous renvoyons le lecteur vers le livre<ref>G. Cizault. livre "IPv6, Théorie et Pratique". [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre sur la Sécurité]</ref>.

=== Segment Routing Header (SRH) ===

Cette extension est une des briques qui permet la mise en œuvre de l'ingénierie de trafic et de la qualité de service dans les réseaux IPv6. Certaines applications ont besoin que le délai, le taux de perte des paquets et le débit ne dépassent pas un certain seuil. Par exemple, une session de vidéo-conférence peut nécessiter que le délai de bout en bout reste inférieur à 100 ms, que le débit disponible soit au minimum de 2 Mbit/s et que le taux de perte reste inférieur à 1 %. La solution habituellement mise en œuvre pour le respect de ces métriques de qualité de service est RSVP-TE<ref>Packet Pushers, novembre 2016.[http://packetpushers.net/rsvp-te-protocol-deep-dive/ Deep dive in the RSVP-TE protocol]</ref>. RSVP est un protocole de réservation de ressources sur les routeurs du chemin entre une source et une destination. La composante d'ingénierie de trafic permet notamment de choisir explicitement le chemin qui sera suivi par le paquet. Lorsqu'une application a besoin de réserver des ressources, un circuit MPLS est établi et le protocole RSVP réserve les ressources sur l'ensemble des routeurs qui composent le chemin. La figure 4 résume ce comportement : le nœud A est la source du flot de vidéo-conférence destiné à B. Elle demande l'installation d'un chemin via MPLS. Le contrôleur détermine que le chemin le plus adapté est celui transitant par G,H,I,K,N source de vidéo-conférence. Elle effectue ensuite une réservation de ressource via RSVP. Chacun des routeurs G,H,I,K,N doit accepter la requête.

<center>
[[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]
</center>

L'inconvénient de cette méthode est qu'avec RSVP, les réservations doivent être fréquemment renouvelées et les routeurs doivent garder des états relatifs à chacun des flots. À chaque fois qu'un routeur reçoit un paquet, il doit chercher dans la liste des flots le comportement à y associer. Cela limite le passage à l'échelle (le nombre de flots supportés). De plus, l'établissement des circuits MPLS est coûteux en temps, en états, et en communication. Pour finir, si un des nœuds ou des liens qui compose le chemin n'est plus disponible, le temps requis pour établir un nouveau chemin peut être trop important face aux besoins des flots <ref>Cisco, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/ SR Traffic Engineering]</ref>.

Le concept de ''segment routing'' a été proposé pour palier ces désavantages. Il permet de réduire l'intelligence des nœuds du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du nœud. Le chemin à suivre ainsi que le traitement à associer aux paquets sont ensuite explicitement listés dans leurs en-têtes. Ces traitements à appliquer au paquet sont appelées segments. Un segment peut être l'adresse d'un routeur par lequel le paquet devra transiter, un lien à emprunter ou encore un service fourni par le routeur sur lequel transite le paquet. La séquence de segments que doit suivre le paquet peut être implémentée via une liste de labels MPLS ou, dans le cas d'un réseau IPv6, via l'option ''Segment Routing'' de l'en-tête <ref> Previdi & al. [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06 IPv6 Segment Routing Header (SRH) (Draft)]</ref>. Contrairement à MPLS, le ''segment routing'' avec IPv6 ne requière pas que tous les nœuds traversés par le paquet soient compatibles avec cette option. Cela permet un déploiement progressif et la traversée de plusieurs types de réseaux. Notons qu'il n'est pas nécessaire d'inscrire l'intégralité du chemin dans la liste. Les règles de routage classique de l'IGP s'appliquent jusqu'au prochain nœud explicitement listé dans l'en-tête. Dans le cas de la figure 5, pour suivre le chemin G,H,I,K,N, il est seulement nécessaire d'ajouter I et B dans la liste. Lorsque le paquet est généré par A, l'adresse de destination est celle de I. Lorsque le paquet atteint I, l'adresse de destination est remplacée par la prochaine dans la liste ; c'est-à-dire B. Le paquet suit le plus court chemin entre I et B ; en l’occurrence I,K,N. Le surcoût induit par la taille de l'extension de l'en-tête est donc limité.

<center>
[[image:Moocipv6-act24-SRH-rsvp.png|thumb|center|600px|Figure 5 : Exemple d'utilisation du ''Segment Routing'' pour l'ingénierie de trafic et la qualité de service.]]
</center>

Le projet de RFC prévoit qu'un segment soit représenté sur 128 bits ; c'est-à-dire autant qu'une adresse IPv6. Le nombre de segments inclus dans l'option SRH peut être déduit du champ <tt>Hdr Ext Len</tt> qui indique le nombre d'octets de l'option moins un. Le prochain segment à appliquer est indiqué par le champ <tt>Segments Left</tt> qui indique le nombre de segments restant à appliquer au paquet. Le segment courant est inscrit dans le champ adresse de destination de l'en-tête IPv6. Lorsque le traitement associé à un segment est achevé, le prochain segment à traiter est copié dans le champ adresse de destination et le champ <tt>Segments Left</tt> est décrementé.

<center>
[[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 6 : Extension de routage par la source.]]
</center>

L'extension SRH est très proche de l'en-tête de routage défini dans le RFC 8200 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source (voir la figure 6) qui consiste à lister les routeurs que devaient traverser le paquet au cours de son acheminement. Cette pratique a été dépréciée en 2007 par le RFC 5095 pour des raisons de sécurité. En effet cela permettait de générer de la congestion sur certains chemins, des attaques de déni de service, des contournements des règles de filtrages de certains pare-feux ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. <ref>P. Biondi et A. Ebalard, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]</ref>.

Pour être acceptée, l'extension SRH doit donc garantir qu'elle ne serait pas vulnérable à ces attaques. Plusieurs cas d'utilisation sont décrits. Lorsque l'extension SRH est générée au sein du réseau de l'opérateur (i.e. routeur de bordure), les attaques listées dans le RFC 5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter que des hôtes s'attribuent des privilèges ou provoquent de la congestion sur certains liens. Lorsque les SRH sont générées en dehors du réseau de l'opérateur, le projet de RFC prévoit l'utilisation d'un mécanisme d'authentification de l'en-tête défini par le RFC 2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des nœuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.

== Conclusion ==
Cette activité vous a décrit les différents mécanismes qui enrichissent les fonctions disponibles au niveau de la couche réseau : routage, fragmentation, sécurité, etc. Ces mécanismes tirent parti de la possibilité d'ajouter des champs supplémentaires à l'en-tête IPv6 grâce aux extensions d'en-tête. Ces extensions sont ajoutées par les extrémités de la communication et sont transparentes pour les routeurs (exception faite des extensions de type ''Hop-by-Hop''). De plus, le mécanisme de chainage par le champ ''Next Header'' permet d'ajouter des extensions de manière souple.

L'usage des extensions est encore assez limité sur l'Internet. Certaines fonctionnalités ont été dépréciées (comme l'extension de routage RH0) et d'autres peinent à se développer (comme la mobilité IPv6). La présence potentielle de ces extensions doit être cependant prise en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.

== Références bibliographiques ==
<references />

== Pour aller plus loin==
Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.

RFC et leur analyse par S. Bortzmeyer :

* RFC 4302 : IP Authentication Header
* RFC 4303 : IP Encapsulating Security Payload (ESP)
* RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]
* RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]
* RFC 7872 : Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World [http://www.bortzmeyer.org/7872.html Analyse]
* RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]
* RFC 8201 : Path MTU Discovery for IP version 6 [http://www.bortzmeyer.org/8201.html Analyse]

2022-02-18T09:25:45Z

Jprioual: /* Introduction de la séquence 2 */

2021-09-22T15:29:45Z

Jprioual: /* Traffic Class */

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: 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.