Résumé

  • En 2001, 6to4 permettait de dériver, à partir d’une adresse IPv4 publique, un préfixe IPv6 dans 2002::/16, puis de traverser IPv4 sans négocier à l’avance chaque tunnel.
  • L’anycast a ensuite rendu le relais presque invisible, mais l’aller et le retour pouvaient dépendre d’opérateurs différents et sans responsabilité commune. Filtres, mauvaises routes et activation par défaut ont transformé la commodité en panne récurrente.
  • En 2015, la RFC 7526 a déprécié le mécanisme de relais anycast. Elle n’a déprécié ni le 6to4 unicast de base ni 2002::/16 — distinction essentielle pour lire le registre actuel.

Une adresse avant l’accord

La partie la plus mémorable de 6to4 tient dans un calcul. On prend les 32 bits d’une adresse IPv4 globalement unique, on les place après le préfixe 2002, et le site obtient un /48. La RFC 3056 écrivait ce résultat 2002:V4ADDR::/48. Un réseau sans accès IPv6 natif pouvait distribuer en interne des adresses de ce préfixe. À sa frontière, un routeur 6to4 encapsulait directement le paquet IPv6 dans IPv4, avec le protocole 41.

Publiée en février 2001, la RFC 3056 qualifiait le dispositif de mécanisme transitoire facultatif. Elle ne le présentait pas comme l’architecture définitive d’IPv6. Sa promesse était plus étroite et très concrète : relier des sites par l’Internet IPv4 sans configurer un tunnel pour chaque correspondant et sans obtenir d’abord, pour cet usage, un préfixe IPv6 ordinaire. L’adresse IPv4 servait à la fois de matière première et de localisateur.

La facilité avait des limites dès le départ. Une adresse IPv4 privée ne pouvait pas produire un préfixe 6to4 valable mondialement. Si l’adresse IPv4 changeait, le préfixe IPv6 dérivé changeait aussi. Et il fallait toujours quelqu’un pour transporter les paquets entre l’univers 6to4 et l’IPv6 natif. La construction de l’adresse était automatisée ; la joignabilité universelle ne l’était pas.

Le relais devenu invisible

Entre deux sites 6to4, l’adresse IPv4 inscrite dans chaque préfixe indiquait à l’autre extrémité où envoyer le tunnel. Entre un site 6to4 et une destination IPv6 native, il fallait en revanche un relais capable de comprendre les deux mondes.

La RFC 3068 a apporté une réponse d’une grande simplicité : attribuer aux routeurs relais une même adresse IPv4 anycast, 192.88.99.1. Le routeur 6to4 envoyait les paquets vers cette adresse et le routage IPv4 ordinaire choisissait un relais annonçant la route, en principe proche. L’utilisateur n’avait plus à découvrir ni à configurer une passerelle précise. Ce qui exigeait auparavant un arrangement opérationnel pouvait désormais ressembler à un interrupteur.

Cet interrupteur masquait une asymétrie. Le relais choisi à l’aller n’était pas nécessairement celui du retour. Un réseau IPv6 natif qui envoyait vers 2002::/16 pouvait choisir un autre relais, exploité par une autre organisation et atteint par une autre politique de routage. Les deux relais n’avaient pas à se connaître. Le succès dépendait de plusieurs organisations fournissant des services compatibles, mais le mécanisme n’établissait entre elles ni contrat ni propriétaire unique de l’aller-retour.

Le problème n’était pas visible dans le format de l’adresse. Une adresse 6to4 parfaitement valide pouvait rencontrer un pare-feu bloquant le protocole 41, une annonce de relais absente, un relais mal placé ou une route de retour menant au néant. Le préfixe pouvait être correct et l’expérience échouer.

Quand le repli masquait la facture

La RFC 3964, publiée en 2004, s’est concentrée sur la sécurité. Un relais devait vérifier si la source IPv4 du tunnel correspondait à l’adresse IPv4 incorporée dans la source 6to4. Sans filtrage, du trafic falsifié pouvait être réfléchi, blanchi par le système de transition ou rendu plus difficile à attribuer. Le texte ne prétendait pas que chaque relais était hostile ; il montrait qu’une encapsulation automatique franchissait des frontières de confiance que l’adresse ne pouvait surveiller seule.

En 2011, la RFC 6343 pouvait décrire un bilan opérationnel plus large : filtres bloquant le protocole 41, relais absents ou injoignables, chemins fonctionnant dans un sens mais pas dans l’autre. Elle citait des expériences contemporaines où les échecs de connexion 6to4 se situaient approximativement entre 9 et 20 %. Ce n’était pas un recensement mondial, mais assez pour faire d’un auxiliaire de transition un problème de fiabilité visible.

Le coût était souvent dissimulé, non supprimé. Une application double pile pouvait essayer IPv6, attendre l’échec de 6to4, puis revenir à IPv4. Pour l’utilisateur, la page semblait simplement lente. Les éditeurs de logiciels ont donc eu intérêt à préférer les chemins natifs fiables et à mettre les solutions en concurrence, comme l’ont fait plus tard des stratégies telles que Happy Eyeballs. Chaque couche réduisait son symptôme sans attribuer la responsabilité manquante du système de relais.

L’activation par défaut a prolongé le phénomène. Sans avoir demandé 6to4, un utilisateur pouvait recevoir une adresse dérivée et une route IPv6 apparente de son système ou de son équipement de bord. La RFC 6343 a qualifié cette pratique de mauvaise et recommandé une désactivation par défaut. Le renversement était révélateur : la fonction appréciée parce qu’elle demandait peu de coordination devait désormais exiger une décision éclairée pour être activée.

Déprécier le raccourci sans effacer l’histoire

En mai 2015, la RFC 7526 a officialisé le recul. Elle a déprécié le mécanisme anycast 6to4, fait passer les RFC 3068 et 6732 au statut « Historic » et demandé l’arrêt de l’annonce anycast et du service de relais 192.88.99.1. Les implémentations devaient désactiver 6to4 par défaut. Le raccourci public ne constituait plus une infrastructure de transition recommandée.

La portée de cette décision est facile à déformer. La RFC 7526 a explicitement indiqué qu’elle ne dépréciait pas le mécanisme unicast de base de la RFC 3056, ni le préfixe 2002::/16. Le registre IANA des adresses IPv6 à usage spécial répertorie toujours ce bloc comme 6to4. Une inscription au registre décrit une allocation architecturale ; elle ne garantit ni la disponibilité ni la pertinence d’un relais public.

Cette distinction explique pourquoi l’histoire ne se termine pas par une suppression. Le processus de normalisation pouvait retirer une recommandation opérationnelle tout en conservant le vocabulaire nécessaire pour reconnaître anciennes adresses, arrangements gérés et systèmes résiduels. Aujourd’hui, 2002::/16 est un indice du mécanisme, pas la preuve que le service anycast a survécu à son examen.