Si un paquet est perdu, et comme ce protocole d'encapsulation ne prévoit pas de faire des retransmissions, le tout est perdu.

Il y a des cas où le protocole d'encapsulation est basé sur TCP (ce que propose OVH) et donc gère lui même les retransmissions.

Il y a aussi le cas du Wifi qui découpe les paquets et qui gère les retransmissions, ainsi que l'ADSL. Dans ces deux cas l'opération est transparente.

Encore une fois, non!

Qui a dit qu'un paquet IPv4 était la charge utile d'un paquet IPv6?

en 4rd un paquet IPv4  n'est pas entier dans le payload IP d'un paquet IPv6.
Il y a un mapping reversible entre les entêtes IPv4 et les entêtes IPv6 et le payload IP est inchangé.
Suivant les cas on peut avoir besoin de place supplèmentaire (8 octets dans le cas présent), dans ce cas la norme IPv6 permet d'utiliser ce qu'on appelle un  "IPv6 Fragment Header" pour avoir plus de place.


                     (A) Without IPv6 fragment header
            IPv4 packet                          Tunnel packet
       +--------------------+ :            : +--------------------+
     20|     IPv4 Header    | :    <==>    : |     IPv6 Header    | 40
       +--------------------+ :            : +--------------------+
       |     IP Payload     |      <==>      |     IP Payload     |
       |                    |     Layer 4    |                    |
       +--------------------+    unchanged   +--------------------+


                     (B) With IPv6 fragment header
                                                 Tunnel packet
                                           : +--------------------+
            IPv4 packet                    : |     IPv6 Header    | 40
       +--------------------+ :            : +--------------------+
     20|     IPv4 Header    | :    <==>    : |IPv6 Fragment Header|  8
       +--------------------+ :            : +--------------------+
       |     IP Payload     |      <==>      |     IP Payload     |
       |                    |     Layer 4    |                    |
       +--------------------+    unchanged   +--------------------+


Ca n'est donc pas un tunnel comme en DS-lite, c'est un tunnel comme en 6rd mais ou les roles sont inversés.

lisez la RFC https://tools.ietf.org/html/rfc7600 si vous voulez tout les détails du mapping entre entêtes.

en 4rd un paquet IPv4  n'est pas entier dans le payload IP d'un paquet IPv6.
Il y a un mapping reversible entre les entêtes IPv4 et les entêtes IPv6 et le payload IP est inchangé.
Suivant les cas on peut avoir besoin de place supplèmentaire (8 octets dans le cas présent), dans ce cas la norme IPv6 permet d'utiliser ce qu'on appelle un  "IPv6 Fragment Header" pour avoir plus de place.


                     (A) Without IPv6 fragment header
            IPv4 packet                          Tunnel packet
       +--------------------+ :            : +--------------------+
     20|     IPv4 Header    | :    <==>    : |     IPv6 Header    | 40
       +--------------------+ :            : +--------------------+
       |     IP Payload     |      <==>      |     IP Payload     |
       |                    |     Layer 4    |                    |
       +--------------------+    unchanged   +--------------------+


                     (B) With IPv6 fragment header
                                                 Tunnel packet
                                           : +--------------------+
            IPv4 packet                    : |     IPv6 Header    | 40
       +--------------------+ :            : +--------------------+
     20|     IPv4 Header    | :    <==>    : |IPv6 Fragment Header|  8
       +--------------------+ :            : +--------------------+
       |     IP Payload     |      <==>      |     IP Payload     |
       |                    |     Layer 4    |                    |
       +--------------------+    unchanged   +--------------------+


Ca n'est donc pas un tunnel comme en DS-lite, c'est un tunnel comme en 6rd mais ou les roles sont inversés.

lisez la RFC https://tools.ietf.org/html/rfc7600 si vous voulez tout les détails du mapping entre entêtes.

Si je comprends bien, le mapping permet de faire tenir l'en-tête IPv4 dans celui IPv6. Donc de combien est l'en-tête dans le cas de l'encapsulation 4rd, si on retire ce qui est commun avec IPv4 ? Comme l'en-tête IPv6 est de 40 octets, et celui IPv4 de 20 octets, cela ferait encore +20, et donc éventuellement le fragment header de 8, donc 28 ? Dans ce cas, on arriverait effectivement à 2472.

Pourquoi tu poses comme hypothèse l'approche la plus lourde en terme de surcharge protocolaire?

Tu supposerais que quand une marchandise arrive par camion, le camion est arrivé sur un train, le train sur la bateau et le bateau sur un avion (ou inversement)?

En tout cas, c'est bien ce qu'il semble se passer dans un tunnel 4in6 :

IPv6 encapsulation consists of prepending to the original packet an IPv6 header and, optionally, a set of IPv6 extension headers

Voir : https://tools.ietf.org/html/rfc2473#section-3.1

D'où la recommandation sur DS-Lite que j'ai déjà citée :

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#section-5.3

Si tu étais un peu plus aimable ? Je préfère les explications détaiallées de kgersen.

Je me répète mais on est certain des tests déja effectués?

le test canonique sous Windows est:

ping -4 -f -l 1472 lafibre.info
ce qui donne un MTU couche IP de 1500 (ping de 1472 + 8 icmp + 20 entete IPv4)

y'aurait pas une confusion du niveau du MTU (couche 3, couche 4) quelque part dans les échanges entre personnes ici ?

un MTU couche IP  de 1472 c'est un ping de ping de 1444 (- 8 icmp - 20 entete IPv4)

donc
ping -4 -f -l 1444 lafibre.infodoit passer
et
ping -4 -f -l 1445 lafibre.infone doit pas passer