Activité 22: Les mécanismes d’encapsulation

Introduction

La représentation de l’encapsulation de protocoles utilise 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 équipements d’extrémités, et certaines seulement pour les équipements réalisant le relais des échanges sur le réseau de transport.

Représentation de l'encapsulation

L’organisme ISO a défini le modèle OSI par une représentation en 7 couches représentées du niveau Physique jusqu’au niveau Application, le modèle DOD TCP/IP a simplifié cette représentation.

Figure 1: Comparaison modèle ISO / Stack TCP/IP.

Pour simplifier l’organisation, nous pouvons considérer par exemple que pour une une configuration d’un poste de travail, 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ée 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.

Traitement des couches basses

La méthode de transport d'un datagramme IPv6 entre deux machines directement reliées entre elles par un lien physique est le même que pour IPv4 : le datagramme est tout d'abord routé vers une interface d'émission qui l'encapsule dans une trame (PDU de niveau 2 dans le modèle de référence de l'OSI) ; cette trame est transmise sur le lien vers l'adresse physique de la machine destination (cette adresse sur un lien sera appelée Adresse MAC dans la suite) ; la machine destination reçoit la trame sur son interface, la décapsule et la traite.

Les différences avec IPv4 sont :

• Le code protocole encapsulé de la trame est différent. 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 équipements 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.
• Le calcul de l'adresse MAC destination change. Par exemple sur un réseau à diffusion le calcul est fait en IPv4 par le protocole ARP, alors qu'en IPv6 on utilise le protocole de découverte de voisins .

* 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 issue du codage des trames et des paquets sur un support cuivre, optique ou sans fils ; 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).

La représentation binaire utilisée dépend du support, sur du cuivre on utilise des variations d’impulsions électriques, en optique ce sont des variations lumineuses sur une ou plusieurs longueurs d’ondes, en sans fils ce sont généralement des signaux radios, 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 d’un monde extérieur au canal de transmission, radiations électromagnétiques, microcoupures ou altérations des signaux par différents facteurs. Les coupleurs intégrés dans les cartes réseaux réalisent les fonctions nécessaires et utiles au niveau Physique, et un dispose d’un indicateur de qualité de la transmission avec le calcul de CRC : Contrôle de Redondance Cyclique, appelé Checksum.

Couche liaison

Le rôle de la couche liaison est en autres de transformer la couche physique en une liaison a priori exempte d'erreurs de transmission pour la couche réseau. De plus elle permet d’occuper le lien en fonction des besoins d’émission ou de récupérer toutes les transmissions fiables réceptionnées. Etant donné que pour la couche physique, les données n'ont aucune signification particulière. La couche liaison de données doit donc être capable d’écarter le trafic nécessaire à la synchronisation, et de reconnaître les débuts et fin de trames. Cette couche écarte les trames en cas de réception erronée, comme par exemple 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ée de protocole de la couche liaison de données est la trame (LPDU : Link Protocol Data Unit) qui est composée de plusieurs champs permettant d’identifier l’origine des échanges, le rôle de la trame, et le contenu de l’enveloppe, ainsi en fin de trame le champ CRC, le tout étant encadré par une séquence particulière de codage début et fin de trame.

Si nous prenons l’exemple de la trame Ethernet, 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=0x86dd, vient ensuite le champ CRC codé sur 32 bits. Dans le cas d’encapsulation 802.1Q, d’autres champs permettent la reconnaissance du numéro de vlan 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 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 (MTU=Maximum Transmit Unit).

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

• PPPoE = 1492
• PPPoA = 1468
• MPLS = 1500-65535
• 6LoWPAN = 81
• Ethernet Jumboframe = 9000

Couches intermédiaires

Couche réseau

Etant 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 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. A ce niveau rappelons qu’aucun champ CRC n’a été retenu, car nous en avons déjà au niveau liaison, et les couches supérieures vont s’en charger.

Couches Transport

UDP et TCP

Les modifications apportées aux protocoles de niveau 4 UDP et TCP 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 à ces protocoles concerne le checksum. Comme il a été précisé Checksum au niveau transport, il a été adapté au format de paquet IPv6 et englobe le pseudo-en-tête. De plus, pour UDP, le checksum qui était facultatif en IPv4, devient obligatoire.

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 1323 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 (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 et il est normal de rejeter ces paquets, or, la plupart des décodeurs de flux multimédias 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'information.

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 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 tout 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 2960 est fortement lié au protocole IPv6. SCTP est un protocole de niveau 4 initialement conçu pour transporter des informations de signalisation. 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 équipements terminaux d'échanger à l'initialisation de la connexion (appelée dans le standard association), l'ensemble de leurs adresses IPv4 et IPv6. Chaque équipement choisi 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 l'équipement n'est plus accessible par l'adresse principale, une adresse secondaire sera 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 superfuges, comme la mobilité IP pour maintenir la connexion. SCTP brise ce lien entre la localisation de l'équipement et l'identification des associations.

Rôle du checksum

Parmi les différences existant entre les datagrammes IPv4 et IPv6, il y a la disparition du checksum dans les en-têtes IP. Cette somme de contrôle était utilisée pour vérifier la validité de l'en-tête du paquet traité. 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 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 quand même 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 incorrectes pour éliminer ces paquets. Dans les mises en oeuvre 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 modifier le calcul de cette somme. Pour un protocole comme UDP qui possède une somme de contrôle facultative, cela signifie 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. Celle-ci est calculée sur l'ensemble formé de la concaténation d'un pseudo-en-tête (cf. Champ du pseudo-en-tête) et du paquet 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 compliquées. 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.

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 équipement. De même le champ longueur est sur 32 bits pour contenir la valeur de l'option jumbogramme, si celle-ci est présente.