MTU Starlink : la MTU du chemin mesurée à 1500 octets

Des paquets de 1500 octets ont atteint les trois hôtes de test, en IPv4 et en IPv6

La MTU (maximum transmission unit, unité de transmission maximale) d’un lien est le plus grand paquet qu’il transporte d’un seul tenant, et la MTU d’un chemin (path MTU) est la plus petite MTU de lien le long de ce chemin. La section 2 de la RFC 8201, consultée en octobre 2026, la définit comme « the minimum link MTU of all the links in a path between a source node and a destination node » (la plus petite MTU de lien parmi tous les liens d’un chemin entre un nœud source et un nœud de destination).

Le test a été lancé en octobre 2026 depuis un ordinateur relié par câble au réseau domestique, sur une connexion Starlink à la maison, en deux relevés à quelques minutes d’intervalle. Toutes les routes vers les hôtes de test sortaient par l’interface filaire ; aucun VPN, nœud de sortie ou tunnel ne transportait donc le trafic. Dans chaque relevé, pour chaque hôte, en IPv4 et en IPv6, tracepath est allé jusqu’au bout. Ensuite, trois pings dimensionnés pour former des paquets de 1500 octets sont partis avec l’option ne pas fragmenter activée et un délai de réponse de 2 secondes. Trois autres, dimensionnés pour former des paquets de 1501 octets, ont été refusés par l’ordinateur avant d’être envoyés.

Les trois hôtes sont des machines publiques que leurs opérateurs proposent pour des tests réseau (chaque page consultée en octobre 2026) :

• scanme.nmap.org, que le projet Nmap a mis en place pour que chacun puisse « test and make sure that their Nmap installation (or Internet connection) is working properly » (vérifier que son installation de Nmap, ou sa connexion à Internet, fonctionne correctement) ;
• speedtest.newark.linode.com, dont la page d’accueil a pour titre « Linode, now Akamai, Speedtest » (Linode, désormais Akamai, test de débit) ;
• proof.ovh.net, un hôte de test de débit réseau d’OVHcloud.

La découverte de la MTU du chemin part de la MTU du premier lien de l’émetteur. En IPv4, l’émetteur active le bit Don't Fragment (DF, ne pas fragmenter), et un routeur qui ne peut pas transmettre un tel paquet entier le rejette et renvoie un message ICMP qui signifie « fragmentation needed and DF set », c’est-à-dire fragmentation nécessaire mais bit DF activé (RFC 1191, section 2, consultée en octobre 2026). En IPv6, un routeur qui ne peut pas transmettre un paquet parce qu’il dépasse la MTU du lien suivant doit renvoyer un message Packet Too Big (RFC 4443, section 3.2, consultée en octobre 2026). Dans les deux cas, l’émetteur abaisse son estimation (RFC 8201, section 3). tracepath trace un chemin en « discovering MTU along this path », c’est-à-dire en découvrant la MTU le long de ce chemin, et affiche la MTU du chemin là où elle change (iputils 20250605, page consultée en octobre 2026). Dans chaque tracé fait ici, elle est restée à 1500 du début à la fin, et aucun ping n’a déclenché de message « too big » (trop grand) ; aucun saut n’a donc signalé de MTU plus petite.

Les pings vérifient la même chose de bout en bout. Chaque ping de 1500 octets a atteint son hôte, et sa réponse est revenue. Cela couvre les sauts qui ne répondent pas à tracepath, que seuls les pings testent. Le chemin commence aussi au routeur de la maison, donc les réglages propres au routeur font partie du résultat : rien sur ces chemins, routeur de la maison et réseau de Starlink compris, ne coupait les paquets en dessous de 1500 octets à ce moment-là.

En IPv4, les tracés commençaient par les mêmes types de sauts que le tracé du guide sur l’auto-hébergement sans adresse IPv4 publique, que cette page ne répète pas.

Un ping de 1472 octets est un paquet de 1500 octets en IPv4

L’option -s de ping fixe le nombre d’octets de données, et ICMP y ajoute un en-tête de 8 octets (ping(8), iputils 20250605, page consultée en octobre 2026). Un message d’écho ICMPv6 a lui aussi 8 octets avant ses données : type, code, somme de contrôle, identifiant et numéro de séquence (RFC 4443, section 4.1, consultée en octobre 2026). Un en-tête IPv4 minimal fait 20 octets, et un en-tête IPv6 fait 20 octets de plus, soit 40 (RFC 8200, section 8.3, consultée en octobre 2026).

Un ping avec l’option ne pas fragmenter qui obtient des réponses avec 1472 octets de données en IPv4 signifie qu’un paquet de 1500 octets a traversé le chemin. Les 1472 octets sont la charge utile du ping, et la MTU, c’est le paquet entier.

En IPv6, les routeurs ne découpent jamais un paquet : « fragmentation in IPv6 is performed only by source nodes » (en IPv6, la fragmentation n’est faite que par les nœuds sources), dit la RFC 8200 (section 4.5). Un ping de 1500 octets en IPv6 traverse donc entier, ou rencontre un routeur qui doit répondre par un message Packet Too Big (RFC 4443, section 3.2).

Pour refaire le test sous Linux avec iputils, lancez ces commandes, montrées ici avec l’un des trois hôtes :

tracepath -4 -n scanme.nmap.org
ping -4 -M do -n -c 3 -W 2 -s 1472 scanme.nmap.org
tracepath -6 -n scanme.nmap.org
ping -6 -M do -n -c 3 -W 2 -s 1452 scanme.nmap.org

-M do active l’option ne pas fragmenter, -c 3 envoie trois pings et -W 2 fixe un délai de réponse de 2 secondes (ping(8)). La page de Nmap demande aux visiteurs de ménager son hôte : « A few scans in a day is fine » (quelques analyses par jour, ça va). Les commandes ping d’autres systèmes prennent d’autres options, et cette page ne les couvre pas.

Les paquets de 1501 octets n’ont jamais quitté l’ordinateur

Sur un ordinateur dont la MTU du lien est de 1500 octets, un ping avec -M do et 1473 octets de données (IPv4) ou 1453 (IPv6) qui échoue aussitôt, avec une erreur locale indiquant que le message est trop long pour une MTU de 1500, a été refusé par cet ordinateur. Cet échec ne dit rien de votre fournisseur d’accès.

Si l’erreur indique une MTU inférieure à 1500, cette lecture ne s’applique pas. L’ordinateur compare alors le paquet à une limite plus basse que celle de son lien, et cette limite peut venir du chemin : un émetteur abaisse son estimation après un message « too big » envoyé par un routeur (RFC 1191, section 2 ; RFC 8201, section 3).

Les outils de tunnel comptent 80 octets pour les en-têtes de WireGuard

Dans le noyau Linux, une nouvelle interface WireGuard reçoit dev->mtu = ETH_DATA_LEN - overhead (device.c, Linux 6.18). ETH_DATA_LEN vaut 1500, la charge utile maximale d’Ethernet (if_ether.h). Le surcoût (overhead) correspond au plus petit message de données de WireGuard, plus un en-tête UDP de 8 octets (RFC 768) et le plus grand des en-têtes IPv6 et IPv4, les 40 octets d’IPv6 (RFC 8200). Ce message fait 32 octets : un type de 4 octets, un index de clé de 4 octets, un compteur de 8 octets et un tag d’authentification de 16 octets (messages.h, avec la taille du tag dans chacha20poly1305.h). Le surcoût est donc de 80 octets, et l’interface démarre à 1420. Le tout consulté en octobre 2026.

Le tag vient après les données chiffrées : dans l’AEAD (authenticated encryption with associated data, chiffrement authentifié avec données associées) de la RFC 8439, la sortie est le texte chiffré, puis le tag (section 2.8, consultée en octobre 2026).

wg-quick sous Linux utilise la ligne MTU de la configuration de l’interface quand elle existe. Sans elle, le script lit la MTU des routes vers les points de terminaison des pairs, se rabat sur celle de la route par défaut puis sur 1500, et règle l’interface 80 octets plus bas (linux.bash, wireguard-tools v1.0.20250521, consulté en octobre 2026). Sur une route à 1500 octets, cela donne 1420.

Tailscale compte les mêmes 80 octets pour le pire cas, un en-tête extérieur IPv6. Sa liste comprend un « 20-byte IPv4 header or 40-byte IPv6 header » (un en-tête de 20 octets en IPv4 ou de 40 octets en IPv6), un en-tête UDP de 8 octets, un type de 4 octets, un index de clé de 4 octets, un nonce de 8 octets et un tag d’authentification de 16 octets (mtu.go, Tailscale v1.90.0, consulté en octobre 2026). Dans ce fichier, la taille ne dépend pas du lien : DefaultTUNMTU(), que le fichier utilise pour fixer la MTU de l’interface, renvoie 1280, la MTU par défaut qu’il qualifie de « safe » (sans risque), sauf si le réglage de débogage TS_DEBUG_MTU donne une autre taille. Elle renvoie 1280 même avec TS_DEBUG_ENABLE_PMTUD, le réglage de débogage qui sonde la MTU du chemin, activé. Avec les 80 octets ajoutés, 1280 donne 1360 octets sur le fil. La valeur 1280 est aussi la plus petite MTU qu’IPv6 autorise sur un lien (RFC 8200, section 5).

Les chemins de ce test transportaient des paquets de 1500 octets. Aucun tunnel n’y circulait ; cette page ne montre donc pas ce qu’auraient fait les paquets d’un tunnel.

Quand un paquet est trop grand pour un lien et que le message « too big » n’atteint jamais l’émetteur, la RFC 8201, dans sa section 1, décrit des connexions qui « complete the TCP three-way handshake correctly but then hang when data is transferred » (terminent correctement la poignée de main TCP en trois temps, puis se figent quand des données sont transférées). Ce test ne l’a pas recherché.

Non testé ici

• La MTU d’un tunnel sur cette connexion, pour WireGuard, Tailscale ou un VPN professionnel. Savoir si changer une MTU règle un problème de VPN n’est pas testé non plus.
• Un maximum ou une valeur par défaut. Rien au-delà de 1500 octets n’a pu quitter l’ordinateur de test ; cette page ne montre donc aucun maximum. Les pages de Starlink sur la MTU n’ont pas été lues pour cette page ; elle ne montre donc pas non plus de valeur par défaut.
• Le Wi-Fi. Les deux relevés ont été faits sur un lien filaire.
• D’autres connexions et d’autres moments. Les deux relevés étaient espacés de quelques minutes, et selon la RFC 8201 (section 3), la MTU d’un chemin « may change over time, due to changes in the routing topology » (peut changer avec le temps, du fait de changements dans la topologie de routage).

Voir comment ces résultats s’articulent avec les autres tests faits à la maison, pour un homelab.