Starlink-MTU-Größe: Pfad-MTU von 1500 Byte gemessen

1500-Byte-Pakete erreichten alle drei Testhosts, über IPv4 und IPv6

Die MTU (Maximum Transmission Unit) eines Links ist das größte Paket, das er in einem Stück überträgt, und die MTU eines Pfades ist die kleinste Link-MTU auf diesem Pfad. RFC 8201 formuliert es als „the minimum link MTU of all the links in a path between a source node and a destination node“, die kleinste Link-MTU aller Links auf einem Pfad zwischen Quell- und Zielknoten (Abschnitt 2, abgerufen im Oktober 2026).

Der Test lief im Oktober 2026 auf einem per Kabel angeschlossenen Computer im Heimnetz, an einem Starlink-Anschluss zu Hause, in zwei Durchläufen im Abstand weniger Minuten. Jede Route zu den Testhosts lief über die kabelgebundene Schnittstelle, kein VPN, kein Exit-Node und kein Tunnel trug also den Verkehr. In jedem Durchlauf lief für jeden Host, über IPv4 und über IPv6, tracepath bis zu seinem Ende. Dann gingen drei Pings hinaus, so bemessen, dass 1500-Byte-Pakete entstehen, mit gesetztem Don't-Fragment-Bit und 2 Sekunden Antwort-Timeout. Drei weitere, für 1501-Byte-Pakete bemessen, lehnte der Computer ab, bevor sie gesendet wurden.

Die drei Hosts sind öffentliche Rechner, die ihre Betreiber für Netztests anbieten (jede Seite abgerufen im Oktober 2026):

• scanme.nmap.org, den das Nmap-Projekt eingerichtet hat, damit Leute „test and make sure that their Nmap installation (or Internet connection) is working properly“, also prüfen können, ob ihre Nmap-Installation oder Internetverbindung richtig funktioniert;
• speedtest.newark.linode.com, dessen Startseite den Titel „Linode, now Akamai, Speedtest“ trägt;
• proof.ovh.net, ein Host von OVHcloud für Geschwindigkeitstests im Netz.

Path MTU Discovery beginnt mit der MTU des ersten Links des Senders. Über IPv4 setzt der Sender das Don't-Fragment-Bit (DF), und ein Router, der ein solches Paket nicht im Ganzen weiterleiten kann, verwirft es und schickt eine ICMP-Nachricht zurück, die „fragmentation needed and DF set“ bedeutet (RFC 1191, Abschnitt 2, abgerufen im Oktober 2026). Über IPv6 muss ein Router, der ein Paket nicht weiterleiten kann, weil es größer ist als die MTU des nächsten Links, eine Packet-Too-Big-Nachricht zurückschicken (RFC 4443, Abschnitt 3.2, abgerufen im Oktober 2026). So oder so senkt der Sender seine Schätzung (RFC 8201, Abschnitt 3). tracepath verfolgt einen Pfad, „discovering MTU along this path“, ermittelt also die MTU entlang des Pfades, und zeigt die Pfad-MTU dort, wo sie sich ändert (iputils 20250605, abgerufen im Oktober 2026). In jedem Trace hier blieb sie vom Anfang bis zum Ende bei 1500, und kein Ping löste eine „too big“-Nachricht aus, kein Hop meldete also eine kleinere MTU.

Die Pings prüfen dasselbe von Ende zu Ende. Jeder 1500-Byte-Ping erreichte seinen Host, und seine Antwort kam zurück. Damit sind auch Hops abgedeckt, die tracepath nicht antworten; die testen nur die Pings. Der Pfad beginnt auch am Heimrouter, die Einstellungen des Routers sind also Teil des Ergebnisses: Nichts auf diesen Pfaden, Heimrouter und Netz von Starlink eingeschlossen, begrenzte Pakete zu diesem Zeitpunkt auf weniger als 1500 Byte.

Über IPv4 begannen die Traces mit denselben Arten von Hops wie der Trace in der Anleitung zum Selbsthosten ohne öffentliche IPv4-Adresse, den diese Seite nicht wiederholt.

Ein 1472-Byte-Ping ist ein 1500-Byte-IPv4-Paket

Die Option -s von ping legt die Zahl der Datenbytes fest, und ICMP fügt ihnen einen 8-Byte-Header hinzu (ping(8), iputils 20250605, abgerufen im Oktober 2026). Eine ICMPv6-Echo-Nachricht hat vor ihren Daten ebenfalls 8 Byte: Typ, Code, Prüfsumme, Kennung und Sequenznummer (RFC 4443, Abschnitt 4.1, abgerufen im Oktober 2026). Ein minimaler IPv4-Header hat 20 Byte, und ein IPv6-Header ist 20 Byte länger, 40 (RFC 8200, Abschnitt 8.3, abgerufen im Oktober 2026).

Bekommt ein Ping mit gesetztem Don't-Fragment-Bit und 1472 Byte Daten über IPv4 Antworten, hat ein 1500-Byte-Paket den Pfad durchquert. 1472 ist die Nutzlast des Pings, und die MTU ist das ganze Paket.

Über IPv6 teilen Router ein Paket nie: „fragmentation in IPv6 is performed only by source nodes“, sagt RFC 8200 (Abschnitt 4.5), fragmentiert wird also nur am Absender. Ein 1500-Byte-IPv6-Ping kommt daher entweder ganz durch oder trifft auf einen Router, der mit einer Packet-Too-Big-Nachricht antworten muss (RFC 4443, Abschnitt 3.2).

Um den Test unter Linux mit iputils zu wiederholen, führe diese Befehle aus, hier mit einem der drei Hosts:

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 schaltet Don't-Fragment ein, -c 3 sendet drei Pings und -W 2 setzt 2 Sekunden Antwort-Timeout (ping(8)). Die Nmap-Seite bittet Besucher, den Host zu schonen: „A few scans in a day is fine“, ein paar Scans am Tag sind in Ordnung. Die ping-Befehle anderer Systeme haben andere Optionen, und diese Seite behandelt sie nicht.

1501-Byte-Pakete verließen den Computer nie

Scheitert auf einem Computer, dessen eigene Link-MTU 1500 Byte beträgt, ein Ping mit -M do und 1473 Byte Daten (IPv4) oder 1453 (IPv6) sofort mit einem lokalen Fehler, die Nachricht sei für eine MTU von 1500 zu lang, dann hat ihn dieser Computer abgelehnt. Das Scheitern sagt nichts über deinen Anbieter.

Nennt der Fehler eine MTU kleiner als 1500, gilt diese Lesart nicht. Der Computer prüft das Paket dann gegen eine niedrigere Grenze als die seines Links, und diese Grenze kann vom Pfad kommen: Ein Sender senkt seine Schätzung nach einer „too big“-Nachricht eines Routers (RFC 1191, Abschnitt 2; RFC 8201, Abschnitt 3).

Tunnel-Werkzeuge rechnen für die Header von WireGuard mit 80 Byte

Im Linux-Kernel bekommt ein neues WireGuard-Interface dev->mtu = ETH_DATA_LEN - overhead (device.c, Linux 6.18). ETH_DATA_LEN ist 1500, die maximale Nutzlast von Ethernet (if_ether.h). Der Overhead ist die kleinste Datennachricht von WireGuard plus ein 8-Byte-UDP-Header (RFC 768) und der größere der Header von IPv6 und IPv4, die 40 Byte von IPv6 (RFC 8200). Diese Nachricht hat 32 Byte: 4 Byte Typ, 4 Byte Schlüsselindex, 8 Byte Zähler und 16 Byte Authentifizierungs-Tag (messages.h, mit der Größe des Tags in chacha20poly1305.h). Der Overhead beträgt also 80 Byte, und das Interface beginnt bei 1420. Alles abgerufen im Oktober 2026.

Der Tag steht hinter den verschlüsselten Daten: Bei der AEAD (authenticated encryption with associated data, authentifizierte Verschlüsselung mit zugehörigen Daten) aus RFC 8439 besteht die Ausgabe aus dem Chiffretext, dann dem Tag (Abschnitt 2.8, abgerufen im Oktober 2026).

wg-quick unter Linux nutzt die Zeile MTU in der Konfiguration des Interfaces, wenn es eine gibt. Ohne sie liest das Skript die MTU der Routen zu den Endpunkten der Peers, greift dann auf die der Standardroute und danach auf 1500 zurück und setzt das Interface 80 Byte tiefer (linux.bash, wireguard-tools v1.0.20250521, abgerufen im Oktober 2026). Bei einer 1500-Byte-Route sind das 1420.

Tailscale rechnet mit denselben 80 Byte für den ungünstigsten Fall, einen äußeren IPv6-Header. Seine Liste ist ein „20-byte IPv4 header or 40-byte IPv6 header“, also ein IPv4-Header mit 20 oder ein IPv6-Header mit 40 Byte, ein 8-Byte-UDP-Header, 4 Byte Typ, 4 Byte Schlüsselindex, eine 8-Byte-Nonce und ein 16-Byte-Authentifizierungs-Tag (mtu.go, Tailscale v1.90.0, abgerufen im Oktober 2026). In dieser Datei hängt die Größe nicht vom Link ab: DefaultTUNMTU(), mit der die Datei die MTU des Interfaces setzt, gibt 1280 zurück, ihre standardmäßige „safe“ MTU, sofern die Debug-Einstellung TS_DEBUG_MTU keine andere Größe vorgibt. Sie gibt 1280 auch dann zurück, wenn TS_DEBUG_ENABLE_PMTUD, die Debug-Einstellung zum Ermitteln der Pfad-MTU, eingeschaltet ist. Mit den 80 Byte dazu sind 1280 auf der Leitung 1360 Byte. 1280 ist auch die kleinste MTU, die IPv6 auf einem Link zulässt (RFC 8200, Abschnitt 5).

Die Pfade in diesem Test trugen 1500-Byte-Pakete. Kein Tunnel lief über sie, diese Seite zeigt also nicht, was die Pakete eines Tunnels taten.

Wenn ein Paket zu groß für einen Link ist und die „too big“-Nachricht den Sender nie erreicht, beschreibt RFC 8201 Verbindungen, die „complete the TCP three-way handshake correctly but then hang when data is transferred“, also den TCP-Drei-Wege-Handshake korrekt abschließen, dann aber hängen, sobald Daten übertragen werden (Abschnitt 1). Danach hat dieser Test nicht gesucht.

Hier nicht getestet

• Die MTU eines Tunnels über diesen Anschluss, für WireGuard, Tailscale oder ein Firmen-VPN. Ob eine geänderte MTU ein VPN-Problem behebt, ist ebenfalls nicht getestet.
• Ein Maximum oder ein Standardwert. Nichts über 1500 Byte konnte den Testcomputer verlassen, diese Seite zeigt also kein Maximum. Starlinks eigene Seiten zur MTU wurden für diese Seite nicht gelesen, sie zeigt also auch keinen Standardwert.
• WLAN. Beide Durchläufe liefen über eine Kabelverbindung.
• Andere Anschlüsse und andere Zeiten. Die beiden Durchläufe lagen wenige Minuten auseinander, und die MTU eines Pfades „may change over time, due to changes in the routing topology“, kann sich also mit der Zeit ändern, wenn sich die Routing-Topologie ändert (RFC 8201, Abschnitt 3).

Wie das für ein Homelab mit den anderen Tests zu Hause zusammenpasst, steht im Homelab-Urteil.