Il ne s'agit donc pas de normaliser le Nième protocole de transition et/ou de coexistence entre IPv6 et IPv4, plutôt de faire le point sur les protocoles existants, dont le nombre a de quoi effrayer. Mais il ne faut pas paniquer : selon le cas dans lequel on se situe, toutes ces techniques ne sont pas forcément pertinentes et il n'est donc pas nécessaire de les maîtriser toutes.
D'abord, notre
Déjà, il faut comprendre ce que ces termes barbares veulent dire :
la section 2 rappelle la terminologie, et les
La section 3 décrit ensuite les principes suivis dans le RFC : le premier est de garder en tête le but, qui est de pouvoir continuer la croissance de l'Internet sans être gêné par des problèmes comme le manque d'adresses. Pour cela, le but final de la transition doit être le déploiement complet d'IPv6 natif dans tout l'Internet. Lorsque cela sera réalisé, toutes les techniques de transition et de coexistence pourront être abandonnées, simplifiant ainsi beaucoup la situation. Mais pour atteindre ce but lointain, il n'y a pas qu'une seule bonne méthode. Par contre, ces méthodes ont quelques points en commun. Il est par exemple essentiel de s'y prendre à l'avance : les adresses IPv4 sont déjà épuisées et une organisation qui n'aurait encore rien fait du tout, question IPv6, va avoir des problèmes. Donc, aujourd'hui, En tout cas, il n'existe pas de raison valable de retarder le déploiement d'IPv6. Ceux qui n'ont pas encore commencé devraient s'y mettre immédiatement.
Mais cela implique une longue période de coexistence avec IPv4. Pas pour tout le monde : il existe des réseaux un peu particuliers, des déploiements récents, contrôlés par une seule organisation, dans un environnement fermé (une usine, par exemple) et qui n'ont pas besoin d'échanger avec le reste du monde. Ceux-ci peuvent faire de l'IPv6 pur et ne pas lire ce RFC. Mais tous les autres doivent se poser la question « Qu'est-ce que je fais avec mes deux protocoles ? ».
Et cela va durer longtemps. Même si on peut espérer qu'un jour on éteigne la dernière machine IPv4, cela ne se produira pas avant de nombreuses années. Même si un réseau est entièrement IPv6, il faudra bien qu'il puisse communiquer avec des machines v4 à l'extérieur. (Le RFC ne mentionne pas le fait qu'actuellement, l'effort de la coexistence repose entièrement sur ceux qui veulent déployer IPv6. Une date importante sera celle où l'effort changera de camp et où ce sera ceux qui veulent continuer à utiliser IPv4 qui devront travailler pour cela. Cette date surviendra longtemps avant la disparition de la dernière machine IPv4.)
Ceux qui déploient IPv6 doivent donc choisir un modèle de
déploiement. Le
Voilà, après ces préliminaires, place aux techniques elle-mêmes, en section 4. Le début de cette section précise qu'elle n'est pas exhaustive : il existe d'autres mécanismes de coexistence/transition mais ils sont considérés comme relativement marginaux. Les techniques sont exposées dans l'ordre d'importance décroissante et les premières sont donc les plus recommandées.
Premier mécanisme de coexistence, et le plus recommandé, la
Cela n'empêche pas ce modèle d'avoir des failles. D'abord, si
l'adoption de ce modèle est une décision individuelle de chaque
réseau, son utilisation nécessite que les deux réseaux qui
communiquent aient adopté ce système. Si un client double-pile veut se
connecter à un serveur en IPv6, celui-ci doit avoir une connectivité
IPv6 (ce qui dépend de son FAI), doit avoir une application IPv6isée
et doit avoir annoncé un
Une deuxième limite de l'approche double-pile est que certaines
applications ne réagissent pas proprement lorsqu'un des protocoles
fonctionne mais pas l'autre. De nos jours, c'est en général l'IPv6 qui
a un problème et la double-pile peut alors entraîner une dégradation
du service, l'application perdant bêtement du temps à tenter de
joindre le pair en IPv6 au lieu de basculer tout de suite vers
IPv4. Le code naïf de connexion d'un client vers un serveur est en
effet (en
for Address in Addresses loop
try
connect_to(Address)
exit loop
except Timeout
# Try the next one
end try
end loop
Cette approche purement séquentielle peut être pénible si les adresses
IPv6 sont en tête de la liste
Rendre les
applications plus robustes vis-à-vis de ce problème pourrait aider
(voir par exemple la technique proposée par l'ISC
ou bien le très bon guide de programmation
IPv6 d'Étienne Duble), surtout si ces mécanisme de connexion intelligents
(tenter en parallèle les connexions v4 et v6) sont emballés dans des
Ces défauts sont à garder en tête mais il n'en demeure pas moins
que la double-pile reste la meilleure méthode, d'autant plus que de
nombreux réseaux ont aujourd'hui IPv6 (le RFC cite les
Une conséquence amusante de la double-pile est qu'elle nécessite
une adresse IPv4 par machine. Cela ne semblait pas un problème au
moment où ce mécanisme a été conçu, puisqu'il semblait possible de
passer tout le monde en IPv6 avant l'épuisement des adresses v4. Comme
cela ne s'est pas fait, on se retrouve aujourd'hui dans une situation
où il n'y a plus d'adresses IPv4. La double pile est donc en général
utilisée avec une adresse IPv6 publique et une IPv4 privée,
La double pile, c'est très bien mais que faire si on n'a pas de
connectivité IPv6, et qu'on veut relier son réseau IPv6 au reste de
l'Internet v6 ? La
section 4.2 expose la solution des
Il existe plusieurs types de tunnels : les tunnels manuels du
Lorsque le tunnel fait partie d'une solution gérée par un
administrateur réseaux compétent, il ne pose pas de problème en
soi. Mais certaines solutions techniques (comme
Pour l'instant, IPv6 est peu déployé et ce sont les gens qui
veulent utiliser ce protocole qui doivent faire des efforts pour se
connecter. Désormais que les adresses IPv4 sont épuisées, on
commencera bientôt à voir des déploiements purement IPv6 et il faudra
alors faire des efforts pour maintenir les vieux systèmes v4. Les
sections 4.3 et 4.4 couvrent ces cas. En 4.3, la question est celle
d'un nouvel entrant dans le monde des opérateurs qui n'a pas eu
d'adresses IPv4 pour son beau réseau tout neuf et qui a donc déployé
un cœur purement v6 ce qui, après tout, simplifie sa configuration. Mais ses clients, et les partenaires
auxquels ses clients essaient de se connecter, sont restés en
v4. Comment leur donner la connectivité qu'ils désirent ? Il va
falloir cette fois tunneler IPv4 sur IPv6. Le modèle recommandé est
Autre cas, légèrement différent, est celui où le réseau local
connecté à l'Internet n'a pas d'équipement IPv4 du tout. Tout beau,
tout neuf, toutes ses machines (et les applications qu'elles portent)
sont purement IPv6. Ce n'est pas aujourd'hui très réaliste avec des
machines et des applications ordinaires mais cela pourrait arriver
avec de nouveaux déploiements dans des environnements modernes. Le problème, décrit en section 4.4, est alors de
se connecter quand même à d'éventuels partenaires restés v4. Une des
solutions est le passage par un
Puisqu'un certain nombre de
Conclusion ? La section 5, après cette longue énumération de bricolages variés recentre le débat : l'essentiel est d'activer IPv6. Une fois ce principe posé, cette section rappelle des points mentionnés au début comme le fait qu'il ne faut pas appliquer aveuglément la même technique à tous les réseaux. Ainsi, un réseau tout neuf ne fera sans doute pas les mêmes choix qu'un réseau existant depuis vingt et ayant accumulé plein de technologies historiques.
La section 6 propose une bibliographie pour ceux qui veulent
approfondir le sujet : plein de