Méthodes de transition IPv6

En cours de rédaction.

https://en.wikipedia.org/wiki/IPv6_transition_mechanism

1. Méthodes de transition IPv6

La transition est train de se réaliser du coeur du réseau des opérateurs jusqu’au client final. Cette transition pourrait prendre 5 à 10 ans. La disponibilité de la connectivité IPv6 dépend du moment de son déploiement global. Le RFC 4213 décrit trois méthodes de transition.

• Dual Stack, double pile IPv4/IPv6, de loin la préférée, la plus probable à moyen terme.
• Tunnels : solution de transition pour transporter de l’IPv6 sur de l’IPv4 et, à terme, de transporter de l’IPv4 dans de l’IPv6 (plusieurs protocoles pour plusieurs scénarios), pourraient probablement se généraliser à court terme.
• Traduction, mécanismes peu recommandés en local. Plutôt exploité chez les ISP pour connecter IPv6 à IPv4 ou les GE. Exemple : NAT64/DNS64

2. Mise en tunnel

La mise en tunnel peut intervenir au niveau de la couche 2 (L2)¹, mais aussi au niveau de la couche Réseau IP (L3), au niveau de la couche Transport TCP/UDP (L4) et même au-delà dans la couche Application (L7). Il est amusant de reconnaître dans ce sujet des techniques de fuite d’informations.

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.

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 IP41 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 : 6to4, ISATAP et 6rd ². 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 :

• Overlay Tunnels for IPv6
• IPv6 Manually Configured Tunnels
• GRE IPv4 Tunnel Support for IPv6 Traffic
• GRE Support over IPv6 Transport
• mGRE Tunnels Support over IPv6
• GRE CLNS Tunnel Support for IPv4 and IPv6 Packets
• Automatic 6to4 Tunnels
• Automatic IPv4-Compatible IPv6 Tunnels
• IPv6 Rapid Deployment Tunnels
• ISATAP Tunnels
• IPv6 IPsec Site-to-Site Protection Using Virtual Tunnel Interface

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.

Le fournisseur de tunnel Hurricane Electric répond à ce modèle. Il supporte seulement les tunnels 6in4 ³.

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.

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).

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, ils génèrent plus de surcharge dans les en-têtes que les tunnels IP41.

IP-HTTPS

IP over HTTPS (IP-HTTPS) Protocol, a mechanism to transport IPv6 packets on an HTTPS connection over TCP port 443.

The IP over HTTPS (IP-HTTPS) Protocol allows encapsulation of IPv6 traffic over HTTPS. To do so, it depends on the following protocols:

• Hypertext Transfer Protocol – HTTP/1.0 [RFC1945].
• Hypertext Transfer Protocol – HTTP/1.1 [RFC2616].
• HTTP Over TLS [RFC2818].
• Tunneling SSL Through a WWW Proxy [SSLPROXY].
• The Transport Layer Security (TLS) Protocol Version 1.1 [RFC4346].

Once the underlying transport is established, IP-HTTPS enables IPv6 traffic exchanges per usual IPv6 specifications such as:

• Neighbor Discovery for IP Version 6 (IPv6) [RFC4861].
• Protocol, Version 6 (IPv6) Specification [RFC2460].

Note The IP-HTTPS Protocol itself does not have any security or authentication methods. Instead, it relies on HTTPS for authentication, data integrity, and confidentiality.

The relationship between these protocols is illustrated in the following diagram:

Microsoft used to discourage IP-HTTPS use because it was slow.⁴

For Windows Server 2012, Microsoft changed the internal workings of the protocol, and IP-HTTPS is now the “preferred IPv6 transition technology” for their “DirectAccess” VPN technology. ⁵

Références

• Tunnel Broker, Wikipedia (en).
• Tim Chown, IPv6 Transition and Integration with IPv4, 6diss, http://www.6diss.org/tutorials/transitioning.pdf

Design

• IPv6 Tunnel Broker. RFC 3053, January 2001.

6in4

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

6to4

• Connection of IPv6 Domains via IPv4 Clouds. RFC 3056, February 2001.
• An Anycast Prefix for 6to4 Relay Routers. RFC 3068, June 2001.
• Security Considerations for 6to4. RFC 3964, December 2004.
• Advisory Guidelines for 6to4 Deployment. RFC 6343, August 2011.

ISATAP

• Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). RFC 5214, March 2008.
• 6rd
• IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol Specification. RFC 5969, August 2010.
• IPv6 Rapid Deployment on IPv4 Infrastructures (6rd). RFC 5569, January 2010.

AYIYA

• Connection of IPv6 Domains via IPv4 Clouds. RFC 3056, February 2001.
• AYIYA: Anything In Anything. http://tools.ietf.org/html/draft-massar-v6ops-ayiya-02, July 2004.

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.

IP-HTTPS

• https://msdn.microsoft.com/en-us/library/dd358571.aspx

3. Traduction

NAT64 / DNS64