MTU IPv6 et Path MTU Discovery : éviter les problèmes de fragmentation

La fragmentation des paquets est l'un de ces problèmes que vous ne remarquez pas jusqu'à ce qu'elle casse tout.

TL;DR - Résumé rapide

Points clés :

Les routeurs IPv6 ne peuvent pas fragmenter : les hôtes sources doivent gérer toute fragmentation via Path MTU Discovery
Ne jamais bloquer ICMPv6 Type 2 : les messages Packet Too Big sont essentiels au fonctionnement de PMTUD
MTU minimum de 1280 octets : tous les liens IPv6 doivent le supporter, l'utiliser comme solution de secours
Les tunnels réduisent le MTU : tenir compte de la surcharge d'encapsulation (6in4 : 20 octets, VPN : 40-80 octets)
Utiliser MSS clamping : forcer TCP à utiliser des segments plus petits quand PMTUD échoue

Aller à : Trous noirs PMTUD | Diagnostiquer les problèmes MTU | Configuration pare-feu

Pourquoi le MTU est plus important en IPv6 #

IPv6 a complètement supprimé la fragmentation au niveau des routeurs. En IPv4, si un routeur reçoit un paquet trop grand pour le prochain saut, il peut le fragmenter. Les routeurs IPv6 ne peuvent pas faire cela — ils abandonnent le paquet et renvoient un message ICMPv6 « Packet Too Big » à la source.

L'hôte source est responsable de toute fragmentation. Cette décision de conception améliore les performances des routeurs et simplifie le protocole, mais elle transfère la charge aux points de terminaison et rend le Path MTU Discovery (PMTUD) critique.

Si le PMTUD échoue, vos connexions se bloquent mystérieusement. Les handshakes TCP se terminent, mais le transfert de données se bloque. Les requêtes HTTP expirent. Les sessions SSH se figent après l'authentification. Ce sont les symptômes classiques d'un trou noir MTU.

MTU minimum IPv6 #

Tous les liens IPv6 doivent supporter au moins 1280 octets. C'est le MTU minimum, et il est non négociable. Si votre lien ne peut pas gérer des paquets de 1280 octets, il n'est pas conforme à IPv6.

La plupart des réseaux utilisent 1500 octets (MTU Ethernet standard), ce qui fournit de l'espace pour l'en-tête IPv6 de 40 octets plus 1460 octets de charge utile. C'est équivalent au MSS TCP typique de 1460 en IPv4.

Les tunnels et les protocoles d'encapsulation réduisent le MTU disponible. Si vous utilisez IPv6-in-IPv4 (6in4), 6to4 ou ISATAP, vous perdez des octets pour l'en-tête externe. Les VPN, IPsec, GRE et VXLAN consomment tous de l'espace MTU.

Valeurs MTU courantes que vous rencontrerez :

1500 : Ethernet standard
1480 : PPPoE (perd 8 octets pour l'overhead PPP)
1460 : tunnel 6in4 (perd 20 octets pour l'en-tête IPv4)
1420 : 6in4 sur PPPoE
1280 : MTU minimum IPv6, valeur de repli
9000 : Jumbo frames (réseaux de datacenter)

Comment fonctionne le Path MTU Discovery #

Le PMTUD détermine la taille maximale de paquet pouvant traverser le chemin entre la source et la destination sans fragmentation.

Le processus est simple :

L'hôte envoie des paquets avec le MTU actuel
Si un routeur le long du chemin a un MTU plus petit, il abandonne le paquet
Le routeur renvoie un message ICMPv6 Type 2 « Packet Too Big » à la source
Le message inclut le MTU du prochain saut
L'hôte réduit son MTU de chemin et renvoie
Le processus se répète jusqu'à ce que les paquets traversent le chemin entier

Le message « Packet Too Big » (ICMPv6 Type 2, Code 0) contient la valeur MTU dans la charge utile du message. Cela indique à la source exactement quelle taille les paquets peuvent avoir, pas seulement qu'ils sont trop gros.

Voici à quoi ressemble le message ICMPv6 :

ICMPv6 Packet Too Big:
  Type: 2
  Code: 0
  MTU: 1280
  [Original packet headers up to minimum MTU]

L'hôte maintient un cache de MTU de chemin avec des entrées qui expirent généralement après 10 minutes (recommandation RFC 8201). Si les chemins réseau changent, les entrées de cache obsolètes pourraient causer des problèmes jusqu'à leur expiration.

Trous noirs PMTUD #

Le système se casse lorsque les messages ICMPv6 Type 2 sont bloqués. Cela crée des « trous noirs PMTUD » où les paquets disparaissent silencieusement.

Causes courantes :

Pare-feu trop zélés : les administrateurs bloquent parfois tout le trafic ICMP, le considérant comme un risque de sécurité. C'est faux. ICMPv6 fait partie intégrante du fonctionnement d'IPv6, ce n'est pas un protocole de diagnostic optionnel comme ping.

Problèmes d'inspection avec état : certains pare-feu n'associent pas correctement les messages d'erreur ICMPv6 aux connexions existantes, les abandonnant comme du trafic non sollicité.

Limitation de débit : les dispositifs de sécurité peuvent limiter le débit d'ICMPv6, abandonnant les messages PMTUD légitimes pendant les périodes chargées.

Passerelles NAT64 : la traduction entre IPv6 et IPv4 peut perdre les informations PMTUD si la passerelle ne traduit pas correctement les messages ICMP.

Symptômes des trous noirs PMTUD :

La connexion TCP s'établit (SYN, SYN-ACK, ACK complet)
Les petits paquets fonctionnent (requêtes DNS, bannière de connexion SSH)
Les gros paquets échouent (transferts de fichiers, HTTP POST avec corps, session SSH interactive après authentification)
Aucun message d'erreur, juste des timeouts
Le problème semble intermittent (dépend de la taille du paquet)

Diagnostiquer les problèmes MTU #

Commencez avec ping. Envoyez des paquets de tailles spécifiques pour tester le MTU du chemin :

# Test avec 1280 octets (MTU minimum)
ping6 -M do -s 1232 2001:db8::1
 
# Test avec 1500 octets (Ethernet standard)
ping6 -M do -s 1452 2001:db8::1
 
# Test avec 1280 octets de charge utile
ping6 -c 5 -s 1280 2001:db8::1

Le flag -M do interdit la fragmentation (don't fragment). L'argument -s spécifie la taille de la charge utile — ajoutez 8 octets pour l'en-tête ICMPv6 et 40 pour l'en-tête IPv6 pour obtenir la taille totale du paquet.

Si 1452 octets échoue mais 1232 réussit, votre MTU de chemin est entre 1280 et 1500. Recherche binaire pour trouver la valeur exacte :

# Essayez 1400
ping6 -M do -s 1352 2001:db8::1
 
# Essayez 1450
ping6 -M do -s 1402 2001:db8::1

Utilisez traceroute pour identifier où le MTU change :

traceroute6 -n 2001:db8::1

Ensuite, testez le MTU vers chaque saut individuellement. Le saut où les gros paquets commencent à échouer est votre point problématique.

Pour les connexions TCP, observez le comportement réel :

# Capturer les paquets
tcpdump -i eth0 -n 'ip6 and (icmp6 or tcp)'

Recherchez :

Les retransmissions TCP après le handshake initial
Les messages ICMPv6 Type 2 (devraient apparaître si PMTUD fonctionne)
L'absence d'ICMPv6 Type 2 (indique un blocage ou un trou noir)

Les outils modernes peuvent automatiser cela. MTR combine traceroute avec des tests de taille de paquet :

# Test avec des paquets de 1400 octets
mtr -6 -s 1400 2001:db8::1

TCP MSS Clamping #

MSS (Maximum Segment Size) est l'option TCP qui indique à l'autre extrémité combien de données elle peut envoyer dans chaque segment. MSS = MTU - en-tête IP - en-tête TCP.

Pour IPv6 : MSS = MTU - 40 (IPv6) - 20 (TCP) = MTU - 60

Avec un MTU standard de 1500 octets : MSS = 1440

Le MSS clamping force les connexions TCP à utiliser une valeur MSS plus faible, contournant les problèmes MTU sans s'appuyer sur PMTUD. C'est courant sur les routeurs qui terminent les tunnels ou les connexions PPPoE.

Configurer le MSS clamping sur Linux :

# Limiter le MSS à 1280 pour IPv6
ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1220

La valeur 1220 tient compte du MTU de 1280 moins 60 octets pour les en-têtes.

Pour PPPoE avec MTU de 1492 :

ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1432

Le MSS clamping n'affecte que TCP. UDP, SCTP et d'autres protocoles s'appuient toujours sur PMTUD ou la fragmentation au niveau applicatif.

Configuration du pare-feu #

Votre pare-feu doit autoriser les messages ICMPv6 Type 2 pour que PMTUD fonctionne. C'est non négociable pour les réseaux IPv6 de production.

Types ICMPv6 minimum requis pour le fonctionnement d'IPv6 :

Type 1 : Destination Unreachable
Type 2 : Packet Too Big (PMTUD)
Type 3 : Time Exceeded
Type 4 : Parameter Problem
Type 133-137 : Neighbor Discovery Protocol

Règle iptables pour PMTUD :

# Autoriser ICMPv6 Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type 2 -j ACCEPT

Meilleure approche — autoriser tout ICMPv6 nécessaire :

# Autoriser ICMPv6 établi
ip6tables -A INPUT -p ipv6-icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Autoriser les types ICMPv6 nécessaires
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 1 -j ACCEPT    # Destination Unreachable
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT    # Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 3 -j ACCEPT    # Time Exceeded
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 4 -j ACCEPT    # Parameter Problem
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -j ACCEPT  # Echo Request
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT  # Echo Reply
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 133 -j ACCEPT  # Router Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 134 -j ACCEPT  # Router Advertisement
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 135 -j ACCEPT  # Neighbor Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 136 -j ACCEPT  # Neighbor Advertisement

La limitation de débit est acceptable mais définissez des limites généreuses :

# Autoriser ICMPv6 avec limitation de débit
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 \
  -m limit --limit 10/sec --limit-burst 20 -j ACCEPT

Ne bloquez jamais complètement ICMPv6. Ce n'est pas un risque de sécurité — c'est une exigence du protocole.

Considérations MTU pour les tunnels #

Les tunnels réduisent le MTU effectif par l'overhead des en-têtes d'encapsulation.

Types de tunnels courants et overhead :

Type de tunnel	Overhead	MTU effectif (depuis 1500)
6in4	20 octets	1480
6to4	20 octets	1480
6rd	20 octets	1480
ISATAP	20 octets	1480
GRE	24 octets	1476
IPsec	50-70 octets	1430-1450
WireGuard	60 octets	1420
OpenVPN	40-80 octets	1420-1460

Configurez le MTU du tunnel explicitement pour éviter les problèmes :

# tunnel 6in4
ip tunnel add tun6in4 mode sit remote 203.0.113.1 local 198.51.100.1
ip link set tun6in4 mtu 1480
ip link set tun6in4 up

Pour WireGuard :

[Interface]
MTU = 1420

Certains protocoles de tunnel supportent la découverte MTU, mais la configuration explicite est plus fiable.

Jumbo Frames et datacenters #

Les réseaux de datacenter utilisent souvent un MTU de 9000 octets (jumbo frames) pour améliorer le débit des transferts en masse.

Activer les jumbo frames sur les interfaces :

ip link set eth0 mtu 9000

Assurez-vous que tous les switchs et routeurs dans le chemin supportent les jumbo frames. Un dispositif avec un MTU de 1500 octets deviendra un goulot d'étranglement.

PMTUD s'applique toujours. Si un paquet quitte votre réseau jumbo frame vers Internet, il doit se réduire à 1500 ou moins.

Tests et vérification #

Vérifiez la configuration MTU de votre hôte :

ip -6 link show

Recherchez la valeur MTU sur chaque interface.

Vérifiez le cache MTU de chemin actuel :

ip -6 route get 2001:db8::1

La sortie montre le MTU en cache pour cette destination.

Testez la connectivité de bout en bout avec des tailles de paquet variables :

for size in 1232 1352 1402 1452; do
  echo "Testing $size bytes:"
  ping6 -M do -s $size -c 3 2001:db8::1
done

Utilisez netcat pour tester la négociation MSS TCP :

# Serveur
nc -6 -l 8080
 
# Client
nc -6 2001:db8::1 8080

Capturez les paquets avec tcpdump et vérifiez les valeurs MSS dans les paquets SYN.

Scénarios courants et corrections #

Problème : les pages Web se chargent lentement, les images échouent Cause : trou noir PMTUD dû au pare-feu bloquant ICMPv6 Type 2 Correction : configurez le pare-feu pour autoriser ICMPv6 Type 2

Problème : SSH se connecte mais se fige après la connexion Cause : MTU trop grand, PMTUD ne fonctionne pas Correction : réduisez le MTU sur l'interface client ou activez le MSS clamping sur le routeur

Problème : le VPN fonctionne pour les petits transferts, échoue pour les gros fichiers Cause : MTU du tunnel mal configuré Correction : réduisez le MTU du tunnel pour tenir compte de l'overhead d'encapsulation

Problème : IPv6 fonctionne sur le réseau local, échoue via Internet Cause : le routeur en amont a un MTU plus petit, ne l'annonce pas correctement Correction : contactez le FAI ou réduisez le MTU local à 1280 (minimum)

Problème : certaines destinations fonctionnent, d'autres échouent Cause : problèmes MTU spécifiques au chemin Correction : testez avec ping pour identifier le MTU fonctionnel, configurez l'interface en conséquence

Bonnes pratiques #

Toujours autoriser ICMPv6 Type 2 dans les pare-feu
Configurez le MTU du tunnel explicitement plutôt que de compter sur l'auto-détection
Testez avec le MTU minimum (1280) pour assurer la connectivité de base
Utilisez le MSS clamping sur les points de terminaison de tunnel et les connexions PPPoE
Surveillez les échecs PMTUD avec des captures de paquets lors du dépannage
Documentez le MTU de votre réseau à chaque couche (physique, tunnel, application)
Définissez des valeurs MTU conservatives en cas de doute (1280 fonctionne toujours)