Revision as of 13:11, 26 October 2015

Activité 24: Les mécanismes d’extensions IPv6

Introduction

Le besoin d’étendre l’en-tête IPv6 permet d’ajouter des fonctionnalités supplémentaires impliquant :

• Soit le destinataire du paquet IPv6
• Soit des routeurs intermédiaires étant impliqués dans l’acheminement de ce paquet IPv6

De nombreuses extensions ont été définies, nous allons proposer quelques exemples simples et démonstratifs de ce mécanisme.

Next Header

Figure 1: Localisation du champ Next Header dans l'en-tête IPv6.

Le champ Next Header désigne généralement les couches de protocoles 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 ci-après :

Tableau 1: Valeurs du champ Next Header.

La classification des extensions est fonction de la portée de celles-ci :

• Extension impliquant le destinataire : Destination, ESP, AH, Fragmentation
• Extensions impliquant tous les routeurs intermédiaires : Hop-by-Hop
• Extensions impliquant seulement certains routeurs désignés : Routing

Figure 2: Enchaînement d'extensions

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 en-tête suivant et longueur. Le premier paquet ne contient pas d'extension, le champ en-tête suivant pointe sur ICMPv6. Le second paquet ne contient pas d'extension, le champ en-tête suivant 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, qui finalement pointe sur ICMPv6.

• 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 adresse de destination du paquet IPv6).
• 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 ou restent du domaine de la recherche.

Quelques exemples

Extension de routage

Cette extension permet d'imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau. Pour l'instant seul le routage par la source (type = 0), similaire à l'option Loose Source Routing d'IPv4, est défini pour IPv6. La mobilité IPv6 a également introduit une autre extension de routage (type = 2 ; Optimisation dans le cas du mobile dans un réseau étranger).

Figure 3: Enchaînement d'extensions.

Dans IPv4, le routage peut être strict (le routeur suivant présent dans la liste doit être un voisin directement accessible) ou libéral (loose) (un routeur peut utiliser les tables de routage pour joindre le routeur suivant servant de relais). Dans IPv6, seul le routage libéral est autorisé. En effet, le routage strict était initialement mis en place surtout pour des raisons de sécurité. La source devait être absolument sûre du chemin pris par les paquets. Cette utilisation a maintenant disparu du réseau.

Le principe du routage par la source ou Source Routing dans IPv4 qui vient d’être rappelé ; est le même pour IPv6. L'émetteur met dans le champ destination du paquet IPv6, l'adresse du premier routeur servant de relais, l'extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé comportant une extension de routage par la source, il permute son adresse avec l'adresse du prochain routeur et réémet le paquet vers cette adresse suivante.

Figure 4: Extension de routage

La figure Format de l'extension routage par la source donne le format de l'extension de routage par la source :

• Le champ longueur de l'en-tête indique le nombre de mots de 64 bits qui composent l'extension. Pour l'extension de type 0, cela correspond au nombre d'adresses présentes dans la liste, multiplié par 2.
• Le champ type indique la nature du routage. Pour l'instant, seul le routage par la source, de type 0 est spécifié. La suite de l'en-tête correspond à ce type.
• Le nombre de segments restant est décrémenté après la traversée d'un routeur. Il indique le nombre d'équipements qui doivent encore être traversés. Il permet de trouver l'adresse qui devra être substituée.
• Les 32 bits suivants sont inutilisés pour préserver l'alignement.

La liste comprenant les routeurs à traverser et le destinataire est fournie. Ces adresses ne peuvent pas être multicast.

Dans l’exemple suivant, nous pouvons suivre l’évolution des changements des champs pendant la traversée du réseau du paquet IPv6 :

• Noter l’évolution du champ Segment Left qui pointe vers l’adresse du prochain routeur spécifié apte à traiter l’extension RH0.
• Chaque routeur spécifié successif remplace l’adresse destination du datagramme avec l’adresse pointée par le champ Segment Left, une fois que le pointeur est décrémenté à 0, plus aucun changement ne sera effectué.
• Les routeurs non spécifiés relaient les paquets de manière transparente.

Figure 5: Extension de routage.

Fragmentation

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 à datagramme, 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.

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.

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 grande taille. 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 chez l'émetteur et le réassemblage chez le récepteur.

Figure 6: Format de l'extension de fragmentation

Authentification

L'extension ESP (Encapsulating Security Payload) décrite dans le RFC 2406 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é. Cela nécessite bien entendu l'existence d'une association de sécurité précisant entre autres le(s) algorithme(s) de chiffrement, la (les) clé(s) et un indice de paramètres de sécurité. L'extension ESP est composée d'un en-tête ESP, d'une queue ESP et d'un authentificateur ESP. Suivant le mode de protection sélectionné, l'étendue des champs protégés diffère :

• En mode transport, seules les données de niveau transport du paquet IP (de type TCP, UDP, ICMP) sont protégées. Plus précisément, le chiffrement porte sur les données et sur la queue ESP avec la possibilité de porter sur l'extension destination à condition que celle-ci soit placée dans l'extension ESP (cf. figure Positionnement de l'extension ESP en modes transport et tunnel). La protection en intégrité/authentification porte sur toute l'extension ESP excepté l'authentificateur placé dans le champ authentificateur. Elle assure ainsi la protection des données de niveau transport du paquet IP. L'extension ESP est insérée dans le paquet IP juste après l'en-tête du paquet IP et les extensions avec la possibilité d'avoir l'extension destination placée juste avant l'extension ESP ou encapsulée dans l'extension ESP en première position.
• En mode tunnel, la protection porte sur tout le paquet IP original. C'est-à-dire, le paquet IP original est chiffré avant d'être encapsulé dans l'extension ESP. Cette extension est alors placée dans un nouveau paquet IP dont les en-têtes IP sont en clair (non chiffrés) pour permettre au réseau IP de correctement acheminer le paquet (cf. figure Positionnement de l'extension ESP en modes transport et tunnel). Il s'agit du classique chiffrement des artères. La protection en intégrité/authentification porte sur l'extension ESP (comprenant le paquet IP original) excepté l'authentificateur ESP. L'extension ESP rend le service de confidentialité du flux de façon limitée en ce sens que ce service n'est rendu qu'en mode tunnel et ne porte que sur la confidentialité des adresses IP. En effet, l'extension ESP en mode tunnel réalise le chiffrement de l'intégralité des paquets IP originaux, y compris leurs adresses IP. De ce fait, si les équipements qui mettent en oeuvre IPsec ne sont pas l'émetteur et le destinataire final des paquets, leurs adresses masqueront celles de ces derniers. Un intrus placé en écoute sur le réseau au niveau d'un tunnel IP (entre les passerelles de sécurité) ne pourra pas dans ce cas-là connaître les adresses des stations en communication.

Pour aller plus loin

Vous pouvez approfondir vos connaissances en consultant les liens suivants :

• RFC 2460 : http://tools.ietf.org/html/rfc2460#section-4.1
• RFC 2095 : http://tools.ietf.org/html/rfc5095