Difference between revisions of "MOOC:Compagnon Act24-s6"

From Livre IPv6

(Segment Routing Header (SRH))
 
(29 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
__NOTOC__  
 
__NOTOC__  
=Activité 24 : Le mécanisme d’extension de l'en-tête IPv6=
+
= Activité 24: Les mécanismes d’encapsulation =
 +
{{Approfondissement}}
 +
==Introduction==
 +
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.
  
== Introduction ==
+
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.
 +
<center>
 +
[[image:2015_10_12_Encapsulation_v01.jpg|thumb|center|500px|Figure 1 : Comparaison modèle OSI - modèle TCP/IP.]]
 +
</center>
 +
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.
  
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 :
+
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.
* 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 :
+
== Traitement des couches basses==
* 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.
+
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.
  
== Principe des extensions IPv6==
+
Les différences avec IPv4 sont les suivantes :
  
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).
+
* sur le support Ethernet, le RFC 2464 précise que le code protocole encapsulé de la trame est différent (champ <tt>EtherType</tt> d'une trame Ethernet). Par exemple, pour les réseaux à diffusion, le code est <tt>0x86DD</tt> alors que, pour IPv4, le code est <tt>0x0800</tt>. À 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 <tt>Version</tt> 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 ;
Une extension a une longueur multiple de 8 octets (64 bits). Elle commence  par un champ <tt>Next header</tt> qui définit sur 1 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.
+
* 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.
  
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.
+
=== 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).  
  
'''''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.''
+
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.
  
Une présentation illustrée des extensionsIPv6 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>.
+
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'').
  
== Le champ ''Next Header'' ==
+
=== 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é.
  
<center>
+
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.
[[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).  
+
  
 +
Si nous prenons l’exemple de la trame Ethernet (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.
 
<center>
 
<center>
[[image:2015_10_10_extensions_IPv6_v01.jpg|thumb|center|600px|Figure 2 : Enchaînement d'extensions.]]
+
[[image:2015 10 12 Ethernet v01.jpg|thumb|center|600px|Figure 2 : Format de la trame Ethernet.]]
 
</center>
 
</center>
 +
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 <tt>Destination</tt> et <tt>Source</tt> puis, soit au champ <tt>Longueur</tt> dans le cas d’une encapsulation au standard 802.3, ou bien au champ <tt>EtherType</tt> 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 <tt>EtherType</tt> vaut <tt>0x86dd</tt>. 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.
  
== Quelques exemples ==
+
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.
  
=== Fragmentation ===
+
D’autres formats de trames permettent des échanges plus ou moins importants. Citons quelques MTU :
La fragmentation, telle qu'elle est pratiquée dans IPv4, n'est pas très performante. Initialement, elle servait à rendre transparente les limitations physiques des supports de transmission. Dans IPv4, quand un routeur ne peut pas transmettre un paquet à cause de sa trop grande taille, et si le bit DF ''don't fragment'' est à 0, il découpe l'information à transmettre en fragments. Or, le réseau IP étant un réseau à datagrammes, il n'y a pas de possibilité de contrôler les fragments. Deux fragments successifs peuvent prendre deux chemins différents et, par conséquent, seul le destinataire peut effectuer le ré-assemblage. En conséquence, après la traversée d'un lien impliquant une fragmentation, le reste du réseau ne voit passer que des paquets de taille réduite.  
+
* PPPoE = 1492
 +
* PPPoA = 1468
 +
* MPLS = 1500 à 65535
 +
* 802.15.4 (LowPAN) = 81
 +
* Ethernet Jumboframe = 9000
  
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 1981 : Mécanisme de découverte du PMTU). En pratique, une taille de paquets de 1 500 octets est presque universelle.
+
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.
  
Il existe pourtant des cas où la fragmentation est nécessaire. Ainsi, une application telle que NFS sur UDP suppose que la fragmentation existe et produit des messages de taille quelconque. Comme on ne veut pas modifier ces applications, la couche réseau d'IPv6 doit aussi être capable de gérer la fragmentation. Pour réduire le travail des routeurs intermédiaires, la fragmentation se fera au niveau de la source et le ré-assemblage par le destinataire. Les informations utiles pour ces mécanismes (identification du paquet fragmenté, place du fragment) sont transportées dans une extension de fragmentation, représentée dans la figure 3.
+
== Couches intermédiaires ==
  
<center>
+
=== Couche réseau ===
[[image:2015_10_14_PMTU_5_v01.jpg|thumb|center|600px|Figure 3 : Format de l'extension de fragmentation.]]
+
</center>
+
  
* Le champ longueur de l'extension est remplacé par un champ réservé, positionné pour l'instant à 0. Un champ de longueur est, car l'extension tient sur un seul mot de 64 bits et le premier mot n'est pas compté dans le calcul de longueur des extensions.
+
É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.
* Le <tt>fragment offset</tt> indique, lors du ré-assemblage, la position à laquelle les données du fragment doivent s'insérer. Ceci permet de résoudre les problèmes dus au déséquencement éventuel des datagrammes. Ce champ étant sur 13 bits, la taille des fragments, excepté le dernier, doit être multiple de 8 octets (alignement sur frontière de mots de 64 bits),
+
* Le bit <tt>M</tt> (More data) est à 1 sur les fragments intermédiaires et à 0 sur le fragment final,
+
* Le champ <tt>identification</tt> permet de repérer les fragments appartenant à un même paquet initial pour une source et une destination données.
+
 
+
Le bit DF (Don't Fragment), de l'en-tête IPv4 n'est plus nécessaire. Si un paquet est trop grand, il y aura rejet par le routeur et émission d'un message ICMP.
+
 
+
Dans IPv6, 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 les autres extensions et l'en-tête de niveau 4 ne seront présents que dans le premier fragment.
+
 
+
Le mécanisme de gestion de la taille d'un paquet IPv6, selon les différents cas possibles, est approfondi dans l'activité suivante.
+
 
+
=== 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. C'est-à-dire, 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 lui suffit 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 algorithme(s) de chiffrement, la ou les clé(s), et un indice de paramètres de sécurité.
+
 
+
=== Segment Routing Header (SRH) ===
+
 
+
Cette extension est une des briques qui permet la mise en oeuvre 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 à 100ms, que le débit disponible soit au minimum de 2Mbit/s et que le taux de perte reste inférieur à 1%. La solution habituellement mise en oeuvre 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 doivent accepter la requête.
+
  
 +
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.
 
<center>
 
<center>
[[image:Moocipv6-act24-SRH-rsvp2.png|thumb|center|600px|Figure 4 : Exemple d'utilisation de RSVP-TE pour assurer la qualité de service.]]
+
[[image:Fig4-10.png|thumb|center|500px|Figure 3 : Champs du <tt>pseudo-en-tête</tt>.]]
 
</center>
 
</center>
 +
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 <tt>en-tête suivant</tt> 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 <tt>longueur</tt> est codé sur 32 bits pour contenir la valeur de l'option ''jumbogramme'' si celle-ci est présente.
  
 +
=== Couches Transport ===
  
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. A 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 équipements 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, SR Traffic Engineering, [http://www.segment-routing.net/tutorials/2017-03-06-segment-routing-traffic-engineering-srte/]</ref>.
+
==== UDP et TCP ====
  
Le concept de segment routing a été proposé pour palier à ces désavantages. Il permet de réduire l'intelligence des équipements du réseau. Un contrôleur choisit le chemin qui respecte les besoins de qualité de service du noeud. 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 label MPLS ou dans le cas d'en réseau IPv6 via l'option Segment Routing de l'en-tête <ref> Previdi & al., IPv6 Segment Routing Header (SRH) [https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-06]</ref>. Contrairement à MPLS, le segment routing avec IPv6 ne requière pas que tous les équipements 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és 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.a.d. 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é.
+
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."''
  
<center>
+
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 <tt>longueur</tt> codé sur 16 bits et, par conséquent, insuffisant pour coder la longueur du jumbogramme :
[[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.]]
+
* pour le protocole UDP, si la longueur des données excède 65 535 octets, le champ <tt>longueur</tt> est mis à 0. Le récepteur détermine la longueur des données par la connaissance de la taille dans l'option ''jumbogramme'' ;
</center>
+
* le protocole TCP pose plus de problèmes. En effet, bien que les messages TCP ne contiennent pas de champ <tt>longueur</tt>, plusieurs compteurs sont codés sur 16 bits ;
 +
* le champ <tt>longueur</tt> 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 TCP (bit <tt>URG</tt>) ainsi que le champ <tt>pointeur urgent</tt>. 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 <tt>pointeur urgent</tt> 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 <tt>pointeur urgent</tt>. 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.
  
Le projet de RFC prévoit qu'un segment soit représenté sur 128bit, c.a.d. 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 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é.
+
==== 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.
  
<center>
+
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 <tt>longueur</tt> est changée. Avec UDP, ce champ est inutile puisqu'il est facilement déduit du champ <tt>longueur</tt> de l'en-tête IP. UDP-lite le transforme en champ <tt>couverture du checksum</tt>. 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.
[[image:2015_10_14_IPv6_extension_routage_v02.jpg|thumb|center|400px|Figure 5 : 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 RFC2460 de IPv6. L'en-tête de routage devait notamment permettre le routage à la source 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 la 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-feu ou encore d'utiliser des machines publiques accessibles (en DMZ) pour accéder à des machines privées. <ref>Philippe BIONDI et Arnaud EBALARD, CanSecWest, 2017 .[http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf IPv6 Routing Header Security]</ref>.
+
==== 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<ref>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.</ref>. 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.  
  
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 (e.g. routeur de bordure), les attaques listées dans la RFC5095 sont inopérantes. Les routeurs de bordures doivent simplement filtrer les paquets provenant de l'extérieur pour éviter 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 RFC2104 (option HMAC). La clé de chiffrement de l'en-tête HMAC est distribuée au sein des noeuds autorisés à générer ou manipuler des extensions d'en-têtes SRH.
+
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 ==
 
== 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 communications 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 pris en compte dans le traitement des paquets, notamment le filtrage sur les valeurs du champ ''Next Header'' de l'en-tête IPv6.
+
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.
  
 
== Références bibliographiques ==
 
== Références bibliographiques ==
Line 129: Line 115:
  
 
== Pour aller plus loin==
 
== Pour aller plus loin==
Vous pouvez approfondir vos connaissances en consultant les documents de ce paragraphe.
+
RFC et leur analyse par S. Bortzmeyer :  
RFC et leur analyse par S. Bortzmeyer :
+
* RFC 1323 : TCP Extensions for High Performance [http://www.bortzmeyer.org/1323.html Analyse]
* RFC 1981 : Path MTU Discovery for IP version 6
+
* RFC 2464 : Transmission of IPv6 Packets over Ethernet Networks
* RFC 2460 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/2460.html Analyse]
+
* RFC 2675 : IPv6 Jumbograms
* RFC 4302 : IP Authentication Header
+
* RFC 3828 : The Lightweight User Datagram Protocol (UDP-Lite) [http://www.bortzmeyer.org/3828.html Analyse]
* RFC 4303 : IP Encapsulating Security Payload (ESP)
+
* RFC 4944 : Transmission of IPv6 Packets over IEEE 802.15.4 Networks
* RFC 5095 : Deprecation of Type 0 Routing Headers in IPv6 Specification [http://www.bortzmeyer.org/5095.html Analyse]
+
* RFC 4960 Stream Control Transmission Protocol [http://www.bortzmeyer.org/4960.html Analyse]
* RFC 7045 : Transmission and Processing of IPv6 Extension Headers [http://www.bortzmeyer.org/7045.html Analyse]
+
* RFC 5692 : Transmission of IP over Ethernet over IEEE 802.16 networks [http://www.bortzmeyer.org/5692.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 6691 : TCP Options and MSS [http://www.bortzmeyer.org/6691.html Analyse]
* [http://livre.g6.asso.fr/index.php/S%C3%A9curit%C3%A9 Chapitre Sécurité du livre "IPv6, Théorie et Pratique"]
+
* RFC 6935: IPv6 and UDP Checksums for Tunneled Packets [http://www.bortzmeyer.org/6935.html Analyse]
 +
* RFC 6936: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums[http://www.bortzmeyer.org/6936.html Analyse]
 +
* RFC 6951 : UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication [http://www.bortzmeyer.org/6951.html Analyse]
 +
* RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification [http://www.bortzmeyer.org/8200.html Analyse]

Latest revision as of 15:07, 15 June 2021

Activité 24: Les mécanismes d’encapsulation

Vous suivez une activité d'approfondissementGrad cap.pngGrad cap.png

Introduction

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 (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 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 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 4960 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.

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 :

Personal tools