Ubuntu 24.04 : l’IPv6 casse des sites au hasard — réparer correctement le double empilement (ne désactivez pas IPv6)

Ce que signifie habituellement la « panne aléatoire » en dual‑stack

Quand les utilisateurs disent « certains sites ne se chargent pas », ils ne décrivent pas le hasard. Ils décrivent des effets de sélection.
Certaines destinations publient des enregistrements AAAA (adresses IPv6), d’autres non. Certains CDN vous dirigent vers un edge IPv6 atteignable, d’autres vers un edge inatteignable.
Certains sites sont derrière des réseaux qui nécessitent que PMTUD fonctionne correctement ; d’autres non. Certains endpoints utilisent QUIC sur UDP ; d’autres restent sur TCP.

Sur un hôte dual‑stack, de nombreuses piles cliente essaieront IPv6 en premier si un AAAA existe. Si la route IPv6 est cassée ou si le serveur DNS renvoie de mauvaises réponses IPv6,
vous obtenez des délais d’attente, des chargements longs, ou des débats « ça marche sur mon téléphone, pas sur mon laptop ». Finalement, Happy Eyeballs peut basculer sur IPv4, mais « finalement »
n’est pas une stratégie d’expérience utilisateur.

Votre objectif n’est pas de « faire disparaître IPv6 ». Votre objectif est de rendre IPv6 correct pour que le dual‑stack se comporte comme un service ennuyeux.
L’ennui, c’est bien. L’ennui paie les factures.

Blague n°1 : Désactiver IPv6 parce que c’est instable, c’est comme enlever votre détecteur de fumée parce qu’il bip quand la pile est faible. Silencieux, oui. Intelligent, non.

Faits et contexte qui expliquent pourquoi cela arrive

• Fait 1 : L’IPv6 a été standardisé à la fin des années 1990, mais les déploiements en entreprise ont pris des décennies ; les déploiements « partiellement fonctionnels » sont courants.
• Fait 2 : Beaucoup d’OS préfèrent IPv6 par défaut quand A et AAAA existent, guidés par les règles de sélection d’adresse de la RFC 6724.
• Fait 3 : « Happy Eyeballs » (initialement RFC 6555, puis mis à jour) existe précisément parce que les chemins IPv6 cassés étaient si fréquents.
• Fait 4 : Les Router Advertisements (RA) peuvent configurer l’IPv6 sans DHCPv6 ; cette commodité rend aussi les mauvaises configurations plus faciles à masquer.
• Fait 5 : DNS64/NAT64 peut permettre à des clients IPv6‑only d’atteindre des services IPv4 ; lorsqu’ils sont déployés accidentellement ou à moitié cassés, cela crée des échecs surréalistes.
• Fait 6 : Les trous noirs de MTU étaient historiquement plus visibles en IPv4 à cause du comportement de fragmentation ; en IPv6, les routeurs ne fragmentent pas pour vous.
• Fait 7 : Certains clients VPN et « agents de sécurité » gèrent encore mal IPv6, surtout le split tunneling et le routage DNS pour AAAA.
• Fait 8 : Les fournisseurs cloud et les CDN ont souvent des edges IPv6 et IPv4 différents ; vous ne touchez pas toujours « le même serveur, juste une IP différente ».
• Fait 9 : systemd‑resolved a changé la façon dont de nombreux postes Linux font la résolution stub ; c’est rapide quand c’est juste et confus quand c’est faux.

Mode d’emploi pour un diagnostic rapide (vérifier d’abord/puis/ensuite)

Premier point : confirmer si les échecs sont corrélés aux recherches AAAA (IPv6)

Si les sites cassés ont systématiquement des enregistrements AAAA et que les sites fonctionnels n’en ont pas, arrêtez de prétendre que c’est « aléatoire ». C’est la préférence IPv6 + un chemin IPv6 cassé.
Si A et AAAA existent et que l’IPv4 fonctionne mais que l’IPv6 bloque, vous regardez des problèmes de routage, MTU, pare‑feu ou transport DNS.

Second point : valider la configuration IPv6 de l’hôte local et la route par défaut

La façon la plus rapide de perdre un après‑midi est de déboguer un comportement applicatif avant d’avoir confirmé que le noyau a une adresse IPv6 valide,
une route par défaut et un voisinage fonctionnel.

Troisième point : tester séparément la joignabilité IPv6 et le comportement DNS

Les problèmes DNS et les problèmes de transfert de paquets peuvent se ressembler depuis un navigateur. Séparez‑les tôt :
(1) pouvez‑vous résoudre un AAAA rapidement, et (2) pouvez‑vous vous connecter à l’adresse IPv6 résolue rapidement ?

Quatrième point : si ça « connecte puis bloque », suspectez MTU/PMTUD ou un pare‑feu avec état

La poignée de main TCP aboutit, TLS bloque, HTTP s’accroche, QUIC échoue : c’est là que vivent les trous noirs MTU et les expirations d’état de pare‑feu.
Diagnostiquez avec des pings ciblés et des captures de paquets, pas avec des impressions.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les tâches que j’exécute réellement sur un hôte Ubuntu 24.04 quand le dual‑stack semble hanté. Chaque tâche inclut ce que la sortie signifie et la décision suivante.
Exécutez‑les dans l’ordre ; vous trouverez généralement le coupable entre la tâche 7 et 10.

Task 1: confirm the host has global IPv6 and the right interface

cr0x@server:~$ ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
    inet6 fe80::a00:27ff:fe4e:66a1/64 scope link
       valid_lft forever preferred_lft forever
    inet6 2001:db8:120:34::25/64 scope global dynamic mngtmpaddr
       valid_lft 7100sec preferred_lft 3500sec

Signification : Vous voulez une adresse scope global sur l’interface attendue (pas seulement fe80::/64 link‑local).
Si vous ne voyez que du link‑local, l’IPv6 n’atteindra pas Internet sans un tunneling spécial.

Décision : Pas d’IPv6 globale ? Stop. Corrigez RA/DHCPv6 sur le réseau ou la configuration netplan avant de déboguer les navigateurs.

Task 2: verify the IPv6 default route exists and points somewhere sane

cr0x@server:~$ ip -6 route show
2001:db8:120:34::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
default via fe80::1 dev enp0s31f6 proto ra metric 1024 pref medium

Signification : La route par défaut via une passerelle link‑local (comme fe80::1) apprise via RA est normale.
Ce qui n’est pas normal, c’est l’absence de default, ou plusieurs routes par défaut qui basculent entre interfaces.

Décision : Route par défaut manquante ? Concentrez‑vous sur les Router Advertisements (ou le routage statique) avant le DNS. Routes par défaut multiples ? Vous pourriez avoir affaire à des VPNs, Wi‑Fi + Ethernet, ou des métriques de route mal définies.

Task 3: check neighbor discovery isn’t failing (L2/L3 reality check)

cr0x@server:~$ ip -6 neigh show dev enp0s31f6
fe80::1 lladdr 00:11:22:33:44:55 router STALE

Signification : Si l’entrée voisin routeur n’apparaît jamais, ou reste en FAILED, vous n’avez pas d’adjacence IPv6 de base.

Décision : Si la découverte de voisins est cassée, suspectez VLANs, isolation Wi‑Fi, RA‑guard, sécurité du switch, ou un pare‑feu local trop zélé.

Task 4: test raw IPv6 connectivity to a known address (bypass DNS)

cr0x@server:~$ ping -6 -c 3 2606:4700:4700::1111
PING 2606:4700:4700::1111(2606:4700:4700::1111) 56 data bytes
64 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=57 time=9.89 ms
64 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=57 time=10.12 ms
64 bytes from 2606:4700:4700::1111: icmp_seq=3 ttl=57 time=10.02 ms

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Signification : Un ICMPv6 réussi ne prouve pas que TCP fonctionnera, mais un échec ici est un grand panneau rouge : l’IPv6 est fondamentalement cassé.

Décision : Si cela échoue mais que le ping IPv4 fonctionne, concentrez‑vous sur le routage/pare‑feu/ISP/VPN plutôt que sur les paramètres applicatifs.

Task 5: confirm DNS returns AAAA and A, and how fast

cr0x@server:~$ resolvectl query example.com
example.com: 2606:2800:220:1:248:1893:25c8:1946
             93.184.216.34

-- Information acquired via protocol DNS in 42.0ms.
-- Data is authenticated: no

Signification : Vous avez obtenu à la fois AAAA et A rapidement. Si les requêtes prennent des secondes ou ne retournent que AAAA alors que le site a aussi un A, c’est une bizarrerie du résolveur/du transport.

Décision : DNS lent ? Investiguer les serveurs amont de systemd‑resolved, le comportement EDNS, ou un problème de capture DNS par un VPN.

Task 6: inspect which DNS servers are in play (per-link matters)

cr0x@server:~$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 2001:4860:4860::8888
       DNS Servers: 2001:4860:4860::8888 8.8.8.8

Link 2 (enp0s31f6)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 2001:4860:4860::8888
       DNS Servers: 2001:4860:4860::8888 8.8.8.8

Signification : systemd‑resolved peut avoir du DNS par interface. Un VPN injecte souvent du DNS sur son lien, ce qui peut changer ou casser les réponses AAAA.

Décision : Si les serveurs DNS diffèrent par lien, confirmez que la route par défaut et le lien DNS correspondent à votre intention (surtout avec des VPN en split tunnel).

Task 7: force IPv6 and IPv4 connections separately to the same hostname

cr0x@server:~$ curl -6 -I --max-time 8 https://example.com
HTTP/2 200
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
server: ECS (nyb/1D2A)

cr0x@server:~$ curl -4 -I --max-time 8 https://example.com
HTTP/2 200
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
server: ECS (nyb/1D2A)

Signification : Si -4 fonctionne et que -6 expire (ou bloque en cours de transfert), vous avez un vrai problème de chemin IPv6.

Décision : IPv6 uniquement en échec ? Passez aux tâches MTU et pare‑feu. Les deux en échec ? C’est un problème de connectivité plus large, proxy ou interception TLS.

Task 8: check route choice for a specific IPv6 destination

cr0x@server:~$ ip -6 route get 2606:4700:4700::1111
2606:4700:4700::1111 from :: via fe80::1 dev enp0s31f6 proto ra metric 1024 pref medium

Signification : Confirme quelle interface/passerelle sera utilisée. Si cela montre une interface VPN ou une NIC inattendue, vous avez trouvé votre « hasard ».

Décision : Mauvaise interface d’egress ? Corrigez les métriques de route, la configuration netplan, ou la politique de routage du VPN.

Task 9: test MTU/PMTUD symptoms with a “do not fragment” style probe (IPv6-style)

cr0x@server:~$ ping -6 -c 3 -s 1452 2606:4700:4700::1111
PING 2606:4700:4700::1111(2606:4700:4700::1111) 1452 data bytes
1452 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=57 time=10.88 ms
1452 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=57 time=10.95 ms
1452 bytes from 2606:4700:4700::1111: icmp_seq=3 ttl=57 time=11.01 ms

--- 2606:4700:4700::1111 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms

Signification : Ce n’est pas une validation parfaite de PMTUD, mais si les petits pings fonctionnent et que les plus grands échouent ou coincident, suspectez un trou noir MTU.
Les VPN, tunnels et PPPoE sont des récidivistes.

Décision : Si les gros paquets échouent, limitez MSS au bord, ajustez le MTU de l’interface, ou corrigez le blocage d’ICMPv6 Packet Too Big.

Task 10: verify ICMPv6 isn’t being “secured” to death locally

cr0x@server:~$ sudo nft list ruleset | sed -n '1,160p'
table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip6 nexthdr icmpv6 icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert, packet-too-big, time-exceeded, parameter-problem } accept
    tcp dport { 22 } accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
  }
  chain output {
    type filter hook output priority filter; policy accept;
  }
}

Signification : En IPv6, ICMPv6 n’est pas optionnel. Si quelqu’un a bloqué « tout ICMP » par réflexe de sécurité, vous pouvez casser la découverte de voisins et PMTUD.

Décision : Assurez‑vous que les types ICMPv6 essentiels sont autorisés. Si vous êtes sur un serveur avec policy drop, soyez explicite.

Task 11: check the kernel’s IPv6 disable switches (yes, people flip them)

cr0x@server:~$ sysctl net.ipv6.conf.all.disable_ipv6 net.ipv6.conf.default.disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0

Signification : Si ces valeurs valent 1, IPv6 est désactivé au niveau noyau. Parfois c’est fait « temporairement » et devient permanent.

Décision : Si désactivé, réactivez et corrigez le vrai problème. Si activé, continuez — votre problème est plus subtil (et donc plus amusant).

Task 12: confirm what /etc/resolv.conf actually points to

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr 19 10:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Signification : Ubuntu utilise couramment le stub resolver de systemd. Si vous attendiez NetworkManager ou un resolv.conf statique, votre modèle mental est dépassé.

Décision : Si c’est stub-resolv.conf, utilisez resolvectl pour la vérité. Si c’est un fichier statique, assurez‑vous qu’il contient des serveurs DNS atteignables sur les deux piles.

Task 13: verify you’re not suffering from DNS over IPv6 transport failure

cr0x@server:~$ resolvectl query -4 example.com
example.com: 93.184.216.34

-- Information acquired via protocol DNS in 16.8ms.

cr0x@server:~$ resolvectl query -6 example.com
example.com: 2606:2800:220:1:248:1893:25c8:1946

-- Information acquired via protocol DNS in 2105ms.

Signification : Même requête, mais le transport IPv6 vers le résolveur est lent. Cela seul peut rendre les « sites aléatoires » cassés.

Décision : Réparez la joignabilité IPv6 vers votre résolveur DNS, ou préférez temporairement un résolveur IPv4 pendant que vous réparez le routage/MTU IPv6.

Task 14: capture proof (short, targeted tcpdump)

cr0x@server:~$ sudo tcpdump -ni enp0s31f6 ip6 and host 2606:4700:4700::1111
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:14:01.233445 IP6 2001:db8:120:34::25 > 2606:4700:4700::1111: ICMP6, echo request, seq 1, length 64
12:14:01.243110 IP6 2606:4700:4700::1111 > 2001:db8:120:34::25: ICMP6, echo reply, seq 1, length 64

Signification : Vous vérifiez que les paquets sortent et que les réponses reviennent sur l’interface attendue. Si les requêtes partent et que rien ne revient, c’est en amont.
Si rien ne part, c’est le routage/pare‑feu local.

Décision : Utilisez cela pour prouver où se situe la panne avant de modifier des configs « juste pour voir ».

Les grandes causes racines : DNS, routage, MTU, RA/DHCPv6 et pare‑feu

1) Les réponses DNS sont correctes ; le transport DNS ne l’est pas

Une des variantes les plus sournoises : votre résolveur est joignable en IPv4 et IPv6, mais l’IPv6 jusqu’au résolveur est cassé (MTU, asymétrie de routage, pare‑feu).
systemd‑resolved peut préférer l’adresse IPv6 du résolveur, bloquer les requêtes, puis réessayer. Du point de vue de l’application : « certains domaines expirent ».

La solution n’est pas de supprimer les enregistrements AAAA (vous ne pouvez pas) ni de désactiver IPv6 (vous ne devriez pas). La solution est de rendre le chemin IPv6 vers le DNS fiable, ou de contraindre
quels serveurs DNS sont utilisés par quelles interfaces afin de ne pas préférer un transport cassé.

2) La route par défaut existe, mais la mauvaise gagne

Les échecs dual‑stack adorent le multi‑homing : Ethernet + Wi‑Fi, LAN + VPN, ponts Docker, et outils « utiles » qui ajoutent des routes.
Vous pouvez avoir une route par défaut IPv4 parfaite et une route par défaut IPv6 cassée, et l’hôte choisira quand même IPv6 pour des destinations avec AAAA.

Corrigez les métriques de route, ou supprimez la source RA fautive. Si vous êtes en entreprise, soyez méfiant envers le Wi‑Fi invité qui annonce l’IPv6 mais ne le route pas réellement.
Cela arrive plus souvent que vous ne le pensez, parce que quelqu’un a activé IPv6 sur un équipement de bord via une case à cocher et n’a jamais vérifié en amont.

3) Trous noirs MTU (le classique « connecte puis bloque »)

L’IPv6 exige que PMTUD fonctionne correctement ; les routeurs ne fragmentent pas pour vous. Si les messages ICMPv6 Packet Too Big sont bloqués quelque part,
ou si un tunnel réduit le MTU et que personne ne l’annonce, TCP peut se connecter puis rester bloqué sur de plus gros enregistrements TLS ou réponses HTTP.

Les VPNs sont des coupables fréquents. Tout comme les pare‑feux avec des règles par défaut‑deny qui droppent accidentellement des types ICMPv6 qu’ils ne reconnaissent pas.
Quand vous entendez « ça charge les petites pages mais pas les grosses », ne discutez pas. Allez tester le MTU.

4) RA et DHCPv6 ne sont pas alignés avec la réalité

La configuration IPv6 peut venir des Router Advertisements (SLAAC), de DHCPv6, ou des deux.
Un réseau peut vous donner une adresse IPv6 globale mais pas une route par défaut fonctionnelle, ou fournir des serveurs DNS qui ne sont pas joignables.
Vous vous retrouvez « configuré » mais non fonctionnel.

Sur les clients Ubuntu, netplan + NetworkManager ou systemd‑networkd peuvent se comporter différemment vis‑à‑vis des RA et DHCPv6.
Assurez‑vous de savoir quel renderer est actif et quel composant doit accepter les RA.

5) Pare‑feux : « bloquer ICMP » n’est pas une stratégie

En IPv4, on peut parfois s’en sortir avec une politique ICMP permissive. En IPv6, non.
La découverte de voisins, la découverte de routeurs et PMTUD reposent sur ICMPv6.
Le bloquer ne vous rend pas plus sécurisé ; ça vous rend aveugle et intermittemment cassé.

systemd-resolved sur Ubuntu 24.04 : quoi croire, quoi vérifier

Ubuntu 24.04 utilise systemd‑resolved dans les configurations par défaut courantes. Il fait du caching, du DNS par lien, du split DNS, et il présente un resolver stub local.
C’est bien. C’est aussi une source fréquente de confusion parce que les gens inspectent /etc/resolv.conf et pensent avoir appris quelque chose.
Souvent ils ont juste appris qu’il s’agit d’un lien symbolique.

Ce en quoi j’ai confiance

• resolvectl status est la vérité actuelle pour quels serveurs DNS sont utilisés par interface et globalement.
• resolvectl query est un bon moyen de mesurer le temps de réponse DNS sans ajouter d’outils externes.
• Le cache de systemd‑resolved est généralement stable et accélère les recherches courantes.

Ce que je vérifie

• Si un lien VPN a injecté des serveurs DNS et est devenu la route par défaut pour IPv6 (souvent par accident).
• Si les serveurs DNS sont joignables en IPv6 sans problèmes de MTU ou pare‑feu.
• Si des règles de split‑DNS existent qui envoient certains domaines vers des résolveurs internes qui ne servent pas AAAA ou expirent.

Si vous suspectez que systemd‑resolved lui‑même est bloqué, vous pouvez le redémarrer — après avoir capturé les symptômes. Redémarrer d’abord est la manière dont les bugs s’échappent.

cr0x@server:~$ sudo systemctl restart systemd-resolved
cr0x@server:~$ resolvectl statistics
Transactions
  Current Transactions: 0
  Total Transactions: 1249
Cache
  Current Cache Size: 317
  Cache Hits: 802
  Cache Misses: 447
DNSSEC Verdicts
  Secure: 0
  Insecure: 1249
  Bogus: 0

Signification : Vous confirmez que le démon est sain et met en cache. Cela ne prouve pas que l’amont est sain.

Décision : Si les redémarrages « résolvent » le problème, vous avez toujours une cause racine ; vous venez juste d’ajouter un rituel. Retournez au transport et au DNS par lien.

Pièges Netplan qui détruisent silencieusement l’IPv6

Netplan est génial quand on le traite comme une configuration déclarative et qu’on le garde ennuyeux. Il est moins génial quand on édite du YAML sous pression à 2h du matin.
YAML est un langage conçu pour punir l’excès de confiance.

Confusion de renderer : NetworkManager vs systemd-networkd

Sur les postes, NetworkManager est typique. Sur les serveurs, systemd‑networkd est courant. Leur comportement autour des RA, DHCPv6 et DNS peut différer.
Lors du dépannage, identifiez le renderer en cours et ne mélangez pas les hypothèses.

cr0x@server:~$ sudo netplan get
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s31f6:
      dhcp4: true
      dhcp6: true
      accept-ra: true

Signification : Cet hôte accepte les RA et utilise DHCPv6. Si vous avez mis accept-ra: false par erreur, vous pouvez perdre la route par défaut.

Décision : Si l’IPv6 est partiellement configuré, vérifiez que dhcp6 et accept-ra correspondent à votre conception réseau.

Mauvaise IPv6 statique + RA : le problème des « deux vérités »

Une adresse IPv6 statique avec un préfixe mal calibré, combinée à des RA fournies, peut produire un comportement de sélection bizarre.
L’hôte pense avoir une adresse globale ; les réponses distantes partent ailleurs ou reviennent par un chemin différent.
L’IPv4 fonctionne toujours, donc tout le monde blâme « l’application ».

cr0x@server:~$ ip -6 route show table main | head
default via fe80::1 dev enp0s31f6 proto ra metric 1024 pref medium
2001:db8:120:34::/64 dev enp0s31f6 proto kernel metric 256 pref medium
2001:db8:120:99::/64 dev enp0s31f6 proto kernel metric 256 pref medium

Signification : Deux préfixes globaux on‑link sur une interface peuvent être valides, mais c’est souvent le signe d’une ancienne configuration statique qui entre en collision avec les RA courantes.

Décision : Si vous n’aviez pas l’intention d’avoir plusieurs préfixes, nettoyez‑les. Réduisez les variables avant de déboguer les couches supérieures.

Erreurs courantes (symptôme → cause → correction)

1) Symbole : « Certains sites expirent, mais ping6 fonctionne »

Cause racine : L’ICMPv6 echo fonctionne, mais TCP/UDP est bloqué ou NAT64/DNS64 interfère, ou le MTU est cassé pour les plus gros paquets.

Correction : Testez avec curl -6 -I, puis probez le MTU. Vérifiez que les règles pare‑feu autorisent l’IPv6 sortant et les types ICMPv6 essentiels, en particulier Packet Too Big.

2) Symptom: « Les recherches DNS IPv6 sont lentes ; IPv4 est rapide »

Cause racine : Le résolveur est joignable via IPv4, mais le chemin IPv6 vers le résolveur est cassé (routage/MTU/pare‑feu), ou l’IPv6 du résolveur est limité par quotas en amont.

Correction : Changez de DNS vers un résolveur joignable en IPv6, ou préférez temporairement le transport DNS IPv4 pendant que vous réparez la joignabilité IPv6 vers le DNS.

3) Symptom: « Ça marche sur le Wi‑Fi, casse sur l’Ethernet (ou inverse) »

Cause racine : Différents RA, différents serveurs DNS, ou différentes routes et métriques IPv6 par lien.

Correction : Comparez resolvectl status et ip -6 route sur chaque lien. Corrigez les métriques de route ou arrêtez la source RA fautive.

4) Symptom: « Après activation d’un VPN, des sites cassent aléatoirement »

Cause racine : Le VPN s’annonce comme route par défaut IPv6 mais ne transporte pas correctement le trafic IPv6 ; ou il détourne le DNS et maltraite les AAAA.

Correction : Assurez‑vous que le VPN supporte IPv6 de bout en bout, ou configurez correctement le split tunneling. Validez avec ip -6 route get pour les destinations en échec.

5) Symptom: « Le navigateur tourne, mais curl -4 fonctionne immédiatement »

Cause racine : IPv6 est préféré ; les délais de repli Happy Eyeballs donnent l’impression que le navigateur est bloqué.

Correction : Réparez le chemin IPv6 (ne le cachez pas). Comme mitigation temporaire, ajustez le DNS ou le routage pour que l’IPv6 ne soit utilisé que lorsqu’il est réellement fonctionnel.

6) Symptom: « Seuls les gros téléchargements échouent en IPv6 »

Cause racine : Trou noir MTU ou ICMPv6 Packet Too Big bloqué.

Correction : Autorisez ICMPv6 PTB. Limitez MSS sur le bord si vous le contrôlez. Réduisez le MTU du tunnel ou corrigez PMTUD de bout en bout.

7) Symptom: « Adresse IPv6 présente, mais pas de route par défaut »

Cause racine : RA non reçue, RA ignorée (accept-ra: false), RA filtrée (RA‑guard), ou routeur n’annonçant pas de défaut.

Correction : Confirmez la réception des RA avec les logs de networkd/NetworkManager ; corrigez netplan ; ajustez la configuration RA‑guard sur le switch.

8) Symptom: « Tout marche un moment, puis casse jusqu’à reconnexion »

Cause racine : Les adresses de confidentialité tournent et un ACL en amont ou un chemin de cache voisin brisé ne suit pas ; ou des routes obsolètes d’une interface transitoire.

Correction : Cherchez des flaps de route et des changements d’adresse. Préférez des adresses stables pour les serveurs ; pour les clients, corrigez le filtrage et la stabilité du routage en amont.

Trois mini‑histoires d’entreprise depuis le terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé Ubuntu 24.04 sur une flotte de développeurs. En une journée, le support interne a vu une nouvelle catégorie : « internet instable ».
Les développeurs ont signalé des installations de paquets qui s’arrêtaient, certains tableaux de bord SaaS qui se chargeaient à moitié, et des redirections d’authentification qui échouaient parfois.
L’équipe réseau affirmait que leur WAN était propre. L’équipe endpoints affirmait que c’était une mise à jour de navigateur. Tout le monde avait raison, ce qui est l’erreur la plus agaçante.

La mauvaise hypothèse était petite et mortelle : « Si le client a une adresse IPv6, IPv6 doit fonctionner. » Sur leur Wi‑Fi invité et certains étages, les points d’accès envoyaient des Router Advertisements avec un préfixe global (les clients se configuaient en IPv6), mais le routage en amont pour ce préfixe manquait sur un commutateur de distribution.
Les paquets IPv6 quittaient le client et disparaissaient dans le vide. L’IPv4 continuait de fonctionner, donc personne n’a été alerté d’un « Internet down ».

Le schéma des symptômes paraissait aléatoire parce que seules les destinations avec enregistrements AAAA déclenchaient le chemin IPv6 cassé. Et parce que différents CDN renvoyaient des AAAA pour différentes régions,
deux personnes assises côte à côte pouvaient toucher des edges différents en échec.

La correction a été ennuyeuse : arrêter d’annoncer ce que vous ne pouvez pas router. Ils ont corrigé la configuration RA sur les SSID affectés et vérifié que chaque préfixe annoncé avait une route en amont.
Ils ont aussi ajouté une vérification client simple dans l’onboarding des appareils : si une route par défaut IPv6 existe, vérifier une courte liste de tests de connectivité IPv6 avant de déclarer le « réseau sain ».

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a décidé « d’optimiser la latence DNS » en standardisant sur des résolveurs IPv6 uniquement. La rationale sonnait moderne : moins de dépendances legacy, meilleur futur, et une seule pile à dépanner.
Ils l’ont déployé via la gestion des endpoints, remplaçant des résolveurs mixtes IPv4/IPv6 par des adresses IPv6‑only.

Ça fonctionnait bien au siège. Ça fonctionnait bien dans les data centers. Puis les bureaux distants ont commencé à signaler que « Microsoft est lent » et « certains sites ne se chargent jamais ».
L’équipe a cherché dans les caches du navigateur, les agents de sécurité endpoint, et même le throttling CPU — car les échecs ne se reproduisaient pas sur le LAN corporate.

Le retour de bâton était classique MTU. Plusieurs sites distants utilisaient un lien WAN avec overhead d’encapsulation ; le MTU effectif était inférieur à 1500.
L’IPv4 avait des années d’expérience dans leur environnement : le clamp MSS était déjà en place pour le trafic IPv4. L’IPv6 n’avait pas bénéficié du même soin.
Le DNS sur IPv6 vers les résolveurs se bloquait parfois quand les réponses franchissaient la frontière MTU et que les messages ICMPv6 Packet Too Big étaient mal gérés par un profil de pare‑feu en bordure.

Le retour en arrière vers des résolveurs mixtes a immédiatement réduit l’impact, mais la vraie correction a été de réparer la story MTU pour l’IPv6 : autoriser ICMPv6 essentiel, clamer MSS où approprié,
et valider avec des tailles de charge utiles réelles. La leçon n’était pas « IPv6 c’est mauvais ». La leçon : si vous optimisez un système que vous ne mesurez pas, vous venez d’inventer une nouvelle classe d’incidents.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société de services financiers (du genre qui adore les gel des changements et déteste les surprises) avait une pratique stricte : chaque changement réseau demandait un test de santé dual‑stack depuis un hôte canari.
Pas une plateforme synthétique sophistiquée — juste un script tournant sur une petite VM Ubuntu dans chaque site, journalisant les temps DNS, la santé des routes IPv4/IPv6, et quelques requêtes HTTP HEAD sur les deux piles.

Lors d’une mise à jour de firmware de pare‑feu de routine, un ingénieur a appliqué un modèle de politique « durci ». Le template autorisait les types ICMP IPv4 attendus,
mais pour IPv6 il passait par défaut à « deny unknown ICMPv6 ». La découverte de voisins et Packet Too Big ont été des dommages collatéraux.
En quelques minutes, les logs canari ont montré des requêtes HTTP IPv6 qui s’attardaient alors que l’IPv4 restait saine.

La pratique ennuyeuse a sauvé la journée parce qu’elle a capté la régression avant que les utilisateurs ne la remarquent. L’astreinte n’a pas eu à interpréter des tickets vagues comme « Slack est bizarre ».
Ils avaient des horodatages, des modes d’échec, et un diff clair : l’IPv6 a cassé exactement quand le template a été appliqué.

La correction a été tout aussi ennuyeuse : autoriser explicitement les types ICMPv6 nécessaires pour ND, RA et PMTUD. Le postmortem a été court, calme et utile.
Personne n’a appris une astuce excitante. Tout le monde a gardé son weekend.

Listes de contrôle / plan pas à pas

Étapes pas à pas : rendre le dual‑stack correct sur Ubuntu 24.04

1. Confirmez que le symptôme est lié à l’IPv6.
   Utilisez curl -4 vs curl -6 pour un nom d’hôte en échec. Si l’IPv6 échoue, arrêtez de blâmer le navigateur.
2. Validez l’adresse IPv6 + la route par défaut.
   Vérifiez ip -6 addr et ip -6 route. Pas d’adresse globale ou pas de route par défaut signifie que vous n’êtes pas prêt pour le débogage applicatif.
3. Vérifiez la découverte de voisins.
   Consultez ip -6 neigh. Si l’entrée routeur manque/est FAILED, vous avez des problèmes L2/L3 ou un filtrage RA.
4. Testez la joignabilité IPv6 sans DNS.
   Pinguez une adresse IPv6 connue. Si ça échoue, concentrez‑vous sur le routage/pare‑feu/VPN en amont.
5. Testez les temps et le transport DNS.
   Utilisez resolvectl query, comparez les requêtes -4 et -6. Un DNS IPv6 lent est toujours une panne IPv6.
6. Confirmez quels serveurs DNS sont utilisés par lien.
   resolvectl status. Si un VPN injecte du DNS, vérifiez que c’est voulu et que cela fonctionne en IPv6.
7. Vérifiez MTU et signaux PMTUD.
   Utilisez des pings IPv6 plus grands et cherchez des blocages. Si vous contrôlez le bord, assurez‑vous que ICMPv6 Packet Too Big est autorisé.
8. Auditez la politique de pare‑feu pour la réalité IPv6.
   Utilisez nft list ruleset. Autorisez les types ICMPv6 essentiels. Ne « sécurisez » pas le protocole en le rendant inutilisable.
9. Verrouillez la correction netplan.
   Confirmez le renderer, l’acceptation des RA, les paramètres DHCPv6. Appliquez les changements avec précaution et restez minimal.
10. Capturez des preuves avant et après.
    Un court tcpdump vaut mille fils Slack. Conservez‑le avec horodatage et nom d’interface.

Checklist opérationnelle : empêcher la réapparition

• Maintenez une vérification canari dual‑stack (temps DNS + HTTP sur v4/v6) par site/VLAN/profil VPN.
• Exigez que les reviewers de changement considèrent explicitement les règles ICMPv6, pas en réflexion après coup.
• Suivez l’origine des RA ; traitez « RA fautive » comme un vrai mode de panne, pas comme une théorie.
• Documentez les métriques de route et la politique de routage quand les VPN sont impliqués.
• Quand vous changez le MTU quelque part, validez PMTUD IPv6 avec des tailles de charge utiles réelles.

Une citation à garder sur votre écran

« L’espoir n’est pas une stratégie. » — Gene Kranz (idée paraphrasée)

Remplacez « désactiver IPv6 » par « espoir » et vous avez la morale de tout ce bazar.

FAQ

1) Pourquoi seuls certains sites cassent‑ils ?

Parce que seuls certains sites publient des enregistrements AAAA, et que certains CDN vous dirigent vers un edge IPv6 que votre réseau ne peut pas atteindre de façon fiable.
Votre navigateur essaie IPv6 en premier, tombe sur un chemin mort, puis finit par revenir sur IPv4.

2) Dois‑je simplement désactiver IPv6 sur Ubuntu 24.04 ?

Comme mesure de confinement temporaire sur un hôte isolé pendant un incident, peut‑être. Comme « solution », non.
Désactiver IPv6 masque la panne et vous garantit de ne pas remarquer quand votre réseau sera à moitié cassé à nouveau.

3) Si ping6 fonctionne, cela ne prouve‑t‑il pas qu’IPv6 va bien ?

Non. L’écho ICMPv6 peut réussir tandis que TCP/UDP échouent à cause de politiques de pare‑feu, de problèmes MTU/PMTUD ou de routage asymétrique.
Traitez ping6 comme un point de départ, pas comme un verdict final.

4) Quelle est la cause réelle la plus fréquente ?

Le routage IPv6 cassé annoncé par RA (les clients obtiennent des adresses et préfèrent IPv6) combiné au fait que l’amont ne route pas réellement ce préfixe.
En deuxième position : trous noirs MTU causés par des Packet Too Big ICMPv6 bloqués.

5) Comment savoir si systemd‑resolved est le problème ?

Si resolvectl query est lent ou incohérent, et surtout si resolvectl status affiche des serveurs DNS injoignables,
le résolveur expose un problème de transport. Le démon lui‑même est rarement la cause racine.

6) Pourquoi un VPN aggrave‑t‑il la situation ?

Les VPN changent souvent les routes et les serveurs DNS. Si le VPN prétend être route par défaut IPv6 mais ne transporte pas correctement l’IPv6, votre hôte enverra de l’IPv6 dans un tunnel vers nulle part.
Ou le résolveur DNS du VPN maltraite les AAAA. Quoi qu’il en soit : la préférence dual‑stack amplifie la panne.

7) Quels types ICMPv6 doivent être autorisés ?

Au minimum : neighbor solicitation/advertisement, router solicitation/advertisement, packet‑too‑big, time‑exceeded, et parameter‑problem.
La politique exacte dépend de votre environnement, mais « bloquer tout ICMPv6 » est un générateur d’incidents auto‑infligé.

8) Comment les problèmes MTU se manifestent‑ils dans les navigateurs ?

Vous verrez des connexions qui commencent mais ne se terminent pas : poignées de main TLS qui s’arrêtent, gros assets qui expirent, ou QUIC qui échoue tandis que TCP peut parfois fonctionner.
Si les petites charges utiles réussissent et que les plus grosses échouent, suspectez immédiatement MTU/PMTUD.

9) Est‑ce spécifique à Ubuntu 24.04 ?

Les modes de panne sous‑jacents sont universels. Ce qui change entre les versions, c’est la plomberie : comportement du résolveur, valeurs par défaut netplan, versions des gestionnaires réseau,
et la façon dont les applications préfèrent IPv6. Ubuntu 24.04 est assez moderne pour ne pas éviter poliment votre IPv6 cassé.

10) Quelle est la mitigation rapide et sûre pendant que je répare le réseau ?

Préférez un transport DNS stable et un routage stable. Par exemple, assurez‑vous que les serveurs DNS sont joignables en IPv6 (ou utilisez temporairement des résolveurs IPv4),
et empêchez qu’une interface/VPN cassée devienne la route par défaut IPv6. Évitez la désactivation kernel d’IPv6 sauf si vous êtes en train de contenir un incident actif.

Conclusion : prochaines étapes durables

Le dual‑stack est censé être ennuyeux. Quand ce n’est pas le cas, ce n’est presque jamais « l’IPv6 mystique ». Ce sont les mêmes vieux péchés opérationnels :
annoncer des routes que vous ne pouvez pas transporter, bloquer des paquets de plan de contrôle dont vous avez besoin, et traiter le MTU comme un concept théorique.

Faites ceci ensuite, dans l’ordre : exécutez le playbook de diagnostic rapide, isolez si c’est le transport DNS ou le routage/MTU, puis corrigez le réseau pour que l’IPv6 soit soit
véritablement fonctionnel soit non annoncé. N’apprenez pas à votre flotte à vivre avec une pile cassée. C’est comme ça qu’on finit avec des politiques qui ne fonctionnent que les mardis.

Blague n°2 : La bonne nouvelle, c’est que l’IPv6 a assez d’adresses pour tous vos appareils. La mauvaise nouvelle, c’est qu’il a aussi assez de façons de les malconfigurer.