Cette section décrit un cas pratique de mobilité IPv6 telle qu'elle est mise en oeuvre dans la souche LIVSIX. Cette souche implémente la plupart des protocoles IPv6 nécessaires à un terminal mobile tels que la découverte de voisins, TCPv6, UDPv6, une grande partie des fonctionnalités de Mobile IPv6, ainsi que l'interface de programmation de type socket. Le but de cette expérimentation sera d'illustrer la continuité de fonctionnement de l'application ping lorsque le terminal mobile s'attache à différents points d'accès lors d'épisodes de mobilité, sans qu'il soit nécessaire de reconfigurer sa couche réseau et de redémarrer l'application comme ce serait le cas sans MIPv6.

L'application ping, fréquemment utilisée pour les tests de connectivité de réseaux, implique une succession d'échanges de paquets symétriques et s'exécute sur le MN. Elle envoie un nombre paramétrable de paquets ICMP de type echo-request, de taille également paramétrable, et attend que le correspondant réponde à chaque paquet echo-request par un paquet ICMP de type echo-reply.

Topologie

Une topologie minimale pour tester la mobilité IP requiert l'utilisation de plusieurs systèmes. Il est en effet nécessaire d'utiliser au moins trois ordinateurs différents pour le MN, le CN et le HA. Ensuite, comme chacun de ces systèmes doit être positionné dans des sous-réseaux différents, quelques routeurs seront nécessaires pour constituer un réseau coeur. Finalement, pour que le terminal soit effectivement mobile, l'utilisation d'une technologie lien sans fil s'impose, donc au moins deux points d'accès, en l'occurrence WiFi (802.11b).

Sur la figure plateforme de test, les deux routeurs centraux R1 et R2 forment un réseau c?ur, au bord duquel les HA, MN et CN sont positionnés. Le réseau mère interconnecte le HA, le MN et le AP1. Les réseaux visités, offrent l'accès WiFi 802.11b au moyen de deux AP's (Access Points) différents : AP1 et AP2. Finalement, le CN est positionné dans un réseau entièrement séparé.

Configuration Initiale

Initialement, le MN est positionné dans son réseau mère et configuré sans Mobile IPv6, c'est-à-dire comme un système IPv6 pourvu d'une adresse auto-configurée dynamiquement ainsi que d'une route par défaut. Dans la description suivante, le code source de la souche LIVSIX à été téléchargé et installé sur le MN et le HA dans le répertoire noté <l>, les noyaux de ces deux systèmes ont été configurés pour accepter LIVSIX, les sources respectives ont été compilées et R1 et R2 sont configurés pour envoyer des RA's sur leur liens avec une fréquence élevée (typiquement 50ms au lieu de 3 secondes). Les instructions d'installation détaillées se trouvent dans le fichier INSTALL de la distribution LIVSIX.

La configuration la plus simple de la souche du MN passe par la modification du fichier livsix.sh dans le répertoire <l>/userspace. Il s'agit d'indiquer seulement le paramètre MCONF, pour spécifier MN :

#!/bin/sh
# Copyright Emmanuel Riou, Alexandru Petrescu,
# Motorola Labs 2000, 2001, 2002, 2003, 2004
#
# Load LIVSIX module
#
# Automatically loads Livsix kernel module and configures it. This
# Script works only on Linux: hasn't been tested on other System.
LOCKDIR=/var/lock/subsys
# ISROUTER=1 means the machine forwards packets according to the
# routing table. ISROUTER=0, or commented, will not forward packets.
# ISROUTER=0
# To set a default interface, normally we have to check its validity
# first by sending a router sollicitation \ (cf: sysctl entry :
# rs_device) But the default interface can be set directly by writing
# into sysctl entry defint please make sure the chosen default
# interface is up and connected to the network ! # DEFINT=eth0
# MCONF: Mobility configuration (mandatory pour activer la mobilité)
# MCONF = 1 pour configurer le n?ud en « Home Agent »
# MCONF = 0 pour configurer le n?ud en « mobile node »
# A noter que si MCONF n'est pas défini, la mobilité sera désactivée
MCONF=0
[...]
# HOMEAGENT address
# Should be commented in case LIVSIX is acting as a HA.
#
# HOMEAGENT=2002:c3d4:6ffd:1201:2D0:59FF:FEAB:E83D
[...]

Une fois cette configuration faite, il est nécessaire de vérifier par ifconfig, qu'aucune autre souche IPv6 n'est déjà lancée avant de démarrer LIVSIX (aucune adresse IPv6 n'est déjà associée à l'interface) :

[root@MN userspace]# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:09:B7:4A:A5:4C UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:465 errors:12532 dropped:0 overruns:0 frame:12532 TX packets:27 errors:9 dropped:0 overruns:0 carrier:9 collisions:0 txqueuelen:1000 RX bytes:32172 (31.4 Kb) TX bytes:4518 (4.4 Kb) Interrupt:3 Base address:0x100

Le lancement de la souche se fait en exécutant depuis le répertoire d'installation le fichier livsix.sh:

[root@MN userspace]# ./livsix.sh start
Starting LIVSIX: [ OK ]
eth1:
FE80::209:B7FF:FE4A:A54C
eth0:
FE80::2D0:59FF:FECC:A14A
lo:
::0.0.0.1

À la fin du lancement de la souche, la commande livconfig est appelé pour afficher certains paramètres de la souche. livconfig permet également de contrôler les différents paramètres d'IPv6, comme la HoA, ou même les délais TCPv6. La commande standard ifconfig peut elle être utilisée pour observer l'apparition des adresses IPv6 sur l'interface :

[root@MN userspace]# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:09:B7:4A:A5:4C
inet6 addr: 2002:c3d4:6ffd:1301:209:b7ff:fe4a:a54c/64 Scope:Global
inet6 addr: fe80::209:b7ff:fe4a:a54c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:758 errors:18926 dropped:0 overruns:0 frame:18926
TX packets:39 errors:9 dropped:0 overruns:0 carrier:9
collisions:0
RX bytes:51972 (50.7 Kb) TX bytes:5358 (5.2 Kb)

Dans ce cas particulier, la souche a auto-configuré une adresse IPv6 locale (fe80::209:b7ff:fe4a:a54c) basée sur l'adresse MAC de l'interface ainsi qu'une adresse globale (2002:c3d4:6ffd:1301:209:b7ff:fe4a:a54c) basée sur la même adresse MAC et sur le préfix 2002:c3d4:6ffd::/64 reçu du RA du R1. En plus, la souche a auto-configuré une route par défaut qui peut être visualisé avec la commande livconfig :

[root@MN userspace]# ./livconfig -r
./livconfig: Default Router List:
FE80::230:85FF:FED7:F4B2 00:30:85:d7:f4:b2 (eth1)

Une fois la souche IPv6 configurée, il est déjà possible d'exécuter les applications qui supportent IPv6, par exemple ping, utilisée ici pour tester la connectivité entre MN et CN :

[root@MN userspace]# ping6 2002:c3d4:6ffd:1:206:5bff:fedd:b517
PING 2002:c3d4:6ffd:1:206:5bff:fedd:b517(2002:c3d4:6ffd:1:206:5bff:fedd:b517) 56 data bytes
64 bytes from 2002:c3d4:6ffd:1:206:5bff:fedd:b517: icmp_seq=1 time=10.1 ms
64 bytes from 2002:c3d4:6ffd:1:206:5bff:fedd:b517: icmp_seq=2 time=5.05 ms
64 bytes from 2002:c3d4:6ffd:1:206:5bff:fedd:b517: icmp_seq=3 time=5.08 ms
--- 2002:c3d4:6ffd:1:206:5bff:fedd:b517 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2018ms
rtt min/avg/max/mdev = 5.055/6.761/10.143/2.392 ms

Cet échange de requêtes/réponses continue aussi longtemps que la connexion sans fil du MN à AP1 est maintenue. Si la connexion au AP1 est interrompue en attachant MN au AP2 (cf. See Noeud mobile déplacé), l'échange est arrêté (on n'utilise pas Mobile IPv6 pour l'instant). Cette interruption est due au changement d'adresse IPv6 du MN.

[root@MN userspace]# ping6 2002:c3d4:6ffd:1:206:5bff:fedd:b517
PING 2002:c3d4:6ffd:1:206:5bff:fedd:b517(2002:c3d4:6ffd:1:206:5bff:fedd:b517) 56 data bytes
64 bytes from 2002:c3d4:6ffd:1:206:5bff:fedd:b517: icmp_seq=1 time=9.61 ms
64 bytes from 2002:c3d4:6ffd:1:206:5bff:fedd:b517: icmp_seq=2 time=5.20 ms
64 bytes from 2002:c3d4:6ffd:1:206:5bff:fedd:b517: icmp_seq=3 time=10.3 ms
[changement d'attachement du AP1 vers AP2]
[block]
^C
--- 2002:c3d4:6ffd:1:206:5bff:fedd:b517 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3029ms
rtt min/avg/max/mdev = 5.201/8.388/10.355/2.276 ms

On remarquera que l'interface a acquis une nouvelle adresse valable sous AP2 et qu'une nouvelle route par défaut a été configurée :

[root@MN userspace]# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:09:B7:4A:A5:4C
inet6 addr: 2002:c3d4:6ffd:1302:209:b7ff:fe4a:a54c/64 Scope:Global
inet6 addr: 2002:c3d4:6ffd:1301:209:b7ff:fe4a:a54c/64 Scope:Global
inet6 addr: fe80::209:b7ff:fe4a:a54c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2324 errors:50553 dropped:0 overruns:0 frame:50553
TX packets:327 errors:9 dropped:0 overruns:0 carrier:9
collisions:1
RX bytes:167860 (163.9 Kb) TX bytes:32542 (31.7 Kb)
[root@MN userspace]# more /proc/net/livsix_drlist
FE80::230:85FF:FED7:F4B3 00:30:85:d7:f4:b3 (eth1)
FE80::230:85FF:FED7:F4B2 00:30:85:d7:f4:b2 (eth1)

Le MN a envoyé 4 paquets Echo Request au CN et en a reçu seulement 3. La réponse perdue a été en fait envoyé au AP1 et, comme MN ne se trouve plus sur son réseau mère (sous AP1) mais dans un réseau visité (sous AP2), toutes les autres réponses du CN sont perdues.

Mouvement

Pour pouvoir gérer dynamiquement ce changement d'adresse du MN et rediriger les réponses arrivées a AP1 vers AP2, il est nécessaire de configurer le HA sur le réseau mère et spécifier au MN l'adresse du HA. Le fichier livsix.sh du HA contiendra au moins le paramètre MCONF=1 et dans le fichier livsix.sh du MN le paramètre

HOMEAGENT=2002:c3d4:6ffd:1301:2d0:59ff:febf:a39

est spécifié.

# MCONF: Mobility configuration (mandatory)
# HA = 1
# MN = 0
MCONF=1

Ensuite le script livsix.sh du HA est lancé :

[root@HA userspace]# ./livsix.sh start
Starting LIVSIX: [ OK ]
Initial Refresh Interval set to 8
LIVSIX box configured as Home Agent
eth0:
FE80::2D0:59FF:FEBF:A39
lo:
::0.0.0.1

Dans le fichier livsix.sh du MN le paramètre HOMEAGENT = 2002:c3d4:6ffd: 1301:2d0:59ff:febf:a39 est spécifié, livsix.sh est relancé sur le MN positionné cette fois à la maison. Après avoir acquis une adresse valable dans le réseau mère (qui devient en effet la HoA), la commande ping vers le CN est redémarrée. Ensuite le MN est déplacé du AP1 vers AP2. On remarquera qu'après un court délai (entre 50ms et plusieurs secondes, dépendant de la fréquence de RA's), les réponses du CN vont commencer à arriver à AP2 et par conséquent au MN.

Ces réponses sont initialement interceptées par HA grâce à son cache d'adresses et ensuite encapsulées vers AP2 et la CoA du MN. Pour remplir son "Binding Cache", le HA utilise la mise à jour d'association envoyée par MN une fois sa nouvelle CoA configurée. À la réception du BU, HA répond avec l'acquittement BAck (Binding Acknowledgement ). Un exemple de capture de paquets BU et BAck réalisée avec le logiciel Ethereal sur HA est montré :

Internet Protocol Version 6
Version: 6
Traffic class: 0x00
Flowlabel: 0x00000
Payload length: 40
Next header: IPv6 destination option (0x3c)
Hop limit: 254
Source address: 2002:c3d4:6ffd:1302:209:b7ff:fe4a:a54c
Destination address: 2002:c3d4:6ffd:1301:2d0:59ff:febf:a39
Destination Option Header
Next header: Mobile IPv6 (0x87)
Length: 2 (24 bytes)
PadN: 4 bytes
Option Type: 201 (0xc9) - Home Address Option
Option Length : 16
Home Address : 2002:c3d4:6ffd:1301:209:b7ff:fe4a:a54c (
Mobile IPv6
Payload protocol: IPv6 no next header (0x3b)
Header length: 1 (16 bytes)
Mobility Header Type: Binding Update (5)
Reserved: 0x00
Checksum: 0x3d51
Binding Update
Sequence number: 0
1... .... = Acknowledge (A) flag: Binding Acknowledgement requested
.1.. .... = Home Registration (H) flag: Home Registration
..1. .... = Link-Local Compatibility (L) flag: Link-Local Address Compatibility
...1 .... = Key Management Compatibility (K) flag: Key Mngnt Mobility Compatib.
Lifetime: 65535 (262140 seconds)
Mobility Options
PadN: 4 bytes
Internet Protocol Version 6
Version: 6
Traffic class: 0x00
Flowlabel: 0x00000
Payload length: 40
Next header: IPv6 routing (0x2b)
Hop limit: 255
Source address: 2002:c3d4:6ffd:1301:2d0:59ff:febf:a39
Destination address: 2002:c3d4:6ffd:1302:209:b7ff:fe4a:a54c
Routing Header, Type 2
Next header: Mobile IPv6 (0x87)
Length: 2 (24 bytes)
Type: 2
Segments left: 1
Home Address : 2002:c3d4:6ffd:1301:209:b7ff:fe4a:a54c
Mobile IPv6
Payload protocol: IPv6 no next header (0x3b)
Header length: 1 (16 bytes)
Mobility Header Type: Binding Acknowledgement (6)
Reserved: 0x00
Checksum: 0xebd2
Binding Acknowledgement
Status: Binding Update accepted (0)
1... .... = Key Management Compatibility (K) flag: Key Mngt Mobility Compatib.
Sequence number: 0
Lifetime: 16383 (65532 seconds)
Mobility Options
PadN: 4 bytes 

Suite à cet échange, la BC du HA peut être consultée ainsi que la " BU list " du MN :

[root@HA userspace]# ./livconfig -b
./livconfig: Binding Cache:
HOME ADDRESS CARE-OF ADDRESS lt
2002:C3D4:6FFD:1301:209:B7FF:FE4A:A54C 2002:C3D4:6FFD:1302:209:B7FF:FE4A:A54C 65529
[root@MN userspace]# cat /proc/net/livsix_bulist
Hoa\Coa\HA\lifetime
2002:C3D4:6FFD:1301:209:B7FF:FE4A:A54C 2002:C3D4:6FFD:1302:209:B7FF:FE4A:A54C   2002:C3D4:6FFD:1301:2D0:59FF:FEBF:A39 65535

Conclusions

Cet exemple démontre l'utilisation de la souche LIVSIX et les bénéfices du protocole Mobile IPv6. Avec Mobile IPv6, une application continuera a fonctionner sans interruption quand un terminal mobile change sont point d'attachement. Plusieurs autres fonctionnalités peuvent être expérimentées avec cette souche. Par exemple, il est possible de commencer les mouvements à partir d'un réseau visité (et non pas du réseau mère) en spécifiant la variable HOMEADDRESS sur MN ; une manière encore plus simple serait de ne spécifier sur MN que le préfix du réseau mère (et pas l'adresse entière du HA) ensuite utiliser DHAAD et MPD47 pour la configuration des autres paramètres de mobilités.