Oui c'est la bonne MTU pour une ADSL dans les années 2000, pas pour une FTTH en 2024
Euh OK... Sauf que tous les gens en FTTH OVH semblent avoir ce MTU (et beaucoup s'en plaignent...).
Cependant après d'autres tests, le MTU semble bien être la source du problème, mais uniquement en IPv6. J'explique:
Hypothèse : Le MTU côté IPv6 qui est normalement déterminé par le protocole PMTUD. Or ici il ne le pourrait pas.
La cause la plus fréquente est un blocage de ICMPv6 côté opérateur sur les noeuds du réseau... Et à la vue des MTR il semble que ce soit bien ça.
OVH ne respecterait donc pas la RFC4638 permettant PMTUD.
Un ping6 -s avec différentes tailles de paquets permet de mettre cela en évidence :
lr@lr-desktop:~$ ping6 -s 1400 ds.lrob.net
PING ds.lrob.net(ds.lrob.net (2a01:4f8:171:28e8::2)) 1400 data bytes
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=1 ttl=52 time=32.6 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=2 ttl=52 time=32.3 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=3 ttl=52 time=32.1 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=4 ttl=52 time=32.3 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=5 ttl=52 time=32.2 ms
1408 bytes from ds.lrob.net (2a01:4f8:171:28e8::2): icmp_seq=6 ttl=52 time=32.1 ms
^C
--- ds.lrob.net ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5293ms
rtt min/avg/max/mdev = 32.053/32.278/32.632/0.183 ms
lr@lr-desktop:~$ ping6 -s 1500 ds.lrob.net
PING ds.lrob.net(ds.lrob.net (2a01:4f8:171:28e8::2)) 1500 data bytes
^C
--- ds.lrob.net ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5186ms
Le protocole QUIC utilisé par les plus grands fournisseurs de services en ligne outrepasse ce problème de MTU, ce qui explique que Amazon, Google et autres qui l'utilisent soient OK, mais pas les autres fournisseurs.
Une réponse trouvée sur un forum Mikrotik explique cela :
https://forum.mikrotik.com/viewtopic.php?t=195044"You'll have to open a support ticket with your ISP so that they don't block ICMPv6 communication in order to allow PMTUD to work, this might be an easier task for them instead of adding support for RFC4638, and you'll want working ICMPv6 either way.
Regarding google, it uses QUIC which is a totally different beast than TCP, and they use a slightly lower, forced MTU, to avoid issues with broken ISPs
so PMTUD doesn't kick in and "discovered" MTU remains equal to default interface MTU."
Je transmets l'info à OVH... En espérant une réaction quelconque.