La prise en charge d'IPv6 dans OpenStack Networking (Neutron) constitue l'une des grandes nouveautés de Juno, la prochaine version d'OpenStack.  Mais cette prise en charge est-elle vraiment complète ?

L'Internet tel que nous le connaissons remonte à 1981, date du lancement d'IPv4. À l'époque, les quelques 4,3 milliards d'adresses potentielles étaient censées suffire dans un futur proche – et ce, d'autant plus qu'il n'était question que de tester les concepts réseau de la DARPA, l'Agence américaine pour les projets de recherche avancée de défense. Mais l'explosion des équipements informatiques, notamment les Smartphones, et les problèmes d'efficacité dans l'attribution des adresses ont rapidement mis le système à rude épreuve. Malgré la mise en place de mesures palliatives comme la Traduction d'adresse réseau (NAT) et le Routage interdomaine sans classe (CIDR), le dernier bloc de 16 millions d'adresses IPv4 de premier niveau a été attribué le 3 février 2011. Mais avec l'arrivée de l'Internet des Objets, il est indispensable de trouver une solution pour le long terme.

Découvrez l'IPv6

Développé par l'Internet Engineering Task Force (IETF) en 1999, le protocole IPv6 utilise des adresses 128 bits. Il permet ainsi de générer 3,4×1038 adresses, soit près de 100 adresses pour chaque atome présent sur terre. Autres avantages de l'IPv6 : la configuration automatique d'adresses par l'hôte et la renumérotation simplifiée du réseau.

« L'IPv6 n'est pas une fonction, mais une condition de survie indispensable », explique Sean Collins, ingénieur logiciel chez Comcast et chef de l'équipe secondaire OpenStack IPv6. « Il n'y a plus d'adresses IPv4, or tous nos produits en ont besoin », poursuit-il.

Différences entre l'IPv4 et l'IPv6

Les adresses IPv4 sont des adresses de 32 bits qui se présentent généralement sous la forme de 4 octets du type 192.168.0.1 ou 10.28.255.168. Les trois premières valeurs représentent le sous-réseau défini par l'administrateur réseau ou le fournisseur, tandis que le dernier chiffre représente l'hôte.

Les adresses IPv6 sont en revanche constituées de huit valeurs hexadécimales du type : 2001:0db8:85a3:0042:1000:8a2e:0370:7334. Les quatre premières valeurs représentent le sous-réseau qui peut être défini par l'administrateur réseau ou reçu dans les messages d’annonce de routage transmis par les routeurs upstream, tandis que les quatre derniers chiffres représentent l'hôte.

Au-delà du format des adresses, la principale différence entre l'IPv4 et l’IPv6 (pour ce qui concerne OpenStack) porte sur le mode d'attribution des adresses. L'IPv4 s'appuie en grande partie sur le protocole DHCP (Dynamic Host Configuration Protocol) qui permet à un nouvel hôte de diffuser facilement une requête de nouvelle adresse sur le réseau. Le serveur DHCP fournit une adresse ainsi que des informations sur les serveurs DNS et le réseau.

En IPv6, l'attribution des adresses peut s'effectuer de trois manières :

■   Auto configuration des adresses sans état (SLAAC) : dans une installation IPv6, les équipements peuvent se configurer en mode SLAAC ; ils prennent l'adresse de sous-réseau fournie et la combinent avec l'identifiant de l'hôte construit à partir de leur adresse MAC. Ils vérifient ensuite si l'adresse est déjà utilisée afin d'établir son unicité.

■   DHCPv6 avec état: dans une configuration avec état, le sous-réseau est défini par l'administrateur, les adresses des hôtes sont conservées, tracées et attribuées par le serveur DHCP comme dans une installation IPv4.

■   DHCPv6 sans état: dans une configuration sans état, le sous-réseau peut être défini par l'administrateur ou reçu dans les messages d’annonce de routage ; le calcul de l'adresse de l'hôte s'appuie sur les mêmes calculs que l'on aurait obtenus en mode SLAAC.

OpenStack dispose en fait de deux services réseau différents. On peut utiliser le système réseau d'OpenStack d’origine, nova-network, pour créer un réseau de base, tandis que les tâches plus complexes de SDN (Software Defined Networking) feront appel au plus récent OpenStack Networking (Neutron). Les deux prennent en charge l'IPv6 dans une certaine limite.

Fonctionnement d'IPv6 avec OpenStack

En IPv6, l'attribution d'adresses IP représente la tâche la plus simple pour OpenStack. IPv6 permet aux hôtes de créer leurs propres adresses à partir d'une adresse de sous-réseau et de leur propre adresse Mac. De ce fait, dans la configuration la plus simple, les équipements externes, comme les routeurs upstream, fournissent l'adresse de sous-réseau via les annonces de routage. Dans ce cas, l'administrateur établit une corrélation entre le VLAN et le réseau du fournisseur ; l'instance récupère l'annonce de routage puis utilise ce sous-réseau pour créer son adresse IP. Quant à la version actuelle d'OpenStack baptisée Icehouse, ce scénario est pris en charge à la fois sur nova-network et Neutron. Neutron permet en plus de séparer les méthodes d'annonce de routage et d'adressage à l'aide de paramètres distincts pour les modes ipv6_ra_mode et ipv6_adress.

La difficulté de cette configuration tient au fait que le sous-réseau vient de l’extérieur d'OpenStack. Que se passe-t-il si vous ne souhaitez pas utiliser le réseau prédéfini d'un fournisseur et préférez utiliser un agent L3 avec routage IPv6 ? À la date où nous écrivons cet article, Neutron était sur le point de permettre l'utilisation du DHCPv6 avec et sans état – ce qui sera possible sur Juno, la prochaine version d'OpenStack.

En résumé, OpenStack prend en charge l'IPv6 pour l'adressage simple. Mais ce n'est pas tout.

OpenStack : les besoins restants

Maintenant qu'OpenStack prend en charge l'adressage IPv6 pour les instances, que reste-t-il à faire ?

OpenStack se compose d'une multitude de projets. La première étape consiste à s'assurer que la prise en charge d'IPv6 au niveau des instances est à la fois complète et confirmée pour chaque projet – notamment en ce qui concerne la fonctionnalité de routeur virtuel distribué (DVR). On pourra alors remonter jusqu'au niveau de la couche réseau. Pour que Neutron gère réellement l'IPv6, l'agent Neutron L3 doit prendre en charge plusieurs préfixes réseau. Cette fonctionnalité est programmée pour fonctionner pendant le cycle Kilo.

L'introduction de la délégation de préfixes est prévue avec la version Kilo (dont la sortie est programmée autour d'avril 2015). En clair : au lieu d'attribuer une adresse /128, à savoir une adresse d'hôte de 128 bits, le fournisseur attribue une adresse /64. Cette valeur 64 bits correspond à l'adresse de sous-réseau et peut servir de préfixe de sous-réseau pour tous les équipements sur votre réseau interne. Une fois cette fonctionnalité en place, plus besoin d’essayer de deviner quel sous-réseau utiliser lors de la création d'un nouveau réseau (l'une des tâches les plus frustrantes dans OpenStack Networking). Au lieu de contacter un administrateur IP pour déterminer quels sont les sous-réseaux disponibles, il suffit de demander un préfixe réseau. C'est aussi simple que cela. La délégation de préfixes permettra également d'avoir de véritables Clouds privés virtuels « routés » dans lesquels plusieurs machines situées en différents endroits pourront être connectées pour former un Cloud unique.

Il manque encore une dernière fonctionnalité, mais OpenStack n'est pas le seul concerné. Du fait du manque d'interopérabilité entre l’IPv4 et l’IPv6, il arrive souvent qu'un réseau prenant en charge l’IPv6 à l'intérieur ne rende pas son plan d'adressage disponible à l'extérieur du réseau. En d'autres termes, si ce réseau est entièrement fonctionnel et « routable » en interne, il reste isolé. L'accès Internet continue à être géré en IPv4. On peut actuellement utiliser des équipements externes pour connecter un Cloud OpenStack à Internet via l’IPv6 de la même manière que l'on peut utiliser le réseau d'un fournisseur pour obtenir un sous-réseau ; la difficulté de l'opération dépend du nombre de tronçons entre votre Cloud et l'équipement concerné. Pour que ce soit possible dans OpenStack, il faudrait mettre en oeuvre les protocoles BGP (Border Gateway Protocols) dans SDN ou NFV (Network Function Virtualization) pour annoncer les préfixes de sous-réseaux. Cette fonctionnalité n'existe pas encore à l'heure où nous rédigeons cet article, mais elle est prévue pour la version Juno.

En résumé

Bien qu'il ne prenne pas encore complètement en charge l'IPv6, OpenStack est en bonne voie. « Les travaux menés au sein de l'équipe secondaire IPv6 se sont attachés à vérifier que Neutron était une plate-forme réseau viable pour l'avenir », conclut Collins. « Le tunnel résonne des grondements d'un avenir qui braque ses phares et avertit bruyamment la population. Je crois cependant que nous avons réussi à extraire Neutron de la voie qui mène à l'épuisement des adresses. »

Le chemin est encore long pour faire suffisamment progresser l'IPv6 pour envisager d'être utilisé par le Software Defined Networking. Mais même avec la version Juno d’octobre 2014, OpenStack permet d'utiliser l’IPv6 au niveau des instances et offre ainsi la prise en charge nécessaire à la plupart des entreprises.