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.
