Revision as of 19:12, 19 January 2022

> MOOC>Contenu>Doc compagnon > Activité 40

Activité 40 : Déployer IPv6 maintenant

Introduction

Généralement, l'identification d'une killer application est recherchée pour justifier un passage rapide vers IPv6. Ce fut le cas avec IPv4 quand le Web est apparu. Les sites sont massivement passés de protocoles propriétaires (IPX, NetBEUI) vers IPv4 pour accéder aux informations par un navigateur ; ce qui a conduit au concept d'intranet. On ne connaît pas actuellement d'application particulière pouvant forcer massivement le passage vers IPv6. Les fonctionnalités avec IPv4 sont les mêmes, puisqu'il ne s'agit que d'une nouvelle version du protocole IP. La qualité de service est souvent évoquée, mais il s'agit d'un leurre, car les mécanismes de réservation ou de différenciation sont pris en charge par les deux versions du protocole. Il n'y a pas une fonctionnalité qu'aurait IPv6 qui ne soit pas dans IPv4. Il peut y avoir des simplifications apportées, comme dans la configuration d'un réseau. Mais ce genre d'avantage ne justifie pas le coût de la migration d'IPv4 vers IPv6. Les raisons poussant au passage à IPv6 ne sont pas à chercher du coté de la demande mais trouvent leurs origines dans les limitations d'IPv4.

Il n'y a plus de préfixe réseau public disponible ni, a fortiori, d'adresse publique. Or, l'adresse est un élément indispensable à la connectivité au réseau Internet. Sans adresse, un nœud est invisible. Il ne peut rien recevoir ni envoyer, et rend toute communication impossible. La demande de connectivité à Internet, autrement dit d'adresses, loin de diminuer, va au contraire s'accélérer dans les prochaines années avec les nouvelles applications telles que la domotique et la route intelligente. Ces dernières impliquent une masse importante d'objets numériques connectés. Ces applications se développent en IPv6, car IPV4 n'a pas les capacités pour les supporter. Il n'est pas adapté pour interconnecter la multitude des composants numériques : son plan d'adressage à 2^32, soit environ 4,3 milliards d'adresses, est trop restreint. Il n'y aurait même pas assez d'adresses pour chaque être humain sur la planète, même si l'allocation d'adresses était parfaite.

Cette taille insuffisante du plan d'adressage n'est pas due à une erreur des concepteurs d'IPv4 mais provient du progrès technologique. Le paradigme de l'ordinateur a beaucoup évolué depuis les années 1960. Au début, il y avait un ordinateur par organisation. Puis il y a eu un ordinateur par département. Ensuite, l'arrivée de la micro-informatique a amené un ordinateur par personne. Enfin, avec la généralisation du numérique dans divers objets du quotidien, on en arrive à plusieurs ordinateurs (machines ou objets connectés) par personne. Il est de plus en plus évident qu'IPv4 est devenu inadapté pour répondre aux besoins d'interconnexion des ordinateurs. Après près de 50 ans d'existence, l'espace d'adressage IPv4 de l'Internet est devenu insuffisant et a atteint la limite de ses capacités. IPv4 est maintenant un problème dans le développement de l'Internet à cause de la complexité et du coût de connectivité grandissant qu'il introduit. Au sein de l'IETF, il y a des voix qui s'expriment pour rendre IPv4 obsolète. Cette volonté se concrétise début 2016 par la publication d'un document de travail qui prône de rendre IPv4 historique^[1]. Ce document illustre bien qu'IPv4 est limité et qu'il est temps de passer à IPv6. Car c'est bien dans les limitations d'IPv4 que la motivation au passage d'IPv6 est à trouver.

Au cours de cette activité, nous exposerons les motivations et les contraintes du déploiement d'IPv6. Ensuite nous décrirons les types de mécanismes d'intégration d'IPv6, leurs principes et leurs limites. Enfin, nous rappellerons aussi le plan de migration vers IPv6 initialement planifiée et celui qui est suivi de nos jours.

Motivations pour IPv6

C'est en partant du constat des limitations et des problèmes induits par l'utilisation d'IPv4 que les motivations en faveur de l'adoption d'IPv6 apparaissent. Le changement du paradigme de l'ordinateur a rendu IPv4 obsolète. Il faut aujourd'hui un grand espace d'adressage. Les nouveaux usages de l'Internet avec les nouveaux objets connectés demandent énormément d'adresses. Dépasser la pénurie d'adresses, c'est ouvrir la voie à de nouveaux services, c'est laisser la porte ouverte à de nouveaux acteurs innovants, c'est pouvoir créer de nouveaux marchés pour de nouveaux besoins. Le passage à IPv6 devient une nécessité car, en attribuant une adresse à chaque nœud du réseau, la connectivité en IPv6 retrouve les principes qui ont fait le succès du fonctionnement de l'Internet, et notamment celui du "bout-en-bout". Car ce principe a été perdu avec l'utilisation du NAT qui a été introduit suite au manque d'adresses. Sans le NAT, la communication vers un serveur retrouve sa simplicité originelle. En effet, il est beaucoup plus simple et direct d'accéder à un serveur lorsque celui-ci à une adresse IP publique. Il n'est pas soutenable que la croissance du réseau s'effectue avec une complexité croissante comme avec IPv4. Tout ceci est bien connu et cette évolution est qualifiée par "non passage au facteur d'échelle" (not scalable). Ainsi, avec cette simplicité retrouvée, de nouveaux champs d'application s'ouvrent à l'Internet en IPv6. Le RFC 7368 en donne une illustration avec la domotique. Enfin sans le NAT, il est aisée d'introduire un nouveau protocole de transport pour des nouveaux services de communications. Un protocole de transport est localisé au niveau des hôtes (à chaque bout de la communication). Le principe de bout en bout change tout pour les applications et pour l'extensibilité du réseau.

En plus de la simplicité retrouvée, IPv6 apporte de nouvelles fonctionnalités, comme la configuration automatique d'un réseau. Avec IPv6, le réseau peut se gérer uniquement au niveau des routeurs, les stations construisant leurs adresses automatiquement, alors qu'avec IPv4, chaque équipement doit se voir attribuer une adresse et obtenir sa configuration depuis un serveur qui reste à gérer. Pour les réseaux avec un grand parc de machines, c'est d'autant plus intéressant.

Geof Huston dans l'article^[2] ajoute un autre argument lié à la sécurité dans l'Internet des objets. Comme un balayage de l'espace d'adressage IPv4 prend 5 minutes, un objet peut être victime d'une action "pirate". En IPv6, l'espace d'adressage est si grand qu'il est impossible de balayer tout un réseau pour trouver les adresses utilisées, ce qui rend les nœuds quasiment indétectables. En effet, il faut 41 000 ans en IPv6 pour balayer exhaustivement un préfixe /64. Cette caractéristique sur la taille rend IPv6 indispensable pour l'Internet des objets car elle rend les objets indétectables par un simple sondage, tout en les laissant accessibles. En pratique, le RFC 7707 montre que cette affirmation n'est pas si vraie. Les adresses IPv6 peuvent être attribuées selon des conventions d'adressage comme "utiliser l'identifiant 1 pour le routeur". Des stratégies de balayage "malin" peuvent débusquer les nœuds dans un réseau. La connaissance à priori du constructeur des interfaces réseaux, donc de son identifiant OUI (Organisationnally Unique Identifier) réduira l'espace des identifiants d'interface (IID) de 64 à 24 bits, par exemple. Dissimuler les adresses IP des nœuds devient de la sécurité par l'obscurité : cela peut ralentir l'attaquant, mais cela ne doit certainement pas être utilisé comme unique moyen de défense car, tôt ou tard, l'attaquant trouvera ces adresses. Il n'en reste pas moins que le balayage est bien plus facile et rapide en IPv4 qu'en IPv6.

Ce sont toutes ces raisons qui donnent la véritable motivation du passage à IPv6 à savoir avoir un Internet adapté au besoin de l'informatique d'aujourd'hui.

Les contraintes du déploiement d'IPv6

Nous avons vu, dans les séquences précédentes, les détails de la technologie de communication liée à IPv6. Nous avons pu constater que le format des paquets et des adresses sont différents de ceux d'IPv4, et ces différences font que ces deux versions d'IP ne peuvent pas interopérer. L'Internet actuel fonctionne en IPv4 mais il a besoin d'IPv6 pour continuer sa croissance. Quelle que soit la version d'IP utilisée, l'objectif est de maintenir une connectivité globale. Se pose alors le problème de la coexistence des deux versions d'IP au sein d'un seul Internet. Plus exactement, le monde IPv6 doit intégrer des mécanismes afin qu'il puisse interopérer avec l'Internet version 4, c'est-à-dire la partie de l'Internet qui utilise encore IPv4. Comme il n'y aura pas de jour du grand basculement d'IPv4 à IPv6, l'introduction d'IPv6 dans l'Internet s'effectue de façon progressive et en s'étalant dans le temps. Elle doit même se faire sans que l'utilisateur puisse s'en apercevoir. La phase de transition doit être simple ou, au minimum, moins compliquée qu'une utilisation prolongée d'IPv4. Cette introduction d'IPv6 progressive et sans rupture dans l'Internet démontre qu'IPv6 est une évolution d'IPv4. La migration doit se focaliser sur les nouveaux réseaux tout en laissant les anciens fonctionner sous IPv4. L'apparition d'IPv6 ne signifie pas que IPv4 cesse d'exister. En effet, la base d'équipements et de logiciels installés est tellement importante que cela assure au protocole IPv4 une durée de vie quasi "illimitée" à l'échelle humaine. Ceci rend l'idée de la migration sans fin. En fait, c'est notamment au travers des extensions du réseau actuel qu'IPv6 viendra suppléer IPv4. Cet objectif de déployer IPv6 tout en laissant fonctionner IPv4 est rappelé dans le RFC 7381, qui décrit la démarche pour le déploiement d'IPv6 dans un réseau administré.

Cette idée d'un protocole visant à soulager IPv4 est marquée par le terme d'intégration. Le terme de transition, lorsqu'il est utilisé, porte l'idée du remplacement d'IPv4 par IPv6. Le remplacement est plus anxiogène car il annonce une migration d'un système de communication qui fonctionne pour aller vers un système plus inconnu. Le but du maintien d'IPv4 en activité est aussi d'éliminer la peur de détruire quelque chose qui fonctionne. De plus, dans le contexte actuel d'un Internet en IPv4, déployer IPv6 ne signifie pas que le réseau ne doit utiliser qu'IPv6. Au contraire, le déploiement d'IPv6 doit s'intégrer dans le réseau actuel et être vu comme une extension du réseau présent.

Principes des mécanismes d'intégration

Ainsi, IPv6 doit se déployer sans remettre en cause l'existant, qui est opérationnel. Mais que faut-il faire pour passer son réseau en IPv6 ? En fait, il n'y a pas une solution unique, mais plusieurs réponses qui dépendent de la place occupée par IPv6 dans le système de communication. Il faut distinguer la bordure (les hôtes) et l'infrastructure de communication. L'infrastructure de communication traite du transport des données. Les hôtes sont les consommateurs et producteurs de données ou, de manière classique, les clients et les serveurs. La distinction entre hôte et réseau conduit à identifier six cas^[3] :

1. un hôte IPv4 qui communique avec un hôte IPv4 via un réseau IPv4 ;
2. un hôte IPv6 qui communique avec un hôte IPv6 via un réseau IPv6 ;
3. un hôte IPv6 qui communique avec un hôte IPv6 via un réseau IPv4 ;
4. un hôte IPv4 qui communique avec un hôte IPv4 via un réseau IPv6 ;
5. un client IPv4 qui communique avec un serveur IPv6 ;
6. un client IPv6 qui communique avec un serveur IPv4.

Chaque cas pose un problème particulier qui demande un mécanisme dédié. En contrepartie, chaque mécanisme de transition introduit une charge administrative supplémentaire dans le réseau. Ces mécanismes dits d'intégration n'ont pas pour vocation à exister durablement. Ils devraient décroître dans le temps en fonction du nombre d'équipements IPv6 présents sur le réseau. Ils servent à rendre le coût du déploiement supportable en partant des composants existants. Les nouvelles applications, comme par exemple la domotique, pourraient directement démarrer en IPv6 natif et se passer des mécanismes.

Double pile

Le premier cas exprime le point de départ de la migration ; le second cas en représente le point d'arrivée. La première idée, pour passer de IPv4 à IPv6, est d'avoir des nœuds qui soient bilingues en quelque sorte, c'est-à-dire capable de parler en IPv6 ou en IPv4 en fonction des capacités de leur correspondant. Pour cela, IPv4 et IPv6 coexistent dans les mêmes nœuds et les mêmes réseaux. Ainsi, les nœuds IPv6 restent compatibles avec les nœuds IPv4. Lorsqu'une nouvelle machine est déployée, elle possède donc une adresse IPv4 et une adresse IPv6. Avec cette idée, la croissance de la taille de l'Internet de ces dernières années aurait été aussi celle d'IPv6. La figure 5 schématise le principe de la communication en double pile. Le déploiement d'IPv6 en double pile était le plan originel de migration. Après la période de spécification que furent les années 90, les années 2000 devaient servir au déploiement des solutions d'intégration. Ainsi, quand le plan d'adressage IPv4 viendrait à épuisement dans la première moitié des années 2010, IPv6 aurait été déployé. Hélas, cette idée n'a pas abouti car elle avait un coût immédiat dû à la double configuration pour un gain futur (à la fin du plan d'adressage IPv4). L'attentisme a régné au niveau du marché et des acteurs comme les fournisseurs d'accès. Ceux-ci n'ont pas montré un réel empressement à déployer une infrastructure en IPv6 pour fournir des préfixes IPv6 afin que leurs clients fonctionnent en double pile. Le déploiement de nœuds double pile a été au final très limité. Nous nous retrouvons maintenant avec deux problèmes à gérer simultanément : l'intégration d'IPv6 et l'épuisement des adresses IPv4 disponibles. Il est à noter que les mécanismes qui suivent (tunnel et traduction) reposent sur des machines à double pile. Elles sont capables de communiquer dans les deux protocoles.

Figure 5 : Double pile.

Tunnel

Les cas 3 et 4 se résolvent à l'aide de tunnels. Le paquet de la source est placé dans une enveloppe qui est en fait un paquet dans la version IP du réseau. Dans le troisième cas, une connectivité IPv6 est offerte au travers d'une infrastructure IPv4 existante comme le représente la figure 6. On parle de câbles virtuels (softwire) : un câble virtuel est un tunnel dans lequel une extrémité du tunnel encapsule les paquets IPv6 dans des paquets IPv4. Les paquets IPv4 transitent dans l'infrastructure IPv4 pour rejoindre l'extrémité du tunnel qui va désencapsuler le paquet IPv6. Le câble virtuel forme une liaison point à point entre 2 nœuds IPv6. IPv4 est alors vu comme un système de transmission, comme peut l'être Ethernet ou une liaison Wifi. Le masquage de la topologie du réseau IPv4 à IPv6 peut conduire à faire un routage des paquets IPv6 susceptible d'être "sous-optimal". Par conséquent, la solution des tunnels doit se faire en essayant de suivre la topologie du réseau et ces tunnels doivent être les plus courts possibles en terme de routeurs IPv4 traversés. Comme les systèmes d'extrémités sont compatibles, la solution à base de tunnels introduit certes une complexité, mais ce n'est pas la plus forte.

Figure 6 : Tunnel.

Traduction

Les deux derniers cas traitent la situation où les extrémités sont incompatibles. Pour certaines catégories d'applications, comme le mail ou le web, le succès d'IPv6 est fortement lié à l'interopérabilité avec IPv4 puisque, jusqu'à présent, la majorité des informations et des utilisateurs ne sont accessibles qu'avec cette version du protocole. Pour des applications distribuées, la technique de traduction (translation) consiste à rendre possible la communication entre un système IPv6 et un système IPv4, comme indiqué par la figure 7. C'est l'idée du NAT d'IPv4 appliquée à IPv6. Dans le cas du NAT IPv4, le format du paquet reste le même, mais avec IPv6, le format du paquet change en même temps que les adresses. Ainsi, un coté du NAT est en IPv4 et l'autre coté repose sur IPv6.

Cette traduction peut se faire à différents niveaux de l'architecture réseau :

• au niveau applicatif, par des passerelles ou ALG (Application Level Gateway). Le proxy est un exemple d'ALG qui comporte, en plus des fonctions de traduction, un cache. Le principe d'une traduction par une ALG consiste à ce que le client envoie sa requête en IPv6 à la passerelle applicative. Celle-ci la renvoie vers le serveur en IPv4. Dans l'exemple du DNS, ceci se conçoit très facilement. Le resolver du client envoie la requête au serveur local en IPv6. Ce dernier envoie la requête au serveur suivant en IPv4. De même, certains protocoles applicatifs, tel le protocole de transfert de courrier SMTP, fonctionnent nativement en mode relais. Le message passe de relais en relais pour atteindre le serveur de courrier de destination. Le relayage s'effectuant au niveau applicatif, chaque saut peut indifféremment s'effectuer en v6 ou en v4. Pour ces applications largement diffusées, comme le web, la messagerie, le DNS, ou encore les serveurs d'impression, la traduction est donc relativement simple à faire. On peut également souligner que le web et la messagerie constituent une part significative des flux Internet actuels. Cette méthode de migration devrait permettre de traiter la majorité des flux. Mais sa mise en œuvre est spécifique car l'ALG est très liée à l'application et la multiplication des applications empêche d'avoir une proposition universelle ;
• au niveau réseau, par des NAT qui agissent au niveau de l'en-tête IP. Le paquet IPv4 est construit à partir d'informations déjà contenues dans l'en-tête IPv6, en particulier différents formats d'adressage permettent de véhiculer une adresse IPv4 dans une adresse IPv6 (le RFC 6052 formalise les différentes variantes d'embarquement d'une adresse IPv4 dans une adresse IPv6). La difficulté d'assurer la compatibilité entre les deux mondes n'est, cependant, pas symétrique. Il est beaucoup plus facile d'initier une session partant du monde IPv6 pour aller vers le monde IPv4. Autrement dit, il est plus facile d'avoir le client du coté IPv6 et le serveur du coté IPv4. En effet, un client IPv6 peut gérer une adresse IPv4 (une adresse sur 128 bits peut contenir une adresse sur 32 bits). Dans le sens inverse, c'est plus complexe : le client IPv4 se retrouve à gérer une adresse en 128 bits et, de plus, il est impossible de modifier l'existant en IPv4 ;
• au niveau transport, au moyen de relais SOCKS [RFC 1928] ou de relais TRT (Transport Relay Translator) [RFC 3142]. Les relais transport peuvent être perçus comme des "proxys génériques" pour relayer de manière contrôlée les protocoles TCP ou UDP. L'équipement relais accepte les flux ou connexions entrantes issus du client, auprès de qui il se fait donc passer pour le serveur, et les relaie vers le serveur authentique en se faisant passer pour le client. Ce type de solution n'est pas totalement satisfaisante d'un point de vue sécurité car le relais a un comportement de type «Man in the Middle» qui intercepte et éventuellement manipule les flux, y compris les flux sécurisés tels que TLS ou SSH. Ce relais peut en effet négocier une clé intermédiaire lors de l'initialisation de la session sécurisée comme SSH (Secure Shell) et déchiffrer le flux SSH reçu avant de le réémettre chiffré avec sa propre clé sur la connexion de sortie. Le relayeur aurait alors tout loisir d'observer le flux en clair. C'est une des limitations importantes des passerelles de niveau transport. Quel niveau de confiance peut-on accorder à la passerelle transport ? On notera également que, compte tenu de son niveau (transport), le relais bloque les flux de contrôle de niveau réseau (ICMP, ICMPv6). Pour ces raisons, l'usage de relais transport est donc aujourd'hui déconsidéré en faveur des deux autres mécanismes précédents.

Figure 7 : Traduction IPv6-IPv4.

Quel scénario pour le déploiement ?

Maintenant que nous avons posé les contraintes du déploiement d'IPv6 et énuméré les mécanismes d'intégration, la question est : quel est le plan envisagé du déploiement d'IPv6 dans l'Internet actuel ?

Le plan originel de migration de l'Internet reposait sur le mécanisme dit de la double pile, comme le rappelle G. Huston^[4] par la figure 2.

Figure 2 : Plan de migration vers IPv6.

Cependant, le problème de la pénurie d'adresses IPv4 n'est pas résolu avec ce mécanisme, puisque l'interface réseau d'un équipement en double pile possède une adresse de chaque version IP. La croissance de l'Internet continue de consommer des adresses IPv4. Mais cela offre la possibilité de déployer des nœuds IPv6 afin de vérifier, dans un premier temps, la compatibilité de son réseau avec ce nouveau protocole. Les problèmes inhérents à l'utilisation d'IPv6 peuvent donc être identifiés très tôt. Ensuite, dans un second temps, cela augmente la base des nœuds IPv6 installés. Au fur à mesure du déploiement de ces nœuds, les communications pourront se faire de plus en plus souvent en IPv6. En effet, le client en double pile utilisera en priorité IPv6 pour joindre un serveur lui-même en double pile. Le protocole IPv4 reste cantonné au cas où la tentative échoue en IPv6, ou si le serveur est resté sur l'ancienne version d'IP. Enfin, dans un dernier temps, quand la majorité des services sera accessible en IPv6, la croissance de l’Internet pourra se poursuivre en IPv6 uniquement. Il deviendra envisageable de se passer d'IPv4 et de ses NAT (Network Address Translation). Un cercle vertueux est enclenché. L'effort d'interopérabilité aura changé de camp, rendant IPv4 encore plus complexe à utiliser, et par conséquent, accélérant encore le passage à IPv6.

Malgré la disponibilité des équipements supportant la double pile, les acteurs de l'Internet tels que les FAI (Fournisseurs d'accès à Internet), les hébergeurs et les administrateurs de sites n’ont pas perçu l’urgence d’intégrer IPv6 dans leurs activités. Les doubles piles déployées sur les nœuds de l’Internet restent largement inutilisées par rapport au plan initial, comme le montre la figure 3. La croissance de l’Internet s’est poursuivie en IPv4, et celle-ci a donc été affectée par plusieurs effets néfastes comme nous l'avons vu précédemment dans ce cours. L'échec du plan initial est largement dû à la dérégulation appliquée dans le secteur des télécommunications qui a conduit les acteurs à privilégier le court terme, et les rend incapables de prendre en compte les besoins à plus long terme dans leurs activités^[4]. Dans l'incapacité de réaliser un déploiement coordonné d'IPv6 qui profiterait à tous, chaque acteur a des actions individuelles qui sont raisonnables pour lui, mais coûtent cher à tous. Comme le note S. Bortzmeyer :"déployer IPv6 coûte à celui qui le déploie, ne pas le déployer coûte équitablement à tout le monde"^[5].

Figure 3 : État du plan de migration initial.

Avec l'intégration d'IPv6 dans les principaux systèmes d'exploitation^[6] et malgré l'attentisme d'une grande majorité des acteurs de l'Internet, de plus en plus d'infrastructures de communication et d’hébergeurs proposent leurs services en IPv6. Certains FAI donnent maintenant une connectivité IPv6 à leurs clients et ceux qui n’ont pas cette chance peuvent se rabattre sur un accès IPv6 via des tunnels. Ces derniers sont souvent gratuits^[7]. Les performances en IPv6 ont été fortement améliorées avec la multiplication des points de présence des FAI en IPv6. Un point de présence est un lieu géographique du FAI contenant un nœud de son réseau fédérateur ; autrement dit, un point de connectivité pour le réseau de distribution de ses utilisateurs. De nos jours, comme un grand nombre d’applications (mail, supervision, firewall...) intègre désormais IPv6, il est beaucoup plus aisé de déployer IPv6 dans son réseau qu'il y a une dizaine d'années. Mais il faut faire ce passage le plus tôt possible de manière à traiter progressivement et sereinement les inévitables bugs logiciels et erreurs de configuration qui surviendront.

Conclusion

L'adoption d'IPv6 dépend des besoins de chacun mais aussi de la hausse du coût généré par la pénurie d'adresses IPv4. Quand ce coût dépasse une valeur admise propre à chaque acteur, la décision du passage à IPv6 s'impose. IPv6 peut s'utiliser dans le réseau de son site, que son réseau de communication soit à construire ou qu'il existe déjà, que la connectivité de son opérateur soit ou non en IPv6. Notons qu'il est envisageable de déployer un intranet en IPv6 tout en laissant les communications avec l'Internet en IPv4. Quoi qu'il en soit, tant qu'il y aura de l'Internet version 4, il faut maintenir cette connectivité depuis le monde IPv6. Donc, en plus du déploiement d'IPv6, il faut installer des éléments pour réaliser cette connectivité.

Pour chaque situation, l'IETF a développé des mécanismes de coexistence^[8]. Chaque mécanisme répond à une problématique précise du déploiement d'IPv6 dans un monde IPv4. La migration vers IPv6 ne soulève pas tous les problèmes possibles. Par conséquent, il faut choisir les mécanismes qui s'appliquent à sa situation. Le fait qu'il y ait un choix à faire dans la multitude des mécanismes est même devenu un argument pour ne pas passer à IPv6. Cette multitude renvoie une image de complexité. Il faut comprendre que chaque technique répond à un problème bien précis, et qu'il n'est pas nécessaire de maîtriser toutes les techniques. C'est à partir de l'étude de ses propres besoins qu'il faut identifier lesquelles des techniques sont à appliquer. La démarche consiste, à partir de l'inventaire du réseau IPv4, à se demander ce qui n'est pas compatible IPv6. Dans la situation d'un nouveau réseau IPv6, ce sont les services accessibles uniquement en IPv4 qui vont guider le choix. La question à élucider quelle que soit la situation est la suivante : quels sont les problèmes qui vont apparaître en utilisant IPv6 ? C'est à partir de ce constat que les techniques de transition vont être retenues. Alors, ce sont ces techniques-là qu'il convient d'apprendre et de maîtriser. Par exemple, après une étude de son réseau de communication, l'utilisation d'IPv6 montre un problème sur la connectivité avec l'Internet version 6 car son fournisseur d'accès Internet est resté en IPv4. Un tunnel statique peut être la solution.

Il convient de garder à l'esprit que la finalité n'est pas d'installer des mécanismes d'intégration. Ces mécanismes sont vus comme temporaires, mais sur une période temporaire qui peut durer. L'objectif final est d'avoir l'Internet en IPv6 partout comme le rappelle le RFC 6180. Le but des mécanismes de coexistence est de faciliter le déploiement progressif et indépendant du protocole IPv6 dans tous les segments du réseau constituant l'Internet. Lorsque cela sera fait, ces mécanismes deviendront obsolètes et leur disparition rendra l'usage d'IPv6 beaucoup plus simple, à l'image d'IPv4 avant l'apparition de son problème de pénurie d'adresses.

La démarche du déploiement d'IPv6 dans un réseau administré d'une organisation est décrite dans le RFC 7381. Ce document suggère 3 phases :

1. Une phase de préparation et d'analyse au cours de laquelle l'inventaire de l'existant est effectué afin de déterminer quels sont les matériels et les logiciels fonctionnant en IPv6. Le choix de la phase suivante est aussi décidé en fonction des priorités de l'organisation.
2. Une phase interne consistant à déployer IPv6 pour les communications internes.
3. Une phase externe dans laquelle il s'agit de traiter la connectivité de son Intranet avec l'Internet.

Les auteurs^[9] montrent aussi que selon l'usage du réseau (mobile, fixe, ou de voix sur IP), la stratégie de migration n'est pas la même et doit prendre en compte leurs spécificités. Plusieurs mécanismes de la migration vers IPv6 sont présentés dans la suite de ce chapitre : le déploiement d'IPv6 dans le réseau local en premier lieu, le maintien de la connectivité entre les îlots IPv6 ensuite et, pour finir, l'interopérabilité avec les services en IPv4.

Références bibliographiques

1. ↑ Pépin G. (2016) Article en ligne sur Next Inpact. Un brouillon de RFC propose de déclarer l'IPv4 obsolète.
2. ↑ Huston, G. (2015) The ISP Column. The Internet of Stupid Things
3. ↑ Soussi, M. (2011). AFNIC’s Issue Papers. IPv6, A Passport For The Future Internet
4. ↑ ^{4.0 4.1} Huston, G. (2008). The ISP Column. The Changing Foundation of the Internet: Confronting IPv4 Address Exhaustion
5. ↑ Bortzmeyer, S. IPv6 ou l'échec du marché
6. ↑ Wikipedia. Comparison of IPv6 support in operating systems
7. ↑ Linux Review. Free IPv4 to IPv6 Tunnel Brokers
8. ↑ RIPE NCC. (2015). Article en ligne. Transition Mechanisms
9. ↑ Boucadair, M.; Binet, D. et Jacquenet, C. (2011). Techniques de l'ingénieur. Transition IPv6 - Outils et stratégies de migration

Pour aller plus loin

Pénurie d'adresses IPv4

• Bortzmeyer, S (2014), article de blog: Épuisement des adresses IPv4
• Huston, G. (2014) The Internet in Transition: The state of the transition to IPv6 in Today's Internet and of measures to support the continued use of IPv4 .
• Huston, G (2015). Addressing 2014 - And then there were 2!
• Van Beijnum, I. (2014). With the Americas running out of IPv4, it’s official: The Internet is full

Statistiques sur IPv6

• APNIC IPv6 Deployment Report
• APNIC Lab List of statistics
• APNIC IPv6 deployment support site. (Useful and up to date information on IPv6')
• RIPE IPv6 statistics
• RIPE Lab List of statistics
• Internet Society Liste de pointeurs
• IPv6 Users by Country
• IPv6 CIDR report
• IPv6 host count by IPv6 matrix

Techniques de transition

• Wikipedia IPv6 transition mechanism

RFC et leur analyse par S. Bortzmeyer :

• RFC 1918 Address Allocation for Private Internets Analyse
• RFC 1928 SOCKS Protocol Version 5
• RFC 2663 IP Network Address Translator (NAT) Terminology and Considerations Analyse
• RFC 2993 Architectural Implications of NAT Analyse
• RFC 3142 An IPv6-to-IPv4 Transport Relay Translator
• RFC 4864 Local Network Protection for IPv6
• RFC 5128 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) Analyse
• RFC 5157 IPv6 Implications for Network Scanning Analyse
• RFC 5684 Unintended Consequence of NAT deployments with Overlapping Address Space Analyse
• RFC 6052: IPv6 Addressing of IPv4/IPv6 Translators Analyse
• RFC 6180 Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment Analyse
• RFC 6269 Issues with IP Address Sharing Analyse
• RFC 6319: Issues Associated with Designating Additional Private IPv4 Address Space Analyse
• RFC 6586 Experiences from an IPv6-Only Network Analyse
• RFC 6888: Common requirements for Carrier Grade NATs (CGNs) Analyse
• RFC 7021 Assessing the Impact of Carrier-Grade NAT on Network Applications Analyse
• RFC 7368 IPv6 Home Networking Architecture Principles Analyse
• RFC 7381 Enterprise IPv6 Deployment Guidelines Analyse
• RFC 7663 IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) Report Analyse
• RFC 7707: Network Reconnaissance in IPv6 Networks Analyse