Revision as of 11:20, 3 June 2015

Objectif

L’utilisation paralèlle des piles IPv4 et IPv6 présentée par le RFC 4213 doit permettre l’intégration de IPv6 tout en assurant aux noeuds en double pile une compatibilité parfaite avec le réseau IPv4 existant. Lorsqu’un service est accessible via IPv6, le client en double pile utilise en priorité IPv6. Le protocole IPv4 n’est utilisé que si la tentative échoue en IPv6 ou si le service n’est pas disponible sous IPv6. Il était envisagé qu’une fois que la majorité des services auraient été porté sur IPv6, la croissance de l’internet aurait pu se poursuivre tout en respectant du principe de bout en bout c’est à dire sans équipement de type NAT pour palier à la pénurie d’adresses IPv4.

Contexte de déploiement

En fonction du contexte de déploiement de la double pile, les enjeux et contraintes ne seront pas les mêmes. En effet, lors du déploiement 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 les équipements terminaux, ce mécanisme de transition a été largement employé dès le début de la standardisation d'IPv6. Il consiste à dôter chaque équipement d'une double pile protocolaire et d'affecter une adresse IPv4 et/ou IPv6 à chaque interface réseau. Cela ne résoud pas le problème de la pénurie d'adresses IPv4, mais permet dans un premier temps d’utiliser indifférement IPv4 ou IPv6. Les problèmes inhérants à IPv6 peuvent donc être identifié et les utilisateurs pourront accéder aux sevices existants uniquement sous IPv6.

Dans le cas d’un réseau d’entreprise, il faudra y ajouter les problématiques d’obtention du prefix IPv6, la structuration de l’espace d’adressage, la gestion du routage IPv6 en parallèle de IPv4. Les réseaux d’entreprises hébergent de nombreux services tels que le DNS, la messagerie, les serveurs web et autres logiciels. L’intégration d’IPv6 dans ces services et leur supervision sont également des taches chronophages qui doivent être adréssées. Pour ce qui est de l’administration des équipements réseaux en double pile, cela demande clairement un double travail de configuration. Notons qu’un réseau peut être entièrement en double pile ou partiellement, à condition que les segments non v6 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 (cf. ISIS).

Malgré la disponibilité des équipements supportant le double pile, les acteurs des réseaux tels que les FAI, les fournisseurs de services et les administrateurs de sites n’ont pas perçu l’urgence d’integrer IPv6 dans leur services et leur connectivité. Les doubles piles déployées sur les hotes et équipements de l’internet restent donc largement inutilisées. Notons que la croissance de l’Internet s’est néanmoins poursuivi avec plusieurs conséquences nefastes :

• [figure] le besoin de connecter de nouveaux sites a ammené au partitionnement des blocs d’adresses existants avec une augmentation du nombre de routes.
• [figure] l’augmentation du coût pour les ISPs qui ont recours à un adressage privé necessitant le deploiement de NAT à grande échelle pour l’ensemble des clients des ISP. Ces NAT connus sous le terme de Carrier Grade Nat (CGN) ou NAT444 ont un coût non négligeable pour ces derniers.
• [figure] l’augmentation du coût de developpement des applications : les clients de l’internet, censés avoir des adresses publiques ont maintenant des adresses privées derrière le NAT de leur routeur ADSL (NAT44) qui est lui même potentiellement derrière un CGN (NAT444). On est loin du principe de bout en bout tel que celui qui a permis la croissance des applications réseaux et de l’internet. La mise en oeuvre des applications s’est donc complexifiée necessitant par exemple le deploiement de serveurs STUN/ICE pour ces applications. Il est de plus en plus compliqué pour les utilisateurs d’héberger des services et du contenu chez eux et ils ne sont plus que des clients.

En dépis de cet attentisme, de plus en plus de services sont accessibles en IPv6 et d’avantages d’herbergeurs proposent IPv6. Certains FAI fournissent directement 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[REF], ils ont fortement amélioré leurs performances et les délais ont été réduits grace à la multiplication des points de présence (PoP). Un grand nombre d’applications (Mail, spam, supervision, Firewall...) intégre desormais IPv6.

Il est donc désormais beaucoup plus aisé d’integrer IPv6 dans son réseau. Il vaut mieux le faire aussi tôt que possible de manière à traiter progressivement et sereinement les inévitables bugs logiciels et erreurs de configuration qui surviendront. Une fois la transition achevée vous pourrez apprecier les avantages que procure le principe de bout en bout dans la conception de vos applications et vous éviterez surtout une transition precipitée et houleuse lorsque l’espace d’adressage d’IPv6 sera pour vous indispensable.

La suite de ce document décrit les principaux éléments relatifs à l’activation d’une double pile. Dans un premier temps, les problématiques d’adressage et de configuration. Ensuite le deploiement des principales applications réseaux (DHCP, DNS, parefeu, supervision). Enfin, les problèmes induits par l’utilisation de la double pile et comment les contourner.

Notons que au délà de sa configuration, une des difficultés consiste à avoir une connection à l’internet IPv6. Nous ferons simplement l’hypothèse que l’utilisateur double pile a un moyen de se connecter à l‘internet IPv6. Cette connection peut se faire de manière native, via un tunnel, via un operateur qui utilise 6to4, 6rd ou autre. Ce problème et ceux qui en découlent seront traités dans les activités suivantes.

Support d’IPv6 sur les équipements réseau & terminaux

Les principaux OS et logiciels réseaux intègrent déjà IPv6. La machine depuis laquelle vous lisez ce texte supporte déjà IPv6 (iOS > 6, Android > 5, Linux, Unix, Windows, OSX...) .

Comment obtenir un préfixe IPv6 (Opérateur ou ULA, le pb de connectivité est abordé ensuite)

Lorsque vous listez les interfaces disponibles sur vos machines, vous verrez que des adresses IPv6 sont déjà configurées.

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 . :

Ces adresses sont dites lien local [RFC3927]. Elles sont utilisées pour le mécanisme de découverte de voisins [RFC4861] ainsi que pour la composition du DUID du DHCPv6. Elle ne sont valides que sur un lien et ne sont donc clairement pas utilisables pour assurer la connectivité IPv6 de l’utilisateur.

Il faut donc fournir à l’utilisateur une adresse unicast qui soit routable, au moins au sein d’un site. Il existe deux types d’adresses qui répondent à ce critère : les adresses unicast locales ULA [RFC ] et les adresses globales GUA [RFC]. Pour rappel, les différences majeures entre ces deux types d’ adresses sont les suivantes :

• Portée: comme leur nom l’indique, les adresses GUA sont globales, une adresse GUA est utilisé par au plus une machine de l’internet à un instant donné. Les adresses ULA sont uniques au sein d’un site mais il peut y avoir plusieurs machines dans le monde qui utilisent une même adresse ULA.
• 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: Les adresses ULA peuvent être générées de manière arbitraire par l’administrateur du site auquel impute la responsabilité de maintenir ces adresses uniques au sein du site. Dans le cas des GUA, le site fait la demande à son ISP un préfix unique dans l’internet. Notez qu’il est possible de demander un prefix independant des ISPs i.e. lorsque le site change d’ISP, il pourra garder son prefix; il pourra également être multi-domicilié.
• Gestion du plan d’adressage : Pour les ULA, le GID (40bits) est généré par l’administrateur pour créer un préfixe de 48bits. Pour les GUA le GID est fixé par l’ISP qui fournit généralement au client un préfixe de 48bit. Les SID (16 bits restant pour former des préfixes de 64 bits) sont gérés par l’administrateur pour la structuration de l’espace d’adressage interne.

ULA ou GUA ? cas d’utilisation :

Il faut tout d’abord noter que même lorsque qu’un site obtient un prefix /48, il peut avoir 2^16 sous réseaux différents et 2^64 hôtes dans chacun de ces réseaux. Certains ISP délivrent à leur clients des adresses /64. Même dans ce cas, le nombre d’adresses administrables par l’utilisateur dépasse par plusieurs ordre de grandeur le nombre d’interfaces qu’il peut d’y avoir dans un réseau.

ULA pour gerer 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 obtenu 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ée dans IPv4 induits que les machines situées derrière un NAT sont plus difficilement accéssibles de l’exterieur. Cela la rend les attaques plus difficiles à réaliser. Cet effet de bord des adresses privées leur vaut la réputation d’être plus sécurisée que des adresses publiques. Certains estiment donc que les adresses GUA exposent les machines directement aux attaquant de l’internet et qu’il faut donc maintenir l’utilisation d’adresse privée au sein des sites et chez les clients. En pratique, même avec une adresse privé, il faut malgré tout utiliser un pare feu pour prévenir les attaques, filtrer le trafic entrant et sortant, restreindre les applications utilisables par les utilisateurs (...). Un simple règle sur un pare feu peut interdire l’ouverture de connection depuis l’exterieur et donc fournir le même niveau de sécurité qu’un NAT.

ULA plus facile à deployer ? Pour utiliser des adresses ULA et fournir un accès internet à vos utilisateurs il vous faudra un NAT66 pour la translation d’adresses ULA en GUA. Cet équipement devra être acheté et maintenu par l’administrateur. De plus il vous faudra néanmoins demander une adresse publique ou un prefixe /48 à votre ISP. Un réseau basé sur les adresses ULA necessite donc plus de travail qu’un équivalent GUA.

Les seuls cas où l’utilisation des adresses ULA est réellement motivé sont les réseaux de tests (TPs, testbeds, déploiements prototype) et les réseaux necessitant un niveau de sécurité très élevé et dont les équipements n’ont pas à être connecté à l’internet (réseaux tactiques, hopitaux ...). Dans tous les autres cas, les adresses GUA sont plus faciles à deployer et à administrer.