MOOC:Compagnon Act41-s7

From Livre IPv6

Revision as of 10:12, 3 June 2015 by Ptournoux (Talk | contribs)

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.
Personal tools