1

Nathan CASTELEIN Karim HAMIDOU César MARCHAL Christian PATRY

SR04

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

2

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

3

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

4

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.

5

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.

6

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.

7

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.

8

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).

9

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.

10

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 :

11

- 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.

12

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.

13

Il est alors possible de distinguer plusieurs cas :

Nœud 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.

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

14

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.

15

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

16

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.

17

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).

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

18

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.

19

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

20

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.

21

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.

22

config prefix

option interface 'lan'

list prefix '2001:123:456:789::/64'

option AdvOnLink '1'

option AdvAutonomous '1'

option AdvRouterAddr '0'

option ignore '0'

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 :

L’adresse peut bien sûr être changée en fonction des besoins. Avec

cette configuration, le routeur émet sur le LAN de manière

automatique. AdvOnLink et AdvAutonomous active l’utilisation du

préfixe pour l’autoconfiguration.

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 :

23

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.

24

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.

25

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).

26

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.

27

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.

28

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.