Interopérabilité avec les services IPv4 par passerelles applicatives

Principe des passerelles applicatives

Les relais applicatifs ou ALG (Application Level Gateway) représentent le moyen le plus simple pour assurer une relation entre le monde IPv4 et le monde IPv6. Il s'agit de machines avec une double pile (cf. figure Exemple de relais applicatif pour le courrier électronique) configurées pour accéder aux deux versions du protocole. Les clients IPv6 émettent leurs requêtes vers le relais applicatif comme s'ils s'adressaient directement au service. Le relais interprète le contenu de ces requêtes pour les retransmettre ensuite en IPv4 à destination du service concerné.

Un ou plusieurs relais peuvent être installés en fonction des services rendus disponibles sur le réseau (par exemple serveur d'impression, serveur de messagerie, relais http, ...). Les machines clientes doivent être configurées pour adresser leurs requêtes applicatives à ces relais.

L'usage de ces techniques est très fréquent dans les réseaux privés pour communiquer avec l'extérieur. Tous les protocoles ne peuvent pas utiliser les relais applicatifs. Certains protocoles ne sont pas prévus pour intégrer un relai intermédiaire (par exemple telnet). D'autres protocoles, par leur nature propriétaire, ne permettent pas le développement de passerelles par de tièrce partie si celle ci n'est pas disponible (comme par exemple Skype). Mais comme la liste suivante l'indique, les ALG concernent des applications courantes qui représentent une partie importante du trafic. Cela permet également d'alléger le travail d'autres mécanismes de transition qui sont plus complexes à mettre en œuvre.

Les relais applicatifs regroupent :

• les proxies et les caches web,
• les spoolers d'impression,
• les serveurs de courrier électronique,
• les serveurs DNS,
• ...

Exemple pour l'interopérabilité avec les services web

Il s'agit ici de faire communiquer des clients avec des services Web, chacun utilisant une version différente du protocole IP. La passerelle applicative utilisée dans ce cas est un relai HTTP qui va interpréter les requêtes des clients pour les retransmettre vers le serveur Web. Deux modèles de déploiement existent pour ce type de relai :

• le déploiement d'un serveur mandataire (proxy) dans le réseau des clients, leur permettant d'atteindre les serveurs extérieurs, dont ceux qui n'utilisent pas la même version du protocole IP,
• le déploiement d'un relai inverse (reverse proxy) dans le réseau du serveur, permettant d'accepter les requêtes des clients qui n'utilisent pas la même version du protocole IP que le serveur.

Interopérabilité côté clients

La passerelle HTTP est ici localisée dans le réseau des clients, généralement dans la DMZ du site ou sur le routeur domestique. Les clients sont configurés pour utiliser cette passerelle en tant que serveur mandataire afin d'atteindre les services Web extérieurs. Ce type de déploiement est couramment utilisé pour sécuriser les accès Web depuis les clients de sites malveillants.

Afin de permettre l'interopérabilité entre les différentes versions du protocole IP, la passerelle est connectée et configurée sur un réseau double pile. Si par exemple les clients sont sur un réseau seulement IPv6, l'adresse IPv6 de la passerelle leur est indiquée en tant que serveur mandataire. La passerelle recevra alors les requêtes HTTP de ces clients et les relaiera vers les services demandées en IPv4 ou en IPv6 selon le protocole utilisé par le serveur.

• Client IPv6
• Proxy web double pile en coupure du réseau des clients
• Service IPv4

Le listing suivant donne un extrait de la configuration d'un serveur Apache pour que celui-ci serve de relais aux requêtes émises par des navigateurs. Aucune configuration n'est relative au protocole IPv6. Il suffit d'activer la fonction de proxy.

#cat /usr/local/etc/apache/httpd.conf
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
<Directory proxy:*>
Order deny,allow
Allow from all
</Directory>
#
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server ver.;"Block" removes all outgoing Via: headers)
# Set to one of: Off | On | Full | Block
#
ProxyVia On
</IfModule>
# End of proxy directives.

Interopérabilité côté service

Problématiques

La problématique ici à résoudre est de rendre un service Web accessible avec les 2 versions du protocole IP alors que celui-ci n'en utilise qu'une seule. S'ajoute à cette problématique la contrainte opérationnelle du service : le fonctionnement du site web sera-t'il perturbé par l'intégration d'IPv6 ? L'expérience utilisateur des visiteurs va-t'elle être impactée ?

Pour rendre accessible un service Web en IPv6, la solution la plus simple consiste à activer la connectivité IPv6 sur le réseau où est connecté ce service, ainsi que sur la machine qui l'héberge. Mais cette solution pose un ensemble de problème opérationnel car l'infrastructure d'hébergement d'un site Web peut être assez complexe (système d'équilibrage de charge ou load balancers, cache, etc.). Une réelle étude du passage à IPv6 de cette infrastructure peut être nécessaire pour effectuer une transition pérenne.

Le RFC 6883 décrit les problématiques et quelques solutions pour permettre l'interopérabilité avec IPv6 des fournisseurs de contenu.

Déploiement d'un relai inverse

Une solution moins coûteuse et plus rapide à mettre en oeuvre (mais avec bien sûr quelques limitations) consiste à déployer un relai inverse (reverse-proxy) proche du serveur. Le rôle de ce relai est d'accepter les requêtes vers le service Web utilisant la version du protocole qui n'est pas encore déployée sur le serveur. Les clients envoient leur requête au relai de manière transparente, comme s'il s'agissait du service. Le relai se charge pour le client de transférer les requêtes vers le serveur et de recevoir sa réponse, en utilisant le protocole IP déployé sur le serveur.

Dans la mise en oeuvre du relai inverse, une étape importante consiste en la configuration du DNS. En effet, l'adresse du relai doit être renseignée comme l'une des enregistrements pour le service concernée. Ainsi par exemple, pour un service seulement accessible en IPv4, l'adresse IPv6 du relai sera renseignée comme enregistrement AAAA au même niveau que l'enregistrement A de l'adresse du serveur.

Le scénario d'intégration d'IPv6 sur un service Web par un relai inverse est illustré par les schémas suivant :

Dans le contexte initial, le service Web n'est accessible qu'en IPv4. L'adresse IPv4 du service est enregistrée dans le DNS, celle-ci est récupérée par les clients à partir du nom du service afin d'initier une connexion vers le serveur.

L'intégration d'IPv6 dans cette architecture passe par 2 actions :

• La mise en place d'un relai inverse dans l'infrastructure du service, sur un réseau double-pile
• L'enregistrement de l'adresse IPv6 du relai comme l'adresse IPv6 officielle du serveur

Un client possédant une connectivité IPv6 et souhaitant consulter le service va résoudre le nom du service en 2 adresses, une IPv4 et une IPv6. La préférence à IPv6 du navigateur lui fera utiliser en priorité cette adresse. Sa requête se fera alors de manière transparente à destination du proxy.

Le relai inverse propose donc une solution simple pour assurer une interopérabilité de son service Web avec IPv6. Cependant elle n'est pas adaptée à des sites à large audience. Même largement dimensionné, un unique relai ne pourrait pas absorber la portion IPv6 des requêtes, même si celle-ci est encore en dessous des 10%. De plus le relai constitue un point de faiblesse unique (SPOF, Single Point of Failure) pouvant compromettre l'accès au service.

Utilisation d'un service d'hébergement ou de distribution des contenus

Pour ces sites à large audience, plusieurs solutions peuvent être envisagées pour permettre l'interopérabilité avec IPv6 :

• Migrer son infrastructure d'hébergement en double-pile (comme mentionné plus haut, cette solution est la plus complexe)
• Faire appel à un service d'hébergement offrant une connectivité double-pile
• Continuer à héberger son service en IPv4, mais utiliser un réseau de distribution de contenus (CDN, Content Delivery Network) double-pile.

Les 2 dernières solutions permettent au responsable du service de déléguer la complexité de l'intégration et de la gestion d'IPv6 à un prestataire extérieur. Ces services sont aujourd'hui assez répandus. Les hébergeurs de sites Web offrent maintenant couramment un accès double-pile aux services hébergés, que ce soit sur des offres de serveurs mutualisés ou dédiés. Toutes les prestations d'hébergement des acteurs majeurs en France que sont OVH, Gandi ou Online, intègrent IPv6 dans leurs offres.

Les réseaux de distribution de contenus (ou CDN) ont pour objectif de répliquer le contenu du service en différents points stratégiques du réseau, permettant aux utilisateurs d'accéder plus rapidement au service et de soulager l'infrastructure du service d'une partie du trafic. Les CDNs peuvent en bonus permettre l'interopérabilité avec IPv6 en jouant le même role que le relai inverse, avec bien sûr une infrastructure plus robuste. Des services de CDN comme Akamai ou CloudFlare permettent ainsi d'offrir des contenus en IPv6 alors que ceux-ci sont hébergés sur des services seulement IPv4.

Conclusion