Pseudo en-tête et Niveau 4

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.

Figure : Champs du pseudo-en-tête

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

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é précédemment, 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 de 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 grave 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 certains 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édia. 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 couche 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 4960 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.