Pourquoi l’IPv6 ne fonctionnait-il pas sur mon réseau domestique ?

• Sur le réseau domestique, ping google.com réussissait mais ping6 google.com échouait ; la cause était que les requêtes DNS IPv6 étaient désactivées dans la configuration de Adguard Home DNS
• ACT broadband ne prenait pas en charge IPv6 par le passé, mais il a été confirmé qu’un déploiement progressif était en cours pour les utilisateurs de Chennai, et l’activation d’IPv6 sur le routeur permettait alors un fonctionnement normal
• Lors de récents tests réseau, le problème IPv6 est réapparu, mais le portail d’administration du routeur confirmait bien l’existence de la connexion IPv6 de l’ISP, et le même problème a pu être reproduit sur macOS comme sur un Raspberry Pi
• dig AAAA google.com ne renvoyait aucun résultat DNS, ce qui a permis de réduire le périmètre du problème : il ne venait ni de la connexion ISP ni de la configuration client, mais du serveur DNS chargé de traiter les requêtes d’enregistrements AAAA
• Le problème venait d’un réglage apparu après la migration du DNS vers Adguard Home l’an dernier ; une fois le bouton de blocage des requêtes DNS IPv6 désactivé, ping -4 et ping -6 ont tous deux réussi avec 0 % de perte de paquets

---

Cause et résolution

• Sur le réseau domestique, ping google.com réussissait mais ping6 google.com échouait ; la cause finale était que toutes les requêtes DNS IPv6 étaient désactivées dans la configuration de Adguard Home DNS
• ACT broadband n’a pas pris en charge IPv6 pendant un certain temps, mais il a été confirmé il y a quelques années qu’un déploiement progressif était en cours pour les utilisateurs de Chennai, et après activation d’IPv6 sur le routeur, tout fonctionnait normalement à l’époque
• Récemment, en testant les connexions réseau après avoir réorganisé l’espace de bureau, le problème IPv6 est réapparu, tandis que le portail d’administration du routeur confirmait bien l’existence de la connexion IPv6 fournie par l’ISP
• Dans les réglages réseau de macOS, IPv6 était également autorisé, et le même problème s’est reproduit sur un Raspberry Pi connecté en LAN au routeur, ce qui rendait peu probable un problème propre à un seul appareil
• Pour tester directement une adresse IPv6, la commande dig AAAA google.com a été exécutée, mais aucun résultat DNS n’est apparu ; comme Google prend en charge IPv6, un problème côté serveur DNS est devenu suspect
• Après s’être souvenu que le DNS avait été migré vers Adguard Home l’an dernier, la configuration du serveur DNS a été vérifiée, et un petit bouton bloquant les requêtes DNS IPv6 a été découvert
• Une fois ce réglage désactivé et enregistré, IPv4 comme IPv6 ont de nouveau fonctionné normalement

Processus de vérification et résultats

• Vérification des symptômes

  • La résolution de noms et la connexion en IPv4 fonctionnaient normalement
  • La résolution de noms ou la connexion en IPv6 échouait
  • Les tests de base utilisés étaient les suivants

    ping google.com
    ping6 google.com
    

• Vérification de l’ISP et de la configuration des appareils

  • L’hypothèse initiale était que l’ISP avait peut-être de nouveau désactivé IPv6, mais la connexion IPv6 était bien visible dans le portail d’administration du routeur
  • Dans les réglages réseau de macOS aussi, IPv6 était autorisé
  • Le même problème se produisait également sur le Raspberry Pi, ce qui rendait peu crédible l’idée d’un problème limité à la configuration d’un seul client
  • Comme un serveur DNS local était utilisé, les adresses des serveurs DNS IPv6 du routeur ont aussi été comparées à l’adresse IP de l’interface Ethernet du Raspberry Pi

• Les indices qui ont permis de cibler le DNS

  • Pour écarter un problème de transmission du DNS IPv6 par DHCP, il a été tenté de vérifier directement l’adresse IPv6, et dig AAAA google.com n’a renvoyé aucun résultat
  • À ce stade, le problème ne semblait plus venir de la connexion ISP ni de l’activation d’IPv6 côté client, mais du serveur DNS chargé de traiter les requêtes d’enregistrements AAAA

• Validation après correction

  • Après avoir désactivé le bouton qui bloque les requêtes DNS IPv6 dans les réglages d’Adguard Home, ping -4 et ping -6 ont tous deux réussi
  • Le test IPv4 vers 172.217.24.110 a envoyé 5 paquets, en a reçu 5, avec 0 % de perte
  • Le test IPv6 vers 2404:6800:4007:817::200e a envoyé 5 paquets, en a reçu 5, avec 0 % de perte
  • Activer IPv6 apporte des avantages comme une latence réduite, de meilleures connexions P2P sans nécessité de NAT traversal, ainsi que SLAAC

[GN⁺]

Avis sur Lobste.rs

• C’est affreux, et AdGuard Home devrait avoir honte

  • On dirait que ce réglage n’est pas activé par défaut
    J’utilise aussi AdGuard Home, et ici c’est désactivé ; comme j’ai remplacé ma configuration/mon routeur il y a moins de deux semaines, je suis à peu près certain de ne pas y avoir touché

• Je ne comprends pas pourquoi une telle fonctionnalité existe

  • Parce que l’ensemble de la communauté du blocage publicitaire DNS, en particulier autour d’AdGuard et de Pi-hole, a historiquement été assez hostile à IPv6 et aux réseaux dual-stack
    Quand quelqu’un demande de l’aide pour ce type de service, que ce soit via les canaux de support officiels ou dans les communautés du projet comme les forums, Discord ou les subreddits, la première recommandation reste souvent de « désactiver IPv6 »

• IPv6 a une mauvaise conception et il est facile de se tromper dans la configuration, donc le conseil le plus évident devient de le désactiver

• Je viens justement de déboguer le problème inverse : IPv4 ne fonctionnait pas sur mon réseau domestique
  C’était un service IPv6-only utilisant DS-Lite pour la connectivité IPv4, et avec DS-Lite le routeur domestique tunnelise les paquets IPv4 vers l’AFTR, le NAT de l’opérateur
  Le domaine de l’AFTR est fourni via DHCPv6 et, dans mon cas, avait la forme something.aftr.kabelbw.de, mais actuellement ce domaine ne se résout pas à cause de problèmes de configuration DNSSEC chez denic
  Heureusement, je n’ai désactivé IPv6 nulle part, donc tout fonctionne bien à part GitHub