|
|
| (242 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| − | __NOTOC__
| |
| − | <!-- ----------------------------------------- -->
| |
| − | == <div id="why">I/ Déployer IPv6 maintenant </div> ==
| |
| − | <!-- ----------------------------------------- -->
| |
| | | | |
| − | 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, NETBUI) 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'applications particulières pouvant forcer massivement le passage vers IPv6. Les fonctionnalités 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 se trouvent indifféremment dans 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. 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 être configuré. Pour les réseaux avec un grand parc de machines, c'est d'autant plus intéressant.
| |
| − |
| |
| − |
| |
| − | ===D'une pénurie à un changement de paradigme ===
| |
| − |
| |
| − | Les raisons poussant au passage à IPv6 ne sont à trouver dans une quelconque ''killer application'' mais trouvent leurs origines dans les limitations d'IPv4 suite à la pénurie d'adresses. C'est à dire qu'il n'y a plus de préfixe réseau disponible et donc d'adresse. L'adresse est un élément indispensable à la connectivité au réseau. Sans adresse, un noeud est invisible, il ne peut rien recevoir et rend la communication impossible. La demande de connectivité à Internet loin de diminuer va au contraire s'accélérer avec les nouvelles applications telles que la domotique et la route intelligente. Cette dernière implique une masse importante d'objets numériques connectés. Ces applications se développent en IPv6. 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 4.3 milliards d'adresses, est trop petit. Il n'y a pas assez d'adresses pour chaque habitant même si l'allocation d'adresses était parfaite. Cette taille trop petite 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 60. 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 par personne. Le modèle d'adressage IPv4 de l'Internet est devenu obsolète et n'est plus capable de répondre au besoin d'interconnexion des ordinateurs. L'IPv6 vise justement à répondre à ce changement. La véritable motivation du passage à IPv6 se situe à ce niveau: avoir un Internet adapté à l'informatique d'aujourd'hui.
| |
| − |
| |
| − | === Où en est IPv4 ? ===
| |
| − |
| |
| − | L'Internet vit depuis des années en situation de pénurie d'adresses. Cette pénurie d'adresses a été prévue dès le milieu des années 1990 peu après la naissance du web. Des mesures ont été prises pour ralentir la consommation des adresses. La première mesure a été de retenir une méthode plus efficace d'attribution des adresses IPv4 en s'appuyant sur des longueurs de préfixe réseau de taille variable. Ce changement connu sous le nom de CIDR ''Classless Inter-Domain Routing'') n'était pas suffisant. Il fallait toujours une adresse IP par noeud se connectant à l'Internet. La seconde mesure a été de restreindre l'attribution des adresses aux noeuds ou plus exactement de partager une adresse IP entre plusieurs noeuds. Ce partage des adresses a validé la constatation qu'il y avait bien une pénurie d'adresses dans l'Internet. En pratique, le partage des adresses IP a été possible avec l'introduction d'un nouvel équipement : le NAT (''Network Address Transator'') et le recours à l'adressage privé comme le préfixe 192.168.0.0/12 largement utilisé dans les accès des particuliers. Un ensemble de noeuds derrière le NAT se partage une adresse IP globale. Le NAT est une fonction de la "box" que tout à chacun possède pour accéder à Internet. La figure 1 montre (c) [http://labs.apnic.net/?p=335 Huston 2013] le changement de vitesse d'attribution des adresses de la réserve avec la mise en pratique des deux mesures. Du temps était ainsi gagné pour promouvoir une solution définitive. Mais le développement de l'Internet dans la teléphonie mobile et l'accès ADSL ont accéléré la pénurie.
| |
| − |
| |
| − |
| |
| − | [[Image:addripv4.png|300px]] [[Image:addripv4-2.png|300px]] <br>
| |
| − | Figure 1: Vitesse de consommations des adresses de la réserve
| |
| − |
| |
| − | Mais la solution du NAT rend la connectivité Internet coûteuse et complexe. De plus elle introduit un état dans le réseau qui fragilise la robustesse du système de communication. Il convient ici de ne pas oublier qu'un principe fondateur de l'Internet est de rendre le fonctionnement de l'infrastructure de communication indépendante du fonctionnement des producteurs et consommateurs de données. Ce principe connu sous le nom de bout en bout a conduit à définir le service réseau en mode non connecté. Aucune marque ou état issu d'une communication se matérialise dans le réseau. Tout est indiqué dans le paquet. On parle d'unité de transfert auto-descriptive. Elle comporte toutes les informations pour aller de la source à la destination.
| |
| − | Le NAT est en complète contradiction avec ce principe. Le paquet n'est plus auto-descriptif de la source à la destination. Chaque NAT traversé change les informations de l'acheminement du paquet. On peut considérer que chaque NAT traversé conduit à constituer un tronçon du chemin pour attendre la destination. C'est cette succession de tronçons qui devient le chemin de la source à la destination. On peut voir que d'une infrastructure de communication de bout en bout, l'Internet a évolué vers une infrastructure de communication devant gérer des changements de tronçons. Or ces changements de tronçons demandent des états complexes à gérer en mode non connecté qui plus est rend le système fragile. En effet, une panne du NAT et ce sont toutes les communications qui sont interrompues. Ce qui n'est pas le cas quand cela arrive à un routeur.
| |
| − |
| |
| − | L'introduction des NAT a changé l'architecture de l'Internet, il n'y a plus de bout en bout. La conséquence est que déployer des nouveaux services ou des nouveaux protocoles de transport est devenu quasi impossible. Car non content de changer l'adresse IP, le NAT change souvent aussi le numéro de port situé au niveau de la couche de transport. Ce qui a pour conséquence de figer les protocoles de transport actuels.
| |
| − | Cette idée de rigidification de l'Internet est nommée par le terme d'ossification. Le modèle d'interaction se trouve aussi d'une certaine manière rigidifier. Dans le modèle d'interaction client-serveur, les clients qui sont derrière le NAT peuvent s'accommoder de partager une simple adresse IP. Il en est tout autrement pour les serveurs qui ont besoin d'une adresse IP qui leur est propre afin d'être contacté. Ainsi ce changement architectural de l'Internet l'a transformé petit à petit en un système minitel. Il est composé de client et de serveurs. Les possédants d'un adressage publique ont ainsi un avantage pour promouvoir leur service. Une certaine forme de contrôle des services est ainsi donné aux hébergeurs et opérateurs. La conséquence de cette évolution est qu'il est très difficile pour un utilisateur derrière un NAT d'offrir un service. Il en est de même pour les applications de type pair-à-pair (comme la téléphonie sur IP, les jeux répartis,...) qui sont devenues terriblement complexes pour contourner les difficultés introduites par le NAT pour les connexions entrantes. De fait, l'innovation dans ce type d'application est d'une certaine manière réduite.
| |
| − |
| |
| − | La pénurie d'adresses ne faisant qu'empirer avec le temps, on en arrive à la situation que les adresses publiques ne sont plus suffisantes pour être attribuées aux opérateurs eux-mêmes. Ainsi certains opérateurs par manque d'adresses publiques ont recours au NAT444 ou encore appelée technique du "double NAT". Le réseau de l'opérateur est lui-même en adressage privé. Ainsi le client de l'opérateur n'a même plus une adresse publique. Le NAT du client final se retrouve à faire un passage d'un adressage privé à un autre adressage privé. D'un point de vue de la terminologie, le NAT du client est dorénavant qualifié de NAT44 pour un changement d'adressage de derrière (le coté client) à devant (le coté opérateur) cet équipement.
| |
| − |
| |
| − | Pour se rendre compte de la situation de l'adressage dans l'Internet IPv4, La figure 2 (http://www.potaroo.net/tools/ipv4/) représente sous forme d'un histogramme l'état des allocations. Cet histogramme est composé de 256 barres indiquées par la valeur du premier octet de l'adresse d'IPv4 (notée ici "/8"). Pour la même valeur du premier octet est alors indiqué l'état de l'usage des 3 autres octets. Cette figure montre qu'il ne reste quasiment plus rien à allouer (en vert). Les RIR ''Regional Internet Registries'') sont sur leur réserve. Ils allouent maintenant les dernières adresses sous des conditions draconniennes. Nous arrivons bien à la fin d'IPv4. Le déploiement des super NAT ou NAT444 pose de nombreux problèmes. Comme par exemple, il était complexe pour un client d'un opérateur d'héberger un serveur derrière un NAT44, ceci devient maintenant impossible derrière un NAT444. Les RFC 5684 et 7021 dressent d'ailleurs une liste des ennuis apparus par l'introduction des NAT444. La seule solution a toutes ces complexités réside au passage d'IPv6 pour sortir enfin de la pénurie.
| |
| − |
| |
| − | [[Image:Fig05.png|300px]] <br>
| |
| − | Figure 2: Etat du plan d'adressage IPv4 en 2015
| |
| − |
| |
| − | === Motivations à IPv6 ? ===
| |
| − |
| |
| − | C'est en partant du constat des limitations et des problèmes induits par l'utilisation IPv4 que les motivations à l'adoption à IPv6 apparaissent. Il faut de nos jours un grand espace d'adressage. Le passage à IPv6 devient donc une nécessité. Ainsi en attribuant une adresse à chaque noeud 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. La technologie de l'infrastructure de communication retrouve sa simplicité originelle. 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'echelle (no scalable).
| |
| − | Geof Huston dans l'article [http://www.potaroo.net/ispcol/2015-04/iotst.html] ajoute un autre argument liè à la sécurité dans l'Internet des objets. Comme un sondage de l'espace d'adressage IPv4 prend 5 minutes, un objet peut être victime d'une action pirate. Alors qu'en IPv6, l'espace d'adressage étant si grand qu'il est impossible de pouvoir sonder tout un réseau pour trouver les adresses utilisées. Ce qui rend les noeuds quasiment indétectables. En effet, il faut 41000 ans en IPv6 pour sonder une adresse /64. Cette caractéristique sur la taille rend IPv6 indispendable pour l'Internet des objets car elle rend les objets indétectables par un simple sondage tout en les laissant accessibles.
| |
| − |
| |
| − | === Où est est IPv6 ? ===
| |
| − |
| |
| − | Depuis le premier RFC sur IPv6 publié en décembre 1995, la version IPv6 a quitté les laboratoires. L'étape de standardisation des protocoles de base de IPv6 (''core specs'') est achevée depuis le début des années 2000.
| |
| − |
| |
| − | En fait, une adresse IP s'utilise dans l'infrastructure de communication mais également dans les applications des systèmes d'extrémités. Dans la communication, l'adresse IP a le double rôle : de localisation et d'identification.
| |
| − | <!-- Etat d'IPv6-->
| |
| − | Les équipements informatiques sont tous devenus IPv6. Les systèmes d'exploitations de tous les ordinateurs disposent d'une pile IPv6 aisément configurable. Le code des routeurs comme celui des équipements terminaux (PC, stations de travail, imprimantes,...) comportent le code IPv6. Ceux-ci s'intègrent à un Internetv6. Il n'y a pas de réelle difficulté à faire fonctionner des équipements en IPv6. Les difficultés commencent à apparaitre pour les logiciels propriétaires ou pour les logiciels anciens dont le code source n'est pas disponible. Ces applications spécialisées (environnement de travail intégré, ...) qui utilisent l'adresse IP comme un identificateur codé sur 32 bits font apparaitre les points de blocage au passage à IPv6. Ce n'est pas un gros problème en soi, mais c'est le risque de multiplication qui va rendre la tâche de migration délicate. C'est actuellement un facteur bloquant pour le déploiement massif d'IPv6.
| |
| − | <!-- Etat du déploiement d'IPv6 : Statistiques-->
| |
| − | En 2015, l'usage d'IPv6 vu par les serveurs google est proche de 7%. La figure 3 [http://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption] montre l'évolution des usages. Cette courbe montre un doublement de l'adoption d'IPv6 tous les ans depuis 2010.
| |
| − | Les utilisateurs de Google peuvent émettre des requêtes en IPv6 si ils ont un accès IPv6 offert par leur fournisseur Internet. Le figure 4 [http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_APNIC;s=_RIR_AfriNIC;s=_RIR_ARIN;s=_RIR_LACNIC;s=_RIR_RIPE_NCC] montre le pourcentage des organisations annonçant un préfixe IPv6. L'Europe de manière générale est active dans le déploiement d'IPv6.
| |
| − |
| |
| − | [[Image:Google.png|200px]]<br>
| |
| − | Figure 3: Evolution du pourcentage de requêtes reçues en IPv6 par Google
| |
| − |
| |
| − | [[Image:Ipv6-usable.png|200px]]<br>
| |
| − | Figure 4: Evolution du pourcentage d'organisation annonçant au moins un préfixe IPv6 par région
| |
| − |
| |
| − |
| |
| − | L'adoption d'IPv6 est aussi une question de formation. Le protocole IPv6 n'est pas une expérience. Il est indispensable pour un fonctionnement normal de l'Internet. Nous entendons par normal, un fonctionnement respectant les principes fondateur de l'Internet dont celui du bout-en-bout. Si les principes sont très similaires entre IPv4 et IPv6. En pratique, IPv4, nous venons de le voir, adopte de plus en plus des principes non conventionnels pour continuer de fonctionner. L'apprentissage du fonctionnement de l'Internet doit se faire de nos jours principalement avec IPv6 et accessoirement avec IPv4. Il faut rendre banale la nouvelle version du protocole IP. Nous espérons que ce cours y concourt.
| |
| − |
| |
| − | Bien que IPv6 soit une technologie mature, le déploiement de l'Internet v6 reste encore limitée. Et cependant son usage devient de plus en plus pressant. Non seulement l'Internet continue de grandir mais des nouveaux usages et des nouveaux équipements apparaissent ne faisant qu'accélérer sa croissance. Nous l'avons dit, IPv4 n'est pas capable de répondre à ce défi. Le principal frein au passage à IPv6 est de se satisfaire de la situation présente. Le cout du passage à IPv6 constitue un investissement qui comme tout investissement s'amortit dans le temps et fournit un retour. Maintenir IPv4 ne produit qu'une dépense sans aucun espoir de retour. Comment procéder pour réaliser cet investissement ? C'est ce que nous allons voir par la suite.
| |
| − |
| |
| − | === <div id="scenario"> Quel scénario pour le déploiement ? </div> ===
| |
| − |
| |
| − | Nous avons vu dans les séquences précédentes les détails de la technologie de communication liées à IPv6. 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 fonctionne en IPv4 mais il a besoin d'IPv6 pour continuer sa croissance. Quelque soit la version d'IP utilisée, l'objectif est de maintenir une connectivité globale. Ce pose alors le problème de la coexistence des deux versions. Plus exactement, le monde IPv6 doit intégrer des mécanismes afin qu'il puisse interopérer avec l'Internetv4.
| |
| − | Comme 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 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.
| |
| − | 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 s'arrête. La base d'équipements installés, de logiciels étant tellement importante que cela assure du 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. Ce RFC décrit la démarche pour le déploiement d'IPv6 dans un réseau administré.
| |
| − |
| |
| − | <!-- 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. Le but du maintient d'IPv4 en activité est aussi d'éliminer la peur de détruire quelque chose qui fonctionne. 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 fabricants 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.
| |
| − | La suite de ce document va présenter les types de mécanismes de transition, leurs principes et leurs limites.
| |
| − |
| |
| − | ===Principes des mécanismes d'intégration ===
| |
| − | <!-- cas de coexistence -->
| |
| − | 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 cas 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 IPv6 qui communique avec un hôte IPv6 via un réseau IPv4.
| |
| − | * 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 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 nativement et se passer des mécanismes de transitions.
| |
| − |
| |
| − |
| |
| − | ==== 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 passer d'IPv6 à IPv4 est d'avoir des noeuds qui soient biligues en quelque sorte. 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.
| |
| − | Le déploiement d'IPv6 en double pile était le plan originel de migration. Après les années de spécification que fût 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 marché car elle avait un coût immédiat du à 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 à fournir une infrastructure en IPv6 pour fournir des préfixes IPv6 pour que leurs clients fonctionnent en double pile. Le déploiement de noeuds double pile a été au final très limité. Nous nous retrouvons maintenant avec deux problèmes à gérer en même temps: l'intégration d'IPv6 et l'épuisement du plan d'adressage IPv4.
| |
| − | Il est à noter que les mécanismes suivant du tunnel et de la traduction reposent sur des machines à double pile. Elles sont capables de communiquer dans les deux protocoles.
| |
| − |
| |
| − | [[Image:Ds.png|400px]]<br>
| |
| − | Figure: Double pile
| |
| − |
| |
| − | ==== Tunnel ====
| |
| − |
| |
| − | Les cas 3 et 4 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. Dans le troisième cas, une connectivité IPv6 est offerte 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'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 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. Comme les systèmes d'extrémités sont compatibles, la solution à base de tunnel n'introduit pas une forte complexité.
| |
| − |
| |
| − | [[Image:Tunnel.png|200px]]<br>
| |
| − | Figure: 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, 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 consiste à rendre possible la communication entre un système IPv6 et un système IPv4. 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, maintenant 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 applicatives 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 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 tres 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. Pour les application largement diffusées, comme pour le web, le DNS, les serveurs d'impressions ou le web, la traduction est relativement simple à faire. Mais sa mise en oeuvre est compliquée car l'ALG est très liée à l'application et la multiplication des applications empêche d'avoir une proposition universelle. 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.
| |
| − | Cette traduction peut se faire sans installer d'état dans un 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. Il est beaucoup plus facile d'initier une session partant du monde IPv6 pour aller vers le monde IPv4. Autrement dit, il est le 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 compliqué. Le client IPv4 se retrouve à gérer une adresse en 128 bits et en plus il est impossible de modifier l'existant en IPv4.
| |
| − |
| |
| − | [[Image:Traduction.png|200px]]
| |
| − |
| |
| − | ===Démarche de déploiement===
| |
| − |
| |
| − | <!-- Une étude des besoins et des choix à faire-->
| |
| − |
| |
| − | 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 en IPv4. Quand ce coût dépasse une valeur admise propre à chaque acteur, la décision du passage à IPv6 s'impose. Que son réseau de communication soit à construire ou qu'il existe déjà, que la connectivité de son opérateur soit ou pas en IPv6, IPv6 peut s'utiliser dans le réseau de son site. A noter 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'Internetv4, 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. Chaque mécanisme répond à une problématique précise au déploiement d'IPv6 dans un monde IPv4. 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.
| |
| − | 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 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 sont à appliquer. La démarche consiste à partir de l'inventaire du réseau IPv4 à se demander qu'est 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 diriger le choix. La question à répondre quelque soit la situation est : quels sont les problèmes qui vont apparaitre en utilisant IPv6? 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 maîtriser.
| |
| − | 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. Certes un temporaire qui peut durer. L'objectif final est d'avoir l'Internet en IPv6 partout comme le rappel le RFC6180. C'est un objectif à long terme. Le but des mécanismes de coexistence est de faciliter le déploiement d'IPv6 dans tout l'Internet. Lorsque cela sera fait, ces mécanismes deviendront obsolétes et leur disparition rendra l'usage d'IPv6 beaucoup plus simple. En fait un peu comme 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:
| |
| − | * 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.
| |
| − | * une phase interne consistant à déployer IPv6 pour les communications internes.
| |
| − | * une phase externe dans laquelle il s'agit de traiter la connectivité de son Intranet avec l'Internet.
| |
| − |
| |
| − | Plusieurs mécanismes 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'interopérabilité avec les services en IPv4.
| |
