Latest revision as of 09:12, 10 January 2023

Activité 20  : L'architecture des protocoles de l'Internet

L'Internet est une interconnexion de réseaux physiques. Pour réaliser cette interconnexion, une couche est superposée à chaque noeud. Cette couche dite de réseau met en oeuvre le protocole IP afin de rendre le service de connectivité qui consiste à transférer des paquets d'une source à la destination. Un protocole se définit comme les règles et le format des échanges entre au moins 2 entités communicantes en vue de réaliser une action ou de rendre un service. Nous avons vu dans la séquence précédente la notion d'adressage qui est indispensable pour identifier et localiser les noeuds du réseau. Nous allons dans cette séquence apprendre comment les communications de données sont mises en oeuvre dans l'Internet.

Le protocole de réseau IP

Le protocole IP (Internet Protocol) a pour fonction d'organiser le transfert de données d’un point d'extrémité à un autre d'un réseau. Les points d'extrémités sont les équipements terminaux tels que les stations des clients et les serveurs. Ils génèrent et reçoivent les paquets IP. Ils sont les sources et les destinations du trafic de données.

Tout nœud connecté peut communiquer avec un autre nœud de l'Internet en utilisant le protocole IP sans qu'il ait besoin de changer le format de l'unité de transfert, à savoir le paquet IP. IP est en quelque sorte le langage commun de tous les nœuds de l’Internet. Les points importants du fonctionnement d'IP sont les suivants :

• indépendance vis à vis des données : aucun nœud intermédiaire ne traite de l’information contenue dans le paquet ; seuls l’émetteur et le destinataire de l’information sont concernés ;

• transfert de bout en en bout : un paquet est transmis à un noeud qui le transmet à son tour au noeud suivant et ainsi de suite, jusqu'à l'hôte destination ; ainsi le protocole IP effectue un relayage de paquets par sauts successifs ;

• acheminement en mode message (datagramme) : cela signifie que chaque paquet dispose des éléments nécessaires et suffisants pour son acheminement à travers le réseau. Chaque paquet est traité indépendamment des autres paquets. Il comporte l'adresse IP source et l'adresse IP destination.

• Service en mode non connecté : Le transfert de données est fait sans échange préalable. A la différence du téléphone comme nous l'utilisons, IP n'a pas besoin d'établir une connexion avec le noeud de destination."

La notion de paquet est essentielle dans le fonctionnement de l'Internet. Nous allons par la suite définir la notion de paquet.

Notion de paquet

Les données échangées dans l'internet sont découpées en blocs de taille limitée appelés paquets. Ce bloc de données est une séquence structurée d'octets qui est transférée sans modification de son contenu d'une source à la destination finale selon le principe du bout-en-bout.

Ainsi lorsqu'un fichier doit être transféré, celui-ci va être découpé en paquets et à destination, les paquets seront ré-assemblés pour reconstituer le fichier. La raison d'un transfert en mode paquet trouve sa motivation dans le partage efficace des ressources du réseau. Dans les systèmes de communications, la ressource principale est la capacité d'écoulement des liens qui est appelée abusivement la bande passante. La bande passante normalement s'exprime en Hertz. Par abus de langage, en numérique elle s'exprime par un débit et l'unité est le bit/s.

Quand il existe des communications entre différentes paires de noeuds (sources et destinations) reliés entre eux par une suite de liens. La problématique porte sur le partage des ressources entre ces noeuds qui communiquent en même temps. Au niveau le plus fin, la question revient à définir comment partager un lien entre des communications simultanées. Il s'agit de la fonction de multiplexage. La figure 1 illustre la notion de multiplexage. Sur cette figure, 3 communications sont multiplexées sur un même lien.

En numérique le partage s'effectue en fonction du temps. La bande passante est découpée dans le temps. A un instant donné, un utilisateur utilise toute la ressource disponible mais pour une période de temps limitée. L'unité de partage élémentaire est donc l'intervalle de temps. Sachant que le support a un débit exprimé bit/s, l'intervalle de temps est une unité de temps, le produit de l'intervalle de temps et du débit donne l'équivalent en terme de quantité de données. D'un point de vue pratique l'intervalle de temps est occupé par la transmission d'un bloc d'octets. Le temps de transmission d'un bloc d'octets est équivalent à l'intervalle de temps.

Figure 1: multiplexage de communications.

Si le principe du découpage de la ressource est posé, il reste la politique d'attribution des intervalles de temps à définir. Le transfert de données en informatique présente un caractère très sporadique. Des périodes d'activités sont suivies de périodes de silence. En pendant les périodes d'activités, il est souhaitable d'obtenir un débit important afin de limiter le temps de transfert du fichier. Dans ces conditions, l'attribution dynamique des intervalles de temps aux communications qui sont en activités représente une solution efficace. Les intervalles de temps qui pourraient être attribuées au communications inactives sont récupérés par celles qui sont actives. En fait une communication en période de silence n'utilise aucune ressource. Comme nous l'avons préalablement indiqué, l'intervalle de temps se présente sous la forme d'un bloc d'octets de taille limitée. Ce bloc est constitué par les données produites par la source. Ce bloc de données est identifié comme appartenant à une communication à l'aide d'une en-tête. La combinaison de l'en-tête et du bloc de données forment le paquet. Le paquet est donc l'unité de partage des ressources dans un réseau. La figure 2 montre une représentation du partage du lien de la figure 1. La transmission des paquets des 3 communications simultanées s'entrelacent au niveau du lien. En l'absence de toute activité, le support reste libre de toute utilisation. Ce mécanisme de multiplexage des communications par entrelacement des paquets des différentes communications simultanées est un moyen simple et efficace de partage dynamique des ressources du lien. Ainsi, lorsqu'une communication est silencieuse ou inactive, l'ensemble des ressources du lien restent partagées par les autres communications du multiplex.

Figure 2: Représentation du partage d'un support.

La figure 3.a illustre la transmission de blocs de données dont la taille ne serait pas limitée. On observe que lorsque un gros bloc est en cours de transmission, il monopolise le support. En coupant ce bloc en bloc de taille plus limitée, la figure 3.b montre un entrelacement des blocs de données. Le partage de la ressource est dans cette situation est bien meilleur.

Figure 3: Représentation du partage d'un support.

Le paquet c'est aussi plus qu'une unité de partage des ressources dans un réseau. C'est aussi l'unité de transfert. Un noeud de commutation reçoit des paquets. Il doit les aiguiller vers un lien en sortie pour atteindre sa destination. La commutation dans un noeud fonctionne sur le principe dit du "store and forward". Le paquet doit être reçu dans son intégralité pour être commuté. C'est à dire transmis sur le lien suivant. Un réseau à commutation de paquets comme l'Internet signifie que l'unité élémentaire d'acheminement est le paquet.

Le paquet a une taille limitée comme vue précédemment. Il a aussi une taille variable toujours par soucis d'efficacité. Le transfert de données en informatique est fondamentalement asymétrique. Dans un sens, circulent les données dans le sens inverse circulent les acquittements pour signaler la bonne ou mauvaise réception des données. Dans cet échange, il y a une grosse quantité de données dans un sens et une quantité plus faible dans l'autre sens avec les acquittements. La taille variable des paquets permet de prendre en compte cette asymétrie dans les quantités échangés.

Acheminement de paquet

Les "matriochkas" des architectures en couches

Les modèles protocolaires d'architectures réseaux en couches, qu'ils soient ISO ou IETF, fonctionnent selon le principe d'encapsulation que l'on peut illustrer avec les célèbres poupées gigognes dites "poupées russes". Dans ce modèle, les unités de données protocolaires (PDU : Protocol Data Unit) échangées par le protocole d'une couche N sont déléguées au service de transfert de données de la couche sous-jacente. En émission, cela consiste pour l'entité de la couche N-1 à encapsuler la PDU-N, confiée pour un transfert, dans la charge utile (champ données) de sa propre unité de données. Ainsi sur un réseau, dont le niveau liaison de données (niveau 2) fonctionne en Ethernet, le datagrammes IP (PDU de niveau 3) est transféré dans le champ données de la trame Ethernet (charge utile de la PDU de niveau 2). En réception c'est le principe inverse (décapsulation) qui s'applique; après vérification protocolaire de la PDU-N-1, l'entité de niveau N-1 remet à l'entité supérieure de niveau N le contenu de sa charge utile à savoir la PDU-N. Ainsi l'entité Ethernet du récepteur, après contrôle d'intégrité de la trame reçue, remet le contenu du champ données à l'entité supérieure (la couche IP). Ce mécanisme d'émission par encapsulation / réception par décapsulation s'applique à toutes les couches du modèle. A l'instar des poupées russes, les PDU des différents niveaux "s'emboitent" en commençant par les couches hautes. Au niveau le plus bas de la transmission, la couche physique, l'unité de données de la couche liaison contient toutes les unités de données imbriquées. Par exemple, pour les applications web modernes basées sur les API de type REST l'enchaînement des imbrications peut être le suivant : les données applicatives (REST) sont encapsulées dans l'unité de données du protocole applicatif web (HTTPS), qui est encapsulée dans le message de transport sécurisé (TLS sur TCP) encapsulé dans le datagramme IPv6 lui même véhiculé dans une trame Ethernet.

Figure 5: Encapsulation des protocoles : les PDU gigognes.

Nous savons depuis la séquence de bienvenue que le protocole IP est dans une couche logicielle superposée au dessus des différents systèmes de transmission. Cette couche est présente dans tous les nœuds de l'Internet. La conséquence de la superposition, et le propre d'une architecture en couches, consiste à ce que chaque unité de données d'une couche lorsqu'elle est passée à la couche inférieure est encapsulée dans l'unité de données de cette couche. La figure 4 illustre le transfert d'un fichier d'un client vers le serveur. Ce fichier est par exemple la requête effectuée par l'application du client. Le fichier (l'unité de données applicative) est découpée en paquets IP pour les raisons que nous avons exposé précédemment. Un paquet IP doit atteindre le serveur qui est la destination finale du transfert de données. Sur le client ce paquet IP, pour être transféré, est passé à l'interface réseau 1 (un système de transmission comme Ethernet par exemple). Celle-ci va procéder à l'encapsulation du paquet IP dans l'unité de données propre au protocole du lien réseau 1 (à savoir une trame Ethernet dans le cas de notre exemple). Le paquet est ainsi transmis du client au routeur qui en recevant la trame, sur son interface d'entrée, décapsule le paquet IP. Il route le paquet en sélectionnant l'interface de sortie vers la destination et lui délègue ce paquet. L'interface de sortie procède alors à l'encapsulation du paquet IP dans la trame propre au protocole de liaison du réseau 2 (par exemple le protocole Point to Point Protocol) pour le transmettre au serveur. L'interface de celui-ci décapsule le paquet de la trame (trame PPP dans notre exemple) qu'elle a reçue. La couche IP du serveur va réassembler toutes les données des paquets IP qu'il reçoit pour reconstituer le fichier original. Une fois ce fichier complet, l'application traite le fichier selon le contexte applicatif. Le paquet IP est transféré de la source à la destination par une succession de sauts (ou hop) d'un noeud à un autre. Pour ce transfert, le paquet subit une série d'encapsulations et de décapsulations.

Chaque nœud utilise l'adresse de destination contenu dans l'en-tête pour prendre une décision de routage à savoir a qui doit être transmis le paquet IP pour le faire converger vers sa destination. Lorsque le système de transmission utilise un support multipoint, il faut avoir recours à une adresse physique, la fameuse adresse MAC qui est mise dans les cartes réseaux. L'adresse MAC du prochain nœud doit être mise dans la trame. Le résultat du routage du paquet IP retourne l'adresse IP du prochain nœud, le destinataire de la trame qui va encapsuler le paquet IP. Pour que la trame soit effectivement remise à ce nœud, il faut que l'adresse de destination de la trame soit justement l'adresse MAC de ce nœud. Cette adresse MAC est obtenu par résolution de l'adresse IP retournée par le routage. La trame avec la bonne adresse MAC de destination sera alors reçu par le next HOP qui pourra alors décapsuler le paquet et procéder au routage pour trouver le nœud suivant qui doit recevoir le paquet. Et ainsi de saut en saut le paquet va arriver à sa destination finale en empruntant des liens de différentes natures.

Figure 4: Transfert d'un paquet IP.

Les mécanismes d’encapsulation

La notion d'encapsulation de protocoles repose sur le principe de l’empilement des couches représentatives des traitements nécessaires à effectuer dans les différents composants d’un réseau. Ces traitements affecteront toutes les couches dans les nœuds d’extrémité, et certaines seulement pour les nœuds intermédiaires.

L’organisation internationale de normalisation ISO a défini le modèle OSI (Open System Interconnection) par une décomposition de l'architecture du réseau en 7 couches représentées du niveau Physique jusqu’au niveau Application comme représentée par la figure 1. Le modèle TCP/IP (ou DOD Department of Defense) a eu une approche plus pragmatique en décomposant l'architecture de réseau en 4 couches. Les couches session, présentation et application sont agrégées en une seule couche applicative propre à chaque protocole.

Figure 1 : Comparaison modèle OSI - modèle TCP/IP.

Pour simplifier l’organisation, pour un nœud d'extrémité du réseau, nous pouvons considérer que la carte réseau réalise les fonctions de niveau Physique et Liaison, que le traitement des couches Réseau et Transport est réalisé par les couches intermédiaires installées dans le système d’exploitation, et que le reste du système, avec les programmes applicatifs, gère les couches Session, Présentation et Application.

Cette activité vise à présenter l’intégration d’IPv6 dans la pile protocolaire. Aussi, nous aborderons l'encapsulation sous l'angle de deux points importants et impactés par le remplacement de IPv4 par IPv6 au sein de la couche de réseau à savoir: la longueur maximale des unités de transfert (Maximum Transmission Unit (MTU)) et la détection des erreurs d'intégrité (ou erreurs binaires). La question de la détection d'erreur binaire se pose dans la mesure où le calcul de redondance a disparu de l'en-tête IPv6.

Traitement des couches basses

La méthode de transfert d'un datagramme IPv6 entre deux nœuds directement reliés entre eux par un lien physique est le même que pour IPv4. Le datagramme est tout d'abord transmis vers l'interface d'émission qui l'encapsule dans une trame. La trame est une PDU (Protocol Data Unit) de niveau 2 dans le modèle de référence OSI. Cette trame est transmise sur le lien avec l'adresse physique du nœud de destination. Cette adresse sur un lien sera appelée adresse MAC dans la suite. Le nœud de destination reçoit la trame sur son interface, désencapsule le datagramme et le traite.

Les différences avec IPv4 sont les suivantes :

• sur le support Ethernet, le RFC 2464 précise que le code protocole encapsulé de la trame est différent (champ EtherType d'une trame Ethernet). Par exemple, pour les réseaux à diffusion, le code est 0x86DD alors que, pour IPv4, le code est 0x0800. À l'origine, il était prévu de garder le même code et d'assurer l'aiguillage entre IPv4 et IPv6 en utilisant le champ Version du paquet. Mais certains nœuds ne vérifient pas la valeur de ce champ et auraient eu un comportement incontrôlable en essayant de traiter un paquet IPv6 comme un paquet IPv4 ;
• la résolution de l'adresse MAC de destination à partir de l'adresse IP de destination du paquet change. Par exemple, sur un réseau à diffusion, cette résolution est faite en IPv4 par le protocole ARP alors qu'en IPv6 on utilise le protocole de découverte de voisins comme nous le verrons dans la séquence 3 ;
• la taille minimale d'une trame est passée à 1 280 octets ; ceci peut forcer certains protocoles à utiliser plusieurs trames par datagramme IPv6 ;
• enfin, certains protocoles ont des parties propres à IPv4. Ces parties doivent être modifiés. C'est le cas des protocoles de contrôle et de compression de PPP.

Couche physique

Commençons par la couche physique, qui est à la base de l’édifice de ce modèle. Les spécifications de cette couche dépendent du support lui-même. Nous devons gérer la transmission des informations binaires issues du codage des trames et des paquets sur un support cuivre, optique ou sans fil ; d’où la nécessité d’adaptation aux caractéristiques des composants (câbles, connecteurs ou antennes) et d’une méthode appropriée de codage des données (représentation physique des données binaires).

La représentation binaire utilisée dépend du support. Sur du cuivre, on utilise des variations d’impulsions électriques ; sur une fibre optique, ce sont des variations lumineuses sur une ou plusieurs longueurs d’ondes ; en transmission sans fil, ce sont généralement des signaux radio, laser ou infrarouge. La couche physique coordonne le débit et la synchronisation de l'émetteur et du récepteur réseau, tout en tentant de garantir la transparence et l’intégrité d’un flux d’information binaire, sans notion d’interprétation du contenu.

Hélas, cette couche est fréquemment soumise à différentes perturbations issues de l'environnement extérieur au canal de transmission : rayonnements électromagnétiques, micro-coupures ou altérations des signaux par différents facteurs. Les coupleurs intégrés dans les cartes réseau réalisent les fonctions nécessaires et utiles au niveau physique, et on dispose d’un indicateur de qualité de la transmission avec le calcul du CRC (Cyclic Redondancy Check).

Couche liaison

Le rôle de la couche liaison est, entre autres, de contrôler l'accès à la couche physique, en réalisant le multiplexage temporel sur le support de transmission, et de transformer la couche physique en une liaison à priori exempte d'erreurs de transmission pour la couche réseau. La couche liaison doit être capable d’écarter le trafic nécessaire à la synchronisation sur le lien physique, et de reconnaître les débuts et fins de trames. Cette couche écarte les trames en cas de réception erronée, comme en cas de non respect du format, ou bien en cas de problème sur la ligne de transmission. La vérification du champ CRC aide à faire ce tri. Cette couche intègre également une fonction de contrôle de flux pour éviter l'engorgement d’un récepteur incapable de suivre un rythme imposé.

L'unité de données de protocole de la couche liaison de données est la trame (Link Protocol Data Unit (LPDU)), qui est composée de plusieurs champs permettant d’identifier l’origine des échanges, le rôle de la trame, le contenu de l’enveloppe et, en fin de trame, le champ CRC, le tout étant encadré par une séquence particulière de codage de début et de fin de trame.

Si nous prenons l’exemple de la trame Ethernet originale (cf. Figure 2), un délai inter-trame minimum de 96 intervalles de temps est spécifié comme silence sur un support cuivre alors que, sur un support optique, tout silence est comblé par la transmission d’un ou plusieurs symboles particuliers « idle » ; une parfaite synchronisation est alors maintenue entre les extrémités du lien optique.

Figure 2 : Format de la trame Ethernet.

Une fois que l’arrivée d’une trame Ethernet est détectée par le coupleur, les premiers champs immédiatement accessibles correspondent aux adresses MAC Destination et Source puis, soit au champ Longueur dans le cas d’une encapsulation au standard 802.3, ou bien au champ EtherType dans le cas d’une encapsulation avec le standard Ethernet original. Ensuite, l’enveloppe de la trame transporte les données, qui correspondent aux paquets IPv6 dès lors que le champ EtherType vaut 0x86dd. Vient ensuite le champ CRC codé sur 32 bits. Dans le cas d’une encapsulation au standard 802.1Q, d’autres champs permettent la reconnaissance du numéro de VLAN (Virtual Local Access Network) et du niveau de priorité défini dans le standard 802.1p.

Un des éléments particulièrement importants est la capacité de transport de la trame. Dans l’exemple ci-dessus, nous voyons que la trame Ethernet traditionnelle dispose d’une enveloppe qui autorise le transport de 1500 octets maximum : MTU = 1500.

D’autres formats de trames permettent des échanges plus ou moins importants. Citons quelques MTU :

• PPPoE = 1492
• PPPoA = 1468
• MPLS = 1500 à 65535
• 802.15.4 (LowPAN) = 81
• Ethernet Jumboframe = 9000

Rappelons que la spécification du protocole IPv6 impose une taille minimale du paquet de 1280 octets. Pour les couches liaison imposant des tailles inférieures, il est donc obligatoire de mettre en place une couche d'adaptation comme 6LowPAN (RFC 4944) pour les réseaux 802.15.4. Cette couche située entre la couche liaison et la couche réseau IPv6 prend en charge le découpage des paquets IPv6 en fragments pouvant être transportés dans les trames et leur ré-assemblage au niveau du premier routeur de sortie.

Couches intermédiaires

Couche réseau

Étant donné que la taille minimum de l’en-tête IPv6 est de 40 octets, le MTU résiduel d’une trame Ethernet classique est de 1500 - 40 = 1460 octets ; sachant que ces 1460 octets de données seront probablement encore amputées d’en-têtes de niveau transport, par exemple 20 octets minimum pour TCP et 8 octets pour UDP.

Parmi les différences existant entre les datagrammes IPv4 et IPv6, il y a la disparition de la somme de contrôle d'erreur (checksum) dans les en-têtes IPv6. Cette somme de contrôle était utilisée pour vérifier l'absence d'erreur binaire de l'en-tête du paquet traité. Une erreur binaire est le changement de valeur d'un bit effectué lors de la transmission. En IPv4, il est nécessaire de la vérifier et de l'ajuster lors de chaque retransmission par un routeur, ce qui entraîne une augmentation du temps de traitement du paquet. Cette somme ne vérifie que l'en-tête IPv4, pas le reste du paquet. Aujourd'hui, les supports physiques sont de meilleure qualité et savent détecter les erreurs (par exemple, Ethernet a toujours calculé sa propre somme de contrôle ; PPP, qui a presque partout remplacé SLIP, possède un CRC). L'intérêt de la somme de contrôle au niveau réseau a diminué et ce champ a été supprimé de l'en-tête IPv6.

Le checksum sur l'en-tête IPv6 n'existant plus, il faut néanmoins se prémunir des erreurs de transmission. En particulier, une erreur sur l'adresse de destination va faire router un paquet dans une mauvaise direction. Le destinataire doit donc vérifier que les informations d'en-tête IP sont correctes avant d'accepter ces paquets. Dans les mises en œuvre des piles de protocoles Internet, les entités de niveau transport remplissent certains champs du niveau réseau. Il a donc été décidé que tous les protocoles au-dessus d'IPv6 devaient utiliser une somme de contrôle intégrant à la fois les données et les informations de l'en-tête IPv6. La notion de pseudo-en-tête dérive de cette conception. Pour un protocole comme TCP, qui possède une somme de contrôle, cela signifie qu'il faut modifier le calcul de cette somme. Pour un protocole comme UDP, qui possède une somme de contrôle facultative, cela signifie qu'il faut modifier le calcul de cette somme et le rendre obligatoire.

IPv6 a unifié la méthode de calcul des différentes sommes de contrôle. Le RFC 8200 définit, dans sa section 8.1, un pseudo-en-tête (cf. Figure 3), résultat de la concaténation d'une partie de l'en-tête IPv6 et du PDU du protocole concerné. L'algorithme de calcul du checksum est celui utilisé en IPv4. Il est très simple à mettre en œuvre et ne demande pas d'opérations complexes. Il s'agit de faire la somme en complément à 1 des mots de 16 bits du pseudo-en-tête, de l'en-tête du protocole de transport, et des données, puis de prendre le complément à 1 du résultat.

Figure 3 : Champs du pseudo-en-tête.

Il faut noter que les informations contenues dans le pseudo-en-tête ne seront pas émises telles quelles sur le réseau. Le champ en-tête suivant du pseudo-en-tête ne reflète pas celui qui sera émis dans les paquets puisque les extensions ne sont pas prises en compte dans le calcul du checksum. Ainsi, si l'extension de routage est mise en œuvre, l'adresse de la destination est celle du dernier nœud. De même, le champ longueur est codé sur 32 bits pour contenir la valeur de l'option jumbogramme si celle-ci est présente.

Couches Transport

UDP et TCP

Les modifications apportées aux protocoles de niveau transport sont minimes. L'un des pré-requis à la mise en œuvre d'IPv6 était de laisser en l'état aussi bien TCP (Transmission Control Protocol) qu'UDP (User Datagram Protocol). Ces protocoles de transport sont utilisés par la très grande majorité des applications réseau et l'absence de modification facilitera grandement le passage de IPv4 à IPv6.

La principale modification de ces protocoles concerne le calcul de la somme de contrôle (checksum) pour vérifier l'intégrité des données. Comme la couche réseau ne possède pas de champ de contrôle, c'est à la couche de transport que revient cette tâche. Le calcul de la somme de contrôle au niveau du transport a donc été adapté pour inclure des données de l'en-tête. De plus, la présence d'une somme de contrôle devient obligatoire pour tout protocole de niveau supérieur transporté au-dessus d'IPv6.

Nota : les RFC 6935 et RFC 6936 ont introduit une dispense à cette obligation, dans les cas des techniques de tunnel au dessus d'UDP. La nouvelle philosophie est résumée ainsi par S. Bortzmeyer : "par défaut, la somme de contrôle doit être calculée et mise dans le paquet. Mais on peut s'en dispenser dans le cas de tunnels (et uniquement celui-ci), sur le paquet extérieur. Le protocole à l'intérieur du paquet (qui n'est pas forcément de l'UDP et même pas forcément de l'IPv6) doit rester protégé par sa propre somme de contrôle. Cela ne doit s'appliquer que pour une liste explicite de ports (ceux utilisés par le tunnel) et pas pour tout le trafic UDP du nœud. Et le tout doit se faire en lisant le RFC 6936 qui précise les conditions d'application de cette nouvelle règle."

Un autre changement au niveau des protocoles de niveau 4 concerne la prise en compte de l'option jumbogramme de l'extension proche-en-proche. Le RFC 2675 définit le comportement d’UDP et de TCP quand les jumbogrammes sont utilisés. En effet, les en-têtes de ces messages contiennent eux aussi un champ longueur codé sur 16 bits et, par conséquent, insuffisant pour coder la longueur du jumbogramme :

• pour le protocole UDP, si la longueur des données excède 65 535 octets, le champ longueur est mis à 0. Le récepteur détermine la longueur des données par la connaissance de la taille dans l'option jumbogramme ;
• le protocole TCP pose plus de problèmes. En effet, bien que les messages TCP ne contiennent pas de champ longueur, plusieurs compteurs sont codés sur 16 bits ;
• le champ longueur de la fenêtre de réception ne pose pas de problème depuis que le RFC 7323 a défini l'option TCP window scale qui donne le facteur multiplicatif qui doit être appliqué à ce champ ;
• à l'ouverture de connexion, la taille maximale des segments (MSS) est négociée. Le RFC 2675 précise que, si cette taille doit être supérieure à 65 535, la valeur 65 535 est envoyée et le récepteur prend en compte la longueur déterminée par l'algorithme de découverte du MTU.

Pour l'envoi de données urgentes avec TCP, on utilise un bit spécifique de l'en-tête TCP (bit URG) ainsi que le champ pointeur urgent. Ce dernier sert à référencer la fin des données à traiter de manière particulière. Trois cas peuvent se présenter :

• le premier, qui est identique à IPv4, est celui où le pointeur indique une position de moins de 65 535 ;
• le second se produit lorsque le déplacement est supérieur à 65 535 et supérieur ou égal à la taille des données TCP envoyées. Cette fois-ci, on place la valeur 65 535 dans le champ pointeur urgent et on continue le traitement normal des paquets TCP ;
• le dernier cas intervient quand le pointeur indique un déplacement de plus de 65 535 qui est inférieur à la taille des données TCP. Un premier paquet est alors envoyé, dans lequel on met la valeur 65 535 dans le champ pointeur urgent. L'important est de choisir une taille de paquet de manière à ce que le déplacement dans le second paquet, pour indiquer la fin des données urgentes, soit inférieur à 65 535.

Il existe d'autres propositions pour faire évoluer TCP. Il faut remarquer que le travail n'est pas de même ampleur que pour IP. En effet, TCP est un protocole de bout en bout. La transition vers une nouvelle génération du protocole peut se faire par négociation entre les deux extrémités. Pour IP, tous les routeurs intermédiaires doivent prendre en compte les modifications.

UDP-lite

UDP-lite permet de remonter aux couches supérieures des données erronées pendant leur transport. Si, dans un environnement informatique, une erreur peut avoir des conséquences relativement graves quant à l'intégrité des données, il est normal de rejeter ces paquets. Dans le domaine du multimédia, cette exigence peut être relâchée. En effet, la plupart des décodeurs de flux audio ou vidéo sont capables de supporter un certain nombre d'erreurs binaires dans un flux de données. Pour améliorer la qualité perçue par l'utilisateur, il est donc préférable d'accepter des paquets erronés plutôt que de rejeter un bloc complet d'informations qui se traduirait par une coupure perceptible du flux.

En IPv4, l'utilisation du checksum UDP étant optionnelle (la valeur 0 indique que le checksum n'est pas calculé), UDP peut être utilisé pour transporter des flux multimédias. Avec IPv6, l'utilisation du checksum a été rendue obligatoire puisque le niveau 3 n'en possède pas. Pour éviter qu'un paquet comportant des erreurs ne puisse pas être remonté aux couches supérieures, le protocole UDP-lite a été défini par le RFC 3828. Les modifications sont minimes par rapport à UDP. Le format de la trame reste le même ; seule la sémantique du champ longueur est changée. Avec UDP, ce champ est inutile puisqu'il est facilement déduit du champ longueur de l'en-tête IP. UDP-lite le transforme en champ couverture du checksum. Si la longueur est 0, UDP-lite considère que le checksum couvre tout le paquet. La valeur 8 indique que seul l'en-tête UDP est protégé par le checksum (ainsi qu'une partie de l'en-tête IP grâce au pseudo-header). Les valeurs comprises entre 1 et 7 sont interdites car le checksum UDP-lite doit toujours couvrir l'en-tête. Une valeur supérieure à 8 indique qu'une partie des données sont protégées. Si la couverture est égale à la longueur du message, on se retrouve dans un cas compatible avec UDP.

SCTP

Le protocole SCTP (Stream Control Transmission Protocol) RFC 9260 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation^[1]. La fiabilité est donc un prérequis important et la gestion de la multi-domiciliation est prise en compte. L'idée est de permettre aux deux nœuds d'extrémité d'échanger, à l'initialisation de la connexion (appelée, dans le standard, association), l'ensemble de leurs adresses IPv4 et IPv6. Chaque nœud choisit une adresse privilégiée pour émettre les données vers l'autre extrémité et surveille périodiquement l'accessibilité des autres adresses. Si le nœud n'est plus accessible par l'adresse principale, une adresse secondaire est choisie.

SCTP permet une transition douce d'IPv4 vers IPv6 puisque l'application n'a plus à se préoccuper de la gestion des adresses. Si les deux entités possèdent une adresse IPv6, celle-ci sera privilégiée. De plus, SCTP peut servir de brique de base à la gestion de la multi-domiciliation IPv6. En effet, avec TCP, une connexion est identifiée par ses adresses. Si une adresse n'est plus accessible, le fait d'en changer peut conduire à la coupure de la connexion. Il faut avoir recours à des subterfuges, comme la mobilité IP, pour maintenir la connexion. SCTP brise ce lien entre la localisation du nœud et l'identification des associations.

Conclusion

Cette activité a fait un rappel des différentes couches de la pile réseau d'un système. La couche réseau, ou niveau 3, est le langage commun de tous les nœuds connectés à l'Internet. L'introduction d'IPv6 a donc un impact sur les différentes couches, notamment la couche sous-jacente, couche liaison, et les couches supérieures, notamment la couche transport.

Même si ces couches sont censées être indépendantes dans le modèle théorique OSI, force est de remarquer que dans la pratique, elles sont interdépendantes. Pour preuve le champ de contrôle d'erreur n'a pas été retenu au niveau de la couche IP car il y a déjà un contrôle fait au niveau liaison. Et un autre contrôle d'erreur a été placé dans les couches supérieures afin de vérifier l'intégrité des données transportées. Cette vérification se fait uniquement par le destinataire. Le contrôle d'erreur est un exemple qui illustre l'interdépendance des couches.

Nous venons d'apprendre comment les communications de données sont mises en oeuvre dans l'Internet.

Introduction de la séquence 2

Dans la première séquence, les différents types d'adresses IPv6 ont été présentés. Cette deuxième séquence va détailler les mécanismes protocolaires. Le fil rouge est la performance du traitement des datagrammes dans tous les équipements et en particulier les équipements intermédiaires tels que les routeurs ou les pare-feux.

Dans cette deuxième séquence du MOOC Objectif IPv6, vous aborderez les différents aspects de ce protocole au travers de cinq activités thématiques :

• A21 : tout d’abord, vous allez découvrir le format et les fonctions de l’en-tête des paquets IPv6 ;
• A22 : puis, vous aborderez les principes de l'acheminement et du routage ;
• A23 : ensuite, les points essentiels de contrôle et diagnostic de l'acheminement par ICMPv6 ;
• A24 : et enfin, vous décomposerez les extensions de l’en-tête IP par le biais de l'exemple de gestion de taille des paquets ;
• Activité pratique : en complément vous pourrez observer l'acheminement de paquets IPv6. Au sein de la même machine virtuelle utilisée lors de la première activité pratique, vous pourrez expérimenter la communication IPv6 sans déstabiliser la configuration de votre ordinateur.

Références bibliographiques

1. ↑ Fu, S. et Atiquzzaman, M. (2004). IEEE Communications Magazine, Vol. 42, No. 4, April. SCTP: State of the Art in Research, Products, and Technical Challenges.

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 2464 : Transmission of IPv6 Packets over Ethernet Networks
• RFC 2675 : IPv6 Jumbograms
• RFC 3828 : The Lightweight User Datagram Protocol (UDP-Lite) Analyse
• RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks
• RFC 5692 : Transmission of IP over Ethernet over IEEE 802.16 networks Analyse
• RFC 6691 : TCP Options and MSS Analyse, depuis intégrées dans les spécifications de TCP dans le RFC 9293
• RFC 6935: IPv6 and UDP Checksums for Tunneled Packets Analyse
• RFC 6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero ChecksumsAnalyse
• RFC 6951 : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication Analyse
• RFC 7323 : TCP Extensions for High Performance Analyse
• RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification Analyse
• RFC 9260 Stream Control Transmission Protocol Analyse