Le support des rseaux mobiles dans IPv6

Thierry Ernst

To cite this version:

Thierry Ernst. Le support des rseaux mobiles dans IPv6. Revue des Sciences et Technologies de
lInformation - Srie TSI : Technique et Science Informatiques, Lavoisier, 2006, 25 (5), pp.573-598.
<inria-00102315>

HAL Id: inria-00102315

https://hal.inria.fr/inria-00102315
Submitted on 29 Sep 2006

HAL is a multi-disciplinary open access Larchive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
destine au dpt et la diffusion de documents
scientifiques de niveau recherche, publis ou non,
manant des tablissements denseignement et de
recherche franais ou trangers, des laboratoires
publics ou privs.
 SYNTHESE

Le support des rseaux mobiles dans IPv6

Thierry Ernst
INRIA Rocquencourt, Domaine de Voluceau B.P. 105
78153 Le Chesnay Cedex FRANCE
thierry.ernst@inria.fr

RSUM. Les rseaux daccs ou les rseaux de senseurs dploys entre autres dans les trans-
ports ont pour particularit dtre connects lInternet via un ou plusieurs routeurs qui
changent frquemment de point dancrage dans la topologie Internet, ce qui entrane la rup-
ture des sessions ouvertes. Sans un mcanisme de gestion de la mobilit des rseaux, il nest
pas permis denvisager le dveloppement attendu des applications de contrle ou multimdia
dans les rseaux embarqus car ce type dapplication exige une connexion permanente et in-
interrompue Internet. Les travaux traditionnels dans le domaine de la gestion de la mobilit,
notamment Mobile IPv6, permettent aux stations mobiles prises individuellement de maintenir
leurs sessions ouvertes. En revanche, ils ne permettent pas de les maintenir pour les stations
fixes situes derrire un routeur mobile ni pour le rseau mobile pris dans son ensemble. Cet
article se propose donc de faire le tour des travaux portant sur la mobilit des rseaux dans
IPv6. Nous prsentons les usages, les besoins, la problmatique et nous faisons le point sur les
travaux conduits par le groupe NEMO qui a t cr au sein de lIETF. Nous terminons cette
tude par les lments prospectifs portant sur loptimisation du routage.
ABSTRACT. Traditional work turning around mobility support has usually focused on host mobil-
ity, i.e. single terminals which change their point of attachment in the Internet topology, whereas
the most current type of mobility in IPv6 is probably going to be network mobility, i.e. entire
IPv6 networks which border routers change their point of attachment to the Internet topology.
Mobile networks are expected to be found in access networks deployed in public transportation,
and networks of sensors installed in vehicles. Without specific support mechanisms, changing
the point of attachment results into broken sessions. Protocols such as Mobile IPv6 designed
to support host mobility are either inappropriate or inefficient to support network mobility. Ex-
tensions to Mobile IPv6 have therefore been proposed and are currently discussed in the IETF
NEMO working group. The purpose of this paper is to explain the problem caused by network
mobility in IPv6 and to overview the current activities of this promising topic.
MOTS-CLS : support de la mobilit des rseaux, rseaux mobiles, NEMO, IPv6, Mobile IPv6.
KEYWORDS: network mobility, mobile network, NEMO, IPv6, Mobile IPv6.

RSTI - TSI. Volume 25 no 5/2006, pages 573 597

574 RSTI - TSI. Volume 25 no 5/2006

1. Introduction

Par mobilit dans Internet, on considre gnralement le dplacement dans la to-

pologie Internet dun quipement de type ordinateur ou tlphone portable. Or, la
notion de mobilit peut stendre aux rseaux eux-mmes ds lors que les rseaux
dans lesquels sont dploys ces quipements deviennent eux-mmes mobiles. Cest
le cas pour les rseaux de capteurs embarqus dans les vhicules, les rseaux daccs
dploys dans les transports, ou les rseaux personnels (PANs). Le besoin de connec-
ter ces rseaux Internet est suscit soit par les fabricants de vhicules, soit par les
compagnies de transport, soit par les usagers eux-mmes. Ceci permet alors la collecte
de donnes et le dploiement dapplications multimdia en tout lieu et tout instant.
Tout quipement, quil soit fixe ou mobile par rapport au rseau dans lequel il
sattache, est donc en mesure de se dplacer gographiquement et topologiquement.
Le dplacement gographique peut impliquer le changement de technologie daccs,
donc de qualit de service, de bande passante, de rgles dusages (contrle daccs),
et une vulnrabilit accrue face aux failles de scurit. Le dplacement gographique
a en gnral pour consquence un dplacement dans la topologie Internet ce qui im-
plique un changement dadresse IP. Or, ladresse IP est utilise la fois pour dter-
miner la position de lquipement dans la topologie Internet, et pour identifier les
sessions tablies avec cet quipement. Un mcanisme de gestion de la mobilit est
alors indispensable pour fournir une connectivit Internet permanente sans rompre les
communications en cours suite ce changement dadresse IP.
Les travaux dans le domaine de la gestion de la mobilit dans IPv6 se sont dans
un premier temps exclusivement consacrs au support des stations mobiles, cest--
dire les terminaux changeant individuellement de point dancrage dans la topologie
Internet. En revanche, les travaux se proccupant des problmes spcifiques lis au
dplacement simultan dun ensemble dquipement regroups en rseau nont rel-
lement vu le jour que rcemment.
Le but de cet article est donc de mettre laccent sur la notion de rseau mobile
qui, tant relativement rcente, nest pas forcment connue de tous. Dans un premier
temps, nous dcrivons quelques usages possibles des rseaux mobiles (section 2) puis
nous prsentons quelques gnralits sur lorganisation de lInternet, ladressage et
la problmatique de la mobilit lie au modle dadressage dans TCP/IP (section 3).
Partant de l, nous discutons des caractristiques et des besoins des rseaux mobiles
(section 4) avant de dresser ltat davancement des travaux de lIETF (Internet Engi-
neering Task Force) permettant le support de la mobilit des rseaux, notamment au
sein du groupe de travail NEMO (section 5). Sen suit une revue des travaux connus
ce jour pour rsoudre la question de loptimisation du routage, classs selon le type
dapproche (section 6). Avant de conclure cet article, nous prsenterons quelques pro-
jets et implmentations des mcanismes du support des rseaux mobiles (section 7).
Cette tude est exclusivement consacre IPv6 (Deering et al., 1998; Cizault,
2005) car il nest pas envisageable de dployer de tels rseaux mobiles dans IPv4,
dautant plus quaucun travail concret ny est rpertori. Les termes utiliss dans cet
 Les rseaux mobiles dans IPv6 575

article sont essentiellement les traductions des termes extraits de (Manner et al., 2004)
qui offre une terminologie applique la mobilit relativement complte, et de (Ernst
et al., 2006) qui dfinit une terminologie spcifique la problmatique de la mobilit
des rseaux. Le lecteur intress par les aspects techniques se rfrera la page web
non officielle du groupe NEMO1 pour retrouver lensemble des documents relatifs
aux travaux de lIETF. Quant ceux plutt intresss par les aspects prospectifs, ils
porteront un regard attentif sur les sections 5.5 et 6.

2. Les usages

De nombreux usages des rseaux mobiles sont envisags. Ceux-ci incluent en par-
ticulier les rseaux personnels (Personal Area Networks, ou PANs) et les rseaux d-
ploys dans les vhicules (Vehicular Area Network, ou VANs), cest--dire les rseaux
de capteurs et les rseaux daccs :
Cas des rseaux de capteurs : ceux-ci sont dploys dans les vhicules (avions,
trains, bateaux, voitures). Certains ont besoin dinteragir avec des serveurs dans lIn-
ternet, par exemple pour assurer la transmission de donnes ncessaires la naviga-
tion, pour procder la maintenance et au contrle de ltat du vhicule, etc. Un autre
exemple, encore futuriste, est celui des vtements intelligents dans lesquels sont incor-
pors des capteurs (humidit, temprature, rythme cardiaque, tension artrielle, etc.)
permettant entre autres le contrle en temps rel de ltat de sant dun patient.
Cas des rseaux daccs : ceux-ci sont dploys dans les transports publics
(bus, trains et taxis) et permettent doffrir une borne daccs Internet aux passagers.
Lexemple le plus typique est celui dun vhicule disposant dun accs Internet par le
biais de technologies sans fil varies (cellulaire, IEEE 802.11, Bluetooth, satellite) afin
damliorer la scurit et la navigation et de fournir du contenu multimdia aux passa-
gers, tout ceci en temps rel (Kellerer et al., 2001; Ernst et al., 2002; Lach et al., 2003).
Ce type de rseau embarqu a pour caractristique principale le changement frquent
de point dancrage, non seulement cause de sa vitesse de dplacement, mais aussi
cause de la varit des technologies offertes en fonction du pays, de la densit de
la circulation, de la densit durbanisation, etc. Un autre exemple tout aussi dmons-
tratif est celui dune compagnie de transport ferroviaire ou arienne offrant un accs
Internet permanent et ininterrompu ses passagers. Cet accs pourra non seulement
permettre aux passagers de se connecter sur un site distant, de tlcharger de la mu-
sique et de la vido depuis nimporte quel fournisseur de service, ou de surfer sur la
toile sans interruption de service en utilisant les appareils proposs par la compagnie,
mais aussi de sy connecter en utilisant leur propre ordinateur portable ou tlphone.
Ce scnario est dailleurs mentionn depuis longtemps dans (Tanenbaum, 1996), sec-
tion 5.15 ; (Partridge, 1994), sections 1.2.4 et 5.5.8 ; (Perkins, 1998), section 5.12 ;
(Solomon, 1998), section 11.2, (Perkins, 2002) section 4.5. Deux expriences de ce
type ont dj t conduites en 2002 par deux compagnies ferroviaires distinctes de la

1. Page additionnelle du groupe NEMO : http ://www.mobilenetworks.org/nemo

576 RSTI - TSI. Volume 25 no 5/2006

banlieue de Tokyo. La compagnie JR permettait, bon escient pendant la dure de

la runion de lIETF Yokohama en juillet 2002, aux passagers du premier wagon
de connecter leur ordinateur portable Internet via une connexion IEEE 802.11b sur
un botier IPv6 embarqu dans le train reliant Yokohama laroport Narita2 . Dans
lexprience, un utilisateur disposant dun accs sans fil 802.11b sur son ordinateur
portable pouvait se connecter Internet via ce botier, lui-mme connect lInternet
via une connexion IEEE 802.11b lors des arrts en gare, et via le rseau cellulaire
pendant les dplacements. La deuxime exprience, conduite avec la compagnie Oda-
kyu en utilisant le code dvelopp au sein de Jun Murai Lab, Keio University, tait
plus modeste, et avait pour but de connecter un routeur Internet, et de tester les
changements dinterface entre IEEE 802.11b (lors des arrts en terminus), et le rseau
cellulaire (pendant les dplacements).
Cas spcifique de lautomobile : le domaine des systmes embarqus bord des
vhicules jouit actuellement dun grand engouement un peu partout dans le monde. Il
existe en effet de nombreux projets gnralement regroups sous la dnomination ITS
(Intelligent Transportation Systems) qui visent amliorer la scurit routire, la na-
vigation, la conduite, la disponibilit et lentretien des vhicules. Ceci ncessite la
transmission de donnes entre vhicules, ou entre un vhicule et linfrastructure rou-
tire ou lInternet. On citera en autres le projet RNRT3 Everyware labellis en octobre
2002 comprenant notamment Renault et France Telecom ; le consortium InternetITS4,
un projet de grande envergure runissant au Japon une centaine dindustriels et duni-
versitaires travaillant en relation troite avec les fabriquants dautomobiles (le systme
de communication mis en place est en fait celui dvelopp par le projet ICAR dcrit
dans la section 7) ; et le projet FleeNet.
Cas spcifique de laviation : dans ce cas spcifique, outre son utilisation par
les passagers, lInternet peut aussi servir la maintenance et la gestion de la flotte
par la compagnie arienne, ainsi qu changer les donnes destines la navigation
entre lavion et les tours de contrle arien. Ce dernier scnario a justement fait lobjet
de recherches de la part dEurocontrol (une organisation europenne pour la scurit
de la navigation arienne) (Robert, 1999; Quinot, 1998), ainsi que de la part dAir-
bus (AFIS) et Boeing (Corenet). Le cas de lavion est particulier car celui-ci change
rarement de point dancrage. Au cours dun vol international, lavion est connect
via un satellite go-stationnaire au-dessus des ocans, via un lien radio au-dessus des
terres (Terry, 2004), et via un WLAN de type 802.11 lors des stationnements. Un ser-
vice commercial (connexion) dvelopp par Boeing et permettant laccs Internet en
vol a t lanc sur certaines compagnies en 20045.
Cas des rseaux personnels : les PANs sont des rseaux constitus dun en-
semble dappareils lectroniques de petite taille (cardio-frquence-mtre, montre, t-
lphone cellulaire, assistant personnel, appareil photo digital, etc.) ports par les per-
sonnes. De nombreux scnarii dutilisation des PANs peuvent tre imagins, notam-

2. JR Narita Express (NEX) : http ://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20020702/1/

3. RNRT : Rseau National de Recherche en Tlcommunications, France.
4. InternetITS : http ://www.internetITS.org
5. voir la prsentation de Boeing lors de l assemble plnire du 62e IETF en mars 2005.
 Les rseaux mobiles dans IPv6 577

ment pour des applications lies la scurit civile (police, pompiers) (Boot, 2002),
la mdecine (Ernst, 2004) et bien entendu aussi larme. Par exemple, un fauteuil
roulant, un sac, ou un vlo quip dun PAN pourrait permettre, un handicap mo-
teur, une personne ayant des dficiences mentales, ou un sportif, dtre suivi
distance et en temps rel (par un mdecin, la famille, la cellule antidopage, etc.) et
dappeler automatiquement les secours en cas de dfaillance, voire de prodiguer des
conseils immdiats la victime. Ces scnarii sont tudis but dmonstratif dans le
projet Nautilus6 (voir section 7) et pourraient aussi bien rpondre aux besoins de la
police, des pompiers, des journalistes, etc.

3. Gnralits sur la mobilit des stations et des rseaux

Dans cette section, nous expliquons brivement la problmatique de la mobilit

lie au modle dadressage de TCP/IP :
Organisation de lInternet et modle adressage : lInternet est une agglom-
ration de rseaux partitionns en plusieurs domaines. Au niveau logique, un domaine
reprsente dordinaire une universit, une entreprise, ou un fournisseur de service.
Un domaine peut lui-mme tre divis en sites, par exemple chaque campus au sein
dune universit ou chaque usine au sein dune entreprise. Au niveau physique, chaque
site ou domaine se dcompose en sous-rseaux, eux-mmes constitus dun lien (e.g.
Ethernet) et de lensemble des nuds se trouvant sur ce mme lien. Les nuds sont de
deux types. Ceux qui relient un sous-rseau un autre sont des routeurs, les autres de
simples stations. A chaque sous-rseau, correspond un prfixe IP qui permet diden-
tifier la position du sous-rseau dans la hirarchie de lInternet. Tous les nuds ayant
une interface sur un sous-rseau donn ont donc une adresse IP correspondant au
prfixe de ce sous-rseau. Cette adresse identifie la fois la position topologique du
nud, et le nud lui-mme6 . Ladresse IP est donc intrinsquement lie la position
du nud dans la topologie Internet. En rsum, un rseau est un ensemble de sous-
rseaux, cest--dire de liens et de nuds partageant le mme prfixe IP et connects
lInternet par le biais dun ou plusieurs routeurs externes.
Problmatique de la mobilit : un nud mobile (MN) est un nud qui change
son point dancrage dans la topologie Internet, cest--dire qui se dplace dun sous-
rseau un autre. Dans le cas des stations, nous parlons de station mobile, dans le cas
de routeur, de routeur mobile (MR). Les routeurs daccs (ARs) sont les routeurs qui
desservent les liens o les noeuds mobiles peuvent prendre ancrage. Le point dan-
crage initial est appel sous-rseau mre tandis que chaque point dancrage subs-
quent est appel sous-rseau visit. Le problme pos par la mobilit vient essentiel-
lement du modle dadressage de TCP/IP qui confond le rle didentifiant dinterface
de ladresse IP, et son rle didentifiant de la localisation dans la topologie Internet
qui est hirarchise. Si un nud change demplacement dans la topologie Internet

6. En fait, ladresse IP identifie linterface dun nud, mais pour simplifier nous nous conten-
tons souvent de dire que ladresse identifie le nud.
578 RSTI - TSI. Volume 25 no 5/2006

HA VMN
CN

Internet
HA MR
AR

sousrseau visit sousrseau mre

Misejour MNN (LFN)

MR
Cache

MNN Noeud du Rseau Mobile MNN

MR Routeur Mobile
HA Agent Mre MNN (VMN)
AR Routeur dAccs

Figure 1. Terminologie pour les Rseaux Mobiles

ladresse IP qui identifie linterface qui change demplacement doit changer. Ce chan-
gement dadresse a pour consquence de rompre les sessions ouvertes qui se servent
de ladresse IP comme identificateur tandis que le changement demplacement nces-
site un re-routage. Le support de la mobilit a donc pour but, dune part de dfinir
un mcanisme permettant de maintenir les sessions ouvertes lors des dplacements, et
dautre part de dterminer la nouvelle position du nud dans la topologie (localisa-
tion et routage). Ceci se fait gnralement au prix de messages de contrle (signalisa-
tion). Pour de plus amples dtails, nous invitons le lecteur se rfrer par exemple
(Ernst, 2001) (chapitre 2) ou (Soliman, 2004) (chapitre 1).
Rseau mobile : un rseau mobile est dfini comme un sous-rseau ou un en-
semble de sous-rseaux connects lInternet par lintermdiaire dun ou plusieurs
routeurs mobiles qui changent leurs points dancrage (AR) lInternet. Les termes
MNNs (Mobile Network Node) et CN (Correspondent Node) dsignent respective-
ment tout nud localis lintrieur du rseau mobile derrire le MR, et tout nud
communiquant avec un ou plusieurs MNNs. Les interfaces dun MR connectes sur
un sous-rseau mre ou un sous-rseau visit sont nommes interfaces externes tan-
dis que toutes les autres interfaces sont nommes interfaces internes. Toute interface
devant disposer dune adresse sur le lien auquel elle est raccroche, le prfixe de lin-
terface externe sera le mme que celui du sous-rseau mre ou celui du sous-rseau
visit, tandis que le prfixe publi dans le rseau mobile (MNP ou Mobile Network
Prefix) servira configurer les adresses de linterface interne du MR et de tous les
MNNs. Ces termes sont illustrs sur la figure 1 qui montre un rseau mobile se dpla-
ant de son sous-rseau mre vers un autre sous-rseau.
 Les rseaux mobiles dans IPv6 579

4. Caractristiques et besoins au niveau de larchitecture IPv6

Les scnarii prsents dans la section 2 justifient tous le besoin dun certain
nombre dquipements interconnects entre eux, et le besoin dun accs Internet direct
pour certains, donc un rseau embarqu de type IP, cest--dire un rseau mobile. Ils
dmontrent aussi que les rseaux mobiles peuvent avoir des caractristiques et donc
des besoins trs diffrents dun cas lautre :
Taille : les rseaux mobiles peuvent tre de taille variable, allant de lordre de
quelques MNNs dans le cas dun PAN jusqu plusieurs centaines de stations inter-
connectes par plusieurs routeurs et sous-rseaux dans le cas dun train. Le nombre de
correspondants (CNs), quant lui, est indpendant du nombre de MNNs, mais peut po-
tentiellement tre trs grand. Par exemple, une source vido mise depuis un vhicule
peut avoir elle seule un nombre de rcepteurs du mme ordre de grandeur que celui
de la multitude de correspondants de lensemble des passagers dun train, mme si le
second cas semble plus raliste. Dans un cas comme dans lautre, un grand nombre
de sessions peuvent avoir lieu simultanment, toutes transitant via le MR. Ainsi, la
quantit de trafic induit par ou vers un rseau mobile est dautant plus significative
que le nombre de CNs est grand. Pour permettre un passage lchelle, il conviendra
donc de prendre en considration non seulement le nombre de rseaux mobiles, mais
aussi le nombre de correspondants. Ceci nous permet de faire une comparaison avec
la gestion de la mobilit pour les stations mobiles o le seul paramtre pris en compte
jusqu prsent est le nombre de stations mobiles.
Htrognit des MNNs : les nuds embarqus (MNNs) peuvent tre de trois
types. Un LFN (Local Fixe Node) est un nud rsidant de manire permanente dans
le rseau mobile et ne changeant pas son point dancrage (par exemple un capteur de
pression des pneus ou de temprature). Un LMN (Local Mobile Node) est un nud
mobile appartenant au rseau mobile et capable de changer son point dancrage dans le
rseau mobile, voire de le quitter (e.g. la clef du vhicule), tandis quun VMN (Visiting
Mobile Node) est un nud mobile nappartenant pas au rseau mobile mais capable de
sy attacher (e.g. quipements appartenant aux passagers tels un ordinateur portable
ou un PDA).
Mobilit enchane (Nested Mobility) : un rseau mobile pouvant accueillir soit
une station mobile, soit un routeur mobile servant lui-mme de passerelle un autre r-
seau mobile, la mobilit des rseaux peut tre rcursive. Dans le cas dun bus servi par
un MR et offrant un accs Internet aux stations mobiles (VMN) des passagers, nous
avons deux niveaux de mobilit. Dans le cas dun passager disposant dun PAN qui
son tour permet lancrage dun VMN, nous devons faire face trois niveaux de mo-
bilit. Le rseau et les MRs qui connectent lensemble Internet sont respectivement
appels root-NEMO et root-MR. Les autres rseaux (respectivement MRs) se servant
dun root-NEMO pour se connecter Internet sont nomms sub-NEMO et sub-MRs.
Deux niveaux de mobilit sont illustrs sur la figure 1. Le rseau mobile y accueille
une station mobile (VMN) issue dun autre sous-rseau (identifi par HAV MN ).
Htrognit des rseaux daccs : au vu de lexemple de lautomobile qui
peut tre amene se dplacer sur de longues distances, passer dun milieu urbain
580 RSTI - TSI. Volume 25 no 5/2006

aux technologies daccs varies un milieu rural pauvre en ressources disponibles,

changer de pays, etc., nous constatons que dune part un rseau mobile peut prendre
ancrage lInternet via des points trs loigns dans la topologie, et dautre part le faire
par le biais de technologies htrognes. Il est ainsi raisonnable de considrer le cas
o les rseaux mobiles non seulement changent de rseau daccs, mais certainement
aussi de fournisseurs de service ou de domaine administratif (mobilit globale). Dans
un tel cas, la scurisation des donnes de contrle, le contrle daccs aux ressources
du rseau visit, et ladaptation des applications la bande passante disponible sont
des besoins cruciaux.
Multidomiciliation (Multihoming) : un rseau mobile est dit multidomicili
lorsquil a plusieurs points dancrage Internet, cest--dire lorsquil est simultan-
ment connect Internet via plusieurs MRs ou lorsquun MR a plusieurs interfaces
externes, ou plusieurs adresses sur son interface externe. Les motivations et les bn-
fices attendus sont les mmes pour un rseau fixe ou mobile, mais la mobilit rend
cette configuration plus frquente. En effet, une telle configuration permet de pallier
aux pannes, de partager les flux, de mettre en place des prfrences ou plus simple-
ment de garantir un meilleur accs lInternet en faisant appel plusieurs technolo-
gies. Cette possibilit de se connecter par lintermdiaire dun ou plusieurs routeurs
mobiles disposant au total de plusieurs interfaces externes ncessite de considrer les
aspects de changement dinterface et de changement de routeur mobile.
Interaction entre rseau Ad Hoc et rseau mobile : les rseaux ad hoc sont
des rseaux sans infrastructure, dont lensemble des nuds sont des routeurs mobiles,
avec ou sans sous-rseau attach leur interface interne, et dont la topologie est trs
dynamique. Les routes de la source la destination (en rgle gnrale toutes deux si-
tues lintrieur du rseau ad hoc) sont calcules dynamiquement. Lhtrognit
des MNNs peut mener confondre rseaux mobiles et rseaux ad hoc car il est pos-
sible quun rseau ad hoc constitue un rseau mobile et inversement quun ensemble
de rseaux mobile constitue un rseau ad hoc. Par exemple, les passagers dun train
peuvent former un rseau ad hoc. Si la connectivit Internet est offerte par le biais
dune passerelle bord du train changeant son point dancrage (i.e. un MR), il sagit
dun rseau mobile constitu de nuds ad hocs. En revanche, lorsque des rseaux sont
embarqus dans des vhicules, et quune flotte de vhicules de ce type forme un r-
seau ad hoc, nous avons un rseau ad hoc constitu de rseaux mobiles (Kellerer et
al., 2001).
Frquence distincte de changement du point dancrage : chaque configu-
ration, et selon lusage, correspond une certaine frquence de mobilit. Un mtro,
par exemple, suit une trajectoire dtermine vitesse dtermine, probablement au
sein dun seul fournisseur daccs. Les handovers sont donc prvisibles. Un piton ou
une automobile en milieu urbain, en revanche, change de trajectoire, de vitesse, et de
rseau daccs ; les handovers sont donc trs difficilement prvisibles. Ils seront en
revanche semi-prvisibles dans le cas dune voiture sur autoroute.
 Les rseaux mobiles dans IPv6 581

Type Mobilit quipements Besoins Particuliers

Vhicule personnel forte petit nombre, handovers verticaux
ou bus interurbain locale et globale essentiellement LFNs, multidomiciliation
(zone urbaine ou faiblement urbanise, plusieurs technologies daccs
franchissement des frontires
Train ou bus urbain moyenne quelques dizaines ou centaines contrle daccs
locale ( lintrieur en majorit VMNs handovers horizontaux
dun rseau daccs (appartenant aux passagers) multidomiciliation
propritaire) 1 ou 2 technologies daccs mobilit enchane
Avion faible, quelques dizaines ou centaines scurit renforce
locale (rseau appartenant aux en majorit VMNs contrle daccs
oprateurs de satellite et aroports) 2 ou 3 technologies daccs handovers verticaux
(satellite, radio, wi-fi) mobilit enchane
multidomiciliation
PAN faible (selon lusage) petit nombre connectivit globale
zone urbaine plusieurs technologies daccs handovers verticaux

Tableau 1. Les caractristiques par type

Besoins des Utilisateurs Besoins du Systme Type

grand nombre de rseaux mobiles IPv6 F, D
grand nombre dquipements F, D
interconnexion des quipements rseau embarqu F
accs continu Internet support des rseaux mobiles F
technologies daccs multiples F,D
multidomiciliation F,P
handovers horizontaux /verticaux F
quipements standards et transparence de la mobilit pour LFNs D
faible cot des quipements (compatibilit avec lexistant)
connecter tlphone mobile, PDA support stations mobiles F
connecter PAN support mobilit enchane F
qualit, performance handovers rapides P
faible cot de la signalisation P
routage optimal P
maintenance, facilit dutilisation auto-configuration F,D
scurit contrle daccs F
(autorisation, authentification) F
confidentialit F

Tableau 2. Les besoins : fonctionnel (F), de performance (P), de dploiement (P)

Le tableau 1 rsume le type de mobilit, dquipement et les besoins correspondant

certains usages des rseaux mobiles. Le tableau 2 rsume les fonctions requises selon
les besoins de lutilisateur.

5. Les travaux de lIETF

Que ce soit une station qui se dplace ou un MR avec le rseau qui lui est attach,
le problme est relativement similaire. Cependant, la problmatique habituelle du
changement dadresse sen ajoute dautres propres aux rseaux mobiles. Nous com-
menons donc par analyser laptitude de Mobile IPv6 (i.e. la solution pour le support
des stations mobiles) supporter la mobilit des rseaux. Nous prsentons ensuite les
tapes qui ont conduit la cration dun nouveau groupe de travail lIETF pour trai-
ter le cas spcifique des rseaux mobiles, et nous dtaillons la solution recommande
par cette organisation, ainsi que les problmes qui subsistent.
582 RSTI - TSI. Volume 25 no 5/2006

MNHoA> MNCoA
CN MNHoA > MNCoA CN MNHoA> MNCoA
2
HA HA

2
2


1
MNHoA MNHoA
1
AR

MNCoA MNCoA

(a) Premiers paquets de donnes (b) Routage optimal

Figure 2. Mobilit des stations avec Mobile IPv6

5.1. Mobile IPv6 : support de la mobilit des stations

Mobile IPv6 (Johnson et al., 2004) gre le problme de la mobilit en allouant

deux adresses chaque station mobile MN. La premire (Home Address ou M NHoA )
est une adresse permanente qui identifie la station dans le sous-rseau mre. La se-
conde (Care-of Address ou M NCoA ) est temporaire et est obtenue dans le sous-rseau
visit sur lequel le mobile prend ancrage. Une relation (binding) est tablie entre les
deux adresses, ce qui permet dutiliser la premire comme identificateur, et la seconde
pour le routage. Le MN peut possder simultanment plusieurs adresses M NCoA sur
des liens diffrents, mais il nen enregistre quune seule, appele ladresse temporaire
primaire. Le mobile fait ensuite parvenir ladresse temporaire primaire M NCoA au
moyen dun message de mise--jour (BU), non seulement son agent mre (HA),
mais aussi chacun de ses correspondants CNs. Les BUs sont des paquets spciaux
contenant deux extensions den-tte IPv6 supplmentaires. Ladresse permanente est
contenue dans loption Home Address Option de lentte dextension Destination Op-
tion. Le message de mise--jour instruisant le destinataire dajouter ou de mettre
jour lentre correspondante dans son cache (Binding Cache) est contenu dans len-
tte dextension Mobility Header.
Au dbut dune communication entre un correspondant CN et un mobile MN, le
CN na pas connaissance de ladresse temporaire M NCoA . Il envoie donc les paquets
normalement vers ladresse M NHoA du mobile. Ces paquets sont ainsi routs jus-
quau sous-rseau ayant le mme prfixe que ladresse de destination et parviennent
donc sur le sous-rseau mre du mobile. Le paquet y est intercept par le HA puis
encapsul vers M NCoA comme cela est montr sur la figure 2a. A la rception dun
paquet encapsul, le mobile le dcapsule, ajoute ladresse du CN dans sa liste de cor-
respondants et peut lui envoyer un BU (figure 2b) pour permettre un routage optimal.
Lorsque le CN obtient un BU valide (i.e. obissant aux tests de conformit lis la s-
curit, particulirement lauthentification de lmetteur par son destinataire), une nou-
velle entre est ajoute dans son cache et les paquets suivants peuvent tre envoys di-
 Les rseaux mobiles dans IPv6 583

rectement ladresse M NCoA (cest--dire sa localisation topologique effective sans

passer par le HA) en utilisant une extension den-tte IPv6 (Routing extension header)
contenant ladresse M NHoA pour lidentification du mobile. En recevant un paquet
contenant cet entte, la couche IP du mobile permute ladresse destination M NCoA et
ladresse M NHoA contenue dans loption et passe le paquet la couche suprieure.
Pour en savoir plus sur le fonctionnement de Mobile IPv6 et les protocoles qui lui sont
associs, nous recommandons (Soliman, 2004), ouvrage paru rcemment.

5.2. Support de la mobilit des rseaux avec Mobile IPv6

Mobile IP, dans sa version IPv4 (Perkins, 2002), mentionne brivement les r-
seaux mobiles. En effet, les concepteurs de Mobile IPv4 pensent grer la mobilit
des rseaux de manire similaire celle des stations, mais ceci est prsent de ma-
nire trs succincte, en partant de lobservation quun rseau mobile nest autre quun
rseau rattach un routeur mobile, cest--dire un nud mobile comme une autre
(voir (Perkins, 2002) section 4.5, (Perkins, 1998) section 5.12, (Solomon, 1998) sec-
tion 11.2). A chacun de ses dplacements, il suffirait donc au MR dobtenir une adresse
temporaire M RCoA et de lenregistrer auprs de son HA comme dans le cas dune sta-
tion mobile. La solution semble dautant plus simple avec Mobile IPv4 que tous les
paquets de donnes passent ncessairement par le HA dans les deux sens ; il ny a
donc pas doptimisation de routage ce qui simplifie la solution.
Cette analyse na cependant pas t suffisamment pousse par leurs auteurs jusqu
considrer les caractristiques et les besoins spcifiques la mobilit des rseaux d-
taills dans la section 4. De plus, la version IPv6 de Mobile IP ne fait plus mention du
support des rseaux mobiles. Il sest en effet avr que Mobile IPv6 nest pas adapt
au support de la mobilit des rseaux comme cela a t dmontr dans (Ernst, 2001).
Dune part, la spcification ne permet pas de rediriger les paquets destins aux nuds
situs derrire le MR, et dautre part le mcanisme doptimisation du routage est in-
adquat :
Maintien des sessions : le besoin le plus essentiel est le maintien des sessions
ouvertes entre les MNNs et leurs CNs lors des dplacements. Un MR oprant Mobile
IPv6 enverrait alors M RCoA son HA. Or, si le MR se limite cette fonction de
Mobile IPv6, rien nindique au HA quil doit procder lencapsulation vers M RCoA
pour lensemble des MNNs situs dans le rseau mobile. En fait, seuls les paquets dont
la destination finale est le MR (i.e. son adresse M RHoA ) peuvent tre encapsuls. Les
sessions tablies entre MNNs et CNs ne peuvent donc pas tre maintenues.
Optimisation du routage : comme tous les paquets transmis entre MNNs et
leurs CNs transitent ncessairement par un MR, le changement de point dancrage du
seul MR a un impact sur le routage vers lensemble des MNNs. Ceux-ci peuvent donc
sembler mobiles du point de vue des CNs. En revanche, la structure interne dun r-
seau mobile est prserve lors des dplacements du MR. Pour permettre un routage
optimal en appliquant les mcanismes de Mobile IPv6, les CNs se devraient de rece-
voir priodiquement un BU contenant ladresse M RCoA . Lenvoi priodique de BUs
584 RSTI - TSI. Volume 25 no 5/2006

CN
Prefix/48 > MRcoa
HA Prefix/48 > MRcoa
CN

MR IP
CN
CN

CN
AR

MRcoa

Binding Update
LFN Prefix/48 > MRcoa

Figure 3. Explosion des messages de contrle (Binding Updates)

chaque CN provoquerait alors une explosion de BUs (Binding Update Explosion

ou BU Storm) comme cela est montr sur la figure 3. Ceci se traduit la fois par un
cot trs lev en ressource mmoire pour garder lhistorique des BUs envoys aux
diffrents CNs, en CPU pour lenvoi des BUs et en bande passante en particulier
proximit de AR o les liens pourraient tre congestionns par un nombre excessif de
messages de contrle.
Scurisation de la signalisation : dautre part, lenvoi des BUs vers les CNs
incomberait alors au nud obtenant ladresse temporaire, donc au MR. Or, il nest pas
possible deffectuer le test dauthentification de la provenance des BUs tel quil est
effectu par les CNs dans Mobile IPv6. Le BU tant mis par le MR, le CN devrait tre
en mesure de raliser ce test pour les paquets destins ladresse M RHoA , mais rien
ne lui permettrait de dduire quil doit en faire autant pour tous les nuds qui partage
le mme prfixe que M RHoA . Cela ncessiterait un nouveau mcanisme. Pour pallier
ces problmes, les MNNs pourraient envoyer directement les BUs leurs propres
CNs, mais cela ncessiterait galement des modifications dans la spcification, entre
autres un mcanisme pour que les MNNs dtectent la mobilit du rseau et obtiennent
ladresse temporaire du MR. Ceci nest pas souhaitable car la gestion de la mobilit
du rseau ne se ferait plus de manire transparente pour les MNNs. Dautre part, on
constaterait une possible duplication des BUs dans le cas o un CN correspondrait
avec plus dun MNN du mme rseau mobile, ce qui consommerait inutilement de la
bande passante et de la mmoire dans le cache de ce CN.
De nombreux problmes subsistent et Mobile IPv6 ne peut pas tre simplement
tendu pour supporter les rseaux mobiles. Le support des rseaux mobiles ncessite
donc une solution spcifique, mais dont le concept nest pas forcment trs loign
de Mobile IPv6, du moins est-ce lide soutenue par lIETF, bien quil existe dautres
approches, dcrites dans la section 6.
 Les rseaux mobiles dans IPv6 585

5.3. Le groupe de travail NEMO de lIETF

La problmatique des rseaux mobiles a fait sommairement son apparition

lIETF plusieurs reprises avant de vritablement prendre son envol partir de 2000
lorsque lanalyse de Mobile IPv6 dcrite dans la section prcdente a t soumise
au groupe de travail Mobile IP. partir de ce moment, la communaut IETF a pris
conscience du besoin de traiter cette problmatique explicitement, tout en vitant din-
terfrer avec le dveloppement de Mobile IP. Aprs de longues ngociations, et trois
runions de lIETF, la communaut est parvenue sentendre sur une charte, ce qui a
donn naissance en octobre 2002 au nouveau groupe de travail NEMO7 . Les contours
de la problmatique ont t difficiles tablir notamment cause de la confusion sou-
vent faite entre rseaux mobiles, rseaux cellulaires et rseaux ad hoc (voir section 4),
et aussi cause de la mconnaissance de la complexit de loptimisation du routage et
de son impact sur la scurit.
Le groupe de travail NEMO a dcid daborder le problme en deux tapes afin
de produire une solution dployable rapidement et de contourner les problmes de
scurit lis loptimisation du routage :
Support de base (NEMO Basic Support) : dans un premier temps, le groupe se
doit de standardiser une solution simple, connue sous le nom NEMO Basic Support,
permettant de maintenir les sessions pour lensemble des MNNs, sans modifications
des MNNs, sans optimisation de routage, et dfinie sur le modle Mobile IPv6 (voir
la description dtaille section 5.4). Outre la spcification du protocole, les livrables
du groupe NEMO comprennent quelques spcifications annexes telles la dlgation
des prfixes, une MIB, les modles dusage du sous-rseau mre (voir le document
home network models (Thubert et al., 2006)), et une analyse de la problmatique des
configurations multidomicilies (voir section 5.5).
Support tendu (NEMO Extended Support) : dans un second temps, le groupe
se doit dtudier les problmes doptimisation. Les livrables sont des documents de
synthse dcrivant la problmatique de la multidomiciliation (Ng et al., 2006a), celle
de loptimisation du routage (Ng et al., 2005) et ses approches potentielles (Ng et
al., 2006b), ne reposant pas ncessairement sur le modle Mobile IPv6. A lissue de
ces documents, le groupe devra dcider soit de continuer ses travaux dans le but de
standardiser une ou plusieurs solutions pour loptimisation du routage, soit de dclarer
sa fermeture. Dans le premier cas, la charte doit pralablement tre redfinie, la vue
des conclusions des documents de synthse. Ces problmes complexes justifient en
fait lapproche en deux tapes dcide par le groupe NEMO. Nous reviendrons sur
ces problmes de recherche dans la section 5.5.

7. Groupe de travail NEMO de lIETF : http ://www.ietf.org/html.charters/nemo-charter.html,

nomm ainsi non pas en mmoire du capitaine Nmo qui pilote le Nautilus mais bien entendu
en rfrence la transcription anglaise de la mobilit des rseaux : NEtwork MObility.
586 RSTI - TSI. Volume 25 no 5/2006

5.4. Description technique du support de base

Le protocole dit Support de Base (NEMO Basic Support, RFC 3963) (Devarapalli
et al., 2005) est une solution permettant le seul maintien des sessions en procdant
la redirection des paquets destins aux MNNs vers la position courante du MR. Elle
reprsente le consensus des personnes impliques dans le groupe de travail et ras-
semble lensemble des diverses propositions qui y ont t faites lors de sa cration.
Elle est tablie sur le modle de Mobile IPv6 selon des rgles pralablement dic-
tes par le groupe de travail dans un document dressant la liste des fonctions requises
((Ernst, 2005), section 4). La rgle fondamentale est de ne pas imposer de modifica-
tions sur les MNNs.
Le principe de base de la solution est que tous les nuds du rseau mobile par-
tagent le (ou les) mme prfixe dadresse IP (MNP). Le dplacement du MR ne cau-
sant pas de changement du point dancrage physique des MNNs, seul le (ou les)
MR est tenu de changer ladresse de son interface externe. En revanche, les MNNs
conservent leur adresse. Le changement de point dancrage est donc gr de manire
transparente pour les MNNs afin de ne pas ncessiter de fonctionnalits nouvelles dans
lensemble des implmentations IPv6. La solution consiste donc tablir un tunnel bi-
directionnel entre le HA et le MR.
Comme dans Mobile IPv6, le support de base gre le problme 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 premire (Home Address ou M RHoA ) est une adresse
permanente qui identifie le MR dans le sous-rseau mre. Elle identifie soit linterface
externe et a pour prfixe celui du sous-rseau mre, soit linterface interne du MR
(voir (Thubert et al., 2006)), et elle a pour prfixe MNP comme chacun des MNNs
du mme rseau mobile. La seconde (Care-of Address ou M RCoA ) est temporaire
et est obtenue dans le sous-rseau visit sur lequel linterface externe du MR prend
ancrage. Le protocole tablit ainsi une relation entre le prfixe MNP utilis comme
identificateur, et ladresse temporaire M RCoA , utilise pour le routage. Seuls les MRs
qui changent leur point dancrage obtiennent cette nouvelle adresse, les autres MNNs
conservent leur seule adresse M N NMN P ; la gestion de la mobilit leur est ainsi
transparente.
Le MR fait ensuite parvenir ladresse temporaire primaire M RCoA au moyen dun
message de mise--jour des prfixes (PBU) son agent mre (HA). Les PBUs IPv6
sont des paquets spciaux contenant une entte dextension Mobility Header. Lorsque
HA reoit un PBU valide (i.e. obissant aux tests de conformit lis la scurit,
particulirement lauthentification de lmetteur par son destinataire), lentre corres-
pondante au MNP est ajoute ou mise jour dans son cache (Binding Cache). Elle
instruit le HA dencapsuler les paquets destination dune adresse ayant un prfixe
correspondant au MNP (i.e. lensemble des stations rsidant dans le rseau mobile)
vers la destination effective du MR (i.e. M RCoA ).
Lors dune communication entre un MNN et un CN, le CN na pas connaissance
de ladresse de routage temporaire M RCoA . Les paquets sont donc envoys normale-
 Les rseaux mobiles dans IPv6 587

CN
toto.foo
DNS
toto.foo:
FECA:700:AAAA:100C::/128 FEC4:700:AAAA:10/56 > FEC4:700:BBBB:200A::/128

Encapsulation HA
FECA:700:AAAA/48
MR












FECA:700:AAAA:1001::/128
  

  
  

MNN toto.foo
FECA:700:AAAA:100C::/128
current AR
FECA:700:BBBB/48
MR
FECA:700:BBBB:200A::/128
Decapsulation Previous AR
MNN toto.foo
FECA:700:AAAA:100C::/128
Binding Cache






Payload Datagram
  
  

Encapsulated Payload
  
  

  
  

Figure 4. NEMO Support de Base : Tunnel HA-MR

ment vers ladresse M N NMN P du MNN et routs jusquau sous-rseau ayant pour
prfixe MNP. Ils parviennent ainsi dans le sous-rseau mre du MR. Les paquets y
sont intercepts par le HA puis encapsuls vers M RCoA comme cela est montr sur la
figure 4. A la rception dun paquet encapsul, le MR le dcapsule et le transmet sur
son interface interne. Le paquet que reoit le MNN ne contient donc plus M RCoA ;
lopration lui est ainsi transparente. Dans le sens inverse, les paquets sont galement
encapsuls du MR son HA.

5.5. Problmes rsoudre lIETF

Le support de base pose certains problmes qui sont dbattus avec plus ou moins
de vigueur sur la liste de discussion du groupe NEMO :
Multidomiciliation : lanalyse du support de base dans les configurations mul-
tidomicilies (Ng et al., 2006a) produite par le groupe de travail NEMO propose dans
un premier temps un taxinomie des configurations possibles (voir section 4) avant
de prsenter la problmatique. Plus dune dizaine de problmes, plus ou moins com-
plexes, y sont recenss. Le groupe NEMO doit prsent dcider lesquels il a vocation
rsoudre, les autres (en particulier ceux du filtrage des adresses, de la slection des
adresses, et de la dtection des pannes) restant au soin dautres groupes de travail.
Parmi ceux propres NEMO, nous notons la synchronisation des HAs et MRs, et le
support des interfaces multiples. Dans ce dernier cas, le MR peut possder simulta-
nment plusieurs adresses M RCoA sur des liens diffrents, mais la spcification ne
permet (pour le moment) de nen enregistrer quune seule dans le cache du HA pour
588 RSTI - TSI. Volume 25 no 5/2006

un MNP donn. La spcification ninterdit cependant pas dapporter les extensions n-

cessaires. Les solutions imagines pour la gestion des interfaces multiples dans Mobile
IPv6, en particulier celles de (Montavont, 2004; Wakikawa, 2004) peuvent sappliquer
au cas des rseaux mobiles. Une thse (Paik, 2004) entirement consacre la mobilit
des rseaux contient un chapitre ddi la slection du MR. Dautres travaux traitent
de problmes de multidomiciliation lis la mobilit enchane : comment dcouvrir
la profondeur du rseau ou comment dterminer le root-MR qui connecte le rseau
agrg Internet (Montavont et al., 2004; Cho et al., 2004; Thubert et al., 2004).
Transition IPv4/IPv6 : la transition entre IPv4 et IPv6, et la traverse des NATs
et PATs causent certains problmes de compatibilit ; ceux-ci sont actuellement dbat-
tus dans les listes de discussions de lIETF (Soliman et al., 2006).
Contrle daccs : les mcanismes de contrle daccs ont t dvelopps pour
autoriser et grer laccs dune station dans un rseau quelconque, mais pas pour per-
mettre laccs un MR et au rseau qui lui est attach. Il est ncessaire de mettre
en place une procdure permettant aux VMNs de bnficier de laccs qua obtenu le
MR. Ces aspects ont t tudis dans (Ng et al., 2002; Zrelli et al., 2005; Bournelle et
al., 2006) mais les problmes soulevs nont pas t jugs spcifiques au cas des r-
seaux mobiles et ne sont donc pas traits dans le groupe de travail NEMO. Ils doivent
pourtant tre rsolus pour permettre un dploiement commercial du RFC 3963.
Routage sous-optimal : le transit des paquets par le HA (dans les deux sens) a
pour consquence daccrotre la distance, donc les dlais de transmission et lusage de
la bande passante, en particulier lorsque CNs et MNNs sont relativement proches dans
la topologie. Ce problme est bien connu dans le domaine du support de la mobilit
des stations. Mais il est plus complexe dans NEMO cause de la multiplicit des confi-
gurations possibles (mobilit enchane, htrognit des MNNs). Dans le cas dune
configuration dite enchane, le dfaut doptimisation de routage se traduit par plu-
sieurs niveaux dencapsulation et, non pas un routage triangulaire comme dans le cas
des stations mobiles (cf. paragraphe prcdent), mais un routage quadrilatral (deux
niveaux de mobilit) voire pire, les paquets transitant par le HA de chaque routeur ou
station mobile de la hirarchie. Par exemple, sur la figure 1, lenvoi des paquets de CN
VMN se traduirait par deux encapsulations, en passant par HAV MN puis HAMR .
Dautre part, deux VMNs situs dans le mme rseau mobile risquent de voir leurs
paquets dirigs vers le HA du MR ou leurs HAs respectifs. Dans un tel contexte, la
question de loptimisation du routage devient cruciale. Plusieurs documents existent l
aussi pour dcrire ces problmes, en particulier ceux du groupe NEMO prcdemment
cits ((Ng et al., 2005) pour la problmatique et (Ng et al., 2006b) pour lanalyse des
solutions) dans lequels le lecteur avis trouvera une important source de rfrences.

6. Gestion de la mobilit des rseaux et optimisation du routage

Dans la section prcdente, nous avons parl de lapproche suivie par lIETF, em-
prise plus par des soucis de cot du dploiement que defficacit, et qui vise donc
 Les rseaux mobiles dans IPv6 589

imposer un minimum de changements. Il existe cependant une multitude dapproches,

dont certaines mriteraient une tude approfondie.
Il nest pas possible dtablir une liste exhaustive des solutions proposes pour
supporter la mobilit des rseaux et permettant loptimisation du routage, car celles-
ci sont dj nombreuses. Elles peuvent nanmoins tre regroupes par catgories. La
taxinomie que nous proposons ci-dessous est largement inspire par ltude des so-
lutions permettant la mobilit des stations. Il nous parat en effet naturel de faire un
parallle entre la mobilit des rseaux et celle des stations cause des similitudes de la
problmatique et des approches existantes. Une telle tude, dont les rsultats sont d-
velopps dans (Ernst, 2001) (chapitres 3, 4 et 5) montre que le problme dadressage
et de routage peut tre rsolu de plusieurs manires, et pas seulement selon le modle
double adressage de Mobile IP :
Double adressage : le moyen le plus rpandu, qui est aussi celui prconis pour
linstant par lIETF et donc celui adopt pour les standards (Mobile IP, NEMO), fait
usage de deux adresses. Lune est permanente et utilise en tant quidentifiant dinter-
face ; lautre est temporaire et est utilise en tant quidentifiant de la position dans la
topologie et donc pour le routage. Un mcanisme est alors ncessaire pour maintenir
jour la relation entre les deux identifiants. Cest lapproche la plus vidente et la
plus simple car elle ne remet pas en cause la prennit des diffrents protocoles de la
couche rseau et ne ncessite lajout de fonctionnalits quaux seules entits mobiles
(au sens IP du terme) ainsi que dans un routeur situ dans le sous-rseau mre (e.g.
le HA). (Ng et al., 2005) dresse une analyse de celles qui tombent dans une approche
base sur Mobile IPv6.
Routage : cette approche permet de conserver les adresses IP et de laisser la
mise--jour de la localisation au soin dun protocole de routage (e.g. OSPF ou BGP-
4), mais ceux-ci ne sont gnralement pas adapts des dplacements nombreux ou
frquents car les tables de routage devraient tre recalcules en permanence. Une telle
approche peut en revanche sappliquer au cas de laronautique. Le service opration-
nel Connexion de Boeing, bas sur une solution BGP-4 propritaire, dans IPv4, en
offre un parfait exemple. Cette approche est aussi suivie par les protocoles de routage
ad hoc, ou par ceux de gestion de la mobilit locale des stations (par exemple Cellular
IP) et pourraient sappliquer aux rseaux mobiles.
Renumrotation : cette approche discute lIETF consiste changer les
adresses de lensemble des nuds de manire disposer dune adresse routable to-
pologiquement correcte. Le routage est donc intrinsquement optimal. En revanche,
il faut un mcanisme complmentaire pour ne pas rompre les sessions ouvertes ainsi
quun mcanisme permettant aux CNs de dterminer ladresse courante du MNN (un
DNS dynamique).
Sparation des fonctions de ladresse : cette approche consiste sparer les
deux fonctions didentification et de localisation des adresses IP de manire ne plus
rompre les sessions lors des dplacements. Par exemple, LINA (Ishiyama et al., 2001)
propose dutiliser la partie haute et variable des adresses pour la localisation, tandis
que la partie basse sert lidentification. Cette solution initialement propose pour
590 RSTI - TSI. Volume 25 no 5/2006

la gestion de la mobilit des stations (LIN6) est maintenant tendue au support de la

mobilit des rseaux (Oiwa et al., 2003).
Approche hirarchique : afin de limiter la signalisation ncessaire la ges-
tion de la mobilit et de permettre le passage lchelle, de nombreuses solutions
proposent galement de diffrencier la mobilit locale (entre sous-rseaux topologi-
quement proches dans la topologie Internet) de la mobilit globale (entre sous-rseaux
topologiquement loigns dans la topologie Internet). Une approche hirarchique peut
alors tre utilise en combinant deux classes de solutions, par exemple le double
adressage pour la mobilit globale et un protocole de routage pour la mobilit locale.
HMIPv6 (Soliman et al., 2005) est une solution hirarchique utilisant une approche
de double adressage base sur Mobile IPv6 la fois pour la mobilit locale et pour la
mobilit globale dont le but est de restreindre lenvoi de BUs une zone locale. Le
mobile obtient en fait deux CoAs, lune (CoA locale) est mise jour chacun de ses
dplacements, et lautre (CoA rgionale) nest mise jour que lors du changement de
domaine. Le concept a t tendu aux rseaux mobiles dans une version intermdiaire
de 2001, mais cette partie a t retire de la spcification courante.
Diffusion multipoint : cette approche permet de lutter contre le phnomne de
lexplosion des messages de mise--jour en les envoyant un groupe multicast au lieu
de les envoyer un nud particulier. Partant du fait que tous les CNs reoivent des
messages de contrle au contenu identique, (Ernst, 2001) propose une telle solution
combinant des extensions multipoint avec le support de base. Une technique multicast
dite traditionnelle et reposant sur les protocoles de routage habituels traite du pro-
blme du passage lchelle lorsque les CNs sont nombreux. Le but consiste tablir
un arbre de distribution entre le routeur mobile et le groupe multipoint constitu par
lensemble des correspondants du rseau mobile, en vue dy transmettre les paquets
de contrle permettant le routage optimal. Une seconde approche plutt destine un
nombre assez restreint de correspondants, repose sur une nouvelle technique de rou-
tage multipoint qui consiste enregistrer la liste des correspondants directement dans
le message de contrle (XCAST), ce qui vite ltablissement de larbre, gnralement
coteux, mais limite aussi le nombre de correspondants d laccroissement de la
taille du paquet.
Rseau virtuel : cette approche consiste positionner quelques routeurs des
emplacements stratgiques, tels les routeurs raccordant chaque domaine lInternet,
de manire former un rseau dit overlay de routeurs spcialiss dans la gestion de
la mobilit. ORC (Wakikawa et al., 2003; Wakikawa, 2004), par exemple, propose
une solution de ce type qui sapparente en fait une gestion hirarchique semblable
HMIPv6. Watari (2005) traite de la question de la mobilit enchane et propose quant
lui le dploiement dun router correspondant dans le site du CN.
 Les rseaux mobiles dans IPv6 591

7. Projets et implmentations de NEMO Basic Support

Plusieurs implmentations de NEMO Basic Support sont en cours de ralisation

ou de dploiement au sein de grands projets publics ou par des industriels. En voici
quelques uns :
ICAR (anciennement InternetCAR) : le scnario dcrit dans la section 2 est mis
en uvre sur la plate-forme de dmonstration de ce projet bas Keio University prs
de Tokyo, et conduit au sein de lorganisation WIDE (Widely Interconnected Distri-
buted Environment). Le projet a t lanc en 1996 dans le but dtudier le systme de
communication ncessaire aux applications ITS (entre le vhicule et Internet). Ce pro-
jet a suivi lvolution des travaux de lIETF depuis ceux du groupe de travail Mobile
IP jusqu ceux du groupe de travail NEMO. Le projet sintresse particulirement au
support de la multidomiciliation. Plusieurs phases du projet ont t ralises. Dans un
premier temps, les tudes ont port sur Mobile IPv4, en ne considrant quune seule
station mobile (un ordinateur muni dune carte 802.11 et dun tlphone cellulaire).
Les expriences ont gagn en complexit jusqu considrer Mobile IPv6 puis NEMO,
mais sur un seul vhicule. La premire solution prsente lIETF pour le support des
rseaux mobiles (Prefix-Scope Binding Updates - PSBU) (Ernst, 2001) a ainsi t im-
plmente et teste sur un vhicule prototype munis de plusieurs technologies daccs
(Ernst et al., 2003). Le rseau mobile dploy dans le vhicule est constitu de trois
sous-rseaux isols les uns des autres. Lun est utilis pour transmettre les donnes de
contrle des organes primaires du vhicule (moteur, freins, pression des pneumatiques,
et divers capteurs) ; lautre pour contrler les organes moins importants (louverture
des portes, des fentres), et le troisime pour la transmission des donnes multimdia.
PSBU a ensuite fait place la solution de lIETF. Actuellement, le projet dveloppe un
rseau test daccs sans fil sur litinraire dune ligne de bus. 4 types de capteurs IPv6
ont t dvelopps (temprature, vitesse, acclration, GPS). Une dmonstration a t
ralise lors de lITS World Congress de Nagoya au Japon en octobre 2004, o un
rseau mobile tait dploy dans un bus. ICAR est un des contributeurs essentiels du
consortium InternetITS en ce qui concerne le systme de communication IPv6. Il b-
nficie ainsi des plates-formes de test dveloppes par ce consortium qui impliquent,
pour certaines expriences, plusieurs centaines de taxis en activit. Les taxis, lex-
ception dun prototype, nont jusqu prsent pas t quips dun MR, en revanche
ils ont permis la collecte dinformations permettant dtudier le trafic et la pertinence
des technologies IPv6.
Nautilus6 8 : ce projet franco-japonais a t cr en fvrier 2003, initialement
au sein de WIDE (il rassemble prsent Keio University, University of Tokyo, IIJ du
ct japonais et lINRIA, lULP, lENST-B, lINT et France Telecom R&D du ct
franais), et a pour but de dmontrer la faisabilit dun dploiement de la mobilit
dans IPv6. Ceci passe par le dploiement de la mobilit des stations et des rseaux, et

8. Nautilsu6 : http ://www.nautilus6.org. Le lecteur devrait tre prsent convaincu quun In-
ternet ne peut pas tre dploy de manire omniprsente sans que NEMO le soit lintrieur
des vhicules, bateaux y compris.
592 RSTI - TSI. Volume 25 no 5/2006

ncessite dapporter une solution aux besoins soulevs dans la section 4 (connectivit
permanente et transparente, performance, scurit, contrle daccs, etc.). Nautilus6
dispose de deux implmentations de NEMO Basic Support. La premire (nomme
SHISA) tourne sous FreeBSD 4.11 / NetBSD 1.6.2 et a t ralise en collaboration
avec le projet KAME. La deuxime implmentation (NEPL), sous Linux, est base
sur la pile MIPL 2.0 et est ralise en collaboration avec Go-Core et USAGI9 . Le
projet est trs prsent lIETF et travaille aussi sur les mcanismes de multidomi-
ciliation, doptimisation des handovers, et dadaptation du flux de donnes mis par
les applications en fonction du type daccs disponible. Des dmonstrations publiques
des mcanismes NEMO et de ses usages potentiels sont ralises en direct sur Internet
(voir le site web) par le biais des plates-formes E-Bike et E-Wheelchair (Ernst, 2004).
Des capteurs IPv6 existants ou en cours de ralisation permettront de dterminer les
pulsations cardiaques, la localisation par GPS, la temprature, la vitesse et lacclra-
tion, et un systme de vido-confrence permettra quant lui denvoyer une vido de
la scne ou de communiquer avec les tiers. Le tout peut tre plac sur un vlo ou sur
un fauteuil roulant, derrire un routeur mobile oprant NEMO Basic Support. Le MR
dispose dun accs 802.11b ou dun accs cellulaire (AirH, B-Mobile, ou FOMA).
Overdrive10 : ce projet est financ par la Communaut europenne (Programme
IST, 5th Framework), dont le but est de dvelopper les mcanismes IPv6 de gestion de
la mobilit (rseaux htrognes, mobilit des sources, mobilit des routeurs, mca-
nismes dautorisation et dauthentification). Il implique notamment Daimler Chrysler,
Motorola, France Telecom, Ericsson, et lUniversit de Surrey. (Lach et al., 2003; Pe-
trescu et al., 2004) donne quelques dtails de lexprience mene avec NEMO Basic
Support, implment dans la pile LIVSIX11 tournant sous Linux 2.4. Les configura-
tions testes sont celles de la mobilit enchane et celle de la multidomiciliation.
ISO TC204 WG16 : lISO conduit dimportant travaux de standardisation, no-
tamment dans les technologies de linformation appliques lautomobile (TC204).
Larchitecture CALM a ainsi t dfinie par le groupe de travail 1612 qui travaille sp-
cifiquement sur la partie permettant aux vhicules munis de cette architecture CALM
de communiquer avec linfrastructure fixe par le biais dIPv6. NEMO Basic Support
est ainsi considr pour grer le changement de point dancrage. Les diffrents CPUs
de contrle devant tre isols des applications multimdia, un modle tout-IPv6 nest
pour le moment pas envisageable. Ces CPUs de contrle ne devraient donc pas tre
munis dune interface IP. Un sous-rseau de type MOST (bus non-IP) est ainsi prco-
nis pour ses qualits de transmission temps-rel et sa fiabilit. Par contre les applica-
tions non sensibles, en particulier le multimdia, tourneront bien sous IPv6.

9. KAME ( prsent dfunt) et USAGI sont deux autres projets de WIDE dont lobjectif est
limplmentation dun pile IPv6 de rfrence respectivement sous NetBSD/FreeBSD et Linux.
Go-Core est un projet de Helsinki University of Technology (HUT).
10. OVERDRIVE : Spectrum Efficient Uni-and Multicast Services Over Multi Radio Networks
in Vehicular Environments : http ://www.comnets.rwth-aachen.de/ o_drive/
11. LIVSIX, an open IPv6 source stack by Motorola Labs : http ://www.nal.motlabs.com/livsix
12. ISO/TC204 Transport Information and Control Systems (TICS) WG16 Wide Area Commu-
nications/Protocols and Interfaces : http ://www.sae.org/technicalcommittees/tc204wg16.htm
 Les rseaux mobiles dans IPv6 593

Autres projets : Renault a ralis des dmonstrations dapplications ITS sous

IPv6 en partenariat avec Cisco en utilisant leur implmentation NEMO Basic Support
(Cisco 3200). Il existe bien entendu de nombreux autres projets traitant de NEMO,
entre autres DAIDALOS13 , un autre projet Europen (Programme IST, 6th Frame-
work) et le projet eMOTION14 en Australie. LOTAN, la NASA, Boeing, Panasonic,
sont connus pour travailler sur le sujet, certains dentre eux disposant de leur propre
implmentation.

8. Conclusion

Dans cet article, nous avons prsent le principe de la mobilit des rseaux, leurs
usages, leur problmatique et leur prise en charge dans IPv6. Nous avons dress lin-
ventaire des contributions dans ce nouveau domaine.
La mobilit des rseaux a ouvert une brche dans la gestion habituelle de la mo-
bilit et mis jour de nouveaux problmes qui ncessiteront de plus amples travaux
de recherche. En effet, le besoin de dplacer des rseaux est peru depuis un certain
temps, mais aucun travail significatif ne leur avait t consacr avant les premiers
travaux introduits lIETF qui ont combl ce manque. Les problmes qui leurs sont
propres nayant pas t abords, donc suffisamment bien dtaills, les premires dis-
cussions lIETF ont eu pour rsultat une certaine prise de conscience, assez faible
dans un premier temps, mais grandissante depuis, dans les rangs de la communaut,
qui a abouti avec la cration du groupe de travail NEMO. Le support des rseaux
mobiles est prsent un sujet qui intresse de nombreux industriels, allant des four-
nisseurs dquipement rseau ou dlectronique grand public jusquaux fabriquants
dautomobiles, en passant par les oprateurs de tlphone et de transport public.
Le support de la mobilit des rseaux permet de dvelopper lide dun Internet
omniprsent, tout instant, tout endroit, avec nimporte qui. Les applications mul-
timdia seront les premires bnficier de ce type denvironnement. En effet, la
mobilit des rseaux rend en pratique possible la mobilit de tout quipement, ce qui
implique aussi que toute application doit tre en mesure de fonctionner dans un en-
vironnement mobile. Ceci ncessitera des mcanismes de changement dinterface et
de routeur mobile, et la prise en considration dun certain nombre de paramtres, en
particulier le changement de qualit de service, de bande passante, de rgles dusage
(pare-feu) en fonction des technologies accessibles un instant donn et du rseau
daccs
La gestion de la mobilit des rseaux mobiles doit faire face de nombreuses
contraintes. Tout dabord, il convient de supporter les rseaux mobiles en nombre et en
taille importantes, en considrant divers types de configurations (un seul sous-rseau,
la multidomiciliation, la mobilit enchane). Le nombre lev de correspondants nous
impose de minimiser la quantit de messages de contrle relatifs la gestion de la

13. DAIDALOS : http ://www.ist-daidalos.org

14. eMOTION : http ://www.cse.unsw.edu.au/ ocean/emotion/
594 RSTI - TSI. Volume 25 no 5/2006

mobilit tout en optimisant le routage. Ces messages doivent tre changs en toute
scurit et authentifis par leurs destinataires pour sassurer quils ne sont pas envoys
par un usurpateur. Les mcanismes intrinsques de Mobile IP doivent tre revus pour
permettre un routage optimal tout en considrant la question de la mobilit encha-
ne et de la multidomiciliation qui accentuent encore plus la question du passage
lchelle. La question de loptimisation de routage nest pour linstant pas officielle-
ment aborde par le groupe de travail NEMO. En revanche, il existe dj quelques
documents prsentant la problmatique et de nombreuses propositions.

Remerciements

Pour leur aide, conseils et mavoir permis douvrir le dbat sur les routeurs mo-
biles lIETF, je tiens adresser mes remerciements mes mentors de thse Claude
Castelluccia (INRIA Rhne-Alpes) et Hong-Yon Lach (Motorola Labs Paris). Cer-
tains rsultats de cette thse ont t mis en pratique au sein de lquipe InternetCAR
de Keio University, SFC, Japon, que jai par la suite rejoint et dont je remercie les
membres. Ceci naurait pu se faire sans lappui de Jun Murai, dit lInternet samurai,
vide-prsident de Keio University et prsident de WIDE, avocat hors normes dIPv6.
Je remercie galement les relecteurs officiels dont les commentaires ont permis dam-
liorer sensiblement cet article ainsi que Thomas Nol pour une dernire relecture.

9. Bibliographie

Boot J., Public Safety Applications for Mobile Networks, and Project MESA , 53rd IETF
meeting, Motorola, March, 2002. Presentation Material, MONET BOF.
Bournelle J., Valadon G., Binet D., Zrelli S., Laurent-Maknavicius M., AAA Considerations
Within Several NEMO Deployment Scenarios , 1st International Workshop on Network
Mobility (WONEMO), Sendai, Japan, January, 2006. http ://www.icoin.org/wonemo.
Cho H., Paik E., Choi Y., HMRA : Hierarchical Router Advertisement for Nested Mobile
networks , 1st IEEE VTS Asia Pacific Wireless Communications Symposium (APWCS),
p. 78-80, January, 2004.
Cizault G., "IPv6 : Thorie et Pratique", n ISBN 284177337X, 4th edn, Editions OReilly,
November, 2005.
Deering S., Hinden R., Internet Protocol Version 6 (IPv6) Specification, Request For Comments
n 2460, IETF, December, 1998.
Devarapalli V., Wakikawa R., Petrescu A., Thubert P., Network Mobility (NEMO) Basic Sup-
port Protocol, Request For Comments n 3963, IETF, January, 2005.
Ernst T., Le Support des Rseaux Mobiles dans IPv6, PhD thesis, Universit Joseph Fourier,
October, 2001. http ://www.inria.fr/rrrt/tu-0714.html.
Ernst T., E-Wheelchair : A Communication System Based on IPv6 and NEMO , 2nd In-
ternational Conference on Smart Homes and Health Telematic (ICOST), Keio University,
Japan, Singapore, September, 2004. http ://icost2004.i2r.a-star.edu.sg.
 Les rseaux mobiles dans IPv6 595

Ernst T., Network Mobility Support Requirements, Internet Draft n draft-ietf-nemo-

requirements-05.txt, IETF, November, 2005. Work in progress.
Ernst T., Lach H.-Y., Network Mobility Support Terminology, Internet Draft n draft-ietf-nemo-
terminology-05.txt, IETF, March, 2006. Work in progress.
Ernst T., Mitsuya K., Uehara K., Network Mobility from the InternetCAR Perspective ,
JOIN : Journal on Interconnection Networks, September, 2003.
Ernst T., Uehara K., Connecting Automobiles to the Internet , 3rd International Workshop
on ITS Telecommunications (ITST), Seoul, South Korea, November, 2002.
Ishiyama M., Kunishi M., Uehara K., Esaki H., Teraoka F., LINA : A New Approach to Mo-
bility Support in Wide Area Networks , IEICE Transactions on Communications, August,
2001.
Johnson D. B., Perkins C., Arkko J., Mobility Support in IPv6, Request For Comments n 3775,
IETF, June, 2004.
Kellerer W., Bettstetter C., Schwingenshlg C., Sties P., (Auto) Mobile Communication in
a Heterogeneous and Converged Wordl , IEEE Personal Communications, vol. 8, n 6,
p. 41-47, December, 2001.
Lach H.-Y., Janneteau C., Leinmueller T., Olivereau A., Petrescu A., Leinmueller T., Wolf
M. M., Pilz M., Laboratory and Field Experiments with IPv6 Mobile Networks in Vehi-
cul Environments, Internet Draft n draft-lach-nemo-experiments-overdrive-01.txt, IETF,
October, 2003. Work in progress.
Manner J., Kojo M., Mobility Related Terminology, Request For Comments n 3753, IETF,
June, 2004.
Montavont N., Multiple Interfaces Management and Fast Handover Mechanisms on an IPv6
Terminal (Gestion Optimise dInterfaces Multiples et Prise en Compte des Dplacements
Rapides sur un Terminal IPv6 Mobile), PhD thesis, Universit Louis Pasteur, Strasbourg,
France, Dpartement Informatique, LSIIT, UMR CNRS-ULP 7005, September, 2004.
Montavont N., Ernst T., Noel T., Multihoming in Nested Mobile Networks , International
Symposium on Applications and the Internet (SAINT) - IPv6 : Technology and Deployment
Workshop", Tokyo, Japan, January, 2004.
Ng C., Paik E., Ernst T., Bagnulo M., Analysis of Multihoming in Network Mobility Support,
Internet Draft n draft-ietf-nemo-multihoming-issues-06, IETF, June, 2006a.
Ng C., Tanaka T., Usage Scenario and Requirements for AAA in Network Mobility Support,
Internet Draft n draft-ng-nemo-aaa-use-00.txt, IETF, October, 2002. Expired.
Ng C., Thubert P., Watari M., Zhao F., Network Mobility Routing Optimization Problem State-
ment, Internet Draft n draft-ietf-nemo-ro-problem-statement-02, IETF, December, 2005.
Ng C., Zhao F., Watari M., Thubert P., Network Mobility Routing Optimization Solution Space
Analysis, Internet Draft n draft-ietf-nemo-ro-space-analysis-02, IETF, February, 2006b.
Oiwa T., Kunishi M., Ishiyama M., Kohno M., Teraoka F., A Network Mobility Protocol
based on LIN6 , IEEE VTC2003 Fall IP Mobility, October, 2003.
Paik E., Performance Enhancement for IPv6 Network Mobility, PhD thesis, Seoul National
University, School of Electrical Engineering and Computer Science, August, 2004.
Partridge C., Technical Criteria for Choosing IP the Next Generation (IPng), Request For Com-
ments n 1726, IETF, December, 1994.
596 RSTI - TSI. Volume 25 no 5/2006

Perkins C., IP Mobility Support, Request For Comments n 3344, IETF, August, 2002. Obso-
letes RFC3220 and RFC2002.
Perkins C. E., Mobile IP, Design Principles and Practices, Wireless Communications Series,
Addison-Wesley, 1998. ISBN 0-201-63469-4.
Petrescu A., Lach H.-Y., Janneteau C., Wolf M., Leinmuller T., Barz C., Pilz M., Frank M.,
Tonjes R., IPv6-based OverDRiVE Moving Networks : Mobility Management and Test-
bed Implementation , IST Mobile Summit, Lyon, France, June, 2004.
Quinot T., An IPv6 architecture for Aeronautical Telecommunication Network , Masters
thesis, Ecole Nationale Suprieure des Tlcommunications Paris, EUROCONTROL - Eu-
ropean Organization for the Safety of Air Navigation - ISA project (IPv6, Satellite commu-
nication and ATMode for ATN), 1998. http ://www.eurocontrol.fr/.
Robert O., IPv6 in the Sky , 1st International Global IPv6 Summit, Eurocontrol Experimental
Centre, October, 1999. Presentation Material.
Soliman H., Mobile IPv6, Mobility in a Wireless Internet, Addison-Wesley, 2004. ISBN 0-201-
78897-7.
Soliman H., Castelluccia C., El-Malki K., Bellier L., Hierarchical Mobile IPv6 Mobility Mana-
gement (HMIPv6), Request For Comments n 4140, IETF, August, 2005. Experimental.
Soliman H., Tsirtsis G., Devarapalli V., Kempf J., Levkowetz H., Thubert P., Wakikawa R.,
Mobile IPv6 Support For Dual Stack Hosts and Routers (DSMIPv6), Internet Draft n draft-
ietf-mip6-nemo-v4traversal-02.txt, IETF, June, 2006. Work in progress.
Solomon J. D., Mobile IP, The Internet Unplugged, Prentice Hall Series in Computer Networ-
king and Distributed Systems, Prentice Hall PTR, 1998. ISBN 0-13-856246-6.
Tanenbaum A. S., Computer Networks - Third Edition, Prentice-Hall International, Inc, 1996.
Terry D., Mobile Network in Aircraft : Concept of Operation , "Mobile Network
Conops" thread in the NEMO mailing list at the IETF, Boeing, August, 2004.
http ://www1.ietf.org/mail-archive/web/nemo/current/msg01427.html.
Thubert P., Montavont N., Nested NEMO Tree Discovery, Internet Draft n draft-thubert-tree-
discovery-01.txt, IETF, October, 2004. Work in progress.
Thubert P., Wakikawa R., Devarapalli V., NEMO Home Network Models, Internet Draft n
draft-ietf-nemo-home-network-models-06, IETF, February, 2006. Work in progress.
Wakikawa R., Design of Architecture and Protocols for Universal Mobile Internet, PhD thesis,
Keio University, Japan, Graduate School of Media and Governance, March, 2004.
Wakikawa R., Koshiba S., Uehara K., Murai J., ORC : Optimized Route Cache Management
Protocol for Network Mobility , IEEE 10th International Conference on Telecommunica-
tion (ICT), Tatiti Papeete, French Polynesia, February, 2003.
Watari M., A Route Optimization Scheme for Nested Mobile Networks , Masters thesis, Keio
University, Japan, Graduate School of Media and Governance, March, 2005.
Zrelli S., Ernst T., Bournelle J., Valadon G., Binet D., Access Control Architecture for Nested
Mobile Environments in IPv6 , 4th Conference and Security and Network Architecture
(SAR), Batz-sur-Mer, France, June, 2005. http ://www-lor.int-evry.fr/sar05.

Thierry Ernst a effectu ses tudes doctorales lINRIA au sein du projet PLANETE. Sa thse
portait sur la mobilit des rseaux et a servi de base la mise en place du groupe de travail
 Les rseaux mobiles dans IPv6 597

NEMO de lIETF dont il est le fondateur et le co-animateur. Il a ensuite rejoint le laboratoire

du Professeur Jun Murai Keio University au Japon do il a mis en place le projet Nautilus6
traitant de la mobilit IPv6. Il est rcemment retourn lINRIA au sein du projet IMARA qui
travaille sur les vhicules intelligents

Article reu le 22/04/2004

Version rvise le 04/04/2005
 ANNEXE POUR LE SERVICE FABRICATION
A FOURNIR PAR LES AUTEURS AVEC UN EXEMPLAIRE PAPIER
DE LEUR ARTICLE ET LE COPYRIGHT SIGNE PAR COURRIER
LE FICHIER PDF CORRESPONDANT SERA ENVOYE PAR E-MAIL

1. A RTICLE POUR LA REVUE :

RSTI - TSI. Volume 25 no 5/2006
2. AUTEURS :
Thierry Ernst
3. T ITRE DE L ARTICLE :
Le support des rseaux mobiles dans IPv6
4. T ITRE ABRG POUR LE HAUT DE PAGE MOINS DE 40 SIGNES :
Les rseaux mobiles dans IPv6
5. DATE DE CETTE VERSION :
25 juillet 2006
6. C OORDONNES DES AUTEURS :
adresse postale :
INRIA Rocquencourt, Domaine de Voluceau B.P. 105
78153 Le Chesnay Cedex FRANCE
thierry.ernst@inria.fr
tlphone : +33 1 39 63 59 30
tlcopie : +33 1 39 63 54 91
e-mail : thierry.ernst@inria.fr

7. L OGICIEL UTILIS POUR LA PRPARATION DE CET ARTICLE :

LATEX, avec le fichier de style   
         
  ,
version 1.23 du 17/11/2005.
8. F ORMULAIRE DE COPYRIGHT :
Retourner le formulaire de copyright sign par les auteurs, tlcharg sur :
    

                
 

S ERVICE DITORIAL H ERMES -L AVOISIER

14 rue de Provigny, F-94236 Cachan cedex
Tl. : 01-47-40-67-67
E-mail : revues@lavoisier.fr
Serveur web : http://www.revuesonline.com