Tu ne dois pas fragmenter en v6, tu dois répondre un ICMP Packet Too Big Après tu peux faire de l'IPv6 avec une MTU <1500, visiblement ils ont juste oublié d'implémenter la base là (genre annoncer la bonne MTU côté LAN dans les RA)
Sent from my iPhone > On 23 Jun 2017, at 12:15, David Ponzone <david.ponz...@gmail.com> wrote: > > Oui d’ailleurs, y a quand même des trucs bizarres. > Il y a une limitation en IPv6 à la fragmentation d’un paquet ICMP ? > > Parce que je viens de constater l’étrangeté suivante: > > $ sudo ping6 -s 1300 www.telecom-infoconso.fr > PING6(1348=40+8+1300 bytes) 2a02:8428:126:dd00:7115:ba7a:d49d:8b6a --> > 2001:8d8:100f:f000::26a > ^C > --- www.telecom-infoconso.fr ping6 statistics --- > 14 packets transmitted, 0 packets received, 100.0% packet loss > > > $ sudo ping6 -s 1300 -m www.telecom-infoconso.fr > PING6(1348=40+8+1300 bytes) 2a02:8428:126:dd00:7115:ba7a:d49d:8b6a --> > 2001:8d8:100f:f000::26a > 1308 bytes from 2001:8d8:100f:f000::26a, icmp_seq=0 hlim=57 time=28.975 ms > 1308 bytes from 2001:8d8:100f:f000::26a, icmp_seq=1 hlim=57 time=25.934 ms > 1308 bytes from 2001:8d8:100f:f000::26a, icmp_seq=2 hlim=57 time=28.413 ms > 1308 bytes from 2001:8d8:100f:f000::26a, icmp_seq=3 hlim=57 time=24.931 ms > ^C > --- www.telecom-infoconso.fr ping6 statistics --- > 4 packets transmitted, 4 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 24.931/27.063/28.975/1.681 ms > > Je suis sur MacOSX, le -m désactive la fragmentation. > Donc un ICMP de 1348 octets fragmenté ne passe pas. > > Le plus gros qui passe en fragmentant est 1280: > > $ sudo ping6 -s 1232 www.telecom-infoconso.fr > PING6(1280=40+8+1232 bytes) 2a02:8428:126:dd00:7115:ba7a:d49d:8b6a --> > 2001:8d8:100f:f000::26a > 1240 bytes from 2001:8d8:100f:f000::26a, icmp_seq=0 hlim=57 time=28.552 ms > 1240 bytes from 2001:8d8:100f:f000::26a, icmp_seq=1 hlim=57 time=25.705 ms > ^C > --- www.telecom-infoconso.fr ping6 statistics --- > 2 packets transmitted, 2 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 25.705/27.128/28.552/1.423 ms > > Le plus surprenant, c’est que quand je regarde le paquet SYN que j’envoie au > serveur (que ça soit telecom-infoconso.fr ou VMware), il demande 1393 et le > serveur renvoie 1393. > > De même avec microsoft.com, mais là, ça marche. > > Je pense qu’il va vite s’imposer comme conclusion que la connexion IPv6 > fournit par SFR, c’est une bidouille pas sèche. > > >> Le 23 juin 2017 à 11:26, Hugues VOITURIER <huguesdelam...@icloud.com> a >> écrit : >> >> Y’a un tunnel en IPv6 chez SFR, tu as donc une mtu un peu plus basse >>> On 23 Jun 2017, at 10:33, David Ponzone <david.ponz...@gmail.com> wrote: >>> >>> Tiens, je viens de m’apercevoir que j’ai le même problème avec >>> www.telecom-infoconso.fr >>> >>> Ca va être sympa IPv6…. >>> >>> >>> >>>> Le 19 juin 2017 à 11:54, Michel 'ic' Luczak <li...@benappy.com> a écrit : >>>> >>>> Salut, >>>> >>>> Perso fibre orange “pro” j’ai du set le MSS à la main pour que ça marche >>>> (je n’utilise pas la livebox). Visiblement la box d’origine a des settings >>>> en dur et avec un routeur tiers ça ne se fait pas tout seul. >>>> >>>> ++ ic >>>> >>>>> On 19 Jun 2017, at 11:26, David Ponzone <david.ponz...@gmail.com >>>>> <mailto:david.ponz...@gmail.com>> wrote: >>>>> >>>>> Ce qui est surprenant, c’est que depuis mon FTTH SFR, je ne peux pas >>>>> faire un ping plus gros que 1450 octets (headers+payload) en IPv6, >>>>> quelque soit le site (Apple, Facebook, MS, VMware), même avec la >>>>> fragmentation activée (par défaut). >>>> >>> >>> >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >> > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
