Difference between revisions of "MOOC:Compagnon 4"
From Livre IPv6
(→II/ Quel scénario pour le déploiement ?) |
(→I/ Pourquoi utiliser IPv6 ?) |
||
| Line 10: | Line 10: | ||
[[MOOC:Compagnon_Act41]] | [[MOOC:Compagnon_Act41]] | ||
| − | + | <!-- ----------------------------------------- --> | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== <div id="scenario"> II/ Quel scénario pour le déploiement ? </div> == | == <div id="scenario"> II/ Quel scénario pour le déploiement ? </div> == | ||
<!-- ----------------------------------------- --> | <!-- ----------------------------------------- --> | ||
Revision as of 07:24, 27 March 2015
> MOOC>Contenu >Séquence 4 > Document compagnon
Contents
Intégration d'IPv6 à l'Internet actuel
I/ Pourquoi utiliser IPv6 ?
II/ Quel scénario pour le déploiement ?
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.
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
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
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
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.
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é.
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.
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 : 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.
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, 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.
Dans le sens inverse, il est impossible de modifier l'existant en IPv4. Le mécanisme 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.
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.
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 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.
III/ Activer IPV6 dans son infrastructure
Successfully Deploying IPv6 https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf
Obtenir un préfixe IPv6
Installation en double pile
Le mécanisme de double pile IP présenté par le RFC 4213 consiste à doter chaque équipement du réseau d'une double pile protocolaire (Dual Stack) et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau.
Les noeuds sont capables de communiquer dans les deux versions du protocole IP. Ceci demande clairement un double travail, tout doit être fait en double. Tous les segments d'un réseau sont en double pile. En contrepartie, ce mécanisme ne prend pas en compte les problèmes de pénurie d'adresses IPv4. En effet, la double pile ne règle pas le problème de l'épuisement du plan d'adressage d'IPv4. Car chaque machine IPv6 a besoin d'une adresse IPv4.
Tous les équipementiers de coeur de réseaux supportent ce mécanisme, qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Le déploiement de ce mécanisme peut être progressif et ne concerner qu'une partie du coeur de réseau dans un premier temps. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé. Dans ce cas en effet, l'activation de fonctions permettant de gérer plusieurs topologies peut s'avérer nécessaire (cf. ISIS).
Pour les équipements terminaux, ce mécanisme de transition a été défini et a été très largement employé dès le début de la standardisation d'IPv6. De la même manière, il consiste à doter chaque équipement d'une double pile protocolaire et d'affecter une adresse IPv4 et/ou IPv6 à chaque inteface réseau. Cela ne résoud pas le problème de la pénurie d'adresses IPv4, mais permet dans un premier temps d'acheminer indifférement du trafic IPv4 ou IPv6 sur un équipement donné (station, routeur).
La figure Compatibilité grâce à la double pile illustre ce principe. La station B peut parler en IPv4 avec la station A et en IPv6 avec la station C. Le listing suivant donne un exemple de configuration d'une double pile dans un environnement Unix.
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255 inet6 3ffe:305:1002:1:2b0:d0ff:fe5c:4aee/64 inet6 fe80::2b0:d0ff:fe5c:4aee/64 ether 00:b0:d0:5c:4a:ee media: 10baseT/UTP <half-duplex> supported media: autoselect 100baseTX
QUelque soit la version de protocole utilisée au niveau de l'application cela ne doit rien changé. Il faut cependant que l'application puisse exprimer l'adresse de son correspondant que ce soit en IPv4 ou en IPv6. Pour cela, les adresses doivent être codées sur 128 bits. Un type d'adresse IPv6 a été défini à cet usage à savoir comporter l'adresse IPv4 d'une communication IPv4. L'adresse IPv4 est imbriquée dans une adresse IPv6. Au niveau de l'interface pour la communication, l'application peut recevoir une connexion aussi bien en IPv4 ou en IPv6. Le format des adresses IPv4 mapped est ::FFFF:<ipv4 address> comme par exemple ::FFFF:1.2.3.4
Reste le problème des applications. Une application écrite avec l'API socket IPv6 (L'interface de programmation "socket" IPv6), utilisant en particulier des struct sockaddr_storage et la fonction getaddrinfo, peut dialoguer indifférement en IPv4 et en IPv6. Simplement, pour un serveur, deux sockets sont nécessaires, l'une pour IPv4 et l'autre pour IPv6. La station B devrait, dans l'exemple de la figure ci-dessus, posséder des serveurs pour chacune des versions de IP, ou au moins des serveurs écoutant sur plusieurs ports en parallèle. Cela peut être évité en utilisant des adresses mappées, qui permettent à une application de voir l'espace d'adresses IPv4 comme une partie de l'espace d'adressage IPv6.
Comme le montre la figure Adresse IPv4 mappée, l'adresse IPv4 est contenue dans l'adresse IPv6.
Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application s'est enregistrée via une socket IPv6 (famille de protocoles PF_INET6), les adresses IPv4 mappée source et destination sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement quand une application IPv6 émet des paquets avec une adresse IPv4 mappée, ceux-ci sont aiguillés vers la pile IPv4.
L'exemple suivant illustre ce fonctionnement. Le client telnet, compilé en IPv6 peut contacter les équipements IPv4 en utilisant l'adresse mappée.
>telnet rhadamanthe Trying 3ffe:305:1002:1:2b0:d0ff:fe5c:4aee... Connected to rhadamanthe.ipv6.rennes.enst-bretagne.fr. Escape character is '^]'. FreeBSD/i386 (rhadamanthe.ipv6.rennes.enst-br) (ttyp3) login:^D >telnet bloodmoney Trying ::ffff:193.52.74.211... Connected to bloodmoney.rennes.enst-bretagne.fr. Escape character is '^]'. SunOS UNIX (bloodmoney) login:
Le mécanisme de double pile permet de résoudre tous les problèmes d'interopérabilité liés à l'introduction de la pile IPv6. Quand cela est possible, la communication se fait en utilisant la nouvelle version du protocole. Dès qu'un des éléments n'est pas compatible (réseau, système d'exploitation, application), le protocole IPv4 est utilisé. Le principal intérêt vient du fait qu'il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes. Pourtant ce mécanisme n'est pas suffisant :
- Il ne résout pas le problème de la pénurie d'adresses puisque chaque machine doit disposer d'une adresse IPv4 et d'une adresse IPv6. Cela complique aussi les mécanismes de configuration automatique.
- Il implique que tous les routeurs soient aussi configurés pour router les deux types de paquets.
- Les applications doivent être compilées pour IPv6, ce qui implique la disponibilité du code source et un "effort" de reprogrammation.
Les applications recompilées avec l'API IPv6 ne fonctionnent que sur des équipements pourvus d'un système récent (et d'une pile IPv6 si on utilise les adresses IPv4 mappées), ce qui peut poser des problèmes de compatibilité entre les différentes versions d'un système.
Implications au niveau du DNS
A résumer
The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map between hostnames and IP addresses. A new resource record type named "AAAA" has been defined for IPv6 addresses [RFC3596]. Since IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 and IPv6 nodes, they must provide resolver libraries capable of dealing with IPv4 "A" records as well as IPv6 "AAAA" records. Note that the lookup of A versus AAAA records is independent of whether the DNS packets are carried in IPv4 or IPv6 packets and that there is no assumption that the DNS servers know the IPv4/IPv6 capabilities of the requesting node.
The issues and operational guidelines for using IPv6 with DNS are described at more length in other documents, e.g., [DNSOPV6].
DNS resolver libraries on IPv6/IPv4 nodes MUST be capable of handling both AAAA and A records. However, when a query locates an AAAA record holding an IPv6 address, and an A record holding an IPv4 address, the resolver library MAY order the results returned to the application in order to influence the version of IP packets used to communicate with that specific node -- IPv6 first, or IPv4 first.
The applications SHOULD be able to specify whether they want IPv4, IPv6, or both records [RFC3493]. That defines which address families the resolver looks up. If there is not an application choice, or if the application has requested both, the resolver library MUST NOT filter out any records.
Since most applications try the addresses in the order they are returned by the resolver, this can affect the IP version "preference" of applications.
The actual ordering mechanisms are out of scope of this memo. Address selection is described at more length in [RFC3484].
Précaution: Eviter led pbs pour les "eye balls"
[Le bonheur des globes oculaires (IPv6 et IPv4) ]
RFC 6555 Happy Eyeballs: Success with Dual-Stack Hosts http://www.bortzmeyer.org/6555.html
IV/ Etablir la connectivité IPv6
L'accès à un réseau IPv6 existant s'effectue par des mécanismes principalement axés autour de la création dynamique de tunnels (TSP.
La construction d'une infrastructure IPv6 même si les équipements d'interconnexion ne gèrent que le protocole IPv4 reposent sur des tunnels statique.
Les mécanismes disponibles pour ce segment de réseau, contrairement à ceux décrits précédemment, mettent en oeuvre une architecture type client/serveur. Sauf exception ou cas particulier, la partie cliente est localisée côté utilisateur et la partie serveur côté ISP.
Le point fort des mécanismes présentés ici est de permettre une mise en oeuvre de solutions dites automatiques, où l'intervention de l'administrateur est réduite à une phase de configuration/ initialisation du service.
Tunnel: 6over4
Un serveur de tunnels (IPv6 dans IPv4) permet de connecter à l'Internetv6 une machine double pile isolée dans l'Internetv4. Dans certaines versions de ce service un réseau local peut être ainsi connecté, quel que soit le nombre de machines qu'il comporte. La configuration du tunnel entre le serveur et la machine cliente est automatique et repose sur le protocole TSP. La demande de connexion au serveur est réalisée par une page HTML dont l'URL est connue à l'avance.
Ce mécanisme/service permet de fournir de la connectivité IPv6 à des équipements/réseaux locaux isolés dans l'Internetv4. Cette connectivité est en générale fournie à titre provisoire (soit en attendant que l'offre des ISP soit disponible soit pour faire des tests de validation, par exemple). Elle peut aussi être une première étape pour un prestataire de service pour procurer de la connectivité IPv6 à ses usagers.
Le service Tunnel Broker repose sur une architecture à base de client/serveur. Côté usager l'installation d'un simple client permet de faire la demande de tunnels au serveur. Ce client est en général authentifié. Pour le prestataire, il faut mettre en oeuvre un serveur qui a plusieurs fonctions : l'interface HTML pour accueillir les demandes de tunnels des usagers et la « comptabilité » qui peut l'accompagner, le configurateur de tunnels qui envoie les paramètres d'extrémité du tunnel entre l'équipement de concentration et celui de l'usager d'une part et le concentrateur de tunnels d'autre part.
De nombreuses évolutions de ce mécanisme sont en cours :
- L'authentification du client demandant à [r]établir une connexion au serveur de tunnels permet de disposer d'une fonction VPN quel que soit le lieu où se trouve l'usager dans l'Internet.
- Les implantations s'appuyant sur des tunnels UDP permettent la traversée de NAT, fonction indispensable aux terminaux (ou réseaux) situés dans un plan d'adressage privé.
- Le découpage de l'espace d'adresse pour numéroter les extrémités de tunnels et les réseaux d'interconnexion, nécessite un peu de doigté. Là aussi des évolutions sont en cours pour simplifier les implantations actuelles et mieux coller à l'expérience de déploiement des réseaux IPv6 acquise ces dernières années.
TSP : tunnel setup protocol
Le tunnel setup protocole [BP-id] a été défini en complément du Tunnel Broker afin de permettre une négociation automatisée des différents paramètres entrant en jeu lors de l'établissement d'un tunnel. En effet, nombre d'implémentations de Tunnel Broker sont basées aujourd'hui sur une interface Web qui permet de saisir ou de récupérer implicitement les paramètres nécessaires à l'établissement du tunnel entre le terminal et le Tunnel serveur. L'architecture d'un Tunnel broker implémentant TSP est donné figure Configuration d'un Tunnel Broker avec TSP.
TSP permet la négociation automatique et transparente à l'utilisateur de tout ou partie des paramètres suivants :
- le mécanisme d'authentification utilisateur utilisé,
- le type d'encapsulation utilisée : IPv4 dans IPv6, IPv6 dans IPv4, IPv6 dans UDP IPv4
- l'adresse IPv6 assignée lorsque le client TSP est un terminal
- le préfixe IPv6 alloué lorsque le client TSP est un routeur
- l'enregistrement DNS dans le cas d'un terminal
- la résolution DNS inverse dans le cas d'un routeur
La disponibilité du type d'encapsulation IPv6 dans UDP IPv4, permet d'offrir une solution de traversée de NAT, alternative à celle proposée par exemple par Teredo. Dans ce cas, le client TSP met en oeuvre un processus de découverte de NAT qui consiste simplement à envoyer au TSP serveur du Broker, un message UDP contenant l'adresse IP du terminal. Le serveur TSP serveur compare simplement l'adresse contenue dans le message avec l'adresse source du paquet UDP. Si elles sont différentes alors le terminal est situé derrière un NAT.
TSP s'appuie sur l'échange de simples messages XML dont un exemple est donné ci-dessous. Cet exemple correspond à la demande de création d'un tunnel simple par un client TSP :
-- Successful TCP Connection -- C:VERSION=2.0.0 CR LF S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF C:AUTHENTICATE ANONYMOUS CR LF S:200 Authentication successful CR LF C:Content-length: 123 CR LF <tunnel action="create" type="v6v4"> <client> <address type="ipv4">1.1.1.1</address> </client> </tunnel> CR LF S: Content-length: 234 CR LF 200 OK CR LF <tunnel action="info" type="v6v4" lifetime="1440"> <server> <address type="ipv4">206.123.31.114</address> <address type= "ipv6">3ffe:b00:c18:ffff:0000:0000:0000:0000</address> </server> <client> <address type="ipv4">1.1.1.1</address> <address type= "ipv6">3ffe:b00:c18:ffff::0000:0000:0000:0001</address> <address type="dn">userid.domain</address> </client> </tunnel> CR LF C: Content-length: 35 CR LF <tunnel action="accept"></tunnel> CR LF
6RD
Le mécanisme 6to4 permet d'interconnecter entre eux des sites IPv6 isolés en créant des tunnels automatiques IPv6 dans IPv4 en fonction du destinataire des données. Le mécanisme définit plusieurs composants.
- la machine terminale 6to4 (dépendante de l'implantation dans le système d'exploitation)
- le routeur de bordure (ou gateway), qui doit encapsuler les paquets IPv6 dans des paquets IPv4, est connecté à IPv4 et IPv6
- le relais 6to4 est un équipement réseau dont l'adresse est bien connue (adresse anycast). Il assure la connexion à l'Internetv6.
6to4 permet à un ISP de fournir de la connectivité IPv6 à ses usagers en installant une machine unique connectée aux deux mondes IP. Il peut aussi permettre à un usager de router du trafic IPv6 même si son prestataire ne fournit qu'une connectivité et des adresses IPv4. Il faut noter que le routage entre les machines distantes a de bonnes probabilités d'être asymétrique notamment si le routeur de bordure utilise un relais 6to4 et que l'utilisation des tunnels peut conduire à des délais de propagation élevés.
On peut envisager l'usage de la technique 6to4 de deux manières :
- Comme un moyen de pression envers les ISP. Un site dont le fournisseur de service refuse d'offrir un service IPv6, n'est pas bloqué. Il dispose d'une méthode simple pour construire ses adresses IPv6 et la création de tunnels. Il suffit de trouver l'adresse IPv4 d'un routeur passerelle qui traitera les paquets.
Cette approche conduit à un routage sous-optimal, comme indiqué précédemment, et à une anarchie dans le réseau en terme d'administration. - Pour permettre aux ISP d'offrir un service IPv6 minimum à leurs clients. Cette approche est acceptable dans la période de déploiement d'IPv6. Le fournisseur de services met en place un routeur passerelle uniquement pour ses clients et le place par exemple dans un point d'interconnexion. D'une part, la charge administrative et technique est réduite puisque l'ISP n'a pas à gérer un nouveau plan d'adressage ou la création de nombreux tunnels. D'autre part, le routage est plus optimal puisque le relais est proche des clients et du réseau IPv6 auquel l'ISP est relié.
On pourrait envisager l'installation de relais 6to4 sur les points d'échange de l'Internet pour accélérer le déploiement et l'usage d'IPv6 par les ISP. Mais il n'y a pas de demande dans ce sens actuellement et ce mécanisme est actuellement peu déployé par les ISP. La question de sa résistance au facteur d'échelle, et des aspect liés à la sécurité, sont posées depuis longtemps. Ils n'ont pas encore trouvé de réponse.
Le préfixe 2002::/16 a été alloué par l'IANA à ce type d'adressage (cf. figure Adresse 6to4). Le gestionnaire d'un site peut aisément créer un préfixe de longueur 48 en y concaténant l'adresse IPv4 (convertie en hexadécimal) d'un routeur en bordure des réseaux IPv4 et IPv6.
La figure Exemple de numérotation en utilisant le préfixe de 6to4 illustre le mécanisme d'attribution de préfixes. Le routeur RB se trouve en bordure du réseau. Il est connecté à la fois à l'Internet v4 et à un (ou des) réseau(x) IPv6. Le routeur possède obligatoirement une adresse IPv4 sur le réseau de l'ISP. Il va s'en servir pour construire les 48 premiers bits de l'adresse IPv6. C'est ce préfixe de 48 bits qui va être utilisé par l'ensemble des équipements 6to4 du site. Ce préfixe identifie un site donné. On peut remarquer que ce plan d'adressage est conforme aux plans d'adressage globaux actuellement en vigueur, puisqu'il réserve 16 bits pour numéroter les réseaux du site et 64 bits pour les identifiants d'interface.
La figure Exemple de routage des paquets explique comment les paquets sont routés quand l'équipement A veut envoyer un paquet IPv6 à l'équipement B. Dans un premier temps, A interroge le DNS pour connaître l'adresse IPv6 de B. La réponse est une adresse du type 2002:C0C0:C0C0:.... La machine A émet un paquet vers cette destination. Les paquets dont l'adresse destination commence par le préfixe 2002::/16, correspondant au plan d'adressage 6to4, sont routés vers un routeur tunnelier pour 6to4. Ce dernier analyse l'adresse IPv6 de destination et trouve l'adresse IPv4 de l'autre extrémité du tunnel (192.192.192.192 dans l'exemple). Le paquet est reçu par le routeur RB qui retire l'encapsulation IPv4 et le route normalement vers la destination B en utilisant le routage interne.
On peut remarquer dans cet exemple que l'adresse de la source peut être aussi bien une adresse IPv6 6to4 qu'une adresse IPv6 globale. Mais le dialogue dans le sens opposé est plus complexe et montre les limites de cette technique.
Un site utilisant 6to4 n'est pas, par définition, connecté à l'Internet v6. Il doit donc exister dans l'Internet v4 des routeurs servant de passerelle vers le réseau Internet IPv6. Un routeur de bordure faisant l'encapsulation des paquets IPv6 dans des paquets IPv4 peut être configuré de la manière suivante :
- si l'adresse du destinataire commence par le préfixe 2002::/16, effectuer l'encapsulation du paquet vers le destinataire IPv4 dont l'adresse est incluse dans l'adresse IPv6 de destination,
- sinon, il s'agit d'une adresse IPv6 globale et le paquet doit être tunnelé à l'adresse IPv4 d'un routeur servant de passerelle vers le réseau IPv6.
De même, dans la figure Exemple de routage des paquets, nous avons supposé que le routeur faisant l'encapsulation était situé en bordure du réseau du site où se trouve la machine A. C'est probable si le site utilise également un plan d'adressage 6to4. Par contre si le site n'utilise que des adresses globales, voire n'a pas de connexion IPv4, l'encapsulation peut être déléguée à un routeur passerelle. Ce routeur passerelle peut en utilisant les protocoles de routage interne et externe annoncer aux équipements IPv6 cette fonctionnalité.
Le danger est d'engorger les tables de routage IPv6 avec une complexité lié à l'adressage IPv4. Pour éviter cet écueil, un routeur passerelle ne doit pas annoncer un préfixe IPv6 autre que 2002::/16. En conséquence, les paquets émis à destination d'une adresse 6to4 seront traités par le routeur le plus proche au sens des protocoles de routage.
Il est important de respecter cette règle au niveau des annonces BGP, comme le montre l'exemple de configuration des routeurs See Règles d'annonce et d'agrégation.
Si 6to4 est une technique intéressante pour relier deux nuages IPv6 à travers un nuage IPv4, elle se complique et n'est pas optimale lorsqu'il s'agit de communiquer avec une machine dont l'adresse est issue d'un plan de numérotation global. Le routage n'est pas toujours optimal et presque assurément asymétrique :
- le site 6to4 peut avoir choisi un routeur passerelle loin du destinataire,
- le site ayant un plan d'adressage global envoie les paquets vers le routeur passerelle le plus proche au sens du routage.
Pour réduire la taille des tunnels, une adresse IP anycast a été proposée pour automatiser et simplifier la phase de configuration de l'adresse du relais. Le préfixe 192.88.99.0/24 a été attribué à ce propos [RFC 3068] et le relais prend l'adresse 2002:c058:6301::, ou 192.88.99.1 en utilisant l'adresse IPv4. Un site offrant ce service peut annoncer ce préfixe dans le routage global de l'Internetv4 et les paquets à destination d'un relais iront vers l'équipement le plus proche.
DS-Lite
V/ Interopérabilité avec les services de l'Internet IPv4
Relais applicatifs
Les relais applicatifs ou ALG (Application Level Gateway) représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les équipements IPv6 émettent leur requête vers le relais applicatif qui interprète le contenu de la requête et la retransmet en IPv4.
Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.
L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs, par exemple telnet. Mais comme la liste précédente l'indique, les ALG concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.
Les relais applicatifs regroupent :
- les proxies et les caches web,
- les spoolers d'impression,
- les serveurs de courrier électronique,
- les serveurs DNS,
- ...
Configuration d'un relais applicatif pour le Web
Le listing suivant donne un extrait de la configuration d'un serveur apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.
#cat /usr/local/etc/apache/httpd.conf
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
ProxyVia On
</IfModule>
# End of proxy directives.
NAT64/DNS64
Le principe reste identique à celui de NAT pour IPv4. Il s'agit ici de traduire les en-têtes des datagrammes IPv6 en en-têtes de datagrammes IPv4. NAT-64 permet le déploiement de réseaux uniquement IPv6 et offrir une « compatibilité » avec le monde IPv4. Les boitiers NAT-64 sont des routeurs réalisant la traduction des paquets IPv6 émis par des clients en paquets IPv4 pour des serveurs.
Le principe de fonctionnement de NAT64 pour passer d'une version à l'autre du protocole IP est le même que pour passer d'un adressage privé à une adressage public, avec également les mêmes limitations, par exemple, si les paquets transportent des adresses sous forme de données. Par contre, ce mécanisme offre une certaine transparence au niveau des clients IPv6.
Conclusion
Etat de la standardisation à l'IETF
Working Group ngtrans : approche "boite à outils"
D'une façon générale, l'une des clés de l'adoption d'une nouvelle technologie repose sur la facilité avec laquelle il est possible d'abandonner l'ancienne au profit de la nouvelle. Aussi, le groupe de travail IETF ngtrans a été créé, dès l'origine et en parallèle du groupe de travail IETF ipng, pour traiter des aspects liés à la transition des réseaux et applications d'IPv4 vers IPv6. La principale contrainte à respecter étant qu'il ne doit pas y avoir de jour J pour le basculement de l'ensemble de l'Internet vers IPv6 (à l'image du passage à l'an 2000 par exemple), et qu'au contraire il doit être possible de passer graduellement et progressivement d'IPv4 à IPv6, à tout moment et indépendamment de l'infrastructure réseau considérée.
Ngtrans a donné le jour à nombre de mécanismes de transition, permettant chacun de résoudre une problématique de transition particulière (interconnexion de réseaux IPv6 isolés, communication entre applications IPv4 et IPv6, transport de flux IPv6 dans les réseaux IPv4, etc...). Finalement une boîte à outils très complète a été définie, apportant des solutions a un vaste ensemble problèmes liés à la transition, soit localement à un terminal, soit plus globalement à l'échelle d'un réseau ou même de l'Internet dans son ensemble.
Cette mission remplie pour sa majeure partie, le groupe de travail ngtrans a finalement été clos pour laisser la place à IPv6ops traitant plus globalement de l'ensemble des aspects opérationnels liés au déploiement d'IPv6. En outre, il a souvent été reproché à ngtrans d'avoir spécifié une large boîte à outils sans en avoir décrit le mode d'emploi, et sans discernement des cas de transition concrets ou théoriques. Ainsi l'adoption d'IPv6 aurait été rendue en apparence plus complexe, contrairement au but initialement recherché.
Working Group IPv6ops : de la transition à la coexistence (déploiement opérationnel)
Au-delà de la critique faite à ngtrans et qui est encore aujourd'hui matière à débats, le groupe de travail IPv6ops (IPv6 operations), créé en septembre 2002, s'inscrit dans une dynamique nouvelle visant à traiter de l'ensemble des problèmes opérationnels liés au déploiement d'IPv6. Fort du principe selon lequel le passage d'IPv4 à IPv6 ne peut se réaliser que progressivement selon les infrastructures concernées et graduellement dans le temps, et sur la base du constat de l'absence d'imminence véritable d'une pénurie d'adresses IPv4, la transition IPv4/IPv6 devient essentiellement une question de coexistence des deux versions du protocole IP. Entre autres, l'approche en scénarios d'intégration d'IPv6 à l'existant, initialisée par ngtrans, est reprise par IPv6ops et se trouve déclinée selon quatre grandes familles : les réseaux de "mobiles" (UMTS, 3G), les réseaux d'ISP, les réseaux d'entreprise et les réseaux SOHO/domestiques. Cette approche en scénarios, a été achevée fin 2004, selon les objectifs fixés actuellement par le groupe IPv6ops.
Utilisation des mécanismes d'intégration d'IPv6
Les principaux mécanismes d'intégration d'IPv6 -aussi dénommés mécanismes de transition- spécifiés par l'IETF sont regroupés dans le tableau ci-dessous. Leur utilisation possible dans différents segments du réseau est mentionnée. La difficulté est de pouvoir distinguer les différents usages de ces mécanismes, par exemple la fonction de serveur du tunnel broker, installée dans le réseau de l'ISP, et la fonction client de ce service installée chez un usager -entreprise ou particulier. Cette distinction est détaillée dans le paragraphe où le mécanisme est décrit (cf. tableau Mécanismes de transition).
| Mécanismes de transition | Coeur de réseau | ISP | Entreprises | Particuliers |
|---|---|---|---|---|
| Double pile | X | X | X | X |
| 6PE (MPLS) | X | X | X | |
| 6to4 | X | X | X | |
| Tunnel Broker | X | X | X | |
| Tunnels configurés | ? | X | X | X |
| TSP | X | X | X | |
| ISATAP | X | |||
| TEREDO | X | X | X | |
| Relais applicatifs | X | X | X | |
| NAT-PT | X | X | X | |
| DSTM | X | X | X | |
| SOCKS | X | X | ||
| VPN | X | X | X | |
| L2TP | X | X | X |
