IPv4 fragmente en transit ; IPv6 envoie à la place un message de paquet trop grand

Les défaillances d'IPv6 sont imputées au protocole bien plus souvent qu'à la taille du paquet qui les a causées. Les deux familles traitent réellement différemment un paquet trop grand, et c'est un tunnel qui rend cette différence importante. Les routeurs IPv4 peuvent fragmenter un paquet lorsque les règles l'autorisent, alors que les routeurs IPv6 ne doivent pas fragmenter en transit du tout. IPv6 le dit à la place à l'émetteur, et l'émetteur est censé réagir. Tout ce qui échoue ensuite découle de l'arrivée ou non de ce message.

Ce que fait chaque famille

Le tableau est le mécanisme en quatre lignes, et une ligne explique l'essentiel de la confusion.

IPv6 n'a pas de fragmentation en transit ni d'indicateur DF à effacer, donc il n'y a rien sur quoi se rabattre quand un paquet est trop grand. Il faut le dire à l'émetteur, et l'émetteur doit le croire.

Le tunnel rétrécit le chemin en silence

Un VPN ajoute des en-têtes externes, et dans le cas chiffré des données d'intégrité aussi, avant que le paquet ne quitte l'hôte. Le paquet interne peut tenir dans la MTU de l'interface qu'il voit tandis que le paquet externe dépasse la limite du lien suivant, et c'est pourquoi cela apparaît d'abord dans un tunnel. Abaissez délibérément la MTU de l'interface du tunnel, ou fixez le MSS TCP sur le chemin, et notez quel nombre vous avez choisi et pourquoi.

La surcharge ESP dépend du mode et des algorithmes, donc la bonne MTU du tunnel est un calcul et non une convention. Quoi que vous choisissiez, cela doit laisser de la place à un paquet IPv6 interne complet de 1280 octets, car chaque lien IPv6 doit en transporter autant. Un tunnel qui ne peut pas transporter 1280 octets d'IPv6 n'est pas un problème de réglage ; c'est un chemin cassé pour cette famille. Cette contrainte est précisément ce qui disparaît quand une valeur de MTU est copiée depuis un déploiement uniquement IPv4.

Pourquoi le symptôme est un blocage

La panne n'est pas une erreur propre, et c'est pourquoi elle est mal diagnostiquée. Une poignée de main TCP aboutit, de petites réponses arrivent, et la connexion se fige dès qu'une grande réponse ou un envoi massif commence, car ce sont les premiers paquets assez grands pour être jetés. SSH se connecte puis se fige sur la première sortie volumineuse, et l'en-tête d'une page se charge tandis que le corps ne se termine jamais.

Si les messages ICMPv6 de paquet trop grand sont filtrés, l'émetteur ne l'apprend jamais et réessaie sans cesse la même taille. C'est un trou noir et non un chemin lent, et sa signature est une frontière de taille reproductible et non une perte aléatoire. Autoriser le trafic de contrôle concerné fait partie d'un déploiement IPv6 qui fonctionne, ce n'est pas une courtoisie.

Ne désactivez pas les messages dont votre propre chemin dépend, puis ne décrivez pas le résultat comme une panne d'IPv6. Le même argument vaut pour les messages Fragmentation Needed d'IPv4, tout aussi impopulaires auprès des auteurs de pare-feu et tout aussi nécessaires.

Mesurez la frontière, puis corrigez la couche

Vérifiez au lieu de deviner : utilisez l'indicateur don't-fragment sur IPv4 et des tailles de charge fixes sur IPv6, et notez où les réponses s'arrêtent. ping -M do -s 1472 et ping -6 -s 1400 suffisent à établir la forme du problème, et tracepath signale la MTU de chemin découverte en cours de route.

Corrigez ensuite la couche qui possède le nombre : la MTU de l'interface du tunnel, le serrage du MSS pour TCP, ou le chemin lui-même. RFC 8200 est la référence pour la règle IPv6, et sa lecture est plus courte que l'incident qu'elle évite.

Testez la famille que l'application utilise réellement, car un nom en double pile peut répondre sur une famille et pas sur l'autre, et une application peut basculer après un changement de réseau. Notez l'adresse que vous avez testée, car un résultat sur l'enregistrement A ne dit rien de l'enregistrement AAAA.

Traitez la frontière de taille comme une preuve

Une frontière de taille reproductible est l'une des rares pannes réseau qui se reproduisent exactement, au même nombre d'octets, depuis la même source, à chaque fois. Cela en fait un cadeau et non un mystère, et cela signifie aussi qu'un correctif peut être vérifié au lieu d'être espéré.

Écrivez dans le ticket la MTU découverte, la MTU du tunnel configurée et le test qui a prouvé la différence. La personne suivante rencontrera la même arithmétique sur un autre lien.