Difference between revisions of "MOOC:Compagnon Act41-s7"

From Livre IPv6

(New page: 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 ...)
 
(→‎Pour aller plus loin)
 
(490 intermediate revisions by 7 users not shown)
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é-->
+
> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Document_Compagnon |Doc compagnon]] > [[MOOC:Compagnon_Act41-s7 |Activité 41]]
−
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 ===
+
----
 +
-->
 +
__NOTOC__
  
−
<!-- 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.  
+
=<div id="Deployer">Activité 41 : Communiquer en double pile </div>=
 +
<!-- ----------------------------------------- -->
 +
<!-- {{Approfondissement}} -->
 +
== Introduction==
  
−
Moving to IPv6
+
Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :
−
https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf
+
* déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;
 +
* rendre le déploiement complètement transparent à l'utilisateur ;
 +
* viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;
 +
* maintenir la connectivité avec l'Internet IPv4.
  
−
<!-- intégration vs transition -->
+
Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons.
−
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.
+
La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.
−
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 ===
+
== Technique de la double pile ==
 +
Le mécanisme de double pile IP (''Dual Stack''), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6.  L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe.
  
−
<!-- cas de la transition -->
+
<center>
−
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:
+
[[image:41-fig1-2.png|280px|thumb|center|Figure 1 : Architecture d'un nœud en double pile.]]
−
* Un hôte IPv4 qui communique avec un hôte IPv4 via un réseau IPv4.
+
</center>
−
* 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é.
+
Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.
−
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.  
+
La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6.
 +
Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.
  
−
<!-- Double pile -->
+
== Étude et préparation du déploiement d'IPv6 ==
 +
En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.
  
−
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é.
+
* Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur.  
 +
* Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.
  
−
<!-- Tunnel -->
+
=== <div id="deploy method"> Méthode </div>===
  
−
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.  
+
L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.
  
−
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.  
+
L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas "IPv6 compatible", il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour.  
  
−
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 applications "métiers", développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note<ref>Botzmeyer, S. (2006). [http://www.bortzmeyer.org/network-high-level-programming.html Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?]</ref> S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements "double pile". Ce dernier point est développé dans la section "Déploiement au niveau des services" de cette activité.
  
−
<!-- Traduction -->
+
<!-- Une section sécurité avec les RFC:  4864 6586 7368  -->
 +
Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (''Network Based Intrusion Detection System''), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (''Access Control List'') des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6.
 +
Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds.
 +
Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des ''back doors'' qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).
  
−
Les deux derniers cas traitent la situation ou les extrémités sont incompatibles.  
+
Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 "lien-local" qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (''rogues RA'') [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (''Man in the Middle''). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard'' (''IPv6 Router Advertisement Guard'') à mettre en œuvre au niveau des commutateurs.
−
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.
+
En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe "problèmes liés à la double pile" de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.
  
−
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'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (''Small Office / Home Office'') est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de ''greynets'' pour IPv4 et 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.  
+
  
 +
Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document <ref>Matthews, P. Kuarsingh, V. (2015). Internet-Draft. [http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-07 Some Design Choices for IPv6 Networks]</ref>  (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage 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).
+
La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.
  
−
* 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 :
+
Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article<ref> Cisco. (2011). White paper. [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/whitepaper_c11-637821_v5.pdf Solution Overview—Getting Started with IPv6]</ref> qui rapporte l'expérience de la migration en IPv6 d'un industriel.
−
** 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.
+
=== Vérification de la disponibilité d’IPv6 ===
 +
Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse "lien-local" (''link-local address'') a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).
  
−
=== Une étude des besoins et des choix à faire===
+
Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité<ref>RIPE documents. (2012). [https://www.ripe.net/publications/docs/ripe-554 Requirements for IPv6 in ICT Equipment]</ref>. Par exemple, c'est ce qu'a fait le département nord-américain de la défense<ref>
 +
Marsan, C.D. (2010).  Network World. [http://www.networkworld.com/article/2197203/lan-wan/u-s--military-strong-arming-it-industry-on-ipv6.html U.S. military strong-arming IT industry on IPv6]</ref>.
  
−
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.
+
MacOSX 10.9.2
 +
<pre>
 +
ifconfig en0
 +
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 +
    ether 14:10:9f:f0:60:46
 +
    inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4
 +
    inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255
 +
    nd6 options=1<PERFORMNUD>
 +
    media: autoselect
 +
    status: active
 +
</pre>
  
−
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.
+
Linux 2.6.32 :
 +
<pre>
 +
ifconfig eth0
 +
eth0      Link encap:Ethernet  HWaddr 60:eb:69:9b:87:97 
 +
          inet addr:195.154.87.139  Bcast:195.154.87.255  Mask:255.255.255.0
 +
          inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link
 +
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 +
          RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5
 +
          TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0
 +
          collisions:0 txqueuelen:1000
 +
          RX bytes:6583563265 (6.5 GB)  TX bytes:5944865545 (5.9 GB)
 +
          Memory:feae0000-feb00000
 +
</pre>
  
 +
Windows :
 +
<pre>
 +
c:\> ipconfig
 +
Windows IP Configuration
 +
Ethernet adapter Local Area Connection:
 +
Connection-specific DNS Suffix . :
 +
IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab
 +
Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54
 +
Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6
 +
IPv4 Address. . . . . . . . . . . : 157.60.14.11
 +
Subnet Mask . . . . . . . . . . . : 255.255.255.0
 +
Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6
 +
IPv4 Default Gateway  . . . . . . : 157.60.14.1
 +
Tunnel adapter Local Area Connection* 6:
 +
Connection-specific DNS Suffix . :
 +
IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11
 +
Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9
 +
Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1
 +
Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9
 +
fe80::5efe:131.107.25.2%9
 +
Tunnel adapter Local Area Connection* 7:
 +
Media State . . . . . . . . . . . : Media disconnected
 +
Connection-specific DNS Suffix . :
 +
</pre>
  
−
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.
+
=== Obtenir un préfixe IPv6  ===
 +
Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses "unicast locales" ULA (''Unique Local Address'') [RFC 4193] et les adresses "unicast globales" GUA (''Global Unicast Address'') [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :
 +
* '''Portée''' : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.
 +
* '''Routage''' : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.
 +
* '''Obtention''' :  Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation.  
  
−
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.
+
Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64.  
  
−
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.
+
Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.
  
−
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.
+
==== Préfixe ULA  ====
 +
 
 +
Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4.
 +
 
 +
Ce RFC propose, dans un espace réservé <tt>fc00::/7</tt>, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (''Global ID'', GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (''i.e.'' SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC.
 +
Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du [https://www.sixxs.net/tools/grh/ula/ SIXXS] qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre.
 +
 
 +
Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :
 +
* '''Manque d’adresses IP publiques'''. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.
 +
* '''Accroitre le niveau de sécurité'''. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.
 +
* '''Facilité de déploiement'''. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (''Network Prefix Translation'') [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA.
 +
 
 +
Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (''Provider Independent''). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI.  Cette idée peut avoir un sens tant que des mécanismes simples de  renumérotation du réseau ne seront pas effectifs [RFC 7010].  Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note<ref>Horley, E. (2013) [http://www.howfunky.com/2013/09/ipv6-unique-local-address-or-ula-what.html IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them]</ref>.
 +
 
 +
==== Préfixe GUA ====
 +
 
 +
Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA<ref>IANA. [http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml IPv6 Global Unicast Address Assignments]</ref> qui délègue aux RIR (''Regional Internet Registry'') l'allocation. Les RIR délèguent eux-mêmes aux NIR (''National Internet Registery'') puis aux LIR (''Local Internet Registery'') et/ou finalement aux FAI. En Europe, le RIR est le [https://www.ripe.net/ RIPE-NCC]. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.
 +
 
 +
Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (''Provider Assigned'' ou ''Provider Aggregatable'') ; si le site est multidomicilié, il faut un préfixe dit PI (''Provider Independent'').
 +
 
 +
Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants : 
 +
* allocation du préfixe à l’organisme ;
 +
* transport du trafic de l’utilisateur ;
 +
* annonce d'un préfixe BGP dans lequel est inclus celui du site.
 +
La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée.
 +
Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887].
 +
Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.
 +
 
 +
À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (''e.g.'' Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.
 +
 
 +
=== Définition du plan d’adressage de sous-réseau avec IPv6 ===
 +
 
 +
Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (''Subnet Identifier'') est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article<ref>Rooney, T. (2013). Deploy 360 Programme. Internet Society. [http://www.internetsociety.org/deploy360/resources/ipv6-address-planning-guidelines-for-ipv6-address-allocation/ IPv6 Address Planning: Guidelines for IPv6 address allocation]</ref>, l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :
 +
 
 +
* reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) <tt>10.0.0.0/8</tt> offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;
 +
 
 +
* numéroter de manière incrémentale les sous-réseaux (''e.g.'' 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;
 +
 
 +
* Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;
 +
 
 +
* séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs.  Ainsi, le préfixe :
 +
** <tt>2001:db8:1234::/52</tt> servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;
 +
** <tt>2001:db8:1234:8000::/52</tt> servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;
 +
** <tt>2001:db8:1234:E000::/52</tt> servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.
 +
 
 +
<center>
 +
{| border="1" cellpadding="5" cellspacing="0"
 +
|-
 +
! Communauté
 +
! 4 bits
 +
! 8 bits
 +
! 4 bits
 +
|-
 +
|Infrastructure
 +
|0
 +
|valeurs spécifiques
 +
|
 +
|-
 +
|Tests
 +
|1
 +
|valeurs spécifiques
 +
|
 +
|-
 +
|Tunnels
 +
|6
 +
|allocation de /60 aux utilisateurs
 +
|
 +
|-
 +
|Invités Wi-Fi
 +
|8
 +
|valeurs spécifiques
 +
|
 +
|-
 +
|Personnels
 +
|a
 +
|Entité
 +
|sous-réseaux
 +
|-
 +
|Étudiants
 +
|e
 +
|Entité
 +
|sous-réseaux
 +
|-
 +
|Autre
 +
|f
 +
|valeurs spécifiques
 +
|
 +
|}
 +
Tableau 1 :  Exemple de découpage du SID
 +
</center>
 +
 
 +
== Déploiement des équipements en double pile  ==
 +
 
 +
Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.
 +
 
 +
Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix :
 +
 
 +
eth0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
 +
inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255
 +
inet6 2001:db8: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
 +
 
 +
Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.
 +
 
 +
=== Configuration  d'adresses ===
 +
 
 +
La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes.
 +
 
 +
Avec la méthode SLAAC (''StateLess Address Auto Configuration'' ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :
 +
* absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (''Router Advertisment'') ;
 +
* absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association "adresse MAC - adresse IP". Le logiciel NDPMON (''Neighbor Discovery Protocol Monitor'') permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.
 +
 
 +
Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.
 +
 
 +
Lorsque DHCP est utilisé dans sa version "sans état", comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP "sans état".
 +
 
 +
Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (''e.g.'' /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.
 +
 
 +
=== Résolution d’adresses ===
 +
Les points importants relatifs au DNS (''Domain Naming System'') dans le déploiement d'IPv6 sont présentés dans le RFC 4472.
 +
Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (''resource record'') appelé AAAA a été défini pour les adresses IPv6 [RFC 3596].
 +
Les "résolveurs" DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le "résolveur" doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au "résolveur" s’il souhaite obtenir les entrées de type A ou AAAA.
 +
 
 +
=== Administration du réseau ===
 +
 
 +
Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.
 +
 
 +
L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.
 +
 
 +
La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (''Management Information Base'') diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 4001 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.
 +
 
 +
Les principales solutions de supervision (''e.g.'' Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.
 +
 
 +
 
 +
<!--
 +
Texte en commentaire pour une future extension (Ne Pas Supprimer)
 +
 
 +
L’administration d’un réseau peut se décomposer en trois principales tâches :
 +
* La supervision : permet de vérifier en temps reel le bon fonctionnement des machines et services déployés dans le réseau.
 +
* La métrologie : mesure la quantité et la nature du trafic qui transite sur le réseau. Elle permet de dimensionner ce dernier de manière adéquate et de suivre la consommation des utilisateurs.
 +
* La sécurité : assure l’intégrité et la confidentialité des données et se fait au travers de la sécurisation de l’accès aux équipements, la restriction de l’accès aux ressources (pare-feu) et le chiffrement des informations qui transitent sur le réseau.
 +
 
 +
Les pare-feu sont depuis longtemps capables d’appliquer leurs règles sur du trafic IPv6 et les mécanismes de chiffrement et certificats n’ont pas été impactés par IPv6. Les outils de metrologie sont généralement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.
 +
 
 +
La difficulté principale porte sur les outils de supervision. Le protocole Simple Network Management Protocol (SNMP) utilisé pour la supervision permet de collecter de diverses informations qui sont stockées sur les équipements réseaux dans des bases de données appelées MIBs (Management Information Base).
 +
 
 +
'''Evolution de SNMP vers IPv6 :''' Le protocole SNMP étant indépendant de la couche réseau, l’évolution vers IPv6 n’a pas posé de problème particulier car les paquets SNMP sont encapsulés dans UDP. De plus, il est possible de superviser des équipements IPv6 depuis un réseau IPv4 pour peu que ces derniers soient en double pile. Pour les réseaux qui sont exclusivement en IPv6, l'implémentation Open Source NET-SNMP intègre IPv6 depuis 2002 et peut utiliser IPv6 pour l’acheminement des données SNMP.
 +
 
 +
'''Evolution des MIBs vers IPv6 :''' A l’inverse, l’évolution des MIBs a été beaucoup plus laborieuse. En effet, l’encodage du champ IP a initialement été prévu sur 4 octets (RFC1902), ce qui ne permettait pas de représenter les adresses IPv6 sur 16 octets. La RFC2465 a par la suite spécifié le champ IP sur 16 octets. Cette modification a eu des répercussions sur de nombreuses autres RFC ainsi que sur les équipements et logiciels qui s’y conformaient. Afin de limiter l’impact sur les RFC existantes, il a été décidé de mettre en oeuvre des versions de la MIB indépendantes pour IPv4 et IPv6. Il a été par la suite reconnu que la maintenance de ces deux bases contenant des informations similaires aurait été trop lourde. Les deux MIBs ont donc été fusionnées dans une MIB unifiée (RFC2851). Dans cette MIB, l’adresse IP est de longueur variable et constitué de deux champs, un pour identifier le type d’adresse et un pour l’adresse en elle même.
 +
 
 +
Les principales solutions de supervision (e.g. Nagios ...) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée de la MIB et ses modifications.-->
 +
 
 +
==<div id="Service">Déploiement d'IPv6 pour les services</div>==
 +
 
 +
=== Les adresses IPv4 imbriquées dans une adresse IPv6 ===
 +
Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :
 +
* '''adresse IPv4 compatible''' (''IPv4-Compatible IPv6 address'' RFC 4213, RFC 3513)  <tt>'''::a.b.c.d/96'''</tt> ou <tt>'''::xxxx:xxxx/96'''</tt>. Ces adresses ont été dépréciées par le RFC 4291.
 +
* '''« IPv4 mappées »''' (''IPv4-mapped IPv6 address'' RFC 4291) <tt>'''::ffff:a.b.c.d/96'''</tt> ou <tt>'''::ffff:xxxx:xxxx/96'''</tt>. Ces adresses font référence à un nœud supportant uniquement IPv4.
 +
* '''« IPv4 translatées »''' (''IPv4-translated IPv6 address'' RFC 7915) <tt>'''::ffff:0:a.b.c.d/96'''</tt> ou <tt>'''::ffff:0:xxxx:xxxx/96'''</tt>. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole de traduction sans état entre IPv4 et IPv6 (IP/ICMP Translation Algorithm SIIT, RFC 7915). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot <tt>ffff</tt>.
 +
 
 +
Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (<tt>:ffff:</tt>), ce qui les rend neutres vis-à-vis du calcul du ''checksum'' intégrant le pseudo-entête (cf. séquence 3).
 +
 
 +
Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (''dual-stack''). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.
 +
 
 +
=== Au niveau des applications ===
 +
 
 +
La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (''IPv4 mapped IPv6 address'', « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est <tt>::ffff:<ipv4 address></tt>, comme par exemple <tt>::ffff:192.0.2.1</tt> (affichée <tt>::ffff:c000:201</tt>).  Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.
 +
 
 +
{{HorsTexte|tolérance de notation (rappel)|Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse <tt>2001:db8:900d:cafe::'''c0a8:a05'''</tt> peut être notée <tt>2001:db8:900d:cafe::'''192.168.10.5'''</tt> lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) <tt>2001:db8:900d:cafe::c0a8:a05</tt> dans le journal de bord (''log system'') de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.}}
 +
 
 +
<center>
 +
[[image:42-fig4-hd.png|400px|center|thumb|Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.]]
 +
</center>
 +
 
 +
Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées "source" et "destination" sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.
 +
 
 +
L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6.
 +
 
 +
>'''telnet rhadamanthe'''
 +
Trying 2001:db8: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:
 +
 
 +
Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications ''IPv6 compatible'' demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4<ref>Cisco. (2011); White paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]</ref>.
 +
Pour rendre une application "IPv6 compatible", il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction.
 +
 
 +
Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.
 +
 
 +
== Problèmes liés au déploiement d'IPv6 ==
 +
 
 +
L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.
 +
 
 +
Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article<ref>Bortzmeyer, S. (2011). [http://www.bortzmeyer.org/globes-oculaires-heureux.html Le bonheur des globes oculaires (IPv6 et IPv4)]</ref>. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au "résolveur" DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes.
 +
 
 +
Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.
 +
 
 +
<center>
 +
[[image:42-fig5.png|400px|center|thumb|Figure 5 : Établissement de connexion d'un client en double pile.]]
 +
</center>
 +
 
 +
Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article<ref name="huston"> Huston, G. (2009). The ISP Column. [http://www.potaroo.net/ispcol/2009-01/mtu6.html A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation]</ref>. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article<ref name="huston" />, le problème de MTU est détaillé et illustré par des captures de traces.
 +
 
 +
<center>
 +
[[image:42-fig6.png|400px|center|thumb|Figure 6 : Le problème de MTU.]]
 +
</center>
 +
 
 +
Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT ''Round Trip Time'') est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.
 +
 
 +
<center>
 +
[[Image:42-fig7.png|400px|center|thumb|Figure 7 : Illustration des délais importants en IPv6.]]
 +
</center>
 +
 
 +
Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.
 +
 
 +
Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée.
 +
Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article<ref>Huston, G. (2012). The ISP Column. [http://www.potaroo.net/ispcol/2012-05/notquite.html Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment]</ref>:
 +
* Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.
 +
* Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports "source" différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés.
 +
* Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.
 +
Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (''e.g.'' mail, VoIP, chat...).
 +
Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.
 +
 
 +
Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6.
 +
 
 +
Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (''MSS clamping''). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (''Maximum Segment Size'') de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.
 +
 
 +
Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.
 +
 
 +
==Conclusion==
 +
 
 +
Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.
 +
 
 +
Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.
 +
 
 +
==Références bibliographiques==
 +
<references />
 +
 
 +
== Pour aller plus loin ==
 +
 
 +
Scénarios de déploiement :
 +
* Guide de déploiement d'IPv6 par RIPE: [https://www.ripe.net/publications/ipv6-info-centre/deployment-planning Deploy IPv6 Now]
 +
* [http://www.hpc.mil/index.php/2013-08-29-16-03-23/networking-overview/2013-10-03-17-24-38/ipv6-frequently-asked-questions/deploying-ipv6-in-the-home-and-small-office-home-office-soho Deploying IPv6 in the Home and Small Office/Home Office (SOHO)]
 +
 
 +
Sécurité :
 +
* Bortzmeyer, S. (2013). [http://www.bortzmeyer.org/ipv6-securite.html Exposé sur la sécurité d'IPv6 à l'ESGI]
 +
* Cisco White paper (2011).  [http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-678658.html IPv6 Security Brief]
 +
 
 +
Pour développer des applications compatibles avec IPv6 :
 +
* [https://www.arin.net/knowledge/preparing_apps_for_v6.pdf Livre blanc ARIN]
 +
* Cisco. White Paper. [http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/network-registrar/white_paper_c11-687444.html IPv6 and Applications]
 +
* Bortzmeyer, S. (2013) [http://www.bortzmeyer.org/bindv6only.html Lier une prise à IPv6 seulement ou bien aux deux familles, v4 et v6 ?]
 +
 
 +
 
 +
RFC et leur analyse par S. Bortzmeyer :
 +
* RFC 1918 Address Allocation for Private Internets
 +
* RFC 3587 IPv6 Global Unicast Address Format
 +
* RFC 3596 DNS Extensions to Support IP Version 6
 +
* RFC 4001 Textual Conventions for Internet Network Addresses [http://www.bortzmeyer.org/4001.html Analyse]
 +
* RFC 4038 Application Aspects of IPv6 Transition
 +
* RFC 4057 IPv6 Enterprise Network Scenarios
 +
* RFC 4193 Unique Local IPv6 Unicast Addresses [http://www.bortzmeyer.org/4193.html Analyse]
 +
* RFC 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers [http://www.bortzmeyer.org/4213.html Analyse]
 +
* RFC 4459 MTU and Fragmentation Issues with In-the-Network Tunneling [http://www.bortzmeyer.org/4459.html Analyse]
 +
* RFC 4472 Operational Considerations and Issues with IPv6 DNS [http://www.bortzmeyer.org/4472.html Analyse]
 +
* RFC 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues
 +
* RFC 4821 Packetization Layer Path MTU Discovery [http://www.bortzmeyer.org/4821.html Analyse]
 +
* RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]
 +
* RFC 4862 IPv6 Stateless Address Autoconfiguration [http://www.bortzmeyer.org/4862.html Analyse]
 +
* RFC 5211 An Internet Transition Plan [http://www.bortzmeyer.org/5211.html Analyse]
 +
* RFC 5375 IPv6 Unicast Address Assignment Considerations [http://www.bortzmeyer.org/5375.html Analyse]
 +
* RFC 5887 Renumbering Still Needs Work  [http://www.bortzmeyer.org/5887.html Analyse]
 +
* RFC 5902 IAB thoughts on IPv6 Network Address Translation  [http://www.bortzmeyer.org/5902.html Analyse]
 +
* RFC 6018: IPv4 and IPv6 Greynets [http://www.bortzmeyer.org/6018.html Analyse]
 +
* RFC 6092 Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service [http://www.bortzmeyer.org/6092.html Analyse]
 +
* RFC 6104 Rogue IPv6 Router Advertisement Problem Statement [http://www.bortzmeyer.org/6104.html Analyse]
 +
* RFC 6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links [http://www.bortzmeyer.org/6164.html Analyse]
 +
* RFC 6177 IPv6 Address Assignment to End Sites
 +
* RFC 6180  Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment [http://www.bortzmeyer.org/6180.html Analyse]
 +
* RFC 6296 IPv6-to-IPv6 Network Prefix Translation
 +
* RFC 6724 Default Address Selection for Internet Protocol version 6 (IPv6) [http://www.bortzmeyer.org/6724.html Analyse]
 +
* RFC 7010 IPv6 Site Renumbering Gap Analysis [http://www.bortzmeyer.org/7010.html Analyse]
 +
* RFC 7084 Basic Requirements for IPv6 Customer Edge Routers [http://www.bortzmeyer.org/7084.html Analyse]
 +
* RFC 7113 Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) [http://www.bortzmeyer.org/7113.html Analyse]
 +
* RFC 7123 Security Implications of IPv6 on IPv4 Networks [http://www.bortzmeyer.org/7123.html Analyse]
 +
* RFC 7381 Enterprise IPv6 Deployment Guidelines [http://www.bortzmeyer.org/7381.html Analyse]
 +
* RFC 7707 Network Reconnaissance in IPv6 Networks [http://www.bortzmeyer.org/7707.html Analyse]
 +
* RFC 7915 IP/ICMP Translation Algorithm  [https://www.bortzmeyer.org/7915.html Analyse]
 +
* RFC 8106 IPv6 Router Advertisement Options for DNS Configuration [http://www.bortzmeyer.org/8106.html Analyse]
 +
* RFC 8305 Happy Eyeballs Version 2: Better Connectivity Using Concurrency [http://www.bortzmeyer.org/8305.html Analyse]
 +
* RFC 8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [http://www.bortzmeyer.org/8415.html Analyse]
 +
* RFC 8899 : Packetization Layer Path MTU Discovery for Datagram Transports [https://www.bortzmeyer.org/8899.html Analyse]
 +
* RFC 8981 Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
 +
[http://www.bortzmeyer.org/8981.html Analyse]
 +
 
 +
Présentations sur le déploiement d'IPv6 :
 +
* Scott Hogg (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/ANOTR5-SuccessfullyDeployIPv6.pdf Successfully Deploying IPv6]
 +
* Leslie Nobile, Mark Kosters. (2015) Keynote in Nanog. [https://www.nanog.org/sites/default/files/moving-to-ipv6_Nobile_Kosters.v2.pdf Moving to IPv6]
 +
* Huston, G (2010) [http://www.potaroo.net/presentations/2010-10-19-ipv6-transition.pdf An  Economic Perspective on the Transition to  IPv6]
 +
* Cisco (2005) [http://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/ent_ipv6_dep.pdf Enterprise IPv6 Deployment]

Latest revision as of 09:17, 10 January 2023


Activité 41 : Communiquer en double pile

Introduction

Une organisation qui a une infrastructure de communication reposant sur le protocole IPv4 rencontre des difficultés pour faire croître son réseau de manière simple. Elle décide de passer à IPv6 avec, comme cahier des charges :

  • déployer IPv6 sans casser ou perturber ce qui fonctionne en IPv4 ;
  • rendre le déploiement complètement transparent à l'utilisateur ;
  • viser des améliorations en terme de simplicité de gestion et de performance du réseau ou, au pire, que cette dernière soit équivalente à celle obtenue en IPv4 ;
  • maintenir la connectivité avec l'Internet IPv4.

Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premiers mécanismes de coexistence, et le plus recommandé. En effet, il évite les problèmes liés à l'utilisation des tunnels. C'est la technique de transition originellement envisagée comme nous le rappellerons. La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, l'adressage et la configuration à mettre en place sont étudiés. Ensuite, les points propres à chacune des principales applications réseaux (DHCP, DNS, pare-feu, supervision) à prendre en compte lors du passage en IPv6 sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.

Technique de la double pile

Le mécanisme de double pile IP (Dual Stack), spécifié par le RFC 4213, consiste à doter un équipement du réseau de la pile protocolaire IPv6, en plus de celle d'IPv4, et d'affecter une adresse IPv4 et IPv6 à chaque interface réseau. La configuration des équipements réseaux en double pile exige clairement un double travail de configuration à la fois en IPv4 et en IPv6. L’utilisation parallèle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux nœuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi, les nœuds en double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe.

Figure 1 : Architecture d'un nœud en double pile.

Dans le cas d'un routeur, il y a une table de routage pour chaque version du protocole. Le routeur est ainsi capable de relayer à la fois les paquets IPv6 et IPv4. De cette façon, IPv4 et IPv6 coexistent sur la même infrastructure. Autrement dit, IPv6 n'a pas besoin d'une infrastructure dédiée.

La technique de la double pile résout le problème d'interopérabilité lié à 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é. Mais, pour que cette technique soit pleinement utilisable, cela implique que les routeurs entre les 2 correspondants soient aussi configurés pour router les deux types de paquets et que des applications soient capables de traiter des communications avec des adresses IPv6. Avec cette technique, il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.

Étude et préparation du déploiement d'IPv6

En fonction du contexte de déploiement, les enjeux et contraintes ne seront pas les mêmes. Il faut distinguer le réseau résidentiel de l'utilisateur domestique qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.

  • Au sein d’un réseau résidentiel, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de noms et configuration d’adresses, ainsi qu’aux performances perçues par l’utilisateur.
  • Dans le cas d’un réseau d’entreprise, il faudra ajouter les problématiques d’obtention du préfixe IPv6, la définition du plan d’adressage, et la configuration du routage IPv6, en plus de celui d'IPv4. Comme les réseaux d’entreprises hébergent de nombreux services tels que le DNS ou le web, il faut aussi prendre en compte la mise à niveau de ces services.

Méthode

L'intégration d'IPv6 dans un réseau d'entreprise demande de la méthode, comme le montre le RFC 7381. Une phase d'étude et d'analyse est un préalable indispensable pour identifier les points bloquant à l'intégration d'IPv6 dans le contexte professionnel.

L'intégration d'IPv6 commence par la désignation d'une personne en charge de suivre et coordonner les actions liées à l'intégration d'IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer ceux qui supportent IPv6. Cet inventaire va être un élément clef pour orienter le choix des techniques de transition. Par exemple, si de nombreux segments du réseau ne sont pas "IPv6 compatible", il n'est pas question de tout jeter et de racheter, mais il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut également faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour.

Les applications "métiers", développées en interne, doivent être modifiées le plus tôt possible afin de les rendre capables de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions d'IP. Dans une note[1] S. Bortzmeyer propose d'utiliser des bibliothèques de langage de plus haut niveau d'abstraction. Ainsi, les détails de la communication ne remontent pas jusqu'au développeur d'application. Le RFC 6724 indique comment sélectionner les adresses sources. Le RFC 8305 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiements "double pile". Ce dernier point est développé dans la section "Déploiement au niveau des services" de cette activité.

Un point, dans cette phase d'étude, à ne pas négliger concerne la sécurité. L'essentiel des failles de sécurité d'un réseau IPv6 est commune avec celles d'un réseau IPv4. Celles qui sont spécifiques à IPv6 peuvent être dues au manque de support d'IPv6 par les fournisseurs d'équipement de sécurité tels que les NIDS (Network Based Intrusion Detection System), pare-feu, outils de monitoring... Ces dispositifs doivent supporter IPv6 aussi bien qu'IPv4 mais ce n'est pas toujours le cas. La faible maturité du code source est également une faille relevée par le RFC 7381. Les problèmes de sécurité spécifiques à IPv6 peuvent aussi être dus à la configuration. Les pare-feu et ACL (Access Control List) des logiciels peuvent avoir des règles strictes pour IPv4 mais beaucoup moins pour IPv6. Étant donné que leur réseau est beaucoup moins sollicité en IPv6, des administrateurs sont tentés de ne pas fournir autant d'efforts que pour la sécurisation d'IPv4. L'utilisation d'adresses protégeant la vie privée des utilisateurs [RFC 8981] complique également la tâche des administrateurs. Elles sont un frein pour une identification rapide des nœuds. Les mécanismes de transition reposant sur des tunnels encapsulant IPv6 sur les réseaux IPv4 apportent également des failles inhérentes à l'utilisation des tunnels [RFC 7123]. S'ils sont mal déployés, ils peuvent créer des back doors qui offrent un moyen de passer outre les sécurités de l'entreprise (en particulier avec Teredo et 6to4 [RFC 6180]).

Même si IPv6 n'est pas déployé dans un réseau, il faut malgré tout prendre en compte IPv6 pour la sécurisation. En effet, la plupart des hôtes sont désormais en double pile. Ils ont une adresse IPv6 "lien-local" qui peut être utilisée pour la communication entre les équipements d'un même lien. Ce trafic peut être filtré sur les équipements de niveau 2 s'ils le permettent. La double pile rend le nœud sensible aux attaques par fausses annonces de routeurs (rogues RA) [RFC 6104]. Ces annonces configurent chez les hôtes une fausse connectivité IPv6. Les hôtes enverront le trafic au routeur par défaut, lequel pourra fournir une connectivité IPv6 aux utilisateurs via des tunnels et mettre en œuvre des attaques de type MitM (Man in the Middle). Le RFC 7113 propose une méthode d'analyse de l'en-tête IPv6 appelée 'RA-Guard (IPv6 Router Advertisement Guard) à mettre en œuvre au niveau des commutateurs. En dépit du fait que les annonces de routeurs illégitimes soient la plupart du temps le fait d'erreurs de configuration de machines hôtes qui émettent des RA, il ne faut néanmoins pas les négliger car une connectivité IPv6 non fonctionnelle ou de mauvaise qualité va affecter la qualité de service perçue par l'utilisateur (voir le paragraphe "problèmes liés à la double pile" de cette activité). Notons que la sécurisation des mécanismes d'autoconfiguration n'est pas un problème spécifique à IPv6. En IPv4, des serveurs DHCP mal intentionnés (idem pour DHCPv6) peuvent également envoyer des informations erronées suite à une requête DHCP. Aussi bien les RA que le DCHP peuvent être sécurisés via l'authentification des messages, mais ces solutions sont très peu déployées en pratique.

L'impact des différences entre les deux versions d'IP est souvent mal évalué. Par exemple, l'utilisation d'un préfixe IPv6 GUA pour les hôtes et l'absence de NAT, notamment dans les routeurs SOHO (Small Office / Home Office) est perçue comme une faille de sécurité. En plus des règles de filtrage nécessaires à la sécurisation, les RFC 6092 et RFC 7084 imposent que les routeurs SOHO filtrent par défaut les connexions venant de l'extérieur au réseau. De cette manière, l'absence de NAT dans le cadre d'IPv6 n'ouvrira pas plus de faille de sécurité que sur les routeurs SOHO en IPv4. La sécurité de IPv6 peut aussi être surévaluée, comme dans les attaques par balayage de l'espace d'adressage. Malgré la taille gigantesque de l'espace d'adressage en IPv6, le RFC 7707 montre que IPv6 est malgré tout sensible aux attaques par balayage, et qu'il faut s'en protéger. À cet effet, le RFC 6018 propose l'utilisation de greynets pour IPv4 et IPv6.

Ensuite, vient la problématique du routage interne. Les principaux protocoles de routage intègrent depuis longtemps IPv6. OSPFv3 supporte IPv4 et IPv6 mais diffère de OSPFv2 sur certains points. Notons qu'il est possible d'utiliser des protocoles de routage différents pour les trafics IPV4 et IPV6. Le document [2] (en cours d'étude au moment de la rédaction de ce document) détaille les choix de conception spécifiques au routage IPv6.

La phase de préparation inclut également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.

Il apparaît donc clairement que l'intégration d'IPv6 nécessite d'impliquer de nombreux corps de métiers. Les formations adéquates doivent donc être proposées au personnel de l'entreprise. Cela inclut aussi bien les administrateurs système et réseau, ceux en charge du routage, de l'infrastructure, les développeurs, que le personnel des centres d'appel du support technique. À titre d'exemple, citons l'article[3] qui rapporte l'expérience de la migration en IPv6 d'un industriel.

Vérification de la disponibilité d’IPv6

Le protocole IPv6 et ses protocoles associés sont pris en charge par les systèmes d'exploitation depuis plus de 10 ans. Il en découle qu'une grande majorité des nœuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un nœud, même en l'absence d'un routeur IPv6 sur le lien de ce nœud, l'interface se configure automatiquement avec une adresse IPv6. Les exemples ci-dessous montrent que c'est le cas pour les OS les plus courants. Pour chacun des OS, une adresse "lien-local" (link-local address) a été allouée [voir la séquence 1]. Elle est utilisée pour les communications locales uniquement, comme par exemple le mécanisme de découverte de voisins [RFC 4861]. Elle n'est pas routable ni, par conséquent, utilisable pour une communication indirecte (passant par un routeur).

Pour que cette vérification soit une formalité, il est nécessaire, bien en amont de l'intégration d'IPv6, d'exiger, dans les achats de matériels et logiciels, la disponibilité d'IPv6 ou la compatibilité[4]. Par exemple, c'est ce qu'a fait le département nord-américain de la défense[5].

MacOSX 10.9.2 

ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 14:10:9f:f0:60:46
    inet6 fe80::1610:9fff:fef0:6046%en0 prefixlen 64 scopeid 0x4
    inet 192.168.1.143 netmask 0xffffff00 broadcast 192.168.1.255
    nd6 options=1<PERFORMNUD>
    media: autoselect
    status: active

Linux 2.6.32 : 

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 60:eb:69:9b:87:97  
          inet addr:195.154.87.139  Bcast:195.154.87.255  Mask:255.255.255.0
          inet6 addr: fe80::62eb:69ff:fe9b:8797/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:75115704 errors:5 dropped:0 overruns:0 frame:5
          TX packets:17934141 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6583563265 (6.5 GB)  TX bytes:5944865545 (5.9 GB)
          Memory:feae0000-feb00000

Windows : 

c:\> ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : 
IPv6 Address. . . . . . . . . . . : 2001:db8:21da:7:713e:a426:d167:37ab
Temporary IPv6 Address. . . . . . : 2001:db8:21da:7:5099:ba54:9881:2e54
Link-local IPv6 Address . . . . . : fe80::713e:a426:d167:37ab%6
IPv4 Address. . . . . . . . . . . : 157.60.14.11
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : fe80::20a:42ff:feb0:5400%6
IPv4 Default Gateway  . . . . . . : 157.60.14.1
Tunnel adapter Local Area Connection* 6:
Connection-specific DNS Suffix . :
IPv6 Address. . . . . . . . . . . : 2001:db8:908c:f70f:0:5efe:157.60.14.11
Link-local IPv6 Address . . . . . : fe80::5efe:157.60.14.11%9
Site-local IPv6 Address . . . . . : fec0::6ab4:0:5efe:157.60.14.11%1
Default Gateway . . . . . . . . . : fe80::5efe:131.107.25.1%9
fe80::5efe:131.107.25.2%9
Tunnel adapter Local Area Connection* 7:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Obtenir un préfixe IPv6

Pour une communication indirecte, il faut compléter la configuration avec une adresse IPv6 unicast qui soit routable. Il existe deux types d’adresses qui répondent à ce critère : les adresses "unicast locales" ULA (Unique Local Address) [RFC 4193] et les adresses "unicast globales" GUA (Global Unicast Address) [RFC 3587]. Pour rappel, les différences majeures entre ces deux types d’adresses sont les suivantes :

  • Portée : les adresses GUA sont des adresses publiques tandis que les adresses ULA sont des adresses privées. Les adresses privées ne peuvent être utilisées que pour des communications dans un intranet.
  • Routage : Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA, routables uniquement sur une topologie privative, doivent être filtrées par les routeurs en bordure de site. Les préfixes ULA ne doivent pas être annoncés ni acceptés par les routeurs inter-AS.
  • Obtention : Un préfixe ULA est généré de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu auprès d'un opérateur tiers qui gère un registre d'allocation.

Mais quelle type d'adresse routable utiliser dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés dans le RFC 5375, qui développe les considérations à prendre en compte pour la mise en place de l'adressage unicast d'IPv6. Ainsi, il recommande un préfixe de lien de /64 pour, notamment, le bon fonctionnement de la procédure d'autoconfiguration d'adresses. Le RFC 6177 discute du préfixe à allouer à un site d'extrémité. Ce préfixe peut varier de /48 à /64. Il est recommandé de donner des possibilités de sous-réseaux à l'intérieur du site, ce que ne permet pas une allocation de préfixe à /64.

Il faut tout d’abord noter que le préfixe alloué à un site est souvent très confortable au niveau du plan d'adressage. Il n'y a rien de commun avec ce qui est connu en IPv4. Lorsqu’un site obtient un préfixe /48, il peut avoir 2^16 sous-réseaux différents et 2^64 nœuds dans chacun de ces sous-réseaux. Même l'allocation d'un préfixe /64, qui reste problématique pour déployer des sous-réseaux, donne un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de nœuds qu’il peut y avoir dans un réseau.

Préfixe ULA

Le préfixe ULA [RFC 4193] est l'équivalent, dans son usage, aux préfixes privés d'IPv4 [RFC 1918], mais quasi unique et sans registre central. Ce dernier point rend le préfixe ULA non agrégeable, et donc les adresses ULA non routables sur l’internet. La caractéristique d'unicité du préfixe ULA supprime le risque de conflit entre les 2 plans d'adressage lorsque 2 sites privés fusionnent, ce qui est loin d'être le cas en IPv4.

Ce RFC propose, dans un espace réservé fc00::/7, de constituer, selon un algorithme, des adresses quasi uniques. Le format des adresses de type ULA est présenté dans l'activité 13. Il est rappelé que le format d'adresse ULA se compose d'un préfixe de 48 bits dont 40 bits (Global ID, GID) pour identifier le site. Les 40 bits du GID sont générés en utilisant une fonction de hachage (i.e. SHA-1) de l'heure et de l'adresse MAC de la machine, exécutant l’algorithme détaillé dans le RFC. Outre le script, sous licence libre GPL et développé par Hartmut Goebel, indiqué dans l'activité 13, il existe des sites pour générer automatiquement un préfixe ULA comme http://unique-local-ipv6.com/ ou http://www.kame.net/~suz/gen-ula.html, ou bien encore celui du SIXXS qui, en plus de fournir un préfixe ULA, l'enregistre dans un registre.

Notons que les raisons conduisant à l'utilisation des adresses privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons :

  • Manque d’adresses IP publiques. Dans l’internet IPv4, la motivation principale pour l’utilisation des adresses privées est que l’espace d’adressage publique n’est pas suffisant pour l’ensemble des machines. Dans le cas d’IPv6, cette motivation n’a clairement plus lieu d’être.
  • Accroitre le niveau de sécurité. L’utilisation des adresses privées dans IPv4 induit que les machines situées derrière un NAT sont plus difficilement accessibles de l’extérieur par un unique effet de bord. Cela rend les machines derrière le NAT moins vulnérables aux attaques extérieures. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquants de l’internet et trouvent là une justification à l’utilisation d’adresses privées. On notera que cet argument est fallacieux car, avec un adressage privé, il faut malgré tout utiliser un pare-feu pour prévenir les attaques, ce qui montre que la sécurisation n'est pas une question de type d'adresse publique ou privée. Donc, une simple règle sur un pare-feu pour interdire l’ouverture de connexion depuis l’extérieur peut fournir le même niveau de sécurité qu’un NAT.
  • Facilité de déploiement. L'accès Internet, pour un site avec un adressage ULA, nécessite un NAT66 dénommé aussi NPTv6 (Network Prefix Translation) [RFC 6296] pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont certaines tares du NAT qui reviennent dans le réseau IPv6 [RFC 5902]. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas l'obtention d'un préfixe GUA (pour l'extérieur du NAT). Au final, un réseau basé sur les adresses ULA introduit un travail plus complexe et plus important qu’un équivalent GUA.

Aussi, les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (enseignement, bancs d'essais, déploiement de prototype) et les réseaux nécessitant un niveau de sécurité très élevé par un isolement complet, comme les réseaux tactiques ou d'hôpitaux. Le RFC 6296 propose une autre utilisation d'un plan d'adressage construit sur un préfixe ULA. Pour des sites de taille petite ou moyenne, un préfixe ULA couplé à un NAT66, offre une solution simple pour changer d'opérateur ou pour gérer la multi-domiciliation sans nécessiter un préfixe PI (Provider Independent). Ainsi, en cas de changement de fournisseur d'accès, la renumérotation n'impactera que le NAT. Les adresses ULA forment ainsi une sorte de substitut aux adresses PI. Cette idée peut avoir un sens tant que des mécanismes simples de renumérotation du réseau ne seront pas effectifs [RFC 7010]. Cette question de la renumérotation n'est pas une question simple {RFC 5887]. Dans tous les autres cas, les adresses GUA sont plus faciles à déployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note[6].

Préfixe GUA

Pour rappel, les préfixes GUA sont sous l'autorité de l’IANA[7] qui délègue aux RIR (Regional Internet Registry) l'allocation. Les RIR délèguent eux-mêmes aux NIR (National Internet Registery) puis aux LIR (Local Internet Registery) et/ou finalement aux FAI. En Europe, le RIR est le RIPE-NCC. Il délègue directement aux FAI/LIR sans passer par des NIR. Les LIR et certains FAI se voient déléguer des préfixes /32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des FAI. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des préfixes alloués par les LIR aux FAI.

Le préfixe GUA peut être alloué par un FAI, par un LIR ou par un RIR. Le choix s'effectue selon le type de préfixe à détenir. Si le préfixe est destiné à un site, on parlera d'un préfixe PA (Provider Assigned ou Provider Aggregatable) ; si le site est multidomicilié, il faut un préfixe dit PI (Provider Independent).

Le préfixe de type PA est attribué par le FAI/LIR. Il n'y a pas de formalités particulières à remplir. Le préfixe est alloué en même temps que la connectivité. Le préfixe est donc spécifique à un site et associe ce site à un opérateur. Ce dernier assure les services suivants :

  • allocation du préfixe à l’organisme ;
  • transport du trafic de l’utilisateur ;
  • annonce d'un préfixe BGP dans lequel est inclus celui du site.

La taille du préfixe alloué varie selon les opérateurs. Certains donneront un /52, voire un /60. Le préfixe alloué est au maximum /64. Si un site doit avoir un préfixe de moins de 48 bits, la demande doit être motivée. Si le FAI change, il faut rendre le préfixe et renuméroter le réseau du site, et cette action est pénible [RFC 5887]. Pour éviter ce désagrément, il est possible de demander un préfixe PI auprès d'un RIR. Ce type de préfixe est une nécessité pour les sites multidomiciliés ou pour les sites qui doivent changer de FAI sans changer d’adresses. La demande de préfixe doit être faite directement à RIPE-NCC qui attribue un préfixe /48 ou un préfixe de longueur inférieure si la demande est motivée. Il faut que l'organisation qui en fait la demande soit membre de RIPE ou que la demande soit parrainée par un FAI/LIR membre de RIPE. Il est ensuite nécessaire que les FAI annoncent et routent le préfixe PI.

À noter que si un FAI ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (e.g. Hurricane Electric) attribuent gratuitement un préfixe /48 lors de l’établissement d'un tunnel.

Définition du plan d’adressage de sous-réseau avec IPv6

Les préfixes alloués dans la majorité des cas laissent de nombreux bits pour gérer les liens à l'intérieur d'un site. Lorsque le préfixe alloué au site est un /48, le SID (Subnet Identifier) est codé sur 16 bits. Il est évident que la structuration du plan d'adressage est radicalement différente selon que l'on soit en IPv4 ou en IPv6. En IPv4, l'essentiel du travail sur l'adressage a pour but d'économiser les quelques adresses disponibles, pour pouvoir fonctionner malgré la pénurie. En IPv6, ce problème disparaît et la définition du plan d'adressage vise la facilité de son administration tout en rendant l'agrégation de routes efficace. La mise en œuvre des politiques de sécurités doit aussi être prise en compte dans la définition du plan d'adressage interne. Dans l'article[8], l'auteur montre comment ces critères doivent servir à guider la définition d'un plan d'adressage pour un site. Comme nous l'avons vu dans l'activité 16, il est possible de structurer le routage interne de plusieurs manières :

  • reproduire le schéma IPv4 déjà déployé. Ainsi, par exemple, le préfixe privé (RFC 1918) 10.0.0.0/8 offre 24 bits d'identification locale à l’administrateur pour la structuration des sous-réseaux. En pratique, sur cet exemple, les plus petits sous-réseaux ont rarement des préfixes supérieurs à /24, ce qui laisse 16 bits (24 - 8) pour la structuration. Dans ce cas, il est donc possible de reproduire le plan d’adressage privé IPv4 à l’aide des 16 bits du SID ;
  • numéroter de manière incrémentale les sous-réseaux (e.g. 0001,0002,0003…). Simple à mettre en œuvre, cette technique peut cependant conduire à un adressage plat et difficile à mémoriser. Elle peut également complexifier l’écriture des règles de filtrage ainsi que l’agrégation ;
  • Utiliser le numéro de VLAN, ce qui est tout à fait possible puisque le VLAN ID n’occupe que 12 bits. Cette méthode permet d’éviter de mémoriser plusieurs niveaux de numérotation ;
  • séparer les types de réseaux et utiliser les chiffres de gauche pour les désigner. D'autres niveaux de structuration peuvent être définis sur les bits restant. Cette technique permet de faciliter les règles de filtrage, tout en utilisant des règles appropriées à la gestion de ces sous-réseaux pour la partie de droite. À titre d'exemple, le tableau 1 contient le plan de numérotation d'une université localisée sur plusieurs sites prenant en compte les différentes communautés d'utilisateurs. Ainsi, le préfixe :
    • 2001:db8:1234::/52 servira pour la création de l'infrastructure, donc en particulier les adresses des interfaces des routeurs prises dans cet espace ;
    • 2001:db8:1234:8000::/52 servira pour le réseau Wi-Fi des invités ; la manière dont sont gérés les 12 bits restants du SID n'est pas spécifiée ;
    • 2001:db8:1234:E000::/52 servira pour le réseau des étudiants. L'entité représente la localisation géographique du campus. Dans chacun de ces campus, il sera possible d'avoir jusqu'à 16 sous-réseaux différents pour cette communauté.
Communauté 4 bits 8 bits 4 bits
Infrastructure 0 valeurs spécifiques
Tests 1 valeurs spécifiques
Tunnels 6 allocation de /60 aux utilisateurs
Invités Wi-Fi 8 valeurs spécifiques
Personnels a Entité sous-réseaux
Étudiants e Entité sous-réseaux
Autre f valeurs spécifiques

Tableau 1 : Exemple de découpage du SID

Déploiement des équipements en double pile

Les services indispensables au fonctionnement d'un réseau doivent être déployés et ceux existants doivent intégrer IPv6 ; par exemple, la configuration d’adresse (DHCP / SLAAC), le nommage (DNS) et l’administration de l’infrastructure (supervision, sécurité et métrologie). Cette section traite des problématiques liées à leur configuration.

Un hôte en double pile présente une interface réseau de la manière suivante dans un environnement Unix : 

eth0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.108.119.134 netmask 0xffffff00 broadcast 192.108.119.255
inet6 2001:db8: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

Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments IPv4 soient masqués par des tunnels dans lesquels IPv6 est encapsulé dans IPv4. Tous les équipementiers de cœur de réseau supportent ces mécanismes, ce qui permet rapidement d'acheminer du trafic IPv6 dans une infrastructure IPv4 existante. Lorsque le déploiement est partiel, une attention particulière doit être portée au protocole de routage utilisé, l'activation de fonctions permettant de gérer plusieurs topologies (v4 et v6) pouvant s'avérer nécessaire.

Configuration d'adresses

La configuration des interfaces réseaux en IPv6 peut s'effectuer selon plusieurs méthodes.

Avec la méthode SLAAC (StateLess Address Auto Configuration ) [RFC 4862], l’interface génère elle-même ses adresses à partir des informations émises par le routeur local. Si SLAAC est sans doute plus simple et plus rapide à déployer, elle peut présenter des inconvénients :

  • absence du DNS. SLAAC n'intègre pas de champ pour transmettre le serveur DNS local. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via le DHCP de l’interface IPv4, mais cela rend donc indispensable l’existence d’une telle interface. Toutefois, le RFC 8106 rend désormais possible l’ajout d’une option DNS dans les messages RA (Router Advertisment) ;
  • absence de contrôle sur les adresses. Il n'y a pas de moyen fiable d’enregistrer l’association "adresse MAC - adresse IP". Le logiciel NDPMON (Neighbor Discovery Protocol Monitor) permet cependant d'écouter le réseau en permanence et de mémoriser les correspondances entre les adresses IP et MAC.

Avec DHCPv6 [RFC 8415], le client obtient son adresse et ses informations auprès du serveur DHCP. Ce dernier peut donc contrôler les informations indiquées à chaque machine, contrôler les adresses attribuées et mémoriser ces dernières. Le serveur DHCP est aussi l'endroit logique où faire des mises à jour dynamiques du DNS pour refléter les changements d'adresses IP. Comme DHCP offre davantage de contrôle que SLAAC, DHCP est en général apprécié dans les réseaux d'organisations.

Lorsque DHCP est utilisé dans sa version "sans état", comme le permet le RFC 8415, il sert à distribuer uniquement des paramètres statiques, comme les adresses des serveurs de noms. Dans cette situation, la méthode SLAAC est utilisée pour allouer les adresses et le nœud doit récupérer les informations manquantes à sa configuration par le serveur DHCP "sans état".

Lors du déploiement de DHCPv6 en double pile, l’inconvénient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans le RFC 4477. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. Par exemple, des informations relatives à la pile IPv6 renseignées manuellement dans la configuration de l’OS (e.g. /etc/resolv.conf) peuvent être effacées par le client DHCPv4. Le client doit savoir s’il doit utiliser les informations les plus récentes ou fusionner ces informations selon des critères bien précis. Ce problème est encore plus prononcé si les réseaux IPv6 et IPv4 n’ont pas les mêmes administrateurs.

Résolution d’adresses

Les points importants relatifs au DNS (Domain Naming System) dans le déploiement d'IPv6 sont présentés dans le RFC 4472. Pour IPv6, le DNS est d'autant plus indispensable que les adresses sur 128 bits ne sont pas simples à lire ni à mémoriser. Le DNS est utilisé pour associer les noms avec les adresses IP. Un nouvel enregistrement (resource record) appelé AAAA a été défini pour les adresses IPv6 [RFC 3596]. Les "résolveurs" DNS (clients du DNS) doivent être capables d’interpréter les enregistrements A pour IPv4 et les enregistrements AAAA pour IPv6. Lorsque les deux types sont retournés par le serveur DNS, le "résolveur" doit trier l’ordre des enregistrements retournés de manière à favoriser IPv6. Par ailleurs, le client (de la couche application) doit pouvoir spécifier au "résolveur" s’il souhaite obtenir les entrées de type A ou AAAA.

Administration du réseau

Il est indispensable que IPv6 et IPv4 soient isofonctionnels. Pour ce faire, il faut maîtriser les outils d'administration réseau IPv6 et en particulier s'assurer du bon fonctionnement des services et équipements IPv6.

L’administration d’un réseau peut se décomposer en trois tâches : la supervision, la métrologie et la sécurité. Les pare-feux sont depuis longtemps capables d’appliquer leurs règles de filtrage au trafic IPv6. Il est à noter que les mécanismes de chiffrement et les certificats n’ont pas été impactés par IPv6. Les outils de métrologie sont généralement assez faciles à adapter à IPv6 puisqu’il y a peu de dépendance entre les logiciels.

La difficulté principale réside dans les outils de supervision. Le protocole de supervision SNMP sert à collecter dans des bases de données appelées MIB (Management Information Base) diverses informations qui sont stockées sur les équipements réseaux. Net-SNMP intègre IPv6 depuis 2002. Cette intégration était nécessaire pour interroger les nœuds uniquement IPv6. Cette intégration d'IPv6 n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interroger un équipement via SNMP depuis son interface IPv4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et le RFC 4001 prévoit que l'adresse IP soit de longueur variable et constituée de deux champs, un pour identifier le type d’adresse et un pour l’adresse elle-même.

Les principales solutions de supervision (e.g. Nagios) et équipementiers supportent désormais largement IPv6. Il faut malgré tout s’assurer que l’ensemble des outils utilisés dans le cadre de SNMP supportent la version unifiée et modifiée de la MIB.


Déploiement d'IPv6 pour les services

Les adresses IPv4 imbriquées dans une adresse IPv6

Les premières adresses IPv4 imbriquées dans une adresse IPv6 ont été décrites dès les premières spécifications des mécanismes d'interopérabilité, dont certains ont depuis été officiellement dépréciés. Parmi ces adresses historiques nous trouvons :

  • adresse IPv4 compatible (IPv4-Compatible IPv6 address RFC 4213, RFC 3513) ::a.b.c.d/96 ou ::xxxx:xxxx/96. Ces adresses ont été dépréciées par le RFC 4291.
  • « IPv4 mappées » (IPv4-mapped IPv6 address RFC 4291) ::ffff:a.b.c.d/96 ou ::ffff:xxxx:xxxx/96. Ces adresses font référence à un nœud supportant uniquement IPv4.
  • « IPv4 translatées » (IPv4-translated IPv6 address RFC 7915) ::ffff:0:a.b.c.d/96 ou ::ffff:0:xxxx:xxxx/96. Ces adresses référençaient dans l'espace v4 un nœud uniquement v6, dans le cadre du protocole de traduction sans état entre IPv4 et IPv6 (IP/ICMP Translation Algorithm SIIT, RFC 7915). Elles se distinguent des « IPv4 mappées » par un décalage à gauche de 16 bits du mot ffff.

Les préfixes de ces adresses sont composés de mots nuls ou tout à 1 (:ffff:), ce qui les rend neutres vis-à-vis du calcul du checksum intégrant le pseudo-entête (cf. séquence 3).

Les longs préfixes nuls de ces adresses les rendent difficilement routables sur le réseau. Ces adresses sont cependant adaptées pour les interfaces logiques internes aux machines double pile (dual-stack). Les adresses « IPv4 mappées » sont par exemple utilisées pour aiguiller les flux vers la pile IPv4, dans le cadre d'applicatifs conformes IPv6 hébergés sur des machines double pile.

Au niveau des applications

La version de protocole IP utilisée doit être transparente au niveau de l'application et cela ne doit rien changer. 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 (IPv4 mapped IPv6 address, « IPv4 mappées »). L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 4. Le format des adresses IPv4 imbriquées est ::ffff:<ipv4 address>, comme par exemple ::ffff:192.0.2.1 (affichée ::ffff:c000:201). Avec ce type d'adresse, l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6.

tolérance de notation (rappel)

Lorsque l'adresse IPv4 occupe la partie basse de l'adresse IPv6, les 32 bits de poids faible (bits 97 à 128), la notation décimale pointée traditionnelle d'IPv4 est tolérée. Ainsi, l'adresse 2001:db8:900d:cafe::c0a8:a05 peut être notée 2001:db8:900d:cafe::192.168.10.5 lors d'une saisie (configuration manuelle d'interface ou passage de paramètre en ligne de commande...). Cependant, elle sera affichée sous sa forme canonique (RFC 5952) 2001:db8:900d:cafe::c0a8:a05 dans le journal de bord (log system) de la machine. Dans ce cas, si la saisie peut nous sembler familière, la correspondance entre l'adresse IPv6 et l'adresse IPv4 embarquée est moins évidente à l'affichage.

Figure 4 : Adresse IPv4 imbriquée dans une adresse IPv6.

Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application utilise le format d'adresse d'IPv6, les adresses IPv4 imbriquées "source" et "destination" sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement, quand une application émet des paquets avec des adresses IPv4 imbriquées, ceux-ci sont aiguillés vers la pile IPv4.

L'exemple suivant illustre ce fonctionnement. Le client Telnet compilé en IPv6 et fonctionnant sur une machine double pile peut contacter les équipements IPv4 en utilisant leur adresse IPv4 mais, bien sûr, les équipements IPv6 avec leur adresse IPv6. 

>telnet rhadamanthe
Trying 2001:db8: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:

Nous venons de le voir : une application compatible IPv6 peut dialoguer indifféremment en IPv4 et en IPv6, alors qu'une application utilisant un format d'adresse IPv4 restera limitée à ce protocole. Ceci ramène au problème du développement du code lié à la communication des applications. Plus généralement, le développement d'applications IPv6 compatible demande de nouvelles méthodes et pratiques au niveau de la programmation du fait du changement de la longueur de l'adresse IP, de la suppression de la diffusion d'IPv4[9]. Pour rendre une application "IPv6 compatible", il faut qu'elle soit compilée ou recompilée avec l'interface de programmation (API) IPv6 ou, pour les applications écrites avec un langage de haut niveau d'abstraction, que la bibliothèque intègre IPv6. Ceci n'est bien sûr possible que sur les équipements pourvus d'un système ayant une pile IPv6, ce qui est aujourd'hui vrai dans la quasi-totalité des cas. Reste le problème des applications non recompilables (code source non disponible) : ce genre de situation est traité par la suite dans l'activité de traduction.

Devant le coût des développements, la problématique de la compatibilité des applications à IPv6 doit être traitée dès le début, dans la stratégie de migration vers IPv6.

Problèmes liés au déploiement d'IPv6

L’intégration d'IPv6 devrait être indolore. L'utilisateur ne devrait pas voir de différence lorsqu'il accède à un service en IPv6. Cependant, en l'absence d'un minimum de précaution, ce souhait peut ne pas être satisfait, et le déploiement d'IPv6 en double pile peut dégrader le fonctionnement des services. Nous allons voir quels sont les problèmes engendrés au niveau du service perçu et comment les prévenir.

Le premier problème porte sur la phase d’établissement de la connexion comme expliqué par cet article[10]. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme représenté sur la figure 5. L’application du client demande au "résolveur" DNS la liste des adresses IP pour joindre “monservice.org”, et ce dernier retourne une adresse IPv6 et une adresse IPv4. Conformément aux préconisations du RFC 6724, la connexion commence avec l’adresse IPv6. Si la connexion IPv6 échoue, une autre adresse, potentiellement en IPv4, est essayée. Si le service est accessible sur une des adresses retournées par le DNS, le client finira par établir une connexion au service. L’inconvénient de cette méthode est que les tentatives de connexion sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considérer qu’une connexion a échoué est de l’ordre de plusieurs dizaines de secondes.

Dans l'état actuel du déploiement d'IPv6, bien des sites ont une connexion IPv6 totalement ou partiellement inopérante. Si un serveur fonctionne en IPv4 et en IPv6, et que son client n'a qu'IPv4, il n'y aura pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins défaillante, il aura des temps de réponse très importants. Les utilisateurs percevront le service comme très dégradé. C’est la raison pour laquelle, encore aujourd’hui, il y a si peu de sites Internet accessibles en IPv6.

Figure 5 : Établissement de connexion d'un client en double pile.

Le second problème est relatif à la taille des paquets IPv6, comme montré dans cet article[11]. Une fois la connexion établie en IPv6, l’utilisateur peut rencontrer des problèmes pour les échanges avec le serveur. En effet, en raison de l'utilisation de tunnels, IPv6 présente un problème de MTU bien plus souvent que IPv4. Le lien « standard » sur Internet a une MTU de 1500 octets, héritée d'Ethernet. Si, de bout en bout, tous les liens ont cette MTU, la machine émettrice peut fabriquer des paquets de 1500 octets et ils arriveront intacts. Mais, s'il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire, comme la figure 6 le représente. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels ceux utilisés lors de l’établissement de la connexion, passent, mais les gros paquets, comme les transferts de fichiers avec HTTP, bloquent mystérieusement. Les paquets dépassant la MTU du chemin ne sont jamais remis à la destination. Si les messages ICMP avertissant de ce problème sont bloqués par un routeur sur le chemin, la source n'apprendra pas le problème et ne pourra donc pas s’adapter. La connexion va finalement se fermer pour cause d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et a fait l'objet du RFC 4459. Dans l'article[11], le problème de MTU est détaillé et illustré par des captures de traces.

Figure 6 : Le problème de MTU.

Le troisième problème porte sur la performance perçue pour un service reposant sur la connectivité IPv6. Celle-ci sera évaluée comme dégradée à l'image de l'interactivité. La connectivité IPv6 est souvent constituée de tunnels. Si les sorties des tunnels sont trop éloignées du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, vidéoconférence, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité de service chuter par rapport au réseau simple pile IPv4 et ce, même si la connectivité IPv6 est parfaitement fonctionnelle. Ce problème de délai important en IPv6 est illustré par la figure 7 dans laquelle le temps de réponse (noté RTT Round Trip Time) est plus long en IPv6 du fait d'un chemin plus long en terme de nœuds de commutation et en distance.

Figure 7 : Illustration des délais importants en IPv6.

Des solutions ont été proposées pour éviter que les utilisateurs désactivent IPv6 en réponse à la baisse de performance qu’ils observent. Il est ici intéressant de noter que les problèmes que nous venons de décrire trouvent leur origine dans l'utilisation d'IPv4 dans la connectivité IPv6. La bonne solution serait de généraliser IPv6 pour un usage sans IPv4. En attendant, les solutions proposées sont détaillées par la suite afin qu'IPv6 fonctionne aussi bien qu'IPv4.

Les problèmes qui apparaissent lors de la phase d’établissement de la connexion sont dus au fait que le client tente de se connecter séquentiellement aux différentes adresses du service. IPv6 étant testé en premier lieu, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. Le RFC 8305 propose d'essayer d'établir une connexion TCP à la fois en IPv4 et en IPv6 et de conserver la première connexion établie. Le RFC précise que les demandes de connexion doivent être émises de sorte que ce soit celle portée par IPv6 qui puisse être conservée. Les navigateurs Web ont pris en compte ces recommandations mais les mises en œuvre divergent comme le rapporte l'article[12]:

  • Le navigateur Safari conserve, dans une table, le délai moyen pour atteindre chaque adresse du serveur. L’adresse ayant le délai le plus court est utilisée en priorité, mais si elle ne répond pas avant le délai attendu, l’adresse suivante est essayée. La demande de connexion est émise en décalé sur les différentes adresses du serveur. La première connexion établie sera utilisée pour la suite des échanges. Cette solution peut cependant induire un délai non négligeable si le serveur comporte de nombreuses adresses et que seule la dernière (celle de plus long délai moyen) est accessible.
  • Le navigateur Chrome mesure les délais pour l’obtention des adresses IPv4 et IPv6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenue en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports "source" différents. Si aucun segment SYN + ACK n’est reçu après 250 ms, un dernier segment SYN est émis depuis un troisième port. Si aucun segment SYN + ACK n’est reçu après un total de 300 ms, le protocole suivant sera essayé. Dans le cas où un problème apparaît avec un seul des protocoles, le délai est donc au maximum allongé de 300 ms. Si un problème apparaît avec les deux protocoles, c’est la méthode par défaut de l’OS qui sera utilisée. Notons que si le RTT est supérieur à 300 ms, les deux protocoles seront systématiquement utilisés.
  • Le navigateur Firefox implémente strictement les recommandations du RFC 8305 et essaye les deux protocoles en parallèle.

Des mises en œuvre similaires à celles des navigateurs sont à développer pour les clients des différentes applications (e.g. mail, VoIP, chat...). Pour ne pas avoir les inconvénients des accès séquentiels, il faudrait ne pas attendre l’expiration des temporisateurs de l’OS, mais choisir des temps de garde plus agressifs et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un délai de 300 ms ou deux RTT, alors IPv4 est essayé.

Notons cependant que le parallélisme a un effet pervers pour les opérateurs. En effet, l’utilisation des CGN pour la connectivité IPv4 leur est coûteuse et le maintien des états relatifs à l’ouverture de chaque connexion consomme des ressources. En suggérant l’ouverture de plusieurs connexions en parallèle, le RFC 8305 va à l’encontre des intérêts des opérateurs et potentiellement des utilisateurs si les CGN sont saturés. C'est pourquoi, il suggère d’essayer en priorité le protocole qui ne générera pas d’état dans le réseau, à savoir IPv6.

Pour les problèmes de MTU, la solution réside dans le fait de forcer les utilisateurs à choisir une faible MTU, par exemple 1400 octets, dans l'espoir qu'il n'y ait pas un lien sur la route dont la MTU soit inférieure à cette valeur. Cela peut être fait lors de la configuration de l'interface réseau ou lors de l'établissement d'une connexion TCP en réduisant la taille maximum des segments autorisée. Cette réduction est effectuée par le routeur (MSS clamping). Dans le RFC 4821, les auteurs proposent une solution qui ne repose pas sur ICMP. L'idée consiste à ce que TCP relève la taille des segments perdus. Si ce sont les segments de grande taille, TCP diminue la MSS (Maximum Segment Size) de lui-même (et, par voie de conséquence, la valeur de la MTU). Le RFC 8899 étend cette technique à d'autres protocoles de transport que TCP et SCTP.

Les problèmes de performance en termes de délai sont dus à l'utilisation de tunnels. La solution réside dans la sélection de points de sorties plus proches pour les tunnels. Au moment de la rédaction de ce document, le problème de délai n'a pas de solution (au niveau application) faisant l'objet d'une recommandation similaire à celle du RFC 8305.

Conclusion

Le mécanisme de double pile permet de résoudre les craintes liées à la migration vers IPv6. Dès lors, il ne s'agit plus d'une migration mais d'une intégration de IPv6 dans le réseau existant. Le réseau IPv4 reste pleinement fonctionnel et l'intégration d'IPv6 ne risque pas de compromettre le bon fonctionnement des services déployés. En effet, 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 réside dans l'adaptation progressive de son système d'information et de son personnel à IPv6.

Notons que le déploiement double pile ne doit être que transitoire car 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 et augmente la charge pour l'administrateur réseau. Lors de l'activation d'IPv6 pour un service existant en IPv4, il faut prendre des précautions afin que la qualité perçue par l'utilisateur ne soit pas dégradée.

Références bibliographiques

  1. ↑ Botzmeyer, S. (2006). Programmer pour IPv6 ou tout simplement programmer à un niveau supérieur ?
  2. ↑ Matthews, P. Kuarsingh, V. (2015). Internet-Draft. Some Design Choices for IPv6 Networks
  3. ↑ Cisco. (2011). White paper. Solution Overview—Getting Started with IPv6
  4. ↑ RIPE documents. (2012). Requirements for IPv6 in ICT Equipment
  5. ↑ Marsan, C.D. (2010). Network World. U.S. military strong-arming IT industry on IPv6
  6. ↑ Horley, E. (2013) IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them
  7. ↑ IANA. IPv6 Global Unicast Address Assignments
  8. ↑ Rooney, T. (2013). Deploy 360 Programme. Internet Society. IPv6 Address Planning: Guidelines for IPv6 address allocation
  9. ↑ Cisco. (2011); White paper. IPv6 and Applications
  10. ↑ Bortzmeyer, S. (2011). Le bonheur des globes oculaires (IPv6 et IPv4)
  11. ↑ 11.0 11.1 Huston, G. (2009). The ISP Column. A Tale of Two Protocols: IPv4, IPv6, MTUs and Fragmentation
  12. ↑ Huston, G. (2012). The ISP Column. Bemused Eyeballs: Tailoring Dual Stack Applications for a CGN Environment

Pour aller plus loin

Scénarios de déploiement :

Sécurité :

Pour développer des applications compatibles avec IPv6 :


RFC et leur analyse par S. Bortzmeyer : 

Analyse

Présentations sur le déploiement d'IPv6 :

Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act41-s7&oldid=20543"
Personal tools