Si on a réellement MTU=1472 en IPv4, en TCP il suffit que la Freebox modifie le MSS, donc les problèmes sous Linux sont étranges.
Est-ce qu'on a des captures côté serveur ?

En mode bridge, le MSS est quand même ajusté par la freebox?
Il semble que notre ami utilise sa box en mode bridge

Il y a un point qui ne me parait pas clair dans ce qui a été dit dans ce sujet, c'est l'histoire du MTU. D'après les liens cités par Marin, cyberjuls avait mesuré un MTU de 1500, aussi bien en linux qu'en windows :

https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283969/?topicseen#msg283969
https://lafibre.info/free-la-fibre/installation-freebox-revolution-optique-avec-convertisseur/msg283960/?topicseen#msg283960

Didjee34 parle d'un MTU de 1472 quand il est en Linux, et de 1500 quand il teste avec windows, ce qui, comme l'a relevé Darklight, ne paraît pas cohérent.

D'autre part, j'ai trouvé un lien qui semble indiquer que l'en-tête d'un tunnel IPv6 pour l'IPv4 serait de 40 octets (en particulier pour DS-lite, mais je pense que c'est la même chose pour 4rd ?) :
http://www.networkworld.com/article/2224654/cisco-subnet/mtu-size-issues.html

Par ailleurs, 1472 est une valeur particulière, c'est celle du paquet ICMP, auquel il faut rajouter 20 octets pour l'en-tête IP, et 8 pour ICMP, pour faire justement 1500 octets...

En fait, est-ce que l'on ne serait pas avec un MTU standard de 1500, et les conditions de didjee34 (mode bridge), induirait une erreur sous Linux ?

Ce qui me fait dire cela, c'est que je viens de lire dans la description du protocole DS-Lite, qu'il est recommandé d'ajouter 40 octets, justement pour que la trame IPv4 fasse toujours 1500 :

Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4 traffic over IPv6 will reduce the effective MTU of the datagram.
Unfortunately, path MTU discovery [RFC1191] is not a reliable method to deal with this problem.

A solution to deal with this problem is for the service provider to increase the MTU size of all the links between the B4 element and the
AFTR elements by at least 40 bytes to accommodate both the IPv6 encapsulation header and the IPv4 datagram without fragmenting the
IPv6 packet.

http://tools.ietf.org/html/rfc6333   Paragraphe 5.3

P.S : si c'était vrai, cela voudrait dire que le MTU en IPv6 serait de 1540, ce qu'il est possible de vérifier.

En tout cas, le MTU du paquet IPv4 ne peut pas être de 1472, avec un MTU "normal" de 1500, car l'en-tête d'un paquet IPv6 fait au minimum 40 octets, auquel peut se rajouter éventuellement d'autres informations, comme par exemple le type de protocole transporté, etc...

https://en.wikipedia.org/wiki/IPv6_packet

Si en IPv4, le MTU est de 1472, la taille du paquet IPv6 qui l'encapsule est au minimum de 1472 + 40 = 1512.

Rq : je ne vois pas comment si le paquet IPv6 n'est pas fragmenté entre les deux bouts, comment le paquet IPv4 pourrait l'être. A mon avis, il ne peut être fragmenté qu'avant l'entrée dans le tunnel, avant l'encapsulation. Si le paquet IPv6 peut être fragmenté, alors sa charge, le paquet IPv4 le sera aussi, même si c'est reconstitué plus loin.

P.S : En 6rd, le paquet IPv6 est encapsulé dans une trame IPv4. Comme l'en-tête du paquet IPv4 est de 20 octets, le MTU du paquet IPv6 est de 1480.

Si le paquet IPv4 est réparti entre deux paquets IPv6, il est fragmenté, non ? S'il n'est pas fragmenté, il est dans une seule trame IPv6 ?
Voir la référence sur DS-Lite que j'ai donnée plus haut.

Plus que moralement, si l'un des paquets est perdu, tu demandes de renvoyer quoi ?