Mon blog

6to4 en anycast, c'est fini ! Cette technique de transition entre IPv4 et IPv6, reposant sur des tunnels établis automatiquement, a pu être utile à un moment pour faciliter l'accès à IPv6 depuis les opérateurs qui étaient en retard pour le déploiement. Mais elle a plein de défauts techniques, qui ont contribué à donner une mauvaise image d'IPv6. Elle est donc marquée par ce RFC comme officiellement abandonnée.

C'est dans le RFC 3068 que 6to4+anycast était normalisé (il existe plein d'autres techniques de transition). Le principe était d'avoir des relais anycast qui recevaient les paquets IPv6 encapsulés dans de l'IPv4, tunnelant ainsi le trafic IPv6 au-dessus d'opérateurs restés en IPv4. Pour éviter d'avoir à configurer manuellement ces relais, une correspondance existait entre les adresses IPv4 des machines, et des adresses IPv6 attribuées dans un préfixe spécifique à 6to4, le 2002::/16 (le réseau IPv6 associé à une adresse IPv4 était 2002:adresse-IPv4::/48). Des outils comme whois connaissaient ce préfixe et savaient donc faire une recherche « intelligente » (ici, d9ae:c921 = 217.174.201.33) :

% whois 2002:d9ae:c921::1

Querying for the IPv4 endpoint 217.174.201.33 of a 6to4 IPv6 address.
...
[affichage des informations au sujet de 217.174.201.33]

Un autre préfixe, en IPv4, était attribué aux relais, pour que les mécanismes de l'anycast trouvent ensuite le relais le plus proche. C'est ce second préfixe, 192.88.99.0/24, qui est retiré du service par ce RFC. En outre, le RFC 3068 est désormais marqué comme « intérêt historique seulement ».

La première version de ces tunnels automatiques, spécifiée dans le RFC 3056, utilisait un adressage unicast. C'est avec le RFC 3068 que 6to4 est passé à l'anycast. Les relais étaient gérés par des tas de volontaires situés sur la planète mais, en pratique, beaucoup marchaient mal ou pas du tout et l'anycast ne permettait pas de garantir qu'on tombe sur un relais valide, encore moins sur un relais proche et rapide. L'étude « Flailing IPv6 » a montré la quantité de problèmes que posait 6to4. Un test avec les sondes RIPE Atlas montre 23 % de timeout sur un serveur 6to4, 2002:d9ae:c921::1, contre 10 % pour une adresse IPv6 native. En test DNS, 343 sondes Atlas sur 470 répondent pour l'adresse 2002:d9ae:c921::1, contre 490 sur 500 pour l'adresse IPv4 du même serveur, 217.174.201.33.

Un résultat tragique de cette mauvaise qualité a été de ralentir le déploiement d'IPv6, bien des utilisateurs coupant IPv6 lorsqu'ils découvraient la lenteur et les pannes de 6to4, bien des gérants de serveurs ne fournissant pas IPv6 de peur que cela entraine une dégradation de la qualité de service.

Le RFC 6343 analysait le problème et faisait des recommandations pour améliorer 6to4. Il recommandait que 6to4 soit coupé par défaut (un scénario commun, avant, était que 6to4 était activé sans demande explicite, le trafic IPv6 passait par un relais lointain, et l'utilisateur en concluait qu'IPv6 était lent) : « it should always be a conscious decision by a user to enable 6to4 ». Le RFC 6343 recommandait aussi de suivre l'algorithme des « globes oculaires heureux » du RFC 6555, afin de masquer les défaillances éventuelles d'une des familles, IPv4 ou IPv6.

Mais ces conseils, quoique assez largement mis en œuvre, ne suffisent pas, et les serveurs accessibles en IPv6 voient toujours du trafic 6to4.

À noter que la technologie 6rd, normalisée dans le RFC 5969, est très proche de 6to4 mais s'en distingue par l'utilisation d'un préfixe IPv6 lié au fournisseur d'accès. Les relais, au lieu d'être gérés un peu partout par des volontaires inconnus, sont donc forcément sous la houlette du FAI qui utilise 6rd, et il peut donc garantir une voie de retour. 6rd n'est donc pas concerné par les critiques de notre RFC.

La section 3 revient en détail sur les problèmes rencontrés avec 6to4. Elle rappelle que les routes peuvent être asymétriques (un relais différent à l'aller et au retour). Si le choix du relais aller peut être contrôlé (par exemple par des préférences BGP pour telle ou telle annonce du préfixe 192.88.99.0/24), le chemin de retour échappe complètement au nœud 6to4, qui ne peut pas être sûr que ses pairs utiliseront un « bon » relais. C'est le cœur du problème de 6to4. (Notez bien que cela ne concerne que le mode anycast, avec le prefixe standard. Des variantes de 6to4, avec un préfixe contrôlé par le FAI, ou avec de l'unicast vers des relais connus, ne sont pas concernées par ce RFC. C'est par exemple le cas de 6rd, cité plus haut)

La section 4 du RFC contient les décisions formellement prises :

• Le mécanisme d'anycast de 6to4 du RFC 3068 est abandonné,
• Le préfixe 192.88.99.0/24 est marqué comme abandonné (dans le registre IANA),
• Le 6to4 en unicast du RFC 3056 reste utilisable, tout comme le préfixe 2002::/16, c'est uniquement son annonce en anycast qui est abandonnée,
• Les règles de sélection de l'adresse source du RFC 6724 ne sont pas modifiées (elles donnent la priorité à IPv4 sur 6to4, contrairement aux règles de son prédécesseur, le RFC 3484).

Comme indiqué dans la section 5, il est déconseillé d'inclure 6to4+anycast dans les mises en œuvre d'IPv6 et, si on le fait, il faut qu'il soit désactivé par défaut. (Bien des CPE IPv6 avaient imprudemment activé ce mécanisme par défaut, pour fournir une connectivité IPv6 dans tous les cas, même au-dessus d'un opérateur resté uniquement à IPv4.)

En revanche, contrairement à ce qui avait parfois été proposé, notre RFC ne formule pas de recommandations sur le filtrage des annonces de route 6to4 (un tel filtrage bloquerait 6to4 chez l'opérateur qui le ferait). Il conseille par contre aux actuels opérateurs de relais 6to4 de se poser sérieusement la question « est-ce que c'est vraiment la peine de continuer ? » Ces recommandations (ou absence de recommandations) avaient fait l'objet des plus vigoureuses discussions au sein du groupe de travail à l'IETF.