Le choix de l'IETF

Plusieurs alternatives sont possibles pour résoudre les problèmes introduits par à la mobilité. La première d'entre-elles consiste à changer le fonctionnement même d'IP en modifiant les principes de l'adressage. Des propositions existent pour définir deux espaces d'adressage. Le premier serait dédié à la localisation et le second à l'identification. Mais il s'agit là d'un travail de très longue haleine. La seconde d'entre-elles consiste à ne rien changer au niveau d'IP et à laisser les couches supérieures gérer le problème. Il serait par exemple possible de modifier TCP pour gérer la mobilité (c'est-à-dire le changement d'adresse) au niveau transport. Malheureusement cela ne peut se faire qu'en modifiant la pile TCP ce qui est impensable étant donné le nombre de stations concernées. Par contre des propositions existent pour SCTP qui est un nouveau protocole de transport et n'est donc pas encore déployé à grande échelle. Le niveau applicatif peut aussi prendre en charge la mobilité en gérant la rupture et le ré-établissement automatique des connexions interrompues lors des handovers (épisodes de mobilité).

Toutes ces solutions supposent d'importants travaux de développement et sont difficiles à mettre en oeuvre. Dans la mesure ou le développement d'IPv6 ne s'accompagne pas nécessairement de la modification en profondeur des niveaux protocolaires supérieurs, l'IETF a eu la volonté de gérer la mobilité au niveau de la pile IP et de la rendre transparente aux niveaux supérieurs utilisant le service IP.

Le groupe de travail Mobile IP s'est donc appuyé sur une solution basée sur deux adresses IP et sur le routage « normal » des paquets pour assurer la gestion de la mobilité des n?uds. Des améliorations apportées par la version 6 d'IP et des éléments spécifiques à MIPv6 ont été utilisés pour assurer au mieux la transparence des déplacements. MIPv6 utilise ou définit l'emploi des éléments suivants :

• les en-têtes d'extension protocolaire (protocole 135) ;
• les en-têtes de routage (nouveau type 2) ;
• les en-têtes destination ;
• les mécanismes d'annonce des routeurs (ICMPv6) ;
• la gestion de l'obsolescence des adresses ;
• la sécurisation des paquets (IPsec).

Vue générale de la gestion de la mobilité IPv6

Les mécanismes d'IPv6 vus dans les chapitres précédents offrent une très bonne base à la gestion de la mobilité. En effet, ils résolvent un certain nombre de problèmes qu'avaient à résoudre les solutions de mobilité IPv4. Ainsi, le mécanisme de configuration sans état permet au terminal mobile (MN : Mobile Node) en déplacement d'acquérir une adresse IPv6 globale topologiquement valide. Il peut dès lors communiquer sans contrainte. Le mécanisme d'annonce des routeurs facilite quant à lui la détection du mouvement qui est essentielle à la gestion de la mobilité.

Le principe à la base de la mobilité IPv6 est de séparer les fonctions d'identification et de localisation toutes deux traditionnellement assurées par l'adresse IP. Il s'en suit que lorsque le mobile se déplace, il doit changer d'adresse IP puisque celle-ci le localise dans le réseau. De ce fait, il perd son identité et n'est plus directement joignable à l'adresse connue de ses correspondants et du service de nom. Il est toujours possible d'enregistrer la nouvelle adresse dans un service de nom dynamique (DDNS) mais cela induit un délai très important et ne résout qu'une partie du problème. En effet, l'adresse IP est aussi utilisée par les couches transport (UDP et TCP) pour identifier une connexion. Lorsque l'adresse IP du mobile change, les connexions TCP en cours sont donc rompues.

Pour éviter cela, mobile IP permet au mobile de conserver l'adresse utilisée dans son réseau d'attachement. A des fins d'identification, on parle de home address (HoA) ou adresse mère et de réseau mère ou réseau mère. Ainsi, du point de vue des couches supérieures, le mobile conserve son adresse mère (HoA) quelle que soit sa localisation. Par ailleurs, il acquiert une adresse nouvelle temporaire appelée care-of address (CoA) ou adresse temporaire, locale celle-ci, dans chacun des réseaux qu'il visite, dits réseaux étrangers. Ce second type d'adresses est utilisé à des fins de localisation. Du point de vue de la pile IPv6 le noeud mobile communique toujours avec l'adresse temporaire sauf lorsqu'il est attaché à son réseau mère. Du point de vue des couches protocolaires supérieures le mobile communique toujours avec son adresse mère (cf. figure Différentes adresses utilisées dans la mobilité IPv6).

Une nouvelle entité, le home agent (HA) ou agent mère, localisé dans le réseau mère est chargé d'assurer la correspondance entre la HoA et la CoA du mobile lorsque celui-ci est attaché à un réseau étranger. Cet agent est également chargé de ré-acheminer les paquets IP à destination de l'adresse mère du mobile vers son adresse temporaire dans son réseau visité.

Le mobile dans son réseau mère.

Lorsque le mobile est attaché au réseau mère (cf. figure Envoi de paquets à un mobile situé dans son réseau mère), il dispose de son adresse mère et communique normalement en utilisant sa HoA comme adresse source. Les paquets qui lui sont destinés comprennent l'adresse mère comme adresse destination et sont routés en fonction du préfixe du réseau mère. L'agent mère est inactif. Il n'y a pas de problème de sécurité supplémentaire induit par la gestion de la mobilité puisque le mobile communique de la même manière que n'importe quel noeud IPv6 sur l'Internet.

Le réseau mère n'est pas nécessairement un réseau sur lequel le mobile peut s'attacher, son rôle principal étant d'accueillir le home agent et les adresses mères des mobiles qu'il gère. Il y a toutefois une relation administrative forte entre le mobile et son réseau mère.

Le mobile dans un réseau étranger

Lorsque le mobile est attaché à un réseau étranger, il dispose, en plus de son adresse mère, d'une ou plusieurs adresses temporaires routables acquises par les mécanismes d'auto-configuration avec ou sans états. Une de ses adresses est choisie comme adresse temporaire primaire et est transmise à l'agent mère pour créer une association entre la HoA et cette CoA primaire.

L'agent mère maintient une "table des associations" contenant les associations de tous les mobiles qu'il gère et qui sont en visite dans un réseau étranger (cf. figure Envoi de paquets à un mobile situé hors de son réseau mère - tunnelage). Grâce à ces informations, il peut faire suivre les paquets à destination de la HoA d'un des mobiles vers la CoA primaire de ce dernier. Il encapsule pour cela les paquets en utilisant l'extension d'en-tête IP-IP d'IPv6. Les paquets ainsi tunnelés sont protégés par IPsec.

Le paquet IP retransmis vers le mobile comporte comme adresse source celle du HA et comme adresse destination la CoA primaire du mobile. Le paquet atteint le réseau étranger puisque la CoA primaire a pour préfixe un de ceux du réseau étranger. Le mobile réceptionne ce paquet et découvre l'extension d'en-tête IP dans IP. Il supprime l'en-tête extérieur et remet le paquet aux couches supérieures comme si le mobile avait réceptionné le paquet dans son réseau mère. Ce paquet à donc pour adresse destination l'adresse mère du mobile et pour adresse source l'adresse IPv6 du correspondant émetteur du message. Le quintuplé TCP d'identification d'une session n'est pas modifié. La communication n'est plus rompue lors d'un épisode de mobilité sans qu'il ait été nécessaire de modifier le protocole TCP.

Pour créer une association, ou la mettre à jour lorsqu'il change de réseau étranger, un mobile utilise une signalisation propre à la mobilité IPv6 appelée Binding Update (BU) ou mise à jour d'association. Cette signalisation utilise un nouveau protocole (135) basé sur les extensions d'en-tête IPv6 (cf. figure Mise à jour d'association entre le mobile et l'agent mère).

Une fois l'association mise à jour, le mobile émet les paquets à destination du correspondant en utilisant sa CoA et en ajoutant une extension d'en-tête spéciale appelée HoA. Cette extension d'en-tête est ajoutée de façon transparente aux couches supérieures pour qui la communication est toujours entre le correspondant et la HoA du mobile. Elle comprend la HoA du mobile, la CoA du mobile étant utilisée normalement pour émettre le paquet. Ainsi l'adresse source du paquet dispose d'un préfixe valide dans le réseau étranger et les paquets ne seront pas filtrés par le routeur de sortie.

Lorsqu'il reçoit ce paquet, le correspondant supprime l'extension d'en-tête "home address" et remplace l'adresse source du paquet par la HoA trouvée dans l'extension. Il remet ensuite le paquet aux couches supérieures qui le considèrent comme venant directement du réseau mère du mobile. Pour effectuer ce traitement, le correspondant ne maintient aucun état spécifique aux mobiles avec qui il communique. Ainsi un mobile peut communiquer avec des correspondants ayant un support minimum de la mobilité. Ce support minimum de la mobilité ne monopolise aucune ressource particulière au niveau du correspondant, et n'induit pas de nouveaux problèmes de sécurité ou de performances.

Toutefois, même avec ce mécanisme très simple, les applications, ou les utilisateurs, n'ont pas conscience de la mobilité et par conséquent du fait que le terminal n'est pas dans son réseau mère. Si bien, qu'elles peuvent faire confiance à un environnement réseau connu entre le correspondant et le noeud mobile, par exemple entre deux bâtiments d'un même campus. Le fait de se trouver dans un réseau visité à l'insu des applications peut donc causer des problèmes de sécurité puisque les paquets vont circuler sur une portion de réseau inconnu et potentiellement non sûr. Pour éviter cela, il est possible d'utiliser le tunnel sécurisé entre le mobile et le "home agent" dans les deux sens. La sécurité est ainsi assurée sans que le correspondant local n'ait à supporter la mobilité.

Optimisation dans le cas du mobile dans un réseau étranger

Le routage systématique par l'agent mère du mobile est simple à mettre en oeuvre et très sûr puisque la communication entre l'agent mère et le mobile est sécurisée par IPsec (cf. figure Envoi de paquets à un mobile situé dans son réseau mère - tunnelage inverse). Par contre, elle est particulièrement inefficace au niveau du routage. En effet, si le mobile est en déplacement loin de son réseau mère et qu'il communique avec un serveur proche de lui, il est plus efficace de communiquer directement que de passer par l'agent mère (cf. See Envoi de paquets par un mobile situé hors de son réseau mère). Cela permet d'économiser des ressources dans l'Internet et au niveau du réseau mère qui pourrait avoir des difficultés à monter en charge si les communications de tous les mobiles passent par lui. C'est pourquoi, l'optimisation de routage, qui était une option de mobile IPv4, a été intégrée à Mobile IPv6.

L'optimisation de routage de Mobile IPv6 profite du fait que IPv6 est un nouveau protocole et que des mécanismes liés à la mobilité peuvent lui être intégrés lors de son déploiement. Ainsi pour supporter l'optimisation de routage les noeuds correspondants doivent intégrer des fonctions spécifiques liées à la mobilité.

Lorsqu'un correspondant supporte l'optimisation de routage, il maintient comme l'agent mère une table des associations pour tous les mobiles utilisant l'optimisation de routage avec lesquels il est en communication. Le mobile met à jour l'association qui le concerne en envoyant un message de mise à jour d'association (BU : Binding Update) au correspondant sitôt après qu'il a informé l'agent mère de sa nouvelle localisation. Il doit pour cela maintenir une table des mises à jour d'associations contenant toutes les associations qu'il doit entretenir auprès des correspondants et de l'agent mère. Cet entretien se fait à chaque déplacement et lorsqu'une mise à jour d'association arrive à échéance en échangeant des message de type BU (cf. figure Mise à jour d'association entre le mobile et le correspondant - route optimisée).

Le correspondant qui émet un paquet à destination d'un mobile et qui utilise l'optimisation de routage, trouve dans sa table des associations une association entre la HoA et une CoA. Il remplace alors l'adresse de destination par la CoA et ajoute une extension d'en-tête de routage particulière (de type 2) contenant la HoA du mobile comme adresse de destination finale (cf. figure Envoi de paquets à un mobile situé hors de son réseau mère - route optimisée).

Les extensions d'en-tête de routage peuvent être filtrées pour des raisons de sécurité et pour qu'elles ne soient pas utilisées pour contourner les politiques de sécurité. Le type de l'extension d'en-tête de routage utilisé par Mobile IPv6 est différent pour permettre aux passerelles de sécurité d'appliquer des règles spécifiques aux paquets contenant un en-tête de routage liés à la gestion de la mobilité.

Tous les correspondants IPv6 potentiels ne supportent pas forcément l'optimisation de routage. Dans ce cas, un correspondant répond qu'il ne comprend pas la mise à jour d'association et les communications continuent à passer à travers l'agent mère. Pour, ce faire il utilise un message ICMPv6 spécifique qui informe le noeud mobile.

Le mécanisme de mise à jour d'association pose d'importants problèmes de sécurité. En effet, il est aisé de protégé les échanges de signalisation entre le mobile et l'agent mère du fait de la relation administrative qui permet par exemple l'utilisation d'un secret partagé. C'est beaucoup plus compliqué en ce qui concerne les correspondants et pourtant la sécurité des mises à jour d'association est vitale. Sans protection, il serait possible de détourner les communications d'un mobile en redirigeant le trafic pour l'espionner ou de mener une attaque par déni de service. C'est pourquoi une procédure appelée "test de routage retour" est spécifiée (voir Sécurisation de la signalisation avec les noeuds correspondants).

Traitement du multicast

Pour la gestion du multicast, il faut considérer séparement les différents types de groupes multicast auxquels un n?ud mobile adhère : il y a d'une part les groupes multicast auxquels toute station IPv6 adhère (par exemple le groupe multicast de sollicitation) et ceux auxquels une station adhère pour des besoins applicatifs spécifiques. Enfin il faut considérer la portée des groupes multicast qui peut être globale, locale ou correspondre à un site donné.

Pour ce qui est de la portée, le problème est relativement simple, les paquets multicast de portée locale ne doivent pas être retransmis à un n?ud mobile qui se trouve dans un réseau visité et d'une manière générale, ceux qui n'ont pas une portée globale ne devraient pas l'être.

Lorsqu'un noeud mobile se trouve dans son réseau d'origine (réseau mère) il se comporte comme toute station IPv6 et traite normalement les paquets multicast. Par contre lorsqu'il se trouve dans un réseau étranger, il y a deux manières de gérer les flux multicast :

• soit l'agent mère retransmet vers le mobile les paquets à destination des groupes auxquels ce dernier a adhéré,
• soit le mobile ré-adhère aux groupes multicasts qui l'intéressent à chaque fois qu'il se déplace.

La première méthode suppose que l'agent mère dispose de la plupart des fonctions d'un routeur multicast. Il doit pouvoir comprendre et initier les échanges concernant l'appartenance du noeud mobile aux différents groupes et lui retransmettre les paquets à travers le mécanisme de tunneling.

Dans le second cas, l'agent mère n'assure pas le relayage des paquets multicast et le mobile qui souhaite écouter un groupe après un changement de réseau IPv6 doit se réabonner au groupe en question. Cette solution suppose que l'application prenne en compte la mobilité pour relancer la procédure d'adhésion avec la nouvelle CoA. Ceci constitue un des problèmes que MIPv6 souhaite éviter. Une autre difficulté vient de ce que l'interruption dans la réception d'un flux multicast entre le changement de réseau et la réception du premier paquet multicast à la nouvelle localisation peut être très longue du fait de la procédure d'adhésion.

Lorsque l'agent mère assure la gestion du multicast, le noeud mobile peut choisir pour chaque groupe multicast auquel il adhère, s'il passe par l'agent mère ou par une adhésion directe. Dans ce cas l'agent mère doit supporter le protocole de gestion des groupes multicast (i.e. MLD). De son côté, le mobile qui veut pouvoir profiter de cette fonctionnalité, doit implémenter la partie du protocole de gestion des groupes qui concerne l'hôte et être capable de traiter les paquets multicast encapsulés par l'agent mère.

Lorsque le mobile souhaite recevoir les paquets multicast destiné à un groupe particulier, il émet un paquet MLD d'adhésion au groupe avec pour destination l'adresse multicast des routeurs MLD et pour portée la valeur 1. Ce paquet est transmis à l'agent mère par l'intermédiaire du tunnel inverse entre le mobile et l'agent mère. De la même manière lorsqu'il ne souhaite plus recevoir les paquets de ce groupe, il informe l'agent mère qu'il quitte le groupe par le même moyen. De son côté, l'agent mère agit comme un routeur multicast standard et interroge régulièrement les mobiles en visite sur leur appartenance à des groupes multicast, en utilisant des messages MLD transmis dans les tunnels vers les mobiles.

Ce paquet est transmis à l'agent mère par l'intermédiaire du tunnel inverse entre le mobile et l'agent mère. De la même manière lorsqu'il ne souhaite plus recevoir les paquets de ce groupe, il informe l'agent mère qu'il quitte le groupe par le même moyen. De son côté, l'agent mère agit comme un routeur multicast standard et interroge régulièrement les mobiles qui sont dans des réseaux visités sur leur appartenance à des groupes multicast en utilisant des messages MLD transmis dans les tunnels vers les mobiles. De cette manière, il maintient, pour chaque mobile, une vue à jour des groupes multicast auxquels il appartient et lui fait suivre les paquets multicast par l'intermédiaire du tunnel.

Pour l'émission de paquet multicast, le mobile possède également deux solutions lorsqu'il est hors de son réseau mère :

• Emission des paquets en utilisant le routeur multicast local (celui du réseau visité). Dans ce cas le mobile utilise l'adresse temporaire locale (CoA) comme adresse source et ne doit pas utiliser l'option home address dans les paquets multicast. Dans ce cas, cela implique que l'application doit gérer l'existence d'une adresse locale.
• Utilisation du tunnel pour émettre les paquets à partir du réseau d'origine du mobile à travers l'agent mère. Dans ce cas les déplacements restent transparents aux applications émettant du trafic multicast au niveau du mobile.

La première alternative pose des problèmes insolubles aux protocoles de routage multicast chargés de construire les arbres de diffusion dans le réseau. En effet, à chaque fois que le mobile change de localisation dans l'Internet, les arbres de diffusion déjà construits sont soit inutilisables soit ne correspondent plus au meilleur choix possible. De plus les membres du groupe adhèrent souvent à un groupe et à une source spécifique, ce qui suppose qu'à chaque changement de localisation du mobile, tout le processus de d'adhésion recommence avec une nouvelle adresse de source et que l'arbre de diffusion spécifique à la source soit reconstruit.

La gestion du multicast pose d'importantes difficultés pour la réception aussi. Elle suppose un important travail de la part de l'agent mère qui doit déjà assurer le transfert des paquets unicasts lorsque l'optimisation de routage n'est pas utilisée. En effet, lorsque l'agent mère transformé pour l'occasion en routeur multicast IPv6 doit émettre une requête de demande d'appartenance aux groupes, il ne peut pas la transmettre en multicast comme un routeur multicast IPv6 normal, il doit au contraire envoyer une copie de la requête dans chacun des tunnels correspondant aux mobiles qui se sont enregistrés auprès de lui. De la même manière, il va devoir traiter autant de réponses qu'il y a de mobiles et ceux-ci ne peuvent pas utiliser les mécanismes de MLD qui permettent de limiter le trafic de signalisation.