...les gens utilisent aussi de plus en plus les plateformes de musique via IP...
Dans quelques années une fois nos ainés parties plus personne n'écoutera la radio...

Déjà il n'y a plus rien à écouter  sur les "grandes" ondes (LW) et presque plus sur les moyennes. Plus grand chose non plus en phonie sur les OC, sauf pour les radio-amateurs DX-eurs bien équipés (et pourvus d'une license). Restaient donc les ondes métriques de la FM, malheureusement encombrées et surchargées de programmes parasites sans intérêt depuis l'éclosion des radios "libres" (qui ne le sont pas restées longtemps).
Big Brother aura finalement eu la peau de la radio, et j'espère que le sympathique modérateur ne jugera pas ce commentaire déplacé. Ce n'est bien sûr que mon opinion.

Sur Livebox 3 FTTH, j'ai déjà eu des pertes d'IPv6 (je crois que le menu était encore présent, mais la box ne récupérait pus d'IPv6).

Dans mon cas un simple reboot permettait de récupérer une IPv6.

J'ai également le pb sur des box 5G Orange, suite à des paquets précis qui font tomber IPv6. Cf Perte de la connectivité IPv6 sur la Flybox 5G. Là aussi un reboot et on récupère IPv6.

Ah moi le reboot a rien fait même quelqyes h après retour a vour si ce soir je peux la rebooter...

20 paquets transmis, 20 reçus, 0% perte
RTT min/avg/max/mdev = 29.9/30.7/31.4/0.4 ms

Il faudrait réaliser des tests sur 10 000 paquets pour pouvoir avoir qq chose de représentatif.

0,01 % de taux de perte cela peut être la cause de ce que tes problèmes. Une perte de paquet pendant le slow start (période ou TCP cherche à savoir de quelle bande passante, il dispose et où le débit monte exponentiellement) peu avoir des impacts énormes avec le protocole de congestion Cubic (pas avec BBR).

Pour les tests iPerf3, peut-être voir le débit moyen sur une durée plus longue afin que cela soit stable et voir s'il y a une différence selon les heures ?

o2switch est le plus gros hébergeur (en termes de nom de domaine .fr) à ne pas proposer d'IPv6.

Il me semble que dans les données qui seront publiées dans quelques semaines, cela serait le seul du top 12 des plus gros hébergeurs en .fr à avoir 0% d'IPv6.

Même si plusieurs hébergeurs proposent IPv6 dans leurs offres, le taux de sites web accessibles en IPv6 est très faible pour les 12 premiers acteurs (en nombre de noms de domaine), car il n’est pas activé systématiquement par défaut.

En considérant les 12 premiers acteurs en termes de nombre de noms de domaine, seuls Cloudflare, IONOS, LWS, Hostinger et Infomaniak ont plus de la moitié des sites qu’ils hébergent compatibles IPv6, leurs déploiements constituent donc des exemples à suivre.



Une liste plus complète des taux de sites web, hébergement mail et infrastructures DNS accessibles en IPv6 est disponible dans quatre formats :
• PDF (75 pages, 27 Mo) ;
• tableur OpenDocument (.ods, 4 Mo, lisible avec LibreOffice Calc) ;
• tableur Office Open XML (.xlsx, 5 Mo, lisible avec Microsoft Excel) ;
• données brutes (.csv, 6 Mo).

Merci pour ces précisions — l'encapsulation IPv4-dans-IPv6 avec transit par l'IDF explique enfin pourquoi passer en IPv6 pourrait faire une différence. Ce n'est pas ce que j'avais compris de la réponse initiale (qui évoquait une réduction du RTT), mais la logique de peering local en IPv6 est cohérente avec le symptôme.

Test ping ICMP dans les deux sens (20 paquets, hors transfert) :

20 paquets transmis, 20 reçus, 0% perte
RTT min/avg/max/mdev = 29.9/30.7/31.4/0.4 ms

Chemin parfaitement sain au repos — aucune perte de fond, gigue quasi nulle.

4 tests iperf3 consécutifs (18h21) — lancés à ~12 secondes d'intervalle :

Test #1 : 779 Mbps  224 retr  cwnd_max=7,11 MB  ← bonne passe
Test #2 : 788 Mbps  285 retr  cwnd_max=7,12 MB  ← bonne passe
Test #3 : 785 Mbps  278 retr  cwnd_max=4,46 MB  ← bonne passe
Test #4 : 277 Mbps    5 retr  cwnd_max=1,34 MB  ← mauvaise passe

Le test #4 est particulièrement révélateur : très peu de retransmissions (5 seulement contre 224–285 sur les autres), mais cwnd écrasé à ~1 MB dès le slow-start et qui ne récupère jamais sur 10 secondes. Ce n'est pas le même régime — le buffer de l'équipement intermédiaire était probablement déjà saturé au moment où ce flux est arrivé, bloquant toute croissance du cwnd.

Sur les heures de pointe vs creuses : honnêtement, je doute que l'heure soit le facteur déterminant. Avec iperf3 en flux unique, ça passe ou ça ne passe pas à n'importe quelle heure — les bonnes et mauvaises passes s'alternent de façon imprévisible en l'espace de quelques secondes (tests #1–#4 ci-dessus). Avec rsync ou scp en flux unique, en revanche, ça ne passe jamais correctement — le débit plafonne systématiquement à ~15 MB/s. Il faut agréger 4 flux parallèles pour retrouver les ~700 Mbps attendus. Ce n'est pas un comportement d'heure de pointe — c'est un comportement permanent.

Sur le test IPv6 : impossible à réaliser pour l'instant — le firewall IPv6 de la Freebox Pop ne permet aucune ouverture de port entrant sélective (on/off uniquement), et les équipements côté distant n'ont pas IPv6 activé. Je reviendrai sur cette piste ultérieurement.