Nathan CASTELEIN

Karim HAMIDOU
César MARCHAL
Christian PATRY

SR04
Projet d’étude et d’expérimentation – Mobilité IPv6

1
Contenu
Pourquoi IPv6 est arrivé ?.................................................................................................................................... 4
Fonctionnement IPv6 .......................................................................................................................................... 5
Adressage ........................................................................................................................................................ 5
Unicast ......................................................................................................................................................... 5
Multicast ...................................................................................................................................................... 6
Anycast ........................................................................................................................................................ 6
Adresses particulières ................................................................................................................................. 6
Auto-configuration .......................................................................................................................................... 7
Neighbor Discovery Protocol ....................................................................................................................... 7
Auto-configuration sans état (SLAAC) ......................................................................................................... 7
Auto-configuration stateful ......................................................................................................................... 7
Routage ........................................................................................................................................................... 8
Routage interne IGP (Interior Gateway Protocols) ..................................................................................... 8
Routage Externe EGP (Exterior Gateway Protocols) ................................................................................... 8
DHCPv6 ............................................................................................................................................................ 9
Etude de la mobilité .......................................................................................................................................... 10
Définition ....................................................................................................................................................... 10
Fonctionnement en IPv4 ............................................................................................................................... 10
La mobilité IPv6 : définitions ......................................................................................................................... 11
Home Address ........................................................................................................................................... 11
Care of Address ......................................................................................................................................... 12
Mobile Node (nœud mobile) ..................................................................................................................... 12
Correspondent node (nœud correspondant) ............................................................................................ 12
Home Agent ............................................................................................................................................... 12
Fonctionnement de la mobilité IPv6 ............................................................................................................. 12
Nœud mobile dans son réseau mère ........................................................................................................ 13
Nœud mobile dans un réseau étranger .................................................................................................... 13
Interception des paquets .......................................................................................................................... 14
Retour dans le réseau mère ...................................................................................................................... 15
Optimisation de routage ........................................................................................................................... 15
Mobility header ............................................................................................................................................. 16
Nouveaux messages ICMP ............................................................................................................................. 17
Risques et sécurité de la mobilité IPv6 .......................................................................................................... 17

2
Mise en œuvre de la mobilité............................................................................................................................ 18
Matériel ......................................................................................................................................................... 18
Préparation des terminaux et routeurs IPv6 ................................................................................................. 18
OpenWRT................................................................................................................................................... 18
Historique .................................................................................................................................................. 19
Compilation du noyau ............................................................................................................................... 19
Nouvelle architecture pour notre réseau ...................................................................................................... 21
Virtualisation ................................................................................................................................................. 21
La mobilité IPv6 côté software ...................................................................................................................... 22
Radvd ......................................................................................................................................................... 22
Daemon UMIP et UserSpace ..................................................................................................................... 24
Deuxième plateforme de test avec Nautilus ................................................................................................. 25
Le protocole SSP : un remplaçant de la mobilité IP pour la couche application ............................................... 27
Conclusion ......................................................................................................................................................... 28

3
Pourquoi IPv6 est arrivé ?
A l’origine, le protocole IP n’avait jamais été prévu pour fonctionner à l’échelle mondiale et, à l’époque de sa
création, personne n’aurait pu prévoir l’expansion d’internet qui eut lieu quelques années plus tard. D’une
centaine de machines, au maximum, prévu lors de la conception, le réseau a rapidement grandi avec
l’arrivée de nombreuses universités, puis du grand public, quelques années plus tard.

Comme le format des adresses IPv4 limitait le nombre maximum d’équipements connectés, les chercheurs
ont rapidement travaillé sur une nouvelle version du protocole visant à corriger ce défaut, pendant que
d’autres ingénieurs mettaient en place des solutions d’urgence.

C’est ainsi que les premières universités à avoir travaillé sur le projet ont accepté de rendre une partie de
leur, beaucoup trop grande, plage d’adresses. Puis, à l’aide de l’adressage privé et du NAT (translation du
port source), des réseaux entiers ont pu communiquer avec l’extérieur à l’aide de seulement quelques
adresses publiques. Enfin, la mise au point du Classless Inter-Domain Routing (CIDR) a permis d’alléger les
tables de routage et d’éviter le gaspillage d’adresses en distribuant des plages plus petites.

De nos jours pourtant, ces premières mesures arrivent à essoufflement et internet est de nouveau confronté
à plusieurs problèmes majeurs :
 De nombreuses autorités internationales (comme l’APNIC ou IANA) n’ont plus de réserves
d’adresses IPv4. Dans quelques années, les territoires qui ont été moins bien desservis à l’origine
(comme l’Asie) risque de connaitre des problèmes de connectivités, dus à la forte croissance de leur
nombre d’internautes.
 L’explosion du réseau allonge les tables de routage, qui sont de plus en plus surchargés. Les grandes
classes d’adresses ont été morcelées afin d’optimiser leur taux d’utilisation, ce qui a coupé tout lien
entre adresse et localisation géographique.
 L’inter-connectivité globale est remise en question, ce qui pourrait amener à la création de plusieurs
réseaux indépendants, ou tout du moins séparés.

Ces dernières années, de nombreuses initiatives ont donc été lancées afin d’accélérer le déploiement d’ipv6
sur le réseau. C’est par exemple le cas du « World ipv6 Day », qui a regroupé les principaux acteurs du web
en 2011. Pourtant, encore aujourd’hui, alors que les spécifications du protocole sont terminées depuis la RFC
2460 de décembre 1998, moins de 0,5% du trafic mondial passerait par ipv6.

Dans ce rapport nous réalisons une étude théorique d’ipv6 afin de mieux comprendre ses mécanismes et ses
avantages. Nous décrirons ensuite les outils que nous avons utilisés pour notre démonstration pratique et
les solutions que nous avons tentées de mettre en place afin de tester la mobilité sur ce nouveau protocole.

4
Fonctionnement IPv6
Si la principale nouveauté de la version 6 tient à son adressage sur 128bits, de nombreuses innovations ont
aussi été implémentées par rapport à la version précédente.

Le protocole possède désormais des mécanismes d’auto-configuration qui facilite l’ajout de nouvelles
machines à un réseau, de nouvelles possibilités pour les terminaux mobiles, ainsi que des entêtes
simplifiées, visant à faciliter le routage. Enfin la diffusion a été améliorée en supprimant les paquets
broadcast, en valorisant le multicast, en faisant disparaitre la fragmentation des paquets et en généralisant
l’utilisation d’IPSec.

Adressage
Ipv6 reconnait 3 types d’adresses :

Unicast
Désigne de manière unique une interface. Il en existe 3 types :
 Les adresses globales sont uniques pour chaque machine connectée, et peuvent donc être utilisées
sur internet. Elles utilisent le préfixe 2000::/3.

001 Global Prefix Subnet ID Interface ID

3 45 16 64
Global Prefix : Topologie publique du fournisseur, sur 48 bits (assigné par le provider).
SID : Topologie du site (sous-réseaux), sur 16 bits (assigné par le réseau).

Interface ID : Identifiant pour les machines, sur 64bits (assigné manuellement ou de manière automatique).
Peut être construit à partir de l’adresse MAC ou généré aléatoirement pour plus de confidentialité.

 Les adresses lien-local sont utilisées pour les nouveaux protocoles de configuration et de
découverte. Elles sont restreintes à un seul lien, c’est-à-dire un ensemble de machines
interconnectées, sans routeur intermédiaire. Elles utilisent le préfixe FE80::/10.

FE8 0 Interface ID
10 54 64
Seul l’identifiant de la machine est nécessaire puisque la portée est locale.

 Les adresses uniques locales sont les remplaçantes des classes d’adresses privées d’IPv4. Elles sont
définies pour un ensemble de réseaux et ne doivent pas être routées sur internet. Elles utilisent le
préfixe FC00::/7.

FC00 L Global ID Subnet ID Interface ID

7 1 40 16 64
L : Si égal à 1, identifie une adresse définit localement, le 0 n’a pas encore de signification.

5
Global ID : Rend l’adresse locale transparente pour les programmes, qui pensent avoir à faire à une adresse
globale.

Multicast
Désigne un groupe d’interface.

Équivalentes à la technologie IPv4, elles utilisent le préfixe FF0X::/8. Gérées par les routeurs, ces adresses
ont différentes portées (lien, LAN, monde, …) et permettent de contacter un groupe de machines,
préalablement inscrites, souvent en fonction de leur rôle sur le réseau (serveurs DHCP, routeurs, …). Le
broadcast n’existant plus en IPv6 (il était très couteux en performance sous la version 4), un mécanisme
smilaire existe en utilisant un groupe multicast (all-nodes) qui comprend toutes les adresses du réseau.

Anycast
Désigne un groupe d’adresses de manière transparente. Après le premier envoi, la communication s’effectue
avec le plus proche (ou le plus rapide à avoir répondu).

Sa structure est encore à définir car le standard est toujours en cours de recherche et d’amélioration. Dans
tous les cas, l’adresse n’est pas différenciable par rapport à une adresse unicast, seule la machine qui l’utilise
est au courant de sa spécificité.

Adresses particulières
 :: -> 0.0.0.0 : Passerelle par défaut et adresse source utilisée lors de la découverte de son IP.
 ::1 -> 127.0.0.1 : Boucle Local.
 ::FFFF:a.b.c.d : Mappage : Communication en IPv4 avec une machine en IPv4.
 ::a.b.c.d : Compatible : Communication entre deux machines IPv6 à travers un réseau ipv4.

6
Auto-configuration
Les créateurs d’IPv6 se sont basés sur les caractéristiques du plug and play pour bâtir les mécanismes de
configuration. Le but est de permettre à une machine de se connecter de manière autonome à un réseau,
sans l’aide d’un serveur auxiliaire, et d’entrer rapidement en communication, avec des machines locales et
vers l’extérieur.

Neighbor Discovery Protocol

Il s’agit du successeur d’ARP, qui tire sa révérence. Ce protocole se base sur l’échange de messages ICMPv6.
Si tout comme son prédécesseur il permet la résolution d’adresses, tout en évitant les broadcast, ce
nouveau protocole offre aussi de nouvelles possibilités :

 Neighbor Unreachability Detection : Permet de détecter les équipements voisins devenus

inaccessibles et de les effacer de ses tables de routage.
 Indication de redirection : En IPv6, si une machine émet vers un routeur alors que la machine de
destination est sur le même réseau, le routeur renverra un message ICMPv6 afin d’en informer
l’émetteur. Une configuration par défaut pourrait donc être d’émettre toutes les trames en direction
du routeur.

L’auto-configuration s’effectue en 4 étapes :

 Découverte des routeurs.

 Découverte des préfixes : L’adresse IP que s’auto-attribue la machine est constituée de deux parties.
La première est fixe et définie par le réseau, la seconde est constituée à partir de l’adresse MAC de
l’interface.
 Détection d’adresse dupliquée : La machine utilise le protocole DAD (Duplicate Address Detection,
RFC4429) pour vérifier si un équipement sur le réseau ne possède pas déjà l’adresse IP qu’elle vient
de créer. Si la vérification est concluante, l’adresse IP devient définitive et peut être utilisée.
 Découverte des paramètres : Récupère les caractéristiques du lien physique (MTU, TTL, …).

Cette dernière étape informe aussi la machine du type d’auto-configuration mise en place sur le réseau :

Auto-configuration sans état (SLAAC)

L’auto-configuration sans état (en anglais StateLess Address Auto Configuration) convient principalement
aux réseaux de petites tailles, et qui n’ont pas besoin d’une table d’association globale des adresses. Les
machines se débrouillent toutes seules entre-elles, sans entité décisionnelle centrale. Chaque terminal
génère une adresse lien-local et une adresse unicast global, avec le même identifiant d’interface, ce qui lui
permet de dialoguer à l’intérieur du LAN comme à l’extérieur. Si un ré-adressage est nécessaire, les
machines seront prévenues par les routeurs, qui fourniront le nouveau préfixe du réseau.

Ce mécanisme d’apparence simple pose cependant de nombreux problèmes de sécurité (type spoofing et
redirect) qu’il faut correctement analyser et contrer.

Auto-configuration stateful
Le mécanisme de base est identique, mais cette fois-ci la configuration peut être contrôlée avec plus de
précision, et les adresses de chaque machine sont stockées. L’auto-configuration avec état repose sur
l’utilisation d’un serveur DHCPv6, décrite ci-dessous. Il faut savoir que les 2 méthodes de configuration (avec
et sans état) peuvent cohabiter sur un même réseau.

7
Routage

Cela fait de nombreuses années maintenant que les principaux protocoles de routage de l’internet sont
compatibles avec IPv6, les algorithmes n’ont d’ailleurs pas beaucoup changé avec la nouvelle version. Tout
au plus ont-ils gagné des spécificités permettant de prendre en compte les quelques nouveautés. Le routage
statique IPv6 étant identique à son prédécesseur, nous nous concentrerons sur les protocoles de routage
dynamiques.

Routage interne IGP (Interior Gateway Protocols)

Ce type de protocole permet une configuration automatique des tables de routage à l’intérieur d’un réseau.
Ce sont les routeurs qui déterminent les plus cours chemin pour chaque destination, en s’échangeant des
informations. Il existe trois principaux algorithmes de routage interne : RIPv2, IS-IS et OSPFv2. Le premier est
un protocole « à vecteur de distance », c’est-à-dire que chaque routeur envoie aux autres la distance qui les
sépare. Les deux suivants sont dits « à état de lien », les routeurs envoyant à leurs voisins l’état de leur
connexion, ce qui permet à chacun de dresser une carte globale du réseau.

RIPng, la nouvelle version compatible IPv6 possède un format identique à la version 2, mais les
fonctionnalités d’authentification ont été retirées, la sécurité se basant désormais sur IPSec, inclus dans IPv6.
Les paquets échangés utilisent dorénavant le multicast (adresse all-rip-router : FF02::9) et transitent par le
port UDP 521 (au lieu du 520).

Intermediate System to Intermediate System s’appuyant sur la couche 2, il est donc compatible nativement
avec toutes les versions du protocole IP. IS-IS utilise des éléments appelés TLV (Type (propriété), Longueur
(nombre de valeurs différentes), Valeur (les informations)) pour faire transiter les données sur les routes. De
nouvelles TLV ont donc simplement été ajoutées pour IPv6, afin d’informer de la compatibilité du routeur
avec ce nouveau protocole ou, par exemple, pour supporter les adresses de type lien local.

OSPFv3 est désormais lui aussi indépendant de toutes version du protocole IP. Les routeurs voisins sont
dorénavant identifiés par un RouterID (sur 32 bits) et le protocole utilise les adresses de lien local et la
sécurité d’IPSec. L’adresse multicast correspondant (OSPFv3 AllDR Routers) est FF02::6.

Routage Externe EGP (Exterior Gateway Protocols)

Deuxième groupe de protocole de routage pour l’internet. Cette fois-ci les routes sont échangées entre deux
réseaux bien distincts (dit « autonome »), les informations viennent de l’extérieur. Ce système permet
d’alléger les tables de routage mondiales, puisque l’infrastructure du réseau est masquée et que tous les
routeurs internes sont accessibles depuis l’extérieur à partir d’une seule route.

BGP4+ (aussi appelé MBGP) est la nouvelle version du protocole BGP4. Elle le rend multi protocole avec
l’ajout de champs pour différencier la famille de l’adresse (IPv4 ou IPv6) et de sa sous-famille (Unicast,
Anycast, multicast).

8
DHCPv6
A première vue, un serveur DHCP tel qu’implémenté dans le protocole IP version 4 n’est plus autant
nécessaire en IPv6 :

 Les machines peuvent communiquer de manière locale avec des identifiants de faible portée.
 Les adresses ne sont plus une ressource rare qu’il faut économiser et contrôler.
 Des mécanismes automatiques existent désormais pour permettre la connexion des ordinateurs au
réseau.

Néanmoins la nouvelle version du protocole va permettre une surveillance plus fine de l’auto-configuration,
ce qui peut s’avérer intéressant pour les réseaux de taille importante.

DHCPv6 repose donc toujours sur le modèle client-serveur de son prédécesseur. Lors des échanges, le client
pourra obtenir les différents paramètres d’adressage, les serveurs de noms (DNS) ainsi que des adresses
d’annuaires (NIS).

Son fonctionnement est proche du DHCP pour IPv4. Un client contacte un serveur DHCP à l’aide de l’adresse
multicast FF02::1:2, après l’échange de données d’identification, le serveur lui fournit une adresse IP. La
communication avec le client s’effectue à travers 12 messages DHCP différents, c’est 4 de plus qu’en IPv4.
Les nouveaux échanges concernent principalement la notification de renouvellement des paramètres que
peut désormais envoyer le serveur, ainsi que le passage des informations à travers un relais intermédiaire
(dans le cas où le serveur DHCP n’est pas sur le même lien que la machine).

Du côté serveur, chaque client possède une liste d’adresses pour son interface, appelée Identity Association,
ce qui simplifie la gestion des durées de vies des adresses et le processus de renumérotation (changement
des préfixes du réseau). Pour reconnaitre les différentes machines, DHCPv6 utilise un identifiant unique
plutôt que l’adresse MAC, le DUID-LL (Link-Layer). A terme, le but de la configuration avec état est de définir
des adresses permanentes aux machines.

9
Etude de la mobilité
Définition
Avant toute chose, il semble important de prendre le temps de définir ce qu’est la mobilité IP. L’idée est de
permettre aux utilisateurs de se déplacer d’un réseau à un autre en conservant une connexion active, et une
même adresse IP. Elle implique donc trois sous-problèmes :

- Être joignable
- Pouvoir communiquer
- Conserver la communication lors d’un déplacement

Par connexion active, nous entendons maintenir tous les liens entre le réseau et le nœud mobile. Par
exemple si une connexion TCP est mise en place entre deux nœuds, ces deux nœuds doivent conserver cette
connexion même si l’un des nœuds se déplace.

Fonctionnement en IPv4
Contrairement à ce que l’on peut penser, la mobilité est un sujet qui avait déjà été abordé dans la version 4
du protocole IP.

Pour rappel, le protocole IPv4 a été défini en 1981, dans la RFC 791. Dans cette première définition, il n’était
alors pas question de mobilité. Ce concept n’était peut-être même pas dans l’esprit des gens. Qui aurait pu
penser, en 1981, que le 21ième siècle serait le siècle de la mobilité ?

Toujours est-il que cette mobilité n’a pas été définie à la base du protocole IPv4. Bien évidemment, quelques
années plus tard, la mobilité prenait son importance et il devenait intéressant d’y réfléchir. C’est en 1998
que l’IETF a standardisé une solution de mobilité pour le protocole en IPv4, au travers de la RFC 3344.
Néanmoins, à cette époque, le protocole était déjà mature et fortement déployé. Il était donc impensable de
transformer le protocole à la source, ce qui pouvait entraîner une modification de toute la structure IPv4
déjà existante.

En effet, le protocole IPv4, avec sa notion de masques et de classes de réseaux, ne regarde que très
rarement l’adresse complète d’une machine : il ne s’y intéresse que si la partie réseau de l’adresse le
concerne. Les paquets se transmettent de routeur en routeur sans regarder l’adresse complète du
destinataire. Un utilisateur mobile qui change de réseau devra donc acquérir une nouvelle adresse IP
provenant du réseau dans lequel il se trouve actuellement.

Néanmoins, l’idée de la mobilité IPv4 était de permettre à un nœud de communiquer avec d’autres nœuds
après s’être déplacé physiquement, sans changer d’adresse IP, et sans risquer d’ouvrir de nouvelles failles de
sécurité.

Pour cela, un nouvel en-tête au niveau 3 a été mise en place. Les paquets IP étaient donc encapsulés dans le
protocole IP.

Lorsqu’un correspondant cherche à communiquer avec un nœud mobile, il envoie son paquet vers l’adresse
IP du correspondant. Lorsque le paquet arrive dans le réseau concerné, un routeur appelé Agent Mère
intercepte les paquets, et les transmet vers la position courante du nœud mobile. Une trace de la position
est donc gardée par l’Agent Mère. Pour rediriger les paquets, deux solutions existent :

10
 - L’utilisation d’un Agent Relai. Il est présent dans le réseau du nœud mobile, et il sert de relai entre
l’Agent Mère et le nœud mobile. L’Agent Mère connait l’existence de ce relai, et peut envoyer ses
paquets directement à cet agent.
- L’autoconfiguration : le nœud mobile acquiert une nouvelle adresse IP temporaire, au sein du réseau
dans lequel il se trouve. L’Agent Mère peut donc communiquer directement avec lui. Cependant,
cela implique qu’une plage d’adresses soit réservée dans chaque réseau pour ces adresses mobiles
temporaires. Attention, il ne faut cependant pas confondre ce concept d’autoconfiguration avec
celui, plus puissant, du protocole IPv6.

Bien évidemment, la seconde solution paraît inconcevable lorsque l’on connait le problème de pénurie
d’adresses IPv4.

Cette mobilité IPv4 annonçait donc les prémisses da la mobilité IPv6, avec l’idée d’agent mère par exemple,
mais elle est arrivée trop tard dans l’implémentation du protocole, et elle n’a donc pas été réellement
déployée. De plus, l’encapsulation d’un paquet IP dans un paquet IP pouvait se révéler lourde ou coûteuse,
car le protocole n’était pas prévu pour cela à la base.

Néanmoins, la conception plus moderne du protocole IPv6, ainsi que son système d’autoconfiguration natif a
permis d’alléger les traitements et de faciliter le déploiement de la mobilité IP.

La mobilité IPv6 : définitions

Parce qu’elle a été prévue dès le départ dans la conception du protocole, la mobilité IPv6 semble bien mieux
pensée et aboutie que celle de son aînée. Tout comme pour la mobilité IPv4, l’IETF a rapidement décidé que
la gestion de la mobilité devait se faire sur la couche 3, et paraître totalement transparente pour les couches
supérieures.

De par son système d’en-têtes modulaires, IPv6 règle le problème d’encapsulation de paquets IP dans des
paquets IP. De plus, l’auto-configuration mise en place dans le protocole IPv6 permet à tout nœud d’acquérir
une adresse valide à dans chaque réseau traversé.

Seulement, on remarque facilement que lorsque le nœud mobile se déplace, il change régulièrement
d’adresse IP. A chaque changement, il « perd son identité ». Or, les couches supérieures (notamment la
couche 4) utilisent l’adresse IP pour maintenir des connexions, par exemple avec TCP. Changer d’adresse IP,
c’est aussi rompre ces connexions.

Pour permettre le maintien de ces connexions tout en changeant d’adresse IP, le protocole de mobilité IPv6
(défini dans la RFC3775) utilise la notion de « double adresse ». Chaque nœud mobile va donc retenir son
adresse mère, et une adresse temporaire.

Avant toute chose, il est néanmoins important de définir les notions importantes de la mobilité IPv6.

Home Address
A unicast routable address assigned to a mobile node, used as the permanent address of the mobile node

La Home Address, ou adresse mère, ou encore HoA, est une adresse permanente, acquise par le nœud
mobile dans son réseau de base. Elle permet d’identifier le nœud quelle que soit sa localisation et le réseau
dans lequel il se trouve.

11
Care of Address
A unicast routable address associated with a mobile node while visiting a foreign link;
the subnet prefix of this IP address is a foreign subnet prefix.

Adresse temporaire, la Care of Address, ou CoA, est locale et appartient à chacun des réseaux que le nœud
mobile fréquente. Lorsqu’un nœud mobile arrive dans un réseau qu’il ne connait pas, il peut alors acquérir
facilement, grâce au système d’auto-configuration, une adresse CoA dans ce réseau. Cette adresse est
utilisée à des fins de localisation.

Ainsi, au niveau de la couche 3, le nœud mobile communique avec son adresse temporaire CoA. Mais d’un
point de vue supérieur (couche 4 et plus), le nœud apparaît comme communiquer avec son adresse
permanente, HoA.

Mobile Node (nœud mobile)

A node that can change its point of attachment from one link to another,
while still being reachable via its home address.

Il s’agit d’un nœud qui change régulièrement de point d’accès à l’Internet. Il ne peut donc avoir une adresse
IP fixe, et seule la mobilité IPv6 pourra permettre de donner un identifiant valable dans tout le réseau, sa
home address.

Correspondent node (nœud correspondant)

A peer node with which a mobile node is communicating.
The correspondent node may be either mobile or stationary.
Il s’agit ici du correspondant qui communique avec le nœud mobile. Il existe donc une connexion entre le
nœud correspondant et le nœud mobile, connexion qu’il ne faut pas couper.

Home Agent
A router on a mobile node's home link with which the mobile node
has registered its current care-of address.
Le Home Agent, ou agent mère, est l’entité chargée de faire correspondre CoA et HoA. Il redirige les paquets
à destination du nœud mobile (identifié par la HoA) vers le nœud mobile en déplacement (alors identifié par
son CoA).

Nous verrons plus tard comment fonctionne cet agent, et comment il maintient sa table de correspondance
pendant la mobilité du nœud.

Fonctionnement de la mobilité IPv6

IPv6 introduit de nouveaux concepts pour résoudre le problème de la mobilité. Le réseau mère est le réseau
dans lequel un équipement mobile s’est initialisé. L’adresse mère (Home address ou HoA) est l’adresse de
l’équipement dans le réseau mère. Un équipement peut également acquérir une adresse dans un réseau
auquel il est temporairement connecté : c’est la care-of-address, ou CoA.

L’agent mère (Home Agent ou HA) est chargé de relayer les données passant du réseau mère au réseau.

Les protocoles de mobilité permettent aux machines qui passent de leur réseau mère à un autre de
conserver leur adresse sur celui-là, grâce au Home Agent, qui va se charger de relayer les paquets.

12
Il est alors possible de distinguer plusieurs cas :

Nœud mobile dans son réseau mère

Figure 1 - Noeud mobile dans son réseau mère

C’est le cas par défaut. L’équipement communique comme n’importe quel nœud du réseau. Le nœud mobile
a en effet récupéré une adresse IPv6 dans ce réseau mère (auto-configuration) et l’utilise pour
communiquer. Le Home Agent n’intervient pas dans cette étape. Néanmoins, une relation forte est établie
entre le nœud mobile et ce réseau mère.

Pour découvrir l’agent mère dans le réseau, le nœud mobile envoie un message ICMPv6 à l’adresse anycast
des agents mère du réseau. Lorsqu’il reçoit une réponse positive à sa demande d’association, il a alors
trouvé son agent mère.

Nœud mobile dans un réseau étranger

Lorsqu’un nœud mobile va arriver dans un réseau étranger, il va tout d’abord acquérir une adresse IPv6.
Cette adresse constituera ce que l’on a appelé care-of-address.

Du côté du nœud correspondant, ce dernier continue à envoyer ses paquets à l’adresse qu’il connait, la
home address du nœud mobile. Une fois que le nœud mobile a pu récupérer son adresse temporaire grâce
au système d’auto-configuration, il va alors envoyer un message à son home agent, lui signalant son nouvel
emplacement en lui donnant son adresse temporaire. Cette opération est appelée Binding Update. Le
Binding Update utilise le principe d’extension d’en-têtes afin de créer ce paquet de signalisation du
changement de réseau.

13
 Figure 2 - Binding update vers le réseau mère

Le home agent va alors ajouter une nouvelle ligne à sa table de correspondance, permettant le lien entre
home address et care-of-address pour le nœud mobile. Il va alors pouvoir faire suivre facilement les paquets
vers le nœud mobile. Quand le home agent va recevoir un paquet provenant du nœud correspondant, il va
l’encapsuler dans un nouveau paquet IP grâce à l’extension d’en-tête IP-IP du protocole IPv6.

Pour le nœud correspondant, ce binding update est donc totalement transparent. Il correspond toujours
avec la même adresse destination. Le nœud mobile, quant à lui, va utiliser le même principe. Il va encapsuler
sa réponse (qui a donc pour source la HoA du nœud mobile, et comme destination l’adresse du nœud
correspondant) avec un nouvel en-tête qui aura, cette fois-ci, comme adresse source la CoA du mobile, et
comme destination l’adresse du Home Agent.

Une fois le paquet récupéré par le Home Agent, ce dernier enlève le premier en-tête, et envoie le paquet
vers le nœud correspondant. Pour ce dernier, ce sera exactement comme si le paquet provenait directement
du nœud mobile. Il n’est donc pas nécessaire pour le correspondant d’implémenter la mobilité IPv6, car il
n’utilise aucun des principes de cette dernière. De son point de vue, il ne fait que de la communication avec
adresse IPv6, il ne sait pas qu’il discute avec un nœud mobile.

Interception des paquets

Pour pouvoir intercepter les paquets qui ne lui sont pas destinés, l’agent mère doit régulièrement diffuser
une annonce de voisin non sollicitée (propagation de changement d’adresse physique) dans tout le réseau
mère. Ce message indique aux différents routeurs du réseau qu’il est nécessaire de rediriger les paquets à
destination du HoA du nœud mobile vers l’agent mère.

14
Retour dans le réseau mère
Lorsque le nœud mobile retourne dans son réseau mère, il est important de le signaler à l’agent mère, afin
d’éviter que ce dernier n’envoie les paquets vers la CoA du nœud mobile. Le retour du nœud mobile dans
son réseau mère est détecté, au niveau du nœud mobile, grâce aux différentes annonces de routeurs
contenant le préfixe de sa home address. Il va alors faire une annonce de voisin pour prévenir l’agent mère
de son retour et supprimer son entrée dans la table d’association de ce dernier.

Optimisation de routage
Les lecteurs attentifs auront vite remarqué que la mobilité, telle que définie jusqu’ici, est théoriquement
simple à mettre en œuvre mais elle n’est pas optimisée dans son routage. En effet, lorsqu’un nœud mobile
est en déplacement, tous les paquets vont passer par le réseau mère pour atteindre le nœud mobile.
Imaginons dès lors un nœud correspondant situé en Amérique, un réseau mère situé en France, et un nœud
mobile en déplacement au Canada : un paquet de données traversera l’Atlantique deux fois avant d’arriver à
destination ! Dans cet exemple, il serait bien plus intéressant de communiquer directement entre les deux
nœuds (correspondant et mobile) sans passer par le réseau mère. C’est pourquoi la mobilité IPv6 a intégré
dans son protocole une optimisation du routage.

Dans un premier temps, pour utiliser cette optimisation de routage, il est dès lors essentiel que le nœud
correspondant possède les options de mobilité IPv6 (ce qui n’était pas nécessaire avant). Grâce à cette
intégration de la mobilité au sein du nœud correspondant, ce dernier va pouvoir maintenir une table des
associations, identique à celle maintenue par l’agent mère. Pour avoir cette table de routage à jour, le nœud
mobile va devoir, lors de chaque changement de réseau, envoyer un paquet de binding update au réseau
mère, puis au nœud correspondant. De cette manière, le nœud correspondant pourra ajouter ou mettre à
jour la ligne dans sa table de correspondance.

Figure 3 - Binding update vers le noeud correspondant

15
Connaissant la HoA et la CoA, le nœud correspondant va pouvoir modifier ses paquets pour leur donner
comme adresse de destination la CoA du nœud mobile. Cette modification consistera aussi en l’ajout d’une
extension d’en-tête de routage particulière contenant l’adresse HoA du nœud mobile comme destination
finale. Cette extension d’en-tête de routage est une extension définie pour la mobilité IPv6. De cette
manière, les passerelles de sécurité pourront adopter un filtrage différent de celui appliqué pour les autres
en-têtes de routage.

Lorsque le nœud mobile cherche à communiquer avec un correspondant, il va d’abord tenter d’envoyer un
paquet de mise à jour d’association. Si le nœud correspondant répond qu’il ne comprend pas cette
demande, l’optimisation des routes n’est pas possible (le nœud correspondant n’est pas configuré pour la
mobilité IPv6). Le nœud mobile utilisera alors la voie classique, passant par son réseau mère. Un message
ICMPv6 a été défini pour ce cas où le nœud correspondant « ne parle pas le langage mobile IPv6 ».

Cette optimisation étant faite au niveau de la couche 3, elle reste transparente pour les couches supérieures,
qui peuvent alors garder une connexion active tout au long du déplacement du nœud mobile.

Figure 4 - Routage optimisé dans le cadre de la mobilité IPv6

Mobility header
Dans les précédentes parties de ce rapport, il est souvent mentionné la notion d’extension d’en-tête. IPv6
propose aujourd’hui environ 150 extensions d’en-tête, répondant à différents protocoles et besoins. Parmi
toutes ces extensions, il en est une à retenir dans le cadre de notre projet : l’en-tête 135, appelée aussi en-
tête de mobilité (mobility header). Cet en-tête, défini dans la RFC 6275 (RFC concernant la mobilité IPv6)
propose un format particulier.

16
 Figure 5 - En-tête de mobilité IPv6

Le champ d’en-tête suivant permet d’associer d’autres extensions d’en-tête à l’en-tête de mobilité.

Le type d’en-tête peut prendre plusieurs valeurs (entre 0 et 7) :

0. Demande de rafraîchissement de lien

1. Initialisation de test d'adresse mère (HoTI)
2. Initialisation de test d'adresse temporaire (CoTI)
3. Test d'adresse mère (HoT)
4. Test d'adresse temporaire (CoT)
5. Mise à jour d'association (binding update)
6. Acquittement de mise à jour d'association
7. Erreur de mise à jour d'association

Nouveaux messages ICMP

La RFC 6275 définit aussi de nouveaux formats de messages ICMP, répondant aux besoins de la mobilité.
Deux concernent la découverte dynamique du Home Agent et deux pour la renumérotation et la
configuration du mobile.

 Home Agent Address Discovery Request

 Home Agent Address Discovery Reply
 Mobile Prefix Solicitation
 Mobile Prefix Advertisement.

Risques et sécurité de la mobilité IPv6

IPv6 supporte par défaut IPsec, qui offre une sécurisation au niveau de la couche Réseau.

Dans le cadre d’IPv6, IPsec permet :

- d’assurer l’authentification de l’émetteur et l’intégrité des données. (Authentification Header)

- d’offrir la confidentialité des données en chiffrant les paquets IPv6, en-tête comprise ou non.
(Encapsulation Security Payload)

L’auto-configuration sans état des adresses (vu précédemment) pose un problème au sein de réseaux
locaux. Une fois qu’une machine a configuré son adresse locale, il interroge ses voisins pour vérifier que son
adresse n’est pas utilisée. S’il ne reçoit pas de réponse négative, le processus se termine. Dans le cas où une
personne décide volontairement de répondre toujours positivement à cette requête, elle peut notamment
détourner des données ou usurper une adresse IP par exemple (usurpation ARP).

17
Mise en œuvre de la mobilité

Après cette étude préliminaire nous sommes passés à la pratique. Notre but était de
créer deux réseaux IPv6 et de tester le passage d’un nœud mobile (connecté en Wifi) de
l’un à l’autre.

Matériel
Nous disposions de quatre routeurs de marque TP-LINK, gracieusement fournis par
l’association Rhizome. Ces routeurs proposent quatre ports Ethernet, du Wi-Fi en norme
n et un port WAN pour réaliser l’interconnexion en Ethernet des deux réseaux
indépendants. Ces routeurs sont configurés sous une distribution de Linux nommée
OpenWRT et disposent au total de 4Mo de mémoire Flash. En excluant l’espace pris par
l’installation d’OpenWRT, il restait environ 1,5Mo de mémoire libre.

Figure 5 : Le modèle de routeur que nous avons utilisé

Préparation des terminaux et routeurs IPv6

Il était essentiel pour nous de disposer de machines facilement configurables, et sur lesquelles nous
pouvions avoir la main. Naturellement, nous nous sommes orientés vers une distribution Linux, la
configuration réseau étant difficile sur les systèmes d’exploitation concurrents (Windows et Mac). Nous
avons choisi des distributions Debian (et sa dérivée Ubuntu) car nous étions habitués à celles-ci.

Concernant les routeurs, OpenWRT étant basé sur un noyau Linux, le choix était déjà fait pour nous, et
semblait nous convenir.

OpenWRT
OpenWRT est une distribution GNU/Linux dédiée aux matériels embarqués. Cette distribution fournit un
système de fichiers totalement modifiable et implémentant la gestion des packages. Cela permet aux
utilisateurs de se libérer totalement de la configuration initiale fournie par le constructeur et pouvoir
personnaliser l’appareil à leur guise, sans aucune contrainte et sans avoir à créer un firmware complet.

Nos routeurs TP-Link sont bon marchés et dispose par défaut de peu d’options. Si ces réglages suffisent
parfaitement pour une utilisation courante, le firmware constructeur ne couvre pas du tout nos besoins,
bien trop spécifiques. Heureusement ce routeur est très bien suivi par la communauté et dispose donc de
versions spécifiques d’OpenWRT ainsi que de nombreux tutoriaux et autres documentations.

18
Historique
Dans un premier temps, nous avons regardé où en était l’implémentation IPv6 au sein du système Linux.

IPv6 est officiellement présent dans le noyau Linux depuis la version 2.2, sorti en janvier 1999. Il était dès
lors possible d’utiliser Linux pour expérimenter IPv6 (adressage, envoi et réception de paquets, etc.).
Néanmoins, la mobilité n’était pas encore réellement envisagée à cette époque. C’est en effet quelques
années plus tard que les premières RFC concernant la mobilité apparaissent, notamment pour IPv4. On peut
par exemple noter la RFC 3344, apparue en août 2002 (puis révisée par avec la RFC 5944 datant de
novembre 2010).

Concernant IPv6, il faudra attendre juin 2004, avec la RFC 3775, pour voir apparaître la notion de mobilité
IPv6.

La mobilité IPv6 n’était donc évidemment pas présente dans le noyau 2.2. C’est dans la version 2.6 du noyau
qu’elle commencera à être implémentée. Cependant, bien que présente au sein du noyau, celle-ci n’est pas
activée par défaut. Et ce jusqu’à … aujourd’hui. En effet, c’est toujours le cas dans la dernière version du
noyau (3.7), sortie le 11 décembre dernier.

Compilation du noyau
Pour activer la mobilité IPv6 sur nos machines, il est nécessaire de recompiler le noyau Linux afin de
“cocher” les cases permettant la mobilité.

Pour les machines

Recompiler le noyau pour les machines n’a pas été une étape très difficile. En effet, la compilation de noyau
sous Debian ou Ubuntu est une opération relativement facile et prévue. Nous avons donc suivi l’un des
nombreux tutoriaux disponibles sur la toile pour compiler le noyau 3.6 afin d’y activer la mobilité
(http://n0dev.org/articles/mobilite-ipv6.php).

Voici les différentes étapes suivies :

1. Téléchargement de la dernière version du noyau sur le site www.kernel.org

2. Décompression de l’archive
3. Activation des options de mobilité IPv6 à l’aide de la commande “make menuconfig”

Figure 6 –
Options à activer dans le
noyau Linux

19
 4. Compilation du noyau
5. Redémarrage de la machine sous le nouveau noyau

Nous disposions alors d’un noyau compatible avec la mobilité IPv6. Il ne restait plus qu’à installer des
paquets permettant l’utilisation de cette dernière, grâce au projet UMIP (présenté dans la partie suivante).

Pour les routeurs

Concernant les routeurs sous OpenWRT, la méthode était sensiblement la même. En effet, OpenWRT est
basé sur un noyau 2.6 de Linux, l’IPv6 et sa mobilité sont donc présents, mais la mobilité n’est pas activée.

Il suffit donc de suivre les mêmes étapes que précédemment. Seulement, la compilation décrite à la page
précédente compile un noyau pour l’architecture où est effectuée la compilation. Malheureusement, il était
impensable d’effectuer cette compilation au sein du routeur TP-Link, à cause des faibles performances et du
peu d’espace disponible sur ces routeurs.

C’est pourquoi nous avons décidé d’utiliser un PC de bureau pour compiler le noyau pour OpenWRT. Nous
avons donc choisi de suivre le tutoriel fourni par OpenWRT afin de compiler le noyau pour l’architecture du
routeur.

Cependant, cette étape n’a pas abouti. En effet, nous avons eu beaucoup de difficultés à compiler le noyau
sans erreurs. Nous avons fini par avoir une version qui semblait avoir compilé sans problèmes, mais lorsque
nous l’avons injecté dans le routeur, ce dernier n’a plus fonctionné comme auparavant : l’interface web
n’était plus accessible, nous ne pouvions accéder au routeur que par SSH. Nous ne pouvions pas non plus
vérifier que les options activées fonctionnaient. Et il nous restait un problème de taille : après avoir compilé
le noyau et activé les options concernant la mobilité, il fallait disposer de paquets permettant l’exploitation
de cette mobilité.

A partir de ce moment-là, nous avons fait face à un constat : il n’existe pas de paquets OpenWRT permettant
l’exploitation de la mobilité IPv6. Nous avons cherché dans les différents dépôts, sans réellement trouver de
solutions.

Nous sommes alors partis sur la cross compilation. La cross compilation permet de compiler un code prévu à
la base pour une certaine architecture vers une architecture différente. Nous voulions compiler les paquets
UMIP (voir paragraphe suivant) pour OpenWRT. Des tutoriaux de cross compilation pour OpenWRT existent,
c’est pourquoi nous sommes partis sur cette piste.

Néanmoins, après avoir plus ou moins réussi cette cross compilation, il nous a été impossible de la tester : le
paquet généré était d’une taille bien trop importante pour être mise sur le routeur TP-Link, ces derniers ne
possédant que 4Mo de mémoire interne.

Nous n’avons donc pas pu installer les paquets nécessaires à la mobilité IPv6 sur les routeurs TP-Link sous
OpenWRT. Notre première idée d’utiliser les routeurs comme home agent n’était plus possible.

Pour contrer ce problème nous avons réfléchi à une nouvelle architecture où les routeurs supportent
uniquement IPv6, et non sa mobilité. Ils routent alors les paquets en s’arrêtant à l’analyse de l’adresse de
destination. Le travail sur la mobilité se faisant uniquement au niveau de l’agent mère et du nœud mobile
qui, cette fois-ci, seront des ordinateurs sous debian, avec la variable net.ipv6.ip_forward à TRUE.

20
Nouvelle architecture pour notre réseau
Nous avons décidé de modifier l’architecture de notre réseau pour utiliser les routeurs OpenWRT
uniquement comme routeurs. Voici un schéma de l’architecture que nous avons conçue :

Figure 7 - Architecture mise en place

Les routeurs OpenWRT sont utilisés pour créer un réseau Wifi. On connecte également aux routeurs par un
port Ethernet le serveur de mobilité (home agent). Nous avons choisi cette configuration pour deux raisons :
d’abord parce qu’elle permet d’effectuer des tests assez simplement - le nœud mobile a juste à passer d’un
réseau wifi à l’autre - ensuite parce que nous comptions utiliser des OS virtualisés pour faire office de
serveur et que dans le cadre de la virtualisation, les connexions Ethernet sont beaucoup mieux supportées
que les connexions Wifi.

Virtualisation
Lors de la mise en œuvre du projet, nous avons décidé de virtualiser les serveurs qui exécuteraient le “Home
Agent” et le “Care of Agent”. En effet, pour chacune de ces machines il est nécessaire de passer par des
étapes assez longues de configuration (du noyau, du compilateur, des démons – voir ci-après) pour obtenir
un système fonctionnel. Un système virtualisé permet de ne faire ce travail qu’une seule fois pour les deux
machines. Il apporte également une très grande souplesse en permettant de sauvegarder et de recharger
l’état d’une machine et même de la déplacer sans problème sur une autre machine hôte.

Dans le cadre du projet nous avons choisi d’utiliser la distribution linux “Debian” qui est très stable et qui a
de plus été utilisée dans la plupart des mises en œuvre que nous avons vues. L’un des autres avantages
d’utiliser des nœuds virtualisés est de protéger nos machines personnelles. Si un noyau est facile à
supprimer, les nombreux services et packages à installer, souvent en version beta, auraient pu rendre
instable des machines que nous utilisons quotidiennement.

Malheureusement nous avons dû abandonner l’idée d’utiliser des systèmes virtualisés à cause de problèmes
d’implémentation : il semblerait que dans le cas d’IPv6, il y ait des conflits entre le système d’exploitation
hôte et la machine virtuelle : nous nous sommes rendu compte que les paquets IPv6 destinés à notre VM
étaient tout simplement jetés silencieusement par la machine hôte.

21
Tandis que le nœud mobile capte bien les paquets de « neighbour solicitation » du protocole NDP, les
machines virtuelles ne reçoivent rien. Il pourtant possible de les solliciter à l’aide de la commande ping6,
mais certains paquets semblent filtrer, quelle que soit la configuration de VirtualBox (Bridge ou NAT).

Plutôt que d’utiliser une machine virtuelle, nous avons donc du patcher le noyau installé sur nos ordinateurs
portables.

La mobilité IPv6 côté software

Maintenant que la pile protocolaire IPv6 a été modifiée, notre noyau est compatible avec les mécanismes de
mobilité IPv6. Pourtant l’ordinateur n’est pas encore près pour une phase de test concrète. Pour recevoir les
messages et gérer la communication entre le nœud mobile et son « home agent » un démon linux est
nécessaire, souvent appelé « userspace ». De la même manière, l’autoconfiguration des machines se
connectant à un réseau est gérée par un démon spécifique.

Radvd
Radvd (Router Advertisement Daemon) est un logiciel open-source implémentant les annonces lien-local
pour des routeurs IPv6. Il permet de distribuer des adresses aux postes se connectant au réseau grâce au
protocole NDP (Neighbour Discovery Protocol) conformément à la RFC 2461. L’adresse est générée en partie
à partir d’un préfixe réseau établit par l’administrateur, le reste pouvant être construit avec l’adresse MAC
de la carte réseau ou via DHCPv6.

NDP rend possible la découverte des autres machines d’un même lien et de leur adresse, il permet aussi
d'identifier les routeurs présents (il prend donc comme prévu la relève d’ARP). Ce protocole est implémenté
dans la couche 3. Le démon radvd permet l’autoconfiguration sans état des machines, concept que nous
avons évoqué plus haut.

Lorsque les machines IPv6 configurent leur interface réseau, elles diffusent des requêtes de Router
Sollicitation sur le réseau dans le but de découvrir les routeurs disponibles. Radvd répond à ces requêtes par
des messages de Router Advertisement qui contiennent, entre autres informations, le préfixe réseau à
utiliser pour l’autoconfiguration, ainsi que l’adresse du routeur. Des messages de même type sont
également envoyés régulièrement par radvd sur le lien connecté pour mettre à jour la liste des voisins.
Radvd prend également en charge les options de Recursive DNS Server (RDNSS) et de DNS Search List
(DNSSL) décrites dans la RFC 6106.

Voici la configuration que nous avons utilisé pour notre préfixe : config prefix
option interface 'lan'
L’adresse peut bien sûr être changée en fonction des besoins. Avec list prefix '2001:123:456:789::/64'
cette configuration, le routeur émet sur le LAN de manière option AdvOnLink '1'
automatique. AdvOnLink et AdvAutonomous active l’utilisation du option AdvAutonomous '1'
préfixe pour l’autoconfiguration. option AdvRouterAddr '0'
option ignore '0'

A l’aide de la capture Wireshark en page suivante, réalisée lors de la mise en place de l’architecture de test,
expliquons plus en détail le fonctionnement de ce logiciel :

22
Comme expliqué précédemment, les adresses commençant par fe80 sont dites « lien-local », elles ont une
visibilité limité et permettent la communication des machines connectées sur un même lien.

Trame 44 : Neighbor Solicitation : L’un de nos ordinateurs portables vérifie l’existence et la connectivité au
voisinage. Il vient de s’attribuer une adresse de lien-local et demande au réseau si celle-ci est unique, et s’il
peut donc l’utiliser. Pour communiquer il utilise l’adresse ::, équivalente à 0.0.0.0 pour IPv4. La destination
(ff02 ::1) commençant par ff, il s’agit donc d’une adresse multicast, le 02 correspond au lien-local, le 1 à
toutes les machines.

Trame 86 : Après s’être attribué une adresse le portable tente de découvrir si un routeur est présent à l’aide
du message « Router Solicitation » envoyé à l’adresse multicast (ff02::2). Les routeurs s’y enregistrant
automatiquement, ceux présents vont donc recevoir son message.

Trame 88 : En réponse au message précédent, ou grâce au logiciel radvd qui permet leur émission régulière
(impossible de savoir), le routeur envoie un « Router Advertisement » sur ff02::1. Ce paquet donne de
nombreuses informations sur le lien-local, il est réémis périodique car ces données ont une durée de vie
limitée. Il permet de configurer la route par défaut et donne les préfixes pour l’autoconfiguration ou, dans le
cas d’une autoconf statefull, l’adresse du serveur DHCPv6 disponible.

Trame 91 : Il s’agit d’une trame du protocole Multicast Listener Discovery (MLDv2) qui permet au routeur de
découvrir les nœuds en cours d’écoute sur le lien. Ces paquets sont envoyés à l’adresse multicast ff02::16.

Trame 205 : Grâce aux adresses en fec0:106:2700/64 que se sont attribuées nos machines grâce aux trames
de « Router Advertisement » émises par radvd, nous tentons de faire communiquer 2 de nos machines.

Trame 206 : La machine de destination ne connaissant pas l’adresse MAC de celle ayant initiée la requête
echo, elle la demande sur le réseau en utilisant NDP (Neighbor Discovery Protocol). Ce paquet est envoyé à
l’adresse multicast de découverte des nœuds (ff02::1:ff00:xxx) ou xxx sont les 24bits de l’adresse recherchée
(ici, seulement :4).

Trame 207 : La machine 4 répond à la machine 2 avec son adresse MAC à l’aide d’un Neighbor
Advertisement. Cet échange montre parfaitement le remplacement d’ARP par le NDP.

Trame 209 : Le routeur observant la conversation entre 2 et 4 tente d’améliorer leur échange à l’aide d’un
ICMPv6 Redirect, qui donne à la machine 4 une meilleure route pour communiquer avec 2. En effet, par
défaut les machines envoient leurs paquets sur le réseau au premier routeur disponible, sans se demander si
une meilleure route existe à travers un autre routeur.

23
Daemon UMIP et UserSpace
En plus du daemon Radvd côté routeur/agent, un daemon gérant la mobilité doit fonctionner sur tous les
équipements du réseau.

Depuis la finalisation des RFC traitant de la mobilité, quelques groupes de recherche ont proposé leur
implémentation du protocole afin de fournir ce logiciel. Les premiers à le faire furent les anglais de la
Lancaster University, qui stoppèrent le développement à la fin des années 90. Apparemment la dernière
version du noyau pris en charge était la version 2.1, leur site n’étant plus accessible, leur code n’est plus
disponible.

Le deuxième projet ayant vu le jour à propos de la mobilité IPv6 nous vient de Finlande, il s’agit du projet
MIPL (Mobile IPv6 for Linux), hébergé par la Helsinki University of Technology's. Ce groupe n’existe plus non
plus aujourd’hui, et toute trace de leur implémentation a disparu. Elle était compatible jusqu’au noyau 2.4.
MIPL 2.0 est sortie en 2006, sa dernière version (2.0.2) était compatible avec le noyau 2.6.16, et nous avons
retrouvé plusieurs articles ayant testé cette solution de manière concluante. Encore une fois, le site internet
n’est plus disponible, mais d’anciens miroirs non officiels sont encore disponibles pour récupérer le code
source.

De toute manière, ces premières implémentations sont aujourd’hui largement obsolètes. Elles ont en effet
pris place avant l’intégration de MIPv6 dans le kernel, qui a eu lieu à la version 2.6.26. Il fallait donc patcher
les sources du noyau, avant de le recompiler, ce qui n’est plus nécessaire aujourd’hui car la mobilité IPv6 est
présente (mais non activée). Si les nouveaux travaux se sont basés sur ces recherches, elles ne sont guère
utilisables aujourd’hui.

Des travaux plus récents sur la mobilité ont été repris au Japon par l’USAGI (UniverSAl playGround for Ipv6)
Project. Basé sur la dernière version de MIPL, leur daemon (UMIP 0.4) a été développé jusqu’à la version
2.6.24 du kernel. Enfin le projet UMIP.org s’est basé sur leurs travaux pour intégrer le support du protocole
NEMO et corriger de nombreux bugs. NEMO permet de maintenir des communications avec un réseau
entier d’éléments mobiles et non plus un seul nœud. UMIP.org a présenté sa solution sur un kernel 2.6.29.

Toutes ces solutions nous ont posés de nombreux problèmes, que nous n’avons pas encore réussi à
résoudre. Tout d’abord nous avons commencé à travailler sur d’anciennes versions du noyau, puisque la
plupart des tests avaient été effectués sur une 2.6. Nous avons donc récupéré les sources des deux noyaux
encore mis à jour de cette version (2.6.32.60 et 2.6.34.13) sur le dépôt officiel. Malheureusement, après leur
avoir appliquer les modifications nécessaires, nous n’avons jamais réussi à les compiler. Les versions de
linux, Debian et Ubuntu, actuellement installés sur nos ordinateurs personnels ne sont plus compatibles. La
compilation, en fonction du noyau testé, échouait à cause d’incompatibilité avec gcc et qt, ou refusait
carrément de se lancer.

En compilant un noyau plus moderne (3.6.9, de la manière décrite au chapitre précédent), ces problèmes ne
sont pas apparus et le système fonctionnait correctement. Nous n’avons cependant pas été capables
d’exécuter les daemons MIP, le lancement ne fonctionnant pas ou entrainant inexorablement un Kernel
Panic obligeant un reboot de la machine.

24
Nos espoirs se sont donc tournés vers un dernier projet travaillant sur la mobilité, le nautilus6.

Ce groupe de travail propose un LiveCD prêt pour effectuer des tests sur la mobilité, basé sur la version 7.10
d’Ubuntu (datant d’octobre 2007). Le kernel (2.6.22) est déjà configuré, et le logiciel UMIP est préinstallé. En
modifiant le fichier d’installation des paquets pour utiliser le dépôt old-releases.ubuntu.com, nous avons
même été capables de mettre à jour le système. Cette distribution avait pour but d’implémenter les derniers
standards de son époque sur la mobilité IPv6. Ses développeurs ont aussi beaucoup travaillé sur NEPL
(NEMO Platform for Linux), l’extension du MIPL de l’Université d’Helsinki, leur site internet fournit donc
beaucoup d’explications sur la mise en place de cette extension, mais peu sur le test simple d’un seul nœud
mobile.

Deuxième plateforme de test avec Nautilus

A la suite de nos précédents échecs, nous avons tenté une approche différente, à l’aide de la distribution
Nautilus. Le noyau de cette distribution étant nativement compatible avec la mobilité IPv6, il nous suffisait
de l’installer sur 3 de nos ordinateurs pour mettre en place notre architecture.

La première difficulté vint de l’âge du système. Basé sur Ubuntu 7.10, Nautilus a refusé de se lancer sur la
plupart de nos machines modernes, nous avons donc utilisé d’anciens ordinateurs portables, exclusivement
basé sur le couple processeur/carte graphique intel/nvidia.

Une fois le système démarré, plusieurs réglages sont nécessaires :

 Changement de la disposition du clavier en Azerty.

 Activation du wifi et des cartes Ethernet sur les différents ordinateurs, une ip fixe ipv6 est ensuite
manuellement ajoutée.
 Le fichier /apt/sources.list est modifié avec l’adresse de dépôts de logiciels encore fonctionnels pour
cette version d’Ubuntu (Gutsy) et les paquets disponibles sont mis à jour.
 echo "net.ipv6.ip_forward = 1" >> /etc/sysctl.conf suivi d’un sysctl –p, permet d’activer le transfert
des paquets sur les machines qui en ont besoin.
 A l’origine le système ne comporte pas de fichier de configuration pour le daemon mip6 (chargé de
la mobilité). Nous avons créé 3 configurations pour le nœud Mobile (MN), le Home Agent HA
(connecté au réseau de départ du MN) et la Care of Address CoA (connecté au réseau de destination
du nœud mobile). Pour réaliser ces fichiers nous sommes parties d’exemple disponibles sur internet
(principalement sur le site UMIP.org).

25
Au départ, le nœud mobile est connecté au routeur A, sur le réseau db8. Il s’enregistre auprès de son Home
Agent, et va tenter de passer sur le réseau wifi du routeur B, sans perdre ses connexions actives, qui
transiteront par le réseau db6 interconnectant les routeurs.

En théorie, les deux routeurs devraient être reliés à travers internet, mais pour des raisons pratiques, nous
avons choisi de travailler entièrement à l’intérieur d’un réseau local.

Les deux routeurs sont configurés pour distribuer des adresses IPv6 aux mobiles qui se connectent à leur
réseau. Cette fonctionnalité est gérée par un démon RADVD (voir les explications disponibles au chapitre
précédent) que nous avons installé sur la distribution OpenWRT des routeurs TP-Link.

Enfin, pour permettre la communication entre les réseaux db8 et db7, nous avons modifié les routes par
défaut des routeurs et des postes HA et CoA afin que les paquets transitent par le réseau d’interconnexion
db6.

Malheureusement, nous n’avons pas réussi à observer de paquets MIPv6 sur le réseau. Bien que les démons
fussent lancés, l’écoute des différentes interfaces à l’aide de Wireshark est restée muette, sans que nous
ayons pu en trouver la cause. Le mobile avait beaucoup de difficulté à se connecter aux réseaux, la carte wifi
n’étant pas vraiment compatible avec cette vieille distribution, mais les différents processus sur les machines
auraient dû transmettre au moins quelques sollicitations.

Après ce nouvel échec, nous avons tenté une nouvelle forme de mobilité, en remontant d’une couche dans
le modèle OSI, afin d’utiliser des technologies plus actuelles.

26
Le protocole SSP : un remplaçant de la mobilité IP sur la couche application

Au cours de nos recherches sur le sujet, nous avons découvert un protocole très récent, nommé “SSP”
(Simple Synchronization Protocol), qui est spécialement conçu dans une optique de mobilité.

Pour l’anecdote, SSP a été conçu à la base pour développer un remplaçant de telnet et de SSH, nommé mosh
(http://mosh.mit.edu). Mosh a pour but de résoudre deux problèmes qui sont très agaçants avec SSH et
telnet :

 la mobilité. Si l’on est sur un portable et qu’on passe d’un réseau wifi à l’autre, la connexion au
serveur distant est perdue
 les problèmes de latence lorsqu’on est sur une connexion à forte latence. En effet, SSH utilise TCP,
qui est assez mal adapté aux connexions à forte latence. Au contraire, SSP utilise UDP pour
davantage de réactivité.

SSP résout ces problèmes de manière assez élégante. En effet, SSP a la particularité d’être à un niveau au-
dessus de SSH : SSH a pour but de crypter un flux entre deux machines; SSP synchronise les états de données
entre deux machines. C’est à dire que par exemple si ma machine est déconnectée du serveur pendant 2
minutes, alors que SSH tenterait de récupérait le flux à l’endroit où il l’a perdu, SSP demande au serveur de
lui fournir tous les états de l’application entre le moment où le client a été déconnecté et maintenant. Par
défaut, une version correspond à un paquet UDP ce qui simplifie beaucoup l’implémentation du système.

La façon dont SSP implémente la mobilité est également très intéressante : étant donné que le protocole
gère l’authentification à l’aide de clés publiques/privées, il n’est plus nécessaire de se préoccuper de
l’adresse IP d’un client puisqu’on peut certifier qu’il est la personne qu’il prétend être à l’aide de sa clé
privée. De cette manière, un client peut passer d’un réseau à l’autre et continuer à converser avec le serveur
sans même se rendre compte que son IP a changé.

Un test est disponible sur internet pour le comparer à SSH en utilisant l’architecture suivante :

Figure 8 - Exemple du protocole SSP

Il suffira alors de vérifier la réactivité de mosh vis à vis de ssh. A défaut d’avoir pu tester une vraie mobilité
IPv6 (à la couche 3 du modèle OSI donc), nous espérons pouvoir tester plus amplement cette solution
applicative permettant la mobilité sur un protocole précis (ici SSH). Le but étant de présenter nos
investigations lors de la soutenance en Janvier. Nous voyons donc que cette mobilité est possible, mais que
pour la généraliser, il est important de la situer en couche inférieure et non en couche applicative. Chaque
application pourrait en effet proposer son propre module de mobilité, mais cette mobilité ne serait pas
standard. C’est pourquoi nous continuons à penser que la mobilité IPv6 est un protocole important.

27
Conclusion
Malgré l’échec de la mise en œuvre de la mobilité IPv6, nous sommes très contents d’avoir travaillé sur ce
projet orbitant autour du protocole IPv6. Dans cette phase d’expérimentation, plus pratique, nous avons
appris beaucoup de choses techniques : compilation d’un noyau Linux pour machine et routeur, installation
de machines virtuelles, configuration de routeurs en CLI ou par interface web, mise en place d’une
architecture réseau simple, analyse de paquets grâce à Wireshark, adressage IPv6, configuration de la
mobilité au sein des différentes entités (nœud mobile, home agent, etc.).

En plus de cela, la première phase du projet, la phase d’étude, a été très enrichissante pour chacun d’entre
nous. Le protocole IPv6 avait déjà été abordé lors d’un cours de SR04, mais n’avait pas été approfondi. Nous
avons donc pris le temps de mieux comprendre ce protocole encore naissant (bien qu’il existe depuis plus de
dix ans), au déploiement est encore limité. Les différentes caractéristiques du protocole ont été étudiées,
certaines ont même été testées :

 L’autoconfiguration, grâce à radvd notamment ;

 L’adressage ;
 Le principe de découverte des voisins.

Au-delà du protocole IPv6, nous nous sommes particulièrement penchés sur la mobilité. Cette seconde
partie de l’étude a été un travail de longue haleine, où nous avons pris le temps de lire une RFC. Nous y
avons découvert la rigueur d’écriture d’un protocole, mais aussi son accessibilité. L’écriture d’une RFC doit
être un travail long et fastidieux, mais aussi pédagogique. Il est important de rester clair afin que la RFC soit
compréhensible pour un maximum de monde.

L’analyse de cette RFC, couplée à la lecture de quelques articles concernant la mobilité nous a permis de
véritablement comprendre cette mobilité et ses mécanismes. Et donc de comprendre son utilité dans ce
21ème siècle « nomade ». L’essor de l’internet connecté partout et toujours, notamment grâce à de simples
appareils usuels comme un téléphone portable, vient poser la question de la mobilité. Les gens bougent,
traversent le monde de réseaux en réseaux. Pouvoir offrir un internet sans perte de connexion à l’utilisateur
est une demande qui se fera de plus en plus sentir.

Avec la pénurie d’adresse IPv4, il n’y a nul doute que le protocole IPv6 va prendre son envol, mais il est
difficile de dire si ce sera dans les années à venir. En effet les grands réseaux d’entreprise resteront encore
longtemps en IPv4, le budget pour passer en IPv6 étant difficile à justifier. Il peut être intéressant de noter
que des opérations comme l’IPv6 Day (06/06/2012) permettent de faire avancer ce déploiement.

Lorsque le protocole IPv6 aura été mondialement déployé, la mise en place de la mobilité se fera
naturellement car elle répond à un besoin concret.

C’est aussi pour cette raison que nous avons apprécié travailler sur ce projet. Bien que la mobilité ne semble
pas encore mature dans son implémentation, nous n’avons aucun doute quant à son utilité (et son
utilisation) d’ici quelques années.

28