Nous l’avons vu dans cet article sur les solutions à disposition des clients afin d’obtenir une connectivité IPv6, mais il s’avère désormais que la gestion des différentes problématiques, relative tant à la pénurie d’adresses IPv4 qu’à la migration vers IPv6, vont incomber en grande partie aux fournisseurs d’accès.

Les opérateurs disposent d’un large choix de solution, leur permettant de sélectionner la meilleure approche possible au regard de leur infrastructure et de l’approche qu’ils envisagent pour aborder ces problématiques. Au regard du nombre d’options possibles, nous allons exposer ces différentes solutions au travers de trois articles successifs, en abordant en premier lieu les solutions hybrides (tunneling) avant de traiter successivement les approches compressives et translatives.

L’approche dual-stack

Si vous avez lu notre précédent article, ce titre doit vous rappeler quelque chose. En effet, la solution idéale serait d’implémenter, tant pour le client que pour le fournisseur d’accès, un réseau dit dual-stack, supportant les IPv4 et IPv6 simultanément. Nous en avions discuté précédemment, mais un client n’aura de réel intérêt à implémenter une double pile réseau v4/v6 que si son fournisseur d’accès lui propose un service IPv6 complet en sortie. Il suffirait dès lors que ces opérateurs migrent leur réseau dans cette optique.

Toutefois, cette approche soulève, pour le fournisseur d’accès, deux problèmes de taille. En premier lieu, migrer chaque équipement de son réseau sur une approche dual-stack est une opération de longue haleine, et ce même dans le cas d’opérateurs de petite taille. Cette migration peut prendre plusieurs mois, voire années, avant d’être accomplie en totalité. De plus, le coût opérationnel imprimé sur le fournisseur d’accès est important, et n’est par conséquent pas une option envisageable, ni envisagée par nombre d’entre eux. En second lieu, une migration de ce type était possible lorsque le problème de la pénurie prochaine d’adresses IPv4 a été soulevée à l’origine (vers le milieu des années 1990). A l’heure actuelle, adresser le problème de la migration sans considérer le problème sous-jacent de la pénurie IPv4 n’a aucun sens : il va en effet devenir impossible bientôt de fournir, et une adresse IPv4 (puisqu’il n’y en a plus), et un préfixe IPv6 simultanément.

Il est par conséquent essentiel d’aborder ce problème sous des angles nouveaux, via des solutions « hybrides » qui vont permettre de limiter l’impact de la opérationnel sur le fournisseur d’accès, tout en proposant des approches valides tant au niveau de la migration en elle-même qu’au niveau de la pénurie d’adresses.

Les approches hybrides (tunneling)

Afin de limiter l’impact financier de la migration de son réseau, un opérateur va tenter de trouver une méthode permettant de faire transiter des données IPv6 sur son réseau en cours de migration. Ce réseau peut dès lors être vu comme un réseau de transit : d’un point d’entrée (par exemple, un client), les données transiteront avant de ressortir sur un autre réseau.

Un réseau de transit fonctionne de façon relativement triviale : sur réception d’une requête, le point d’entrée effectue une décision relative au point de sortie à utiliser à partir des informations contenues dans le message en entrée. Cette décision, et les mécanismes engagés par la suite, vont dépendre de certains critères (protocole d’entrée, type de trafic, etc.). Par exemple, dans le cas d’IPv6 en entrée sur le réseau de l’opérateur, plusieurs possibilités existent :

  • Le réseau de l’opérateur utilise le même protocole, auquel cas les mécanismes classiques sont utilisés.
  • Le protocole utilisé est différent, et la requête sera encapsulée au sein du protocole de l’opérateur (qui pourrait être par exemple IPv4 ou MPLS). Cette encapsulation sera retirée en sortie du réseau.

Cette dernière approche va prendre tout son sens dans le cadre de cette migration d’IPv4 vers IPv6. La plupart des solutions proposées vont en effet se reposer sur ce principe, comme nous allons le voir dans les différents protocoles imaginés dans cette optique.

6rd

Le protocole 6rd – ou IPv6 Rapide Deployment –, décrit au sein de la RFC 5969, se repose sur des concepts déjà décrits précédemment en les raffinant de manière à obtenir un tout cohérent et efficace. En particulier, il fait évoluer le protocole 6to4 détaillé dans notre précédent article. Ce protocole a originellement été imaginé afin d’apporter une connectivité IPv6 rapidement et efficacement au travers d’un réseau legacy (IPv4), de la manière la plus transparente possible pour l’utilisateur final, et engendrant le moins de coup possible pour le fournisseur. Le groupe français Iliad (Free), à l’origine de cette idée, a notamment réussi à définir le protocole, et le déployer sur tous ses CPE en cinq semaines seulement (RFC 5569).

Au contraire de 6to4 qui utilisait un préfixe spécifique (2002:: /16) couplé à l’adresse IPv4 publique du site, 6rd se repose directement sur la plage IPv6 du fournisseur d’accès, qui lui a été allouée par son RIR (Regional Internet Registry, en Europe le RIPE NCC). Cet usage des préfixes permet de limiter la portée de 6rd au seul fournisseur d’accès, rendant du même fait le travail des relais plus efficaces, puisque n’annonçant que le préfixe global de l’opérateur, et non plus le trop global préfixe 2002:: /16.

Puisque ce protocole est proposé par le fournisseur d’accès – et non plus configuré sur décision du client comme 6to4 –, ces relais sont aussi beaucoup mieux gérés : plutôt que d’avoir des entités publiques, fournies par de tierces parties, à la disponibilité et aux performances aléatoires, ceux-ci sont directement fournis par l’opérateur, qui garantit ce service et est en mesure de les dimensionner en fonction de sa clientèle. Le principe reste le même que pour 6to4, seul leur implémentation affiche une cohérence accrue, tout en ayant l’assurance que l’opérateur dispose d’un contrôle total sur cette fonction du réseau.

Ce protocole n’est toutefois pas exempt de défauts. Il est en effet nécessaire, pour que le déploiement se passe sans encombre, que l’opérateur gère l’intégralité de ses CPE, afin que celui-ci soit en mesure de supporter le protocole au niveau logiciel (mises à jour à distance, …). Les plus gros coûts d’implémentation ne concernent donc que la mise à jour des CPE et l’installation des relais 6rd, rendant cette solution particulièrement efficace, tant pour le client que pour l’opérateur. Grâce à cette méthode, le client dispose en effet d’une connectivité tant IPv4 que IPv6, malgré que le réseau de son fournisseur d’accès soit encore uniquement basé sur IPv4. La rapidité avec laquelle cette fonction peut être implémentée, ainsi que le fait qu’elle ait été implémentée avec succès par un opérateur, renforce son intérêt auprès des autres fournisseurs d’accès.

MPLS et 6PE

La technologie MPLS (MultiProtocol Label Switching) ne représente pas une solution de transition à proprement parler. Toutefois, un réseau opérateur se reposant sur MPLS pour acheminer ses paquets va permettre au fournisseur d’accès de très facilement proposer un réseau de transit supportant indistinctement IPv4 et IPv6. L’approche n’est guère différente ici des mécanismes utilisés par 6rd, puisqu’un entête (MPLS en lieu et place d’IPv4) est ajouté devant le paquet IPv6.

La seule réelle contrainte relative à IPv6 concerne les terminaisons des tunnels (les Provider Edge ou PE), au sein desquels il est nécessaire d’introduire directement les fonctions de routages nécessaires, BGP, et plus particulièrement iBGP fonctionnant au sein de l’AS (Autonomous System) du fournisseur d’accès.

Cette approche ne représente toutefois pas un mécanisme de transition à proprement parlé. Certes, sa ressemblance avec ce que propose 6rd (encapsulation, etc.) ne peut pas être dénigrée. Toutefois, MPLS est un protocole de couche inférieure à IP (souvent considéré comme une couche 2.5, intermédiaire entre la liaison de donnée – Ethernet – et le réseau – IP) et le changement de version du protocole IP n’a en soi aucun impact sur le réseau. MPLS en tant que tel est une solution permanente : un réseau MPLS n’aura que peu de modifications à apporter afin de supporter IPv6 à ses extrémités. Toutefois, implémenter MPLS pour spécifiquement faire transiter de l’IPv6 sur un réseau IPv4 ou inversement est contre intuitif, et remet en question les choix technologiques précédemment effectués par l’opérateur, sans compter que déployer une infrastructure MPLS en partant de rien aura un coût non négligeable.

Au niveau des solutions de tunneling à proprement parlé, ce sont globalement les seules grosses tendances actuelles de déploiement potentiels. Il existe toutefois des approches différentes que nous allons traiter ultérieurement : les approches compressives, qui vont tenter de limiter l’hémorragie d’adresse IPv4, et les approches translatives qui vont tenter de faire cohabiter les deux versions du protocole de front.