|
|
| Line 1: |
Line 1: |
| − | L'étape de standardisation des protocoles de base de IPv6 (''core specs'') est achevée depuis le début des années 2000. Nous avons vu dans les séquences précédentes les détails de cette technologie de communication. Nous avons pu constater que le format des paquets et des adresses sont différents d'IPv4 Ces différences font que ces deux versions d'IP ne peuvent interopérer. L'internet actuel fonctionnant en IPv4 et l'internet a besoin d'IPv6 pour continuer sa croissance. L'objectif étant de quelquesoit la version d'IP utilisée d'offrir une connectivité globale. Ce pose alors le problème de la coexistence des 2 versions. Il n'y aura pas de jour du grand basculement d'IPv4 à IPv6. L'introduction d'IPv6 dans l'Internet s'effectuera de manière progressive. C'est notamment au travers des extensions du réseau actuel qu'IPv6 viendra suppléer IPv4.
| |
| − | <!-- Supprimer la peur de casser qqchose : la progressivité-->
| |
| − | Le risque de casser quelque chose qui fonctionne correctement en changeant le protocole. Cette possibilité peut exister, mais la migration en douceur du réseau, sans jour J, permet de se focaliser sur les nouveaux réseaux tout en laissant les anciens fonctionner sous IPv4.
| |
| | | | |
| − | ===Scénario initial de transition ===
| |
| − |
| |
| − | <!-- Le plan initial de transition -->
| |
| − | L'intégration est un processus qui s'étale dans le temps. Les spécifications IPv6 ont été produites à la fin des années 90. La période des années 2000 devaient servir au déployement des solutions d'intégration. Car le plan d'adressage IPv4 viendrait à épuisement dans la première moitié des années 2010. Ainsi, avant l'épuisement du plan d'adressage IPv4, IPv6 aurait été déployé. Or avec le recul, il n'en a rien été. L'attentisme a régné au niveau du marché et des acteurs. Nous nous retrouvons maintenant avec 2 problèmes à gérer en même temps: l'intégration d'IPv6 et l'épuisement du plan d'adressage IPv4.
| |
| − |
| |
| − | Moving to IPv6
| |
| − | https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf
| |
| − |
| |
| − | <!-- intégration vs transition -->
| |
| − | Cette idée d'un protocole visant à soulager IPv4 est marquée par le terme d'intégration. Lorsque le terme de transition est utilisé, celui porte l'idée du remplacement d'IPv4 par IPv6. Cette idée est plus anxiogène car elle indique une migration d'un système de communication qui fonctionne pour aller vers un système plus inconnu. Il est notoirement connu que la transition lorsqu'elle porte sur l'acheminement des paquets en utilisant les adresses IPv6 fonctionne sans problème. Les difficultés de transition porte sur les autres fonctions (comme la sécurité) ou la couche applicative lorsque celle-ci utilise des adresses IP. Les fabriquants n'ont pas toujours appliqué des procédures de test complètes ou pu valider les équipements en IPv6. Cela est du à un marché encore de petite taille bien qu'en croissance.
| |
| − | Enfin, l'apparition d'IPv6 ne signifie pas que IPv4 s'arrête. La base d'équipements installés, de logiciel étant tellement importante que cela lui assure une durée de vie illimitée à l'échelle humaine. Ceci rend l'idée de la migration sans fin. Nous allons dans la suite de ce chapitre présenter les techniques réseau qui rendent IPv6 interopable avec IPv4.
| |
| − |
| |
| − | ===Principes des mécanismes d'integration ===
| |
| − |
| |
| − | <!-- cas de la transition -->
| |
| − | Ainsi IPv6 doit se déployer sans remettre en cause ce qui fonctionne déjà. Mais que faut il faire pour passer son réseau en IPv6 ? En fait, il n'y a pas une réponse 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. Ceci donne 6 possibilités comme le montre le RFC 6144:
| |
| − | * Un hôte IPv4 qui communique avec un hôte IPv4 via un réseau IPv4.
| |
| − | * Un hôte IPv6 qui communique avec un hôte IPv6 via un réseau IPv6.
| |
| − | * Un hôte IPv4 qui communique avec un hôte IPv4 via un réseau IPv6.
| |
| − | * Un client IPv4 qui communique avec un serveur IPv6
| |
| − | * 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 complexité supplémentaire dans le réseau. Ces mécanismes dits de transition n'ont pas pour vocation d'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 côut du déploiment supportable en partant des composants existants. Les nouvelles applications comme par exemple la domotique pourraient directement démarrer en IPv6 nativement et se passer des mécanismes de transitions.
| |
| − |
| |
| − | La suite de ce document va présenter les types de mécanismes de transition, leurs principes et leurs limites.
| |
| − |
| |
| − | <!-- Double pile -->
| |
| − |
| |
| − | Le premier cas exprime le point de départ de la migration. Le second cas représente le point d'arrivée de la migration. La première idée pour pour passer d'IPv6 à IPv4 est d'avoir des noeuds qui soient biligues en quelquesorte. C'est à dire capable de parler en IPv6 ou en IPv4 en fonction des capacités de son correspondant. Ainsi les noeuds IPv6 restent compatibles avec les noeuds IPv4 en intégrant également le protocole IPv4. Lorsqu'une nouvelle machine se déploie 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. Hélas cette idée n'a pas marché car elle avait un cout immédiat du à la double configuration pour un gain futur (à la fin du plan d'adressage IPv4). L'autre difficulté de la machine double pile est d'avoir un préfixe IPV6 alloué par son fournisseur Internet. Ceux-ci n'ont pas non plus montré un réel empressement à fournir une infrastructure en IPv6. Le déploiement de noeuds double pile a été au final très limité.
| |
| − |
| |
| − | <!-- Tunnel -->
| |
| − |
| |
| − | l'accès à un réseau IPv6 existant ou la construction d'une infrastructure IPv6 même si les équipements d'interconnexion ne gèrent que le protocole IPv4. Ces mécanismes sont principalement à base du tunnels où les paquets IPv6 sont encapsulés dans des paquets IPv4.
| |
| − |
| |
| − | Les deux cas suivants se résolvent à l'aide de tunnel. Le paquet de la source est mis dans une enveloppe qui est en fait un paquet dans la version IP du réseau. Des propositions ont été faites pour faire la gestion des tunnels. Mais les solutions à base de tunnels ne sont pas pas complexe car les extrémités sont compatibles.
| |
| − |
| |
| − | Le deuxième mécanisme vise à offrir une connectivité IPV6 au travers d'une infrastructure IPv4. On parle de nos jours de cables virtuels (softwire). Un cable virtuel est un tunnel dans lequel une extrémité du tunnel encapulse Les paquets IPv6 dans les paquets IPv4. Les paquets IPv4 transitent dans l'infrastrcuture IPv4 pour rejoindre l'extrémité du tunnel qui va désencapsulé le paquet IPv6. Le câble virtuel forme une liaison point à point entre 2 noeuds IPv6. IPv4 est vu comme un système de transmission comme peut l'être Ethernet ou Wifi. Le masquage de la topologie du réseau IPv4 à IPv6 peut conduire à faire un routage des paquets IPv6 qui peut être sous optimal. Par conséquent, la solution des tunnels doit se faire en essayant de suivre la topologie du réseau et d'être les plus courts possibles en terme de routeurs IPv4 traversés.
| |
| − |
| |
| − | <!-- Traduction -->
| |
| − |
| |
| − | Les deux derniers cas traitent la situation ou les extrémités sont incompatibles.
| |
| − | Pour certaines catégories d'applications comme le mail, 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. Il faut donc pouvoir amorcer un cercle vertueux qui permettra de passer à IPv6.
| |
| − |
| |
| − | Enfin la dernière technique proposée consiste à rendre possible la communication entre un système IPv6 avec un système IPv4. C'est l'idée du NAT d'IPv4 utilisée maintenant pour faire de l'IPv6. Dans le cas du NAT IPv4, le format du paquet reste le même. Maintenant avec IPv6, le format du paquet change en même temps que les adresses. Par exemple un coté du NAT est en IPv4 et de l'autre coté, il utilise IPv6. Ce changement peut se faire au niveau du réseau comme nous venons de le voir mais il peut aussi se faire au niveau de la couche applicative. Ici, on parle de passerelle applicative. Par exemple, le client envoie sa requête en IPv4 à la passerelle applicative (ALG Application Level Gateway). Celle-ci la renvoie vers le serveur en IPv6.
| |
| − | L'exemple du DNS ceci se concoit tres facilement. Le resolver du client envoie la requéte au serveur locale en IPv4 ce dernier envoie la requête au serveur suivant en IPv6.
| |
| − |
| |
| − |
| |
| − | Dans cette situation, il n'y a pas une proposition universelle. C'est un problème complexe et très lié à l'application. C'est encore plus compliqué quand le client est IPv4 car ce dernier se retrouve à gérer une adresse en 128 bits. Or, Il ne sait pas le faire. L'inverse est plus facile, un client IPv6 peut gérer une adresse IPv4 (une adresse sur 128 bits peut contenir une adresse sur 32 bits).
| |
| − |
| |
| − | * les mécanismes de traduction permettant la communication entre les deux versions du protocole pour que des applications conçues pour IPv4 et celles pour IPv6 puissent échanger des données. Cette traduction peut se faire à différents niveaux de l'architecture réseau :
| |
| − | ** au niveau applicatif avec des relais ([[#ALG|ALG]] : ''Application Level Gateway'') ou proxy. Si l'application est connue, comme pour le web, le DNS les serveurs d'impressions ou le web, la traduction est relativement simple à faire. Cette méthode de migration devrait permettre de traiter la majorité des flux.
| |
| − | ** au niveau réseau avec des mécanismes de traduction d'en-tête. <br>Cette traduction peut se faire sans installer d'état dans un routeur NAT. Le paquet IPv4 est construit à partir d'informations déjà contenues dans l'en-tête IPv6, en particulier un format d'adressage particulier permet de véhiculer une adresse IPv4 dans les adresses IPv6. La difficulté d'assurer la compatibilité entre les deux mondes n'est pas symétrique. Avec les mécanismes comme [[#NAT-64|NAT-64]], il est beaucoup plus facile d'initier une session partant du monde IPv6 pour aller vers le monde IPv4. En effet, il est possible d'ajouter des fonctionnalités au monde IPv6 pour faciliter la cohabitation. De plus comme une adresse IPv6 est quatre fois plus grande, elle peut contenir une adresse IPv4. <br>Dans le sens inverse, il est impossible de modifier l'existant en IPv4. Le mécanisme [[#NAT-64|NAT-64]] s'appuie sur le DNS pour la convertion des adresses IPv4 en IPv6.
| |
| − |
| |
| − | Il est à noter que l'extrémité du tunnel comme la passerelle applicative sont des machines à double pile. Elles sont capables de communiquer dans les 2 protocoles.
| |
| − |
| |
| − | === Une étude des besoins et des choix à faire===
| |
| − |
| |
| − | Le déploiement progressif de ces mécanismes permet d'introduire graduellement et indépendamment le protocole IPv6 dans tous les segments du réseau. Chaque mécanisme répond à une problématique précise au déploiement d'IPv6 dans un monde IPv4.
| |
| − |
| |
| − | La phase de transition doit être simple, ou au minimum moins compliquée qu'une utilisation prolongée d'IPv4. Elle doit être également souple pour permettre un étalement dans le temps de la transition. Il n'y a pas de jour J pour le passage d'IPv4 à IPv6, il n'y a également pas d'échéance pour la disparition du protocole IPv4.
| |
| − |
| |
| − |
| |
| − | Le problème lié à la phase de démarrage, dit de la poule et l'oeuf : les sites ne vont pas migrer vers IPv6 puisque les opérateurs n'offrent pas de connectivité IPv6 et les opérateurs ne vont pas offrir de réseaux IPv6 puisqu'il n'y a pas de client.<br>En réalité il s'agit d'un faux problème. Un réseau IPv6 peut être déployé en intranet, les communications avec l'Internet restant en IPv4.<br>De plus les opérateurs commencent à déployer des réseaux IPv6, les autorités régionales (RIPE-NCC, APNIC, ARIN,...) allouent des préfixes officiels, et les réseaux se mettent en place. Un site voulant acquérir une expérience en IPv6 peut se raccorder relativement facilement à un de ces réseaux. Si cette démarche est impossible, l'emploi de [[Déploiement IPv6 des fournisseurs d'accès (ISP)#6to4|6to4]] permet de construire son propre préfixe IPv6 et de s'interconnecter au reste du monde IPv6, D'autres mécanismes, comme Tunnel Broker permettent de se connecter tres simplement à l'Internet IPv6. Ces mécanismes sont passés en revue au long de ce chapitre.
| |
| − |
| |
| − | Pour chaque situation, l'IETF a développé des mécanismes de coexistence. Le fait qu'i y a 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 n'est pas nécessaire maitriser toutes les techniques. Il faut comprendre que chaque technique s'applique à un problème bien précis. La migration vers IPv6 ne soulève pas tous les problèmes possibles. C'est à partir de l'étude de ces propres besoins qu'il faut identifier lesquelles des techniques est à appliquer. La démarche consiste à partir de l'inventaire du réseau IPv4 à se demander qu'est ce qui n'est pas compatible IPv6. Quels ont les problèmes qui vont apparaitre ? C'est à partir ce constat que les techniques de transition à retenir vont être choisies. Alors ce sont ces techniques là qu'il convient d'apprendre et de maitriser.
| |
| − |
| |
| − | L'objectif final: Avoir de l'IPV6 natif partout. C'est un objectif à long terme. L'objectif n'est pas d'installer des mécanismes d'intégration. Ces mécanismes sont vus comme temporaire. Un temporaire qui peut durer.
| |
| − |
| |
| − | Plusieurs champs de la migration d'IPv6 sont présentés dans la suite de ce chapitre : le déploiement d'IPv6 dans le réseau local en premier lieu, maintenir la connectivité entre les ilots IPv6 ensuite, et pour finir, l'interoperabilité avec les services en IPv4.
| |
