Amélioration de la gestion de la mobilité IPv6

Table des matières

Un exemple de mise en oeuvre de la pile LIVSIX

Les réseaux mobiles

Un réseau mobile est défini comme un ensemble de sous-réseaux connectés à l'Internet par l'intermédiaire d'un ou plusieurs routeurs mobiles (MR : Mobile Router) qui changent leurs points d'ancrage AR à l'Internet. Les termes MNNs (noeud du réseau mobile) et CN (noeud correspondant) désignent respectivement tout noeud localisé à l'intérieur du réseau mobile et tout noeud communiquant avec un ou plusieurs MNNs. Les interfaces d'un MR connectées sur un sous-réseau mère ou un sous-réseau étranger sont nommées interfaces externes tandis que toutes les autres interfaces sont nommées interfaces internes. Toute interface devant obtenir une adresse sur le lien auquel elle se raccroche, le préfixe de l'interface externe sera le même que celui du sous-réseau mère ou celui du sous-réseau étranger tandis que celui de l'interface interne et de tous les MNNs sera le même que celui du réseau mobile, nommé MNP (Mobile Network Prefix). Ces termes sont illustrés sur la figure Terminologie pour les réseaux mobiles montrant un réseau mobile se déplaçant de son sous-réseau mère vers un autre sous-réseau.

Les Usages

Les usages possibles des réseaux mobiles sont très variés. Ceux-ci incluent entre autres les réseaux de capteurs déployés dans les véhicules (avions, trains, bateaux, voitures) qui ont besoin d'interagir avec des serveurs dans l'Internet, par exemple pour assurer la transmission de données nécessaires à la navigation; les réseaux d'accès déployés dans les transports publics (bus, trains et taxis) offrant une borne d'accès à l'Internet aux passagers; ou encore les réseaux personnels (Personal Area Networks : PANs) constitués d'un ensemble d'appareils électroniques de petite taille (cardio-fréquence mètre, montre, téléphone cellulaire, assistant personnel, appareil photo numérique, etc) portés par les personnes.

De Mobile IP à NEMO

La problématique des réseaux mobiles a fait sommairement son apparition à l'IETF à plusieurs reprises avant de véritablement prendre son envol à partir de 2000.

Les concepteurs de MIPv6 proposent de gérer la mobilité des réseaux de manière similaire à celle des stations, mais ceci est présenté de manière très succincte, en partant de l'observation qu'un réseau mobile n'est rien d'autre qu'un réseau rattaché à un routeur mobile, c'est-à-dire un noeud comme une autre. A chacun de les déplacements, il suffirait donc au MR d'obtenir une adresse temporaire MRCoA et de l'enregistrer auprès de son HA comme dans le cas d'une station mobile. Cette analyse n'a cependant pas été suffisamment poussée par leurs auteurs pour considérer les caractéristiques et les problèmes spécifiques à la mobilité des réseaux. De nombreux problèmes subsistent donc.

Il s'est en effet avéré que MIPv6 n'est pas adapté au support de la mobilité des réseaux comme cela a été démontré dans [Ernst01f-fr] et [Ernst03f]. Le document qui en a été extrait pour être soumis au groupe de travail Mobile IP en août 2000 a, en particulier, mis en avant les insuffisances de MIPv6 pour supporter les stations situées derrière le routeur mobile. D'une part, la spécification ne permet pas au HA de rediriger les paquets destinés aux noeuds situés derrière le MR, et d'autre part le mécanisme d'optimisation du routage est inadéquat. Le support des réseaux mobiles nécessite donc une solution spécifique, mais dont le concept n'est pas forcément très éloigné.

La communauté IETF a donc pris conscience du besoin de traiter le cas des réseaux mobiles comme un sujet à part entière. Pour éviter les interférences avec le développement de Mobile IP, elle a créé, en octobre 2002, un nouveau groupe de travail nommé NEMO (NEtwork MObility). Les contours de son champ de travail ont été difficiles à établir notamment à cause de la confusion souvent faite entre réseaux mobiles et réseaux ad-hoc.

Le groupe de travail NEMO de l'IETF

Le groupe de travail NEMO a décidé lors de sa création d'aborder le problème en deux étapes afin de produire une solution déployable rapidement :

• Support de Base (Basic Support) : Dans un premier temps, le groupe a standardisé dans le RFC 3963 une solution simple permettant de maintenir les sessions pour l'ensemble des MNNs, sans optimisation de routage.
• Support Étendu (Extended Support): Dans un second temps, le groupe se doit d'étudier les problèmes d'optimisation, en particulier l'optimisation du routage. Un document de synthèse décrivant la problématique et les approches potentielles (ne reposant pas nécessairement sur le modèle MIPv6) sera publié. A l'issue de ce document, le groupe devra décider s'il continue ses travaux dans le but de standardiser une ou plusieurs solutions pour l'optimisation du routage, ou déclarer sa fermeture. Dans le premier cas, la charte devra être préalablement redéfinie, à la vue des conclusions du document de synthèse.

Le lecteur intéressé se référera sur le site web du groupe de travail pour retrouver l'ensemble des documents en cours l'étude à l'IETF.

NEMO support de base

La solution pour le support de base est définie sur le modèle MIPv6 (protocole de gestion de la mobilité des stations) selon des règles préalablement édictées par le groupe de travail dans un document dressant la liste des fonctions requises [Ernst-id]. La règle fondamentale est de ne pas imposer de modifications sur les noeuds localisés derrière le routeur mobile (MNNs) et de maintenir les sessions, sans optimisation de routage.

Cette solution permet la seule redirection des paquets destinés aux MNNs vers la position courante du MR. Elle consiste à établir un tunnel bidirectionnel entre le HA et le MR. Le principe de base est que tous les noeuds du réseau mobile partagent le (ou les) même préfixe d'adresse IP (MNP).

Comme dans MIPv6, le support de base gère le problème de la mobilité en allouant deux adresses à chaque interface externe du MR (ou des MRs dans le cas où il y en aurait plusieurs). La première MRHoA est une adresse permanente qui identifie le MR dans le sous-réseau mère. Elle identifie soit l'interface externe et a pour préfixe celui du sous-réseau mère, soit l'interface interne du MR [RFC 3810], et elle a pour préfixe MNP comme chacun des MNNs du même réseau mobile. La seconde (MRCoA) est temporaire (CoA) et est obtenue dans le sous-réseau visité sur lequel l'interface externe du MR prend ancrage. Le protocole établit ainsi une relation entre le préfixe MNP utilisé comme identificateur, et l'adresse temporaire MRCoA, utilisée pour le routage. Seuls les MRs qui changent leur point d'ancrage obtiennent cette nouvelle adresse, les autres MNNs conservent leur seule adresse MNNMNP; la gestion de la mobilité leur est ainsi transparente (cf. figure Support de base de NEMO).

Le MR fait ensuite parvenir l'adresse temporaire primaire MRCoA au moyen d'un message de mise-à-jour des préfixes (PBU) à son agent mère (HA). Les PBUs sont des paquets spéciaux contenant une en-tête d'extension Mobility Header. Lorsque HA reçoit un PBU valide (i.e. obéissant aux tests de conformité liés à la sécurité, particulièrement l'authentification de l'émetteur par son destinataire), l'entrée correspondante au MNP est ajoutée ou mise à jour dans son cache (Binding Cache). Elle instruit le HA d'encapsuler les paquets à destination des stations résidants dans le réseau mobile vers la destination effective du réseau mobile (i.e. MRc) dans la mesure où le préfixe de l'adresse de destination correspond à celui enregistré dans le cache.

Lors d'une communication entre un MNN et un CN, le CN n'a pas connaissance de l'adresse de routage temporaire MRCoA. Les paquets sont donc envoyés normalement vers l'adresse MNNMNP du MNN et routés jusqu'au sous-réseau ayant pour préfixe MNP. Ils parviennent ainsi sur le sous-réseau mère du MR. Les paquets y sont interceptés par le HA puis encapsulés vers MRCoA comme cela est montré sur la See Support de base de NEMO. A la réception d'un paquet encapsulé, le MR le décapsule et le transmet sur son interface interne. Le paquet que reçoit le MNN ne contient donc plus MRCoA; l'opération lui est ainsi transparente. Dans le sens inverse, les paquets sont également encapsulés du MR à son HA.

Le groupe a récemment décidé de débattre de la question de la multi-domiciliation. Un document commun a été publié [NPE-id] dans le but d'analyser le problème et de décider des configurations qui devront être supportées dans le support de base. Le groupe de travail doit également produire quelques documents annexes au protocole NEMO Basic Support, en particulier, la délégation des préfixes, une MIB, et les usages [Thubert-id].

Amélioration de la gestion de la mobilité IPv6

Table des matières

Un exemple de mise en oeuvre de la pile LIVSIX