Vous êtes ici : Accueil Fondamentaux Choisir un fournisseur de tunnel IPv6

Choisir un fournisseur de tunnel IPv6

L’Internet connait sa phase de transition vers IPv6. Pour concevoir un prototype, il est possible d’établir sans frais une connectivité IPv6 globale (publique) à travers un réseau IPv4. Dans un réseau local maîtrisé, il est assez évident de mettre en oeuvre la double-pile « Dual Stack » IPv6/IPv4 sur les hôtes Windows et Linux. Le RFC 4213 décrit entre autres des mécanismes de mise en tunnel à des fins de transition. Dans d’autres scénarios, une alternative est la traduction.

L’Internet connait sa phase de transition vers IPv6.  Pour concevoir un prototype de type réseau d'entreprise, il est possible  d’établir sans frais une connectivité IPv6 globale (publique) à travers un réseau IPv4. Dans un réseau local maîtrisé, il est assez évident de mettre en oeuvre la double-pile « Dual Stack » IPv6/IPv4 sur les hôtes Windows et Linux. Le RFC 4213 décrit entre autres des mécanismes de mise en tunnel à des fins de transition. Dans d’autres scénarios, une alternative est la traduction.

La mise en tunnel peut intervenir au niveau de la couche 2 1, mais aussi au niveau de la couche Réseau IP et  au niveau de la couche Transport TCP/UDP. Il est amusant de reconnaître dans ce sujet des techniques de fuite d’informations 2.

Cet article fait la part des choses entre les technologies proposées par les fournisseurs de tunnel IPv6 et leur rôle dans les stratégies de transition. Chaque tunnel peut « router » un bloc global /48, gratuitement. En attendant les offres des FAI locaux, nous pouvons monter nos labs de test.

Sommaire

  1. Principe de mise en tunnel
  2. Protocoles IP 41
  3. Modèle « Tunnel Broker »
  4. Protocoles UDP/TCP
  5. Support logiciel et services
  6. Choisir un fournisseur de tunnel
  7. Notes
  8. Requests for Comments (RFCs)

Principe de mise en tunnel

Le principe technique consiste à placer la charge IPv6 dans des paquets IPv4 au niveau de la couche Réseau ou dans des paquets TCP ou UDP au niveau de la couche Transport. En quelque sorte, ces protocoles agissent en tant que couche de Liaison de données (facilité L2) virtuelle pour connecter deux points d’extrémité IPv6.

Encapsulation et désencapsulation d'IPv6 dans IPv4.
Encapsulation et désencapsulation d'IPv6 dans IPv4.

Encapsulation et désencapsulation d'IPv6 dans IPv4.

Quand le tunnel encapsule du trafic IPv6 dans IPv4, on parle de tunnel 6in4. Dans l’en-tête IPv4, le champ « Protocol » qui annonce le protocole de la charge prend la valeur 41 (soit celle qui identifie IPv6). Les adresses IPv4 utilisées dans les en-têtes doivent être globales pour assurer la connectivité IPv6. Les points d’extrémités sont définis de manière statique, ils sont alors configurés manuellement. En s’adjoignant les services d’un mécanisme Heartbeat, les points d’extrémité peuvent être définis de manière automatique comme c’est le cas avec 6in4 dit Heartbeat . Il est utile quand le FAI attribue des adresses IPv4 dynamiques. Notons enfin que le MTU du tunnel DOIT être compris entre 1280 octets et 1480 octets. Une capture de paquets 6in4 est disponible ici.

Protocoles IP41

Les protocoles qui se basent sur cette encapsulation IP41 traversent difficilement les pare-feux. Un tunnel IP 41 devrait être placé en bordure du réseau sur une passerelle d’accès à l’Internet, "pour connecter des îles IPv6 dans un océan IPv4" dans une première étape du déploiement global. En plus du protocole 6in4 déjà décrit, on peut aussi citer comme protocoles de mise en tunnel fondés sur l’encapsulation IP41 : 6to4ISATAP et  6rd3. Ces trois protocoles construisent l’identifiant d’interface du tunnel sur base de son adresse IPv4 globale. Ils sont donc incompatibles derrière un routeur NAT. Le protocole IP41 doit rester ouvert dans les pare-feux. En résumé,

  • 6to4 permet de créer automatiquement un tunnel IPv6 sur IPv4 en construisant l’identifiant d’interface IPv6 sur base de l’adresse IPv4.  La plage 2002::/16 est réservée aux tunnels montés avec le protocole. Il permet d’interconnecter facilement deux îles IPv6. Par contre, il a besoin de passerelles relais pour s’interconnecter au monde global IPv6. Teredo est la version « NAT Traversal » personnelle de 6to4.
  • ISATAP, Intra-Site Automatic Tunnel Addressing Protocol, permet la transmission de paquets IPv6 entre des noeuds dual-stack au dessus d’un réseau IPv4. Une architecture ISATAP propose un réseau de type overlay sur IPv4 au sein d’un site. Il ne propose pas de solution de connectivité IPv6 globale.
  • 6rd est une autre extension de 6to4 qui utilise le préfixe global d’un Fournisseur d’Accès à Internet plutôt que l’adressage 2002::/16 de 6to4. Cette variante supprime la nécessité de passerelle relais. Il est utilisé dans le déploiement IPV6 du FAI français Free. Il s’agit d’une solution de transition pour un FAI.

Ces solutions de mise en tunnel répondent aux besoins des Fournisseurs d’Accès Internet locaux qui gèrent eux-mêmes les POPs des clients finaux. Implementing Tunneling for IPv6 nous donne une liste des configurations possibles sous Cisco IOS :

Pour plus d’information sur les solutions de transition pour les FAI, voyez l’article Transition to IPv6 at the Service Providers.

Modèle « Tunnel Broker »

Pour obtenir une connectivité IPv6 indépendante des FAI locaux, on peut faire appel à un fournisseur de tunnel IPv6. On peut voir en lui un FAI IPV6 virtuel. Un modèle typique de fournisseur de tunnel (RFC 3053) contrôle les sessions de tunnels établies entre le client en Dual-Stack et le serveur de tunnel qui est en fait un routeur.


Modèle fournisseur de tunnel
Modèle fournisseur de tunnel

Le fournisseur de tunnel Hurricane Electric répond à ce modèle. Il supporte seulement les tunnels6in4.4

Une encapsulation au niveau de la couche transport apporte à ce modèle une série d’avantages en matière de  :

  • Sécurité, authentification
  • Facilité de gestion
  • Configuration automatique ou manuelle
  • Prise en charge d’adresses IPv4 dynamique
  • Supports des hôtes et des sites
  • Évolutivité du nombre de tunnels
  • Support du NAT Traversal
  • Découverte de services
  • Support de services spécifiques (Multicast)

On notera une surcharge au niveau des en-têtes que les encapsulations IP41 ne créent pas. Cette surcharge aura nécessairement un certain impact sur les performance du tunnel.

Protocoles UDP/TCP

Parmi les protocoles de mise en tunnel qui se basent sur une encapsulation de couche transport UDP/TCP (sur IPv4 protocoles 6 et 17) :

  • AYIYA (UDP 5072),
  • TSP (TCP 3653 ou UDP 3653) et
  • Teredo/Miredo (UDP 3544)

Ils sont plus souples avec les pare-feux à un point tel qu’ils peuvent devenir une menace pour la sécurité d’un réseau géré. Sans filtrage fin sur les passerelles, ces tunnels traversent aisément les pare-feux et les routeurs NAT. Ce qui est utile à un laboratoire devient dangereux sur un réseau d’entreprise en production.


Tunnel AYIYA

Il est utile de préciser que la connectivité ICMP echo request / echo response doit être activée pour monter ces tunnels. On notera que AYIYA et 6in4 Heartbeat utilisent aussi le protocole TIC (TCP 3874) 5. Ces derniers sont proposés par le fournisseur de tunnels IPv6 Sixxs. On citera aussi le protocole TSP est supporté par plusieurs fournisseurs de tunnels IPv6 dont Gogo6/Freenet6. On peut trouver une perspective objective de l’offre sur la page de Wikipedia (en) List of IPv6 tunnel brokers.

Teredo, « Tunneling IPv6 over UDP through Network Address Translations (NATs) », fondé sur 6to4, encapsule le trafic IPv6 dans des paquets UDP (port 3544) et utilise  une version simplifiée de STUN NAT Traversal. Il traverse certains pare-feux NAT. Les identifiants d’interface IPv6 sont attribués dans la plage 2001::/32, d’une dérivation des adresses IPv4 natives. L’identifiant d’interface IPv6 généré peut donc changer. Il ne permet pas de router des sous-réseau. Une offre publique de serveurs publics est disponible.

Si ces mécanismes offrent plus de souplesses, il génère plus de surcharge6 dans les en-têtes que les tunnels IP 41.

Support logiciel et services

Sixxs dispose d’un client multi-OS AICCU (bien supporté sur Linux ou sur BSD), les POPs sont nombreux, le service est sérieux.

Hurricane Electric opte pour la simplicité avec 6in4 mais supporte mal les infrastructures protégées. Hurricane Electric délivre une auto-certification IPv6 intéressante.

Gogo6/Freenet6 reste à tester.

Choisir un fournisseur de tunnel

Si la mise en tunnel est une solution de transition vers IPv6, elle consiste aussi en une menace pour les réseaux d’entreprise. En laboratoire, la solution est aisée à mettre en place. En entreprise, elle permet d’envisager la construction de pilotes ou la consolidation d’infrastructures réseaux de manière durable.

Pour choisir un fournisseur de tunnel, on sera attentif aux éléments qui pourraient filtrer le trafic IPv6 transporté de bout en bout dans sa topologie. Ensuite, on choisira sa méthode de transition soit en fonction de l’encapsulation (couche 2, 3 et 4), soit en fonction de l’usage ou du modèle à déployer (sénario FAI, Site-to-Site, connectivité virtuelle, IPv6-only site, etc.) ainsi qu'en fonction du plan d'adressage (/64, /56/, /48 voire plus).

Références

Requests for Comments (RFCs)

Design

  • IPv6 Tunnel BrokerRFC 3053, January 2001.

6in4

  • Transition Mechanisms for IPv6 Hosts and Routers.RFC 4213, October 2005.

6to4

  • Connection of IPv6 Domains via IPv4 CloudsRFC 3056, February 2001.
  • An Anycast Prefix for 6to4 Relay RoutersRFC 3068, June 2001.
  • Security Considerations for 6to4RFC 3964, December 2004.
  • Advisory Guidelines for 6to4 DeploymentRFC 6343, August 2011.

ISATAP

  • Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)RFC 5214, March 2008.

6rd

  • IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol SpecificationRFC 5969, August 2010.
  • IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)RFC 5569, January 2010.

AYIYA

TSP

  • IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)RFC 5572, February 2010.
  • Simple Authentication and Security Layer (SASL)RFC 4422, June 2006.

Teredo/Miredo

  • Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)RFC 4380, February 2006.

Notes

  1. Tunneling Protocol version 2 (L2TPv2) hub-and-spoke, RFC 5571
  2. parmi les exemples, http://www.hsc.fr/ressources/articles/sstic06/SSTIC06-article-Lehembre_Thivillon-Detection_de_tunnels.pdfhttp://www.unixgarden.com/index.php/misc/tunnels-dns-fuite-dinformation-universellehttp://www.unixgarden.com/index.php/misc/895
  3. 6over4 est obsolète. Il ne faut pas le confondre avec 6in4 ou 6to4. 
  4. Il n’est pas impossible de faire fonctionner ces tunnels derrière certains routeurs/NAT. Derrière des pare-feu dignes de ce nom, en entreprise ou sur le lieu de formation, il n’est pas aisé d’établir ces services avec succès. 
  5. Tunnel Information and Control protocol : http://www.sixxs.net/tools/tic/
  6. http://www.sixxs.net/faq/connectivity/?faq=comparison
Mots-clés associés : , , , , , ,