<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>6. FAQ</title>
<link rel="stylesheet" href="style.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.66.1">
<link rel="start" href="index.html" title="Guide pratique de la mobilité IPv6 avec Linux">
<link rel="up" href="index.html" title="Guide pratique de la mobilité IPv6 avec Linux">
<link rel="prev" href="ar01s05.html" title="5. Quelques tests">
<link rel="next" href="ar01s07.html" title="7. Références">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">6. FAQ</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="ar01s05.html">Précédent</a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="ar01s07.html">Suivant</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="sect1" lang="fr">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="faq"></a>6. FAQ</h2></div></div></div>
<div class="orderedlist"><ol type="1">
<li>
<p>
<span class="emphasis"><em>
Q : pourquoi faut-il créer un fichier
<tt class="filename">/dev/mipv6_dev</tt> ?
</em></span>
</p>
<p>
R : le fichier de périphérique est essentiellement employé par
le programme mipdiag pour modifier le paramétrage du noyau au
moyen d'ioctl.
<span><b class="command">mknod</b></span> crée un fichier spécial adapté au module
mobile-ip6.
</p>
</li>
<li>
<p>
<span class="emphasis"><em>
Q : les noyaux 2.6.x sont-ils supportés ?
</em></span>
</p>
<p>
R : voici la <a href="http://www.mobile-ipv6.org/pipermail/mipl/2003-December/001871.html" target="_top">réponse
d'Henrik Petander</a> dans la liste de diffusion MIPL :
</p>
<p>
« <span class="quote">Voici une revue rapide de l'état de MIPL pour la famille
des noyaux 2.6 :</span> »
</p>
<p>
« <span class="quote">L'infrastructure noyau demandée par la mobilité IPv6 a
été mise au point en coopération avec le projet USAGI.
L'optimisation du routage, ainsi que la gestion des tunnels et
de la politique de routage sont opérationnels.</span> »
</p>
<p>
« <span class="quote">Le travail se concentre à présent sur le programme
résidant en espace utilisateur qui prend en charge la
signalisation MIPv6 et contrôle les opérations du noyau. Les
utilitaires avancent également à un rythme correct. La logique
protocolaire est toutefois absente : les utilisateurs n'ont
donc rien à tester pour l'instant. Un prototype opérationnel et
testé devrait être disponible d'ici la fin du mois de
mars.</span> »
</p>
</li>
<li>
<p>
<span class="emphasis"><em>
Q : MIPL est-il compatible avec IPSec ?
</em></span>
</p>
<p>
R : la série des noyaux 2.4.x ne gère pas IPSec. MIPL pour Linux
va gérer IPSec dès sa sortie. Il sera possible d'employer une souche
IPSec fournie par un tiers.
</p>
</li>
<li>
<p>
<span class="emphasis"><em>
Q : comment contrôler la nature du routage entre une station
mobile MN et un correspondant CN (recours au tunnel avec la
station d'attache HA ou bien communication directe après association
et acquittement) ?
</em></span>
</p>
<p>R : on utilise le paramètre suivant :</p>
<p>
<b class="userinput"><tt>
/proc/sys/conf/net/ipv6/mobility/accept_return_routability
</tt></b>
</p>
<p>
Pour désactiver le renvoi d'informations de routage et son
optimisation, on positionne le paramètre à 0 :
</p>
<p>
<b class="userinput"><tt>
# echo 0 > /proc/sys/..../accept_return_routability
</tt></b>
</p>
<p>
La station mobile MN ne communiquera alors plus avec le
correspondant CN qu'au travers du tunnel.
</p>
</li>
<li>
<p>
<span class="emphasis"><em>
Q : des réseaux sans fil distincts peuvent-ils avoir des
ESSID et des clefs WEP différentes ?
</em></span>
</p>
<p>
R : oui, mais le changement doit être effectué manuellement lors
de l'entrée dans un nouveau réseau. La souche MIPL de MIPv6 ne sait pas
procéder à la transition automatiquement.
</p>
</li>
<li>
<p>
<span class="emphasis"><em>
Q : lorsque la station mobile MN a traversé plusieurs réseaux
et qu'elle retourne dans son réseau d'attache, son interface
supporte encore les adresses IPv6 générées automatiquement
dans tous les réseaux visités. Peut-on supprimer ces adresses ?
</em></span>
</p>
<p>
R : à défaut d'une méthode de suppression automatique des dites
adresses, il est possible de les éliminer manuellement :
</p>
<p>
<b class="userinput"><tt># ifconfig eth0 inet6 del <ipv6-address></tt></b>
</p>
</li>
<li>
<p>
<span class="emphasis"><em>
Q : la station B comprend deux interfaces sur des réseaux
distincts. B ne répond pas aux sollicitations ICMP émises
depuis la station A alors qu'A sait où trouver les réseaux
de B. Pourquoi ?
</em></span>
</p>
<p>
R : la station B ignore comment joindre la station A. Il faut
donc ajouter une route :
</p>
<p>
<b class="userinput"><tt>
# ip route add fec0:106:2700::/64 via fec0:106:2300::1
</tt></b>
</p>
<p>ou</p>
<p>
<b class="userinput"><tt>
# route -A inet6 add fec0:106:2700::/64 gw fec0:106:2300::1 dev eth0
</tt></b>
</p>
</li>
<li>
<p>
<span class="emphasis"><em>
Q : comment mettre en place une passerelle par défaut pour
IPv6 ?
</em></span>
</p>
<p>
R : on emploie la commande « <span class="quote">route</span> » habituelle :
</p>
<p>
<b class="userinput"><tt># route -A inet6 add default gw <ipv6-host></tt></b>
</p>
<p>
ou sa variante moderne « <span class="quote">ip</span> » :
</p>
<p>
<b class="userinput"><tt># ip route ::/0 via <ipv6-host></tt></b>
</p>
</li>
<li>
<p>
<span class="emphasis"><em>
Q : pourquoi les stations sollicitent-elles les routeurs au
moyen d'une émission en multidiffusion au lieu d'une émission
avec un adressage anycast ?
</em></span>
</p>
<p>
R : la station attend une réponse de chaque routeur et non d'un
seul. Elle obtient ainsi tous les paramètres et peut choisir
le « <span class="quote">meilleur</span> » routeur par défaut.
</p>
</li>
<li>
<p>
<span class="emphasis"><em>
Q : pourquoi la station mobile ne remarque-t-elle pas qu'elle
s'est déplacée ?
</em></span>
</p>
<p>
R : la station s'imagine que son dernier routeur est toujours
joignable. Ceci peut être dû à des durées de vie très élevées
au niveau des annonces de routeur. Il faut vérifier la
configuration du programme responsable de l'envoi des annonces
depuis le routeur. Si le programme gère les intervalles d'annonces
de routage, ces derniers peuvent aider la station mobile MN à
détecter les déplacements. Se reporter à la page de manuel de
<span><b class="command">radvd.conf</b></span> pour les détails.
</p>
</li>
</ol></div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="ar01s05.html">Précédent</a> </td>
<td width="20%" align="center"><a accesskey="u" href="index.html">Niveau supérieur</a></td>
<td width="40%" align="right"> <a accesskey="n" href="ar01s07.html">Suivant</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">5. Quelques tests </td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Sommaire</a></td>
<td width="40%" align="right" valign="top"> 7. Références</td>
</tr>
</table>
</div>
</body>
</html>
