Summary

  • Dans un récit publié par ARIN en 2019, Matthew Wilder décrit les essais en laboratoire puis la participation volontaire de salariés de TELUS avant un déploiement plus large.
  • Ces essais ont révélé un détail décisif : les réponses DNS en AAAA étaient configurées, mais la connectivité vers les routes DNS en IPv6 n'était pas activée.

Le serveur avait appris sa réplique. Restait à ouvrir la porte de la salle. Dans son témoignage conservé par ARIN, Matthew Wilder raconte que TELUS avait configuré le DNS pour renvoyer des enregistrements AAAA. Des sites d'essai ont ensuite montré que l'accès aux routes DNS en IPv6 n'était pas encore en service. Un contrôle de configuration validait une moitié du parcours ; l'utilisateur devait parcourir les deux.

Le travail ne se limitait pas au DNS. TELUS avait mis l'IPv6 à disposition de ses abonnés Internet résidentiels dès 2015, puis avançait progressivement sur le mobile. Wilder détaille des choix de préfixes : /56 pour les foyers, /48 pour les sites professionnels, /64 pour les abonnés mobiles. La société avait aussi demandé à ARIN d'étendre son allocation de /32 à /29 afin de disposer d'une structure adaptée à sa géographie et à son routage. Il s'agit des chiffres exposés par l'ingénieur en 2019.

L'enchaînement des travaux explique pourquoi une telle lacune pouvait survivre. Il fallait vérifier les interconnexions et le transit, rendre le cœur et les points d'accès compatibles, puis passer par les services partagés et les produits. Wilder mentionne une formation qui touchait aussi l'exploitation et l'assistance. Chaque équipe détenait une pièce du trajet, sans pouvoir tester seule le voyage complet.

Avant de généraliser, des salariés volontaires ont utilisé leurs propres services après les essais en laboratoire. Ils ont vérifié notamment le MTU et le DNS. L'erreur de route est apparue dans cette étape intermédiaire. Voilà le mérite de l'essai limité : il fait passer une hypothèse technique devant de vrais usages pendant qu'elle coûte encore peu à corriger.