Panne IPv6 partielle sur le réseau Free (Freebox, Paris/IdF) - 28 août 2026

[rustyx]

Depuis au moins aujourd'hui, un ensemble important de réseaux est injoignable en IPv6 depuis ma connexion Freebox, alors qu'ils répondent parfaitement en IPv4. Le trafic vers ces destinations est perdu silencieusement (pas d'ICMP unreachable): les connexions TCP restent en SYN-SENT jusqu'au timeout.

Tous les traceroutes vers les destinations mortes s'arrêtent au même endroit - le routeur cœur/bordure de Free 2a01:e20:14:0:a000:: (hop 11, après les agrégateurs 2a01:e02:102x::2). Les destinations qui fonctionnent passent ce même routeur sans problème. Ce n'est pas un problème de MTU ni de hachage de flux (testé avec plusieurs ports source et deux adresses source). Tout indique une session de peering/transit cassée sur ce routeur.

Préfixes injoignables en IPv6 (fonctionnels en IPv4) :

• Cloudflare (AS13335), intégralement : 2606:4700::/32, 2a06:98c0::/29, 2803:f800::/32 - donc 1.1.1.1 (2606:4700:4700::1111), cloudflare.com, WARP, et tout site derrière Cloudflare (npmjs.org, digitalocean.com, scaleway.com, medium.com, linkedin.com…)
• Google Public DNS, partiellement : 2001:4860:4860::8844, ::6464, ::8800 morts ; ::8888 et ::64 OK
• Hurricane Electric (AS6939) : 2001:470::/32
• Dropbox : 2620:100::/32
• Zoom : 2407:30c0::/32
• Notion : 2602:f79a::/32

Fonctionnent normalement en IPv6 : Google, Meta, Akamai, AWS/CloudFront, Fastly, Hetzner, Wikimedia, Quad9, OpenDNS, AdGuard, Yandex, CDN77, Bunny, Gcore, Orange, Bouygues.

D'autres abonnés Free constatent-ils la même chose ? Test rapide:

ping -6 2606:4700:4700::1111
curl -v6 https://www.cloudflare.com/

 

[mb-kb]

Même symptôme chez moi ce matin (2 septembre, constaté vers 4h30), mais en IPv4 et pas sur les mêmes destinations. L'IPv6 de mon côté est OK : traceroute6 vers 2606:4700:4700::1111 passe, curl -6 vers cloudflare.com répond.

En IPv4, un ensemble de préfixes est perdu silencieusement. Pas d'ICMP unreachable, TCP en SYN-SENT jusqu'au timeout, ping sans réponse. Tous les traceroutes vers les destinations mortes s'arrêtent au même endroit : hop 2 taller-49m-1-v804.intf.routers.proxad.net (194.149.162.230), hop 3 212.27.35.8 (pas de reverse), puis plus rien jusqu'au hop 20. Les destinations qui fonctionnent (Google, Fastly) ne passent pas par 212.27.35.8.

Injoignables :

- GitHub Francfort, 140.82.121.0/24 (AS36459) : github.com, api.github.com, codeload.github.com, ssh.github.com, ports 22 et 443, ICMP aussi
- Akamai Paris, 23.46.188.0/22 (AS16625) : store.steampowered.com, steamcommunity.com

Fonctionnent normalement : GitHub US (140.82.112.x à 140.82.116.x), raw.githubusercontent.com (Fastly), api.steampowered.com (Akamai 2.21.243.x, AS20940), Google, 1.1.1.1, 8.8.8.8.

Ce n'est pas du DNS, la Freebox, 1.1.1.1 et 8.8.8.8 renvoient les mêmes IP et la résolution est instantanée. Ce n'est pas local non plus : un deuxième Mac sur le même LAN a exactement le même comportement, et 140.82.121.4:443 répond depuis des sondes externes (check-host.net en Autriche, Suisse et Turquie). Les deux préfixes morts n'ont rien à voir entre eux, le point commun c'est le chemin Free via ce routeur. Ça ressemble à une session de peering ou de transit cassée sur 212.27.35.8, peut-être le même équipement que votre 2a01:e20:14:0:a000:: en dual-stack.

Test rapide pour d'autres abonnés :

nc -vz -G 5 github.com 22
traceroute -n 140.82.121.4
curl -sI -m 5 https://store.steampowered.com/

[Pixy]

Idem de mon côté depuis ce matin. Impossible d'accéder à github.com.

Mêmes symptômes.

tracert 140.82.121.4

Détermination de l’itinéraire vers lb-140-82-121-4-fra.github.com [140.82.121.4]
avec un maximum de 30 sauts :

  1    10 ms     2 ms     6 ms  192.168.0.254
  2     4 ms     *        3 ms  taller-49m-1-v804.intf.routers.proxad.net [194.149.162.230]
  3     9 ms     8 ms     9 ms  212.27.35.8
  4     *        *        *     Délai d’attente de la demande dépassé.

 

[Pixy]

A priori c'est corrigé