Difference between revisions of "Protocoles de Niveau 4"
From Livre IPv6
m |
(→UDP et TCP) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 7: | Line 7: | ||
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. | 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 | + | Un autre changement au niveau des protocoles de niveau 4 concerne la prise en compte de l'option jumbogramme de l'extension [[Les extensions#PeP|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. | * 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. | ||
| Line 14: | Line 14: | ||
* À 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. | * À 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 : | * 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 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 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. | + | ** 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. | 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. | ||
Latest revision as of 18:23, 22 February 2006
| |
ICMPv6 | Table des matières | Découverte de voisins | |
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 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 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.
| |
ICMPv6 | Table des matières | Découverte de voisins | |
