Revision as of 09:10, 19 June 2015

> MOOC>Contenu>Séquence 4 > Activité 42

II/ Activer IPv6 dans son infrastructure

Introduction

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

• Déployer IPv6 sans casser ce qui fonctionne en IPv4,
• Rendre le déploiement complètement transparent à l'utilisateur.

Afin d'avoir un déploiement progressif d'IPv6, elle s'oriente vers un déploiement en double pile qui est un des premier 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ées. Ensuite les points propres à prendre en compte au passage en IPv6 des principales applications réseaux (DHCP, DNS, parefeu, supervision) sont soulevés. Enfin, les problèmes induits par l’utilisation de la double pile ainsi que leurs solutions sont précisés.

Rappel de la technique de la double pile

Le mécanisme de double pile IP (Dual Stack) présenté 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. L’utilisation paralèlle des piles IPv4 et IPv6 vise l’intégration de IPv6 tout en assurant aux noeuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Ainsi les noeuds double pile sont capables de communiquer dans les deux versions du protocole IP. La figure 1 illustre ce principe. La station B peut dialoguer en IPv4 avec la station A et en IPv6 avec la station C. Le listing suivant donne un exemple de configuration d'une double pile dans un environnement Unix.

Figure 1: Noeud double pile.

Plan de migration originel

La double pile a été proposée dès le début d'IPv6. Le plan originel de migration de l'Internet reposait d'ailleurs sur ce mécanisme comme le rappelle G. Huston [1] par la figure 2.

Figure 2: Plan de migration vers IPv6.

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

Malgré la disponibilité des équipements supportant le double pile, les acteurs de l'Internet tels que les FAI (Fournisseur d'accès à Internet), les hébergeurs et les administrateurs de sites n’ont pas perçu l’urgence d’integrer IPv6 dans leurs activités. Les doubles piles déployées sur les noeuds de l’Internet restent largement inutilisées par rapport au plan initial comme le montre la figure 3. Comme la croissance de l’Internet s’est poursuivie en IPv4. Celle-ci a été affectée avec plusieurs conséquences nefastes comme nous l'avons vu dans l'activité précédente. L'échec du plan initial est largement due à la dérégulation appliquée dans le secteur des télécommunications qui l'a rendu hautement compétitif. Cette dérégulation a conduit les acteurs à privilégier le court terme et les rend incapables de prendre en compte les besoins à plus long terme dans leurs activités [2] .

Figure 3: Etat du plan de migration initial.

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

Préparation au 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 domestique de l'utilisateur résidentiel qui se caractérise par l'absence d'administration, du réseau d'entreprise qui est administré.

• Au sein d’un réseau domestique, les problématiques sont liées à la configuration des équipements terminaux, au déploiement des services de résolution de nom et configuration d’adresse 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 ses services.

Pour ce qui est de la configuration des équipements réseaux en double pile, cela demande clairement un double travail de configuration à la fois en IPv4 et en IPv6. 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 coeur de réseaux 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.

Méthode

L'intégration de 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 indipensable pour iidentifier les points bloquant à l'intégration de IPv6 dans le contexte professionnel.

L'intégration d'IPv6 commence par nommer une personne en charge de suivre et coordonner les actions liées à l'intégration de IPv6. Sa première tâche consistera à dresser un inventaire des équipements du réseau afin de déterminer lesquels 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 compatiible". Il n'est pas question de tout jeter et de racheter. Il faudra retenir la technique de transition adaptée à son réseau. En plus du matériel, il faut egalement faire l'inventaire des logiciels utilisés pour déterminer lesquels supportent IPv6 et lesquels nécessitent une mise à jour.
Les applications métiers developpées en interne doivent être modifiées le plus tôt possible afin de les rendre capable de manipuler des adresses sur 128 bits. Le RFC 4038 propose des méthodes pour développer du code indépendant des versions de IP. Le RFC 6724 indique comment selectionner les adresses sources. Le RFC 6555 liste et solutionne les problèmes liés à la baisse de performance parfois observée dans les déploiement double pile. Ces points sont développés 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é et notamment les différences qui distinguent IPv6 de IPv4 :

• il se peut que les mises en oeuvre de IPv6 soient moins sures pour la simple raison qu'elles n'ont pas été validés aussi longtemps qu'IPv4 et qu'elles peuvent avoir des failles non encore découvertes. Ce point a été noté par le RFC 7381.
• Les adresses protegeant la vie privée de utilisateurs [RFC 4941] compliquent l'administation du réseau parce que les utilisateurs ne sont plus identifiable par le IID de leur adresse. . Il est possible d'interdire l'anonymisation des adresses IPv6 par une configuration manuelle ou par le biais de DHCPv6.
• En double pile, la surface à protéger pour les administrateur réseau est doublée. Si la partie IPv6 est négligée, cela peut naturellement conduire à d'importantes failles de sécurité.

Il faut être conscient que d'autres points sont souvent mal apréhendés au niveaux des développeurs comme le chainage des en-têtes IPv6 [RFC 7113] ou la fragmentation [RFC 4821].

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 le trafic IPV4 et IPV6. Le document [6] (en cours d'etude 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 inclue également le plan d'adressage et l'allocation des adresses. Ces points sont abordés en détail dans la suite de ce document.

Vérification de la disponibilité d’IPv6

Le protocole IPv6 et ses protocoles associés sont dans les systèmes d'exploitation depuis plus de 10 ans. Il en découle que une grande majorité des noeuds de l'Internet comporte IPv6. Ainsi, au démarrage d'un noeud, même en l'absence d'un routeur IPv6 sur le lien de ce noeud, 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 ne sont pas routables et par conséquent utilisables pour une communication indirecte (passant par un routeur).

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 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 pour des communications dans un intranet.
• 'Routage: Les adresses GUA peuvent être routées dans l’internet. Les adresses ULA doivent être filtrées par les routeurs en bordure de site. Les prefixes ULA ne doivent pas être annoncés ni accepté par les routeurs inter AS.
• 'Obtention: Un préfixe ULA est générée de manière aléatoire par l’administrateur d'un site. Le GUA est obtenu soit auprès de son FAI ou auprès du RIR de sa région. On parle de préfixe PA (Prefix Aggregable) lorsqu'il est obtenu de son FAI. Si le FAI change, il faut rendre le préfixe et rénuméroter le réseau du site. Pour éviter ce désagrément, il est possible de demander un préfix independant d'un FAI. On parle alors de préfixe PI (Prefix Independant). Ce type de préfixe est un nécessité pour les sites multi-domiciliés.

Mais quelle type d'adresse routable utilisé dans un site ? Quelles sont les cas d'utilisation des adresses ULA ? Les éléments de réponses à ces questions sont abordés.
Il faut tout d’abord noter que quelquesoit le type de préfixe alloué à un site; Au niveau de la taille du plan d'adressage celui-ci reste très confortable. Il n'a rien de commun avec ce qui est connu en IPv4. Lorsque qu’un site obtient un préfixe /48, il peut avoir 2^16 sous réseaux différents et 2^64 noeuds dans chacun de ces réseaux. Même l'allocation d'un préfixe /64 laisse à l'utilisateur un nombre d’adresses disponibles qui dépasse de plusieurs ordres de grandeur le nombre de noeuds qu’il peut y avoir dans un réseau.

Préfixe ULA

EN COURS

Le préfixe ULA [4193] est l'équivalent dans son usage au préfixe privé d'IPv4 mais quasi unique et sans registre central. Le RFC 4193 propose, dans un espace réservé FC00::/7, de constituer selon un algorithme indiqué dans le RFC des adresses quasi-uniques. Le format des adresse 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) 40 bits pour identifier le site.

Les 40bits du GID sont générés en utilisant une fonction de hash (i.e.. SHA-1) de l'heure et ll'adresse MAC de la machine exécutant l’algorithme.

Le script, sous licence libre GPL, développé par Hartmut Goebel, disponible à l'URL 3, peut générer une série de préfixes conforme en utilisant une des adresses MAC ethernet d'un poste de travail. Il existe des sites qui permette d'enregistrer les prefix ULA de manière à minimiser la probabilité de collision lors des fusions de sites https://www.sixxs.net/tools/grh/ula/. [[7]]

Notons que les motivations ou les croyances à l'utilisation des adresse privées d'IPv4 ne s'appliquent plus dans le cas d'IPv6. Citons:

• ULA pour gérer la carence d’adresse IP publique. 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.
• ULA pour 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 attaquant de l’Internet et trouvent là une justification à l’utilisation d’adresse privée. On notera que cet argument est bancale, car avec une 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 connection depuis l’extérieur peut donc fournir le même niveau de sécurité qu’un NAT.
• ULA plus facile à déployer. L'accès Internet pour un site avec un adressage ULA nécessite un NAT66 pour le changement d’adresses ULA en GUA. En plus de l'achat et de la maintenance de cet équipement, ce sont toutes les tares du NAT qui reviennent dans le réseau IPv6. L'usage d'ULA dans le cas d'un accès Internet n'économisera pas de 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.

Les seuls cas où l’utilisation des adresses ULA est réellement motivée sont les réseaux de tests (TPs, bancs d'essais, déploiements prototype) et les réseaux necessitant un niveau de sécurité très élevé par un isolement complet comme les réseaux tactiques ou d'hôpitaux. Dans tous les autres cas, les adresses GUA sont plus faciles à deployer et à administrer. C'est aussi le conseil donné par l'auteur de cette note [8].

Préfixe GUA

Le préfixe global peut être alloué par un ISP, par un Local Internet Registery ou par un RIR. Il y a plusieurs cas à distinguer : si le prefixe est destiné à un organisme, on parlera d’assignement de site, si le site est multidomicilié il faut des prefix dits “provider independent” et enfin le cas où les prefixes sont dédiésà un usage personnel.

Internet Registery, des acteurs structurés : Pour rappel, les prefixes d’adresses IPv6 global unicast sont gérés par l’IANA qui délégue aux Regional Internet Registry (RIR). Les RIRs deleguent aux National Internet Registery (NIR) puis aux Local Internet Registery (LIR) et/ou aux ISP. En Europe, le RIR est le RIPE-NCC. Il delegue directement aux ISP/LIR sans passer par des NIR. Les LIR et certains ISP se voient déleguer des prefixes de longueur 32. Ils ont obligation d’allouer les blocs IPv6 à des utilisateurs finaux tels que des organismes ou des ISP. Le RIPE-NCC ne prévoit pas de recommandation sur la taille des prefixes alloués par les LIRs aux ISPs.

Assignement de site : Les ISP/LIR font des assignements de site aux utilisateurs. Le bloc d’adresse associé est donc spécifique à un site et associe un organisme à un ISP qui assure les services suivant : l’ISP assigne le bloc d’adresse à l’organisme; assure un service de transit entre l’utilisateur et les autres sites; transporte le trafic de l’utilisateur et annonce un prefix BGP dans lequel est inclu celui de l’utlisateur. Les prefixes alloués sont au maxmimum sur 64 bits. Si un utilisateur souhaite avoir un prefix de moins de 48 bit pour son site, sa demande doit être motivée.

Multidomiciliation - Provider Independent prefix : Comme pour IPv4, si le site doit être multidomicilié ou s'il faut pouvoir changer d’ISP sans changer d’adresses [RFC5887], il est necessaire d'obtenir des prefix dits “Provider Independent”. La demande doit être faite directement à RIPE-NCC qui assigne un prefix /48 ou un prefix de longueur inferieur 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 parainée par un ISP/LIR membre de RIPE. Il est ensuite necessaire que les ISP annoncent et routent le préfix.

Client d’un ISP : Les clients d’un ISP qui propose IPv6 obtiennent par défaut un prefix sur 64bit. Leur routeur ADSL est configuré avec cette adresse. La configuration des autres équipements (e.g. routeurs WiFi ..) pour permettre la configuration des machines via RADV ou DCHPv6 reste à la charge du client. Si un ISP ne propose pas IPv6, il est possible d'utiliser un service de tunnels. Certains d’entre eux (e.g. hurricane electric) proposent l’assignement gratuit de prefixes sur 48 bit lors de l’etablissement d'un tunnel.

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

Les préfixes alloués laissent de nombreux bits pour gérer les liens. Si tel n’est pas le cas e.g. un prefixe /64 est utilisé, deux solutions sont disponibles :

• mettre en place un adressage privé avec un NAT66 pour faire la conversion. Cette solution vient avec le double inconvénient de necessiter un équipement supplémentaire et de rompre le principe de bout en bout.
• mettre en place des liens avec des préfixes de plus de 64 bits. La RFC7421 décrit les avantages et inconvenients de cette pratique. Il en ressort que même si les protocoles de routage et la pile protocolaire des hôtes supportent jusqu’à des prefixes de 128 bits, ce cas de figure n’est pas prévu par IPv6 qui indique clairement que le IID doit faire 64 bits. La RFC7368 considère même que le cas ou il n’y a pas suffisamment de bits pour l’adressage interne comme “une erreur”, le site devant à minima recevoir 16 bits pour le SID.

Un SID sur 16 bit est a priori suffisant et il est possible de structurer le routage interne de plusieurs manières :

• reproduire le schema IPv4 déjà déployé : Le bloc privée de classe A 10.0.0.0/8 offre 24 bit à l’administrateur pour la structuration des sous réseaux. En réalité, les plus petits sous réseaux ont rarement des prefixes >24, ce qui ne laisse que 16 bits pour la structuration. Dans la plupart des 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 oeuvre, 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’agregation.
• 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’eviter 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 suivant 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 sont 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é;
• 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é.

La RFC5375 developpe les problématiques liées à la structuration de l'espace d'adressage.

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 integrer IPv6 e.g. 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ématique 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

Configuration des adresses

Il existe plusieurs méthodes pour la configuration des interfaces réseaux. Pour rappel, avec la méthode SLAAC (StateLess Address Auto Configuration), l’interface génère elle même ses adresses. Cependant cette méthode peut présenter des inconvénients :

• Absence du DNS : la RFC définissant le protocole de decouverte de voisins ne prévoyait pas de champs pour renseigner le DNS. Ce n’est pas un problème si l’adresse d’un serveur DNS est obtenue via l’interface le DHCP de l’interface IPv4. Cela rend donc indispensable l’existence d’une telle interface. Toutefois, la RFC6106 rend désormais possible l’ajout d’une option DNS dans les messages RA.
• Il n’y a pas de contrôle sur les adresses utilisées par les interfaces et il n’y a pas moyen fiable d’enregistrer l’association machine / adresse IP. Le logiciel NDPMON permet cependant d'écouter le réseau en permanance et de mémoriser les correspondances entre les adresses IP et MAC.

Le Stateless DHCP [RFC3736] permet de contourner certains de ces problèmes. En effet, il utilise le méthode SLAAC pour définir les adresses et permet à l’hote de demander explicitement les informations manquantes à un serveur DHCP dit sans état.

Avec DHCPv6, le client obtient son adresse et ses informations aupres du serveur DHCP. Ce dernier peut donc controler les informations renseignées à chaque machine, controler les adresses assignées et mémoriser ces dernières.

Autoconfiguration avec état

Lors du déploiement de DHCPv6 en double pile, l’inconvenient majeur va être la gestion des informations recueillies via des sources différentes. Ce problème bien connu est notamment décrit dans la [RFC4477]. En effet, des informations pouvant être reçues à la fois du DHCPv4 et du DHCPv6, il peut y avoir inconsistance. 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 peut être d’autant plus prononcé si le réseau IPv6 et IPv4 n’ont pas les mêmes administrateurs.

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.

Lorsque DHCPv6 et SLAAC sont deployés simultanement sur le réseau, leur interaction peut également être problématique.

Résolution d’adresses

Dans IPv6, le DNS est d'autant plus indispensable que les adresses sur 128bit sont difficiles à lire et mémoriser. Afin d’integrer la possibilité qu’une machine identifiée par son nom soit accèssible en IPv4 et en IPv6, la RFC3596 prévoit un nouveau type d’entrée dans les fichiers de zone. L’adresse IPv4 associée à un nom est toujours renseignée par le type “A” tandis que le nouveau type “AAAA” permet de renseigner l’adresse IPv6.

Les resolveurs DNS doivent être capables d’interpreter les deux types d’entrée. Lorsque les deux types sont retournés par le serveur, le resolveur doit influencer l’ordre des entrées retournées de manière à favoriser IPv6. Par ailleurs, le client doit pouvoir spécifier au resolveur s’il souhaite obtenir les entrées de type A ou AAAA.

Administration du réseau

L’administration d’un réseau peut se décomposer en trois taches qui sont la supervision, la métrologie et la sécurité.

Les firewalls 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 generalement assez facile à porter puisqu’il n’y a peu de dépendance entre les logiciels.

La difficulté principale a été porté sur les outils de supervision. Le protocole de supervision SNMP 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). Net-SNMP intègre IPv6 depuis 2002. Cette intégration était necessaire pour interroger les hotes uniquement IPv6 ce n'était pas indispensable dans le cas d'un réseau double pile puisqu'il est possible d'interoger un équipement via SNMP depuis sont interface IPV4. L'évolution des MIB a été beaucoup plus délicate mais elle est achevée et la RFC2851 prévoi 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 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.

Déploiement d'IPv6 pour les services

Au niveau des applications

Quelque soit la version de protocole utilisée au niveau de l'application 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) L'adresse IPv4 est imbriquée dans une adresse IPv6 comme le montre la figure 3. Le format des adresses IPv4 imbriquées est ::FFFF:<ipv4 address> comme par exemple ::FFFF:1.2.3.4. Avec ce type d'adresse l'espace d'adressage IPv4 est vu comme une partie de l'espace d'adressage IPv6. Le problème au niveau des applications est par conséquent que les applications utilisent le format d'adresse IPv6 pour leur communication. Car nous venons de le voir une application compatible IPv6 peut dialoguer indifférement en IPv4 et en IPv6. Alors qu'une application utilisant un format d'adresse IPv4 reste cantonné à ce protocole. Pour rendre une application IPv6, il faut qu'elles soient compilées ou recompilées avec l'API IPv6. Ceci est bien sur possible que sur les équipements pourvus d'un système ayant une pile IPv6. Ce qui est aujourd'hui dans la quasi totalité des cas vrai. Reste le problèmee des applications non recompilables (code source non disponible), ce genre de situation est traité par la suite dans l'activité de traduction.

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

Quand la pile IPv4 d'un équipement reçoit un paquet et qu'une application s'est enregistrée via une socket IPv6 (famille de protocoles PF_INET6), les adresses IPv4 imbriquées source et destination sont construites à partir des informations contenues dans l'en-tête du paquet. Réciproquement quand une application IPv6 émet des paquets avec une adresse IPv4 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 sur 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:

De la qualité de service perçues par l'utilisateurs

L’intégration de IPv6 devrait être indolore. C'est à dire que 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, cette hypothèse peut être fausse et le déploiement d'IPv6 peut s’avérer ralentie. 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’etablissement de la connexion. Pour l'illustrer, prenons un service “monservice.org” accessible aux adresses IPv4 et IPv6 comme schématisé par la figure. L’application du client demande au resolveur 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, sera 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’inconvenient de cette méthode est que les tentatives de connexions sont bloquantes et donc effectuées de manière séquentielle. Le délai d’attente pour considerer qu’une connexion a échouée 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 cassée. Si un serveur a IPv4 et IPv6 et que son client n'a qu'IPv4, pas de problème. Mais si le client a IPv6, tente de l'utiliser, mais que sa connectivité IPv6 est plus ou moins en panne, il aura des temps de réponse très important. 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.

           DNS Server                  Client                  Server
               |                          |                       |
         1.    |<--monservice.org A?-----|                       |
         2.    |<--monservice.org AAAA?--|                       |
         3.    |---192.0.2.1------------->|                       |
         4.    |---2001:db8::1----------->|                       |
         5.    |                          |                       |
         6.    |                          |==TCP SYN, IPv6===>X   |
         7.    |                          |==TCP SYN, IPv6===>X   |
         8.    |                          |==TCP SYN, IPv6===>X   |
         9.    |                          |                       |
         10.   |                          |--TCP SYN, IPv4------->|
         11.   |                          |<-TCP SYN+ACK, IPv4----|
         12.   |                          |--TCP ACK, IPv4------->|

Figure: Etablissement de connexion d'un client dual-stack.

Le second problème porte sur l'usage d'IPv6. 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 si il y a sur le trajet un tunnel qui réduit la MTU, le problème de MTU peut se produire comme la figure le schématise. Le problème de MTU se manifeste par le fait que les paquets de petite taille, tels que ceux utilisés lors de l’etablissement de la connexion passent mais les gros paquets, comme les transferts de fichier 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 de d'inactivité (aucune réception n'est faite). Ce problème est assez sérieux dans l'Internet et à fait l'objet du RFC 4459. Dans l'article [9], le problème de MTU est détaillé et illustré par des traces.

         DNS Server                  Client                  Server
               |                          |                                 |
         1.    |<--monservice.org A?------|                                 |
         2.    |<--monservice.org AAAA?---|                                 |
         3.    |---192.0.2.1------------->|                                 | 
         4.    |---2001:db8::1----------->|                                 |
         5.    |                          |                                 |
         6.    |                          |==TCP SYN, IPv6, 60o =>          |
         7.    |                          |<= TCP SYN+ACK, IPv6,60o ========|
         8.    |                          |== TCP ACK, IPv6, 60o ==========>|
         9.    |                          |== HTTP/POST TCP, IPv6, 1500o => X|
         10.   |                          |   X <== ICMPv6 Pkt too big  =====|
         11.   |                          |== HTTP/POST TCP, IPv6, 1500o => X|
         12.   |                          |   X <== ICMPv6 Pkt too big  =====|
         13.   |                          |== HTTP/POST TCP, IPv6, 1500o => X|
         14.   |                          |   X< == ICMPv6 Pkt too big  =====|
         ...   |                          |            .......              |

Figure: Le problème de MTU

Le troisième problème impactant un service est relatif à la performance de la connectivité IPv6. La connectivité IPv6 est souvent constituées de tunnels. Si les sorties des tunnels sont trop éloignés du point d'entrée, le temps de réponse peut significativement augmenter et dépasser les valeurs souhaitables pour les applications interactives (ToIP, video conference, jeux en ligne...) et même pour le Web. L’utilisateur verra alors sa qualité d’expérience chuter par rapport au réseau simple pile IPv4 et ce même si la connectivité IPv6 est parfaitement fonctionnelle.

Figure: Illustration des délais importants en IPv6

Des solutions ont été proposées pour éviter que les utilisateurs desactivent 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 que 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 éssayé en premier, il faut attendre que la tentative de connexion échoue, ce qui peut prendre plusieurs secondes. La RFC 6555 propose d’établir les connexion en parallèles et de ne concerver que la plus rapide. Les navigateurs internet ont pris en compte ces recommandations mais la mise en oeuvre diverge comme le rapporte l'article [10]:

• 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 premier 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élai pour l’obtention des adresses v4 et v6 via le DNS. Il tente d’établir une connexion avec le protocole dont l’adresse a été obtenu en premier. Notons que pour maximiser les chances de réussite, il envoie deux segments SYN en parallèle avec des ports sources differents. Si aucun segment SYN+ACK n’est reçu après 250ms, un dernier est émis depuis un troisième port. Si aucun segment SYN ACK n’est reçu après un total de 300ms, le protocole suivant sera essayé. Dans le cas ou un problème apparait avec un seul des protocoles, le délai est donc au maximum ralongé de 300ms. Si un problème apparait 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 à 300ms, les deux protocoles seront systématiquement utilisés.
• Le navigateur Firefox implémente strictement les recommandations de la RFC 6555 et essaye les deux protocoles en parallèles.

Des mises en oeuvre similaires à celles des navigateurs sont développés pour les clients des différentes applications (e.g. mail, VoIP, chat ...).

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 suggerant l’ouverture de plusieurs connexion en parallèle, la RFC 6555 va à l’encontre des intérêts des operateurs et potentiellement des utilisateurs si les CGN sont saturés.

La RFC 6555 prend en compte ce paramètre et suggère d’essayer en priorité le protocole qui ne generera pas d’états dans le réseau e.g. IPv6. Pour ne pas retrouver les mêmes inconvenients qu’avec un pur accès séquentiel, il faudrait établir simplement ne pas attendre l’expiration des timeout de l’OS mais choisir des valeurs plus agressives et ayant moins d’impact pour les utilisateurs. Par exemple, si IPv6 ne répond pas avant un minimum de 300ms ou deux RTT, alors IPv4 est essayé. Par ailleurs contrairement aux propsitions ci-dessus, il faudrait continuer à écouter les segments SYN ACK de IPv6 même si les timeurs ont expirés.

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 de lien dont la MTU soit inférieure à cette valeur. Cela peut être faire via ipconfig, via les annonces radv ou via l'option clamping des routeurs qui permet de modifier la valeur du MSS lors de l'établissement d'une connexion TCP [11]. Les problèmes de performance en terme de délai sont dus à l'utilisation de tunnels. La solution réside dans la selection de point de sortie plus proches pour les tunnels.

Au moment de la rédaction de ce document, les problèmes de MTU et de délai n'ont pas de solution niveau application faisant l'objet de recommandations similaires à celle de la RFC6555.

Conclusion

Le mécanisme de double pile permet de résoudre 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 de IPv6 ne risque pas de compromettre le bon fonctionement 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 vient du fait qu'il est possible d'écrire des applications en IPv6 qui restent compatibles avec les applications IPv4 existantes.

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 de IPv6 pour un service existant en IPv4, il faut mettre en oeuvre les mécanismes de happy eyeballs afin que la qualité perçue par l'utilisateur ne soit pas degradée.