IPv6: Ping funktioniert, HTTPS hängt – liegt es an der MTU?
Kleine Pakete kommen an, größere Übertragungen bleiben stehen: So grenzen Sie IPv6-MTU-Probleme ein und prüfen Packet Too Big, Filter und Tunnel.
Ein erfolgreicher IPv6-Ping beweist noch nicht, dass eine Webanwendung zuverlässig erreichbar ist. Wenn kleine Anfragen funktionieren, HTTPS aber beim Verbindungsaufbau oder bei größeren Antworten hängen bleibt, lohnt sich eine Prüfung der Paketgrößen. Ein MTU-Problem ist eine mögliche Ursache, kein Beweis: DNS, TLS, Paketverlust und die Anwendung selbst müssen ebenfalls eingegrenzt werden. Entscheidend ist ein reproduzierbarer Vergleich zum gleichen Ziel.
Was zwischen Ping und einer großen Antwort passiert
Die Path MTU ist die kleinste IP-MTU entlang eines Übertragungswegs. Ist ein IPv6-Paket für den nächsten Link zu groß, fragmentiert der weiterleitende Router es nicht. Er verwirft es und meldet dem Absender per ICMPv6 „Packet Too Big“ die MTU des nächsten Links. Der Absender kann seine Paketgröße anpassen. Fehlt diese Rückmeldung, kann bereits der TCP-Verbindungsaufbau gelingen, während die Datenübertragung anschließend stehen bleibt. RFC 8200 und RFC 8201 beschreiben diese Zusammenhänge.
MTU ist keine Bandbreite
Eine höhere Portgeschwindigkeit behebt keine zu großen Pakete. Ebenso ist die am Server eingestellte Interface-MTU kein Nachweis dafür, dass derselbe Wert auf dem gesamten Weg funktioniert.
Ein bewusst vereinfachtes Beispiel
Das folgende Szenario ist ein Rechenbeispiel, keine Messung im AS51202-Netz: Ein Server sendet über ein Interface mit 1.500 Byte IP-MTU. Auf dem Weg liegt ein Tunnel, dessen effektiv nutzbare innere IP-MTU 1.400 Byte beträgt. Ein kleines Testpaket passt. Ein 1.500 Byte großes IPv6-Paket passt dort nicht. Die korrekte Reaktion ist eine passende Rückmeldung an den sendenden Endpunkt; bleibt sie aus, sieht der Anwender unter Umständen nur einen Timeout.
| Beobachtung | Was sie aussagt | Was offen bleibt |
|---|---|---|
| Kleiner Ping erfolgreich | Diese kleinen Testpakete können ausgetauscht werden. | Große Pakete und der Anwendungsfluss sind noch nicht geprüft. |
| Großer Transfer hängt | Der Fehler tritt unter einer anderen Last oder Paketgröße auf. | MTU, Verluste, Filter und Anwendung als Ursachen unterscheiden. |
| Passendes Packet Too Big erreicht den Sender | Eine MTU-Rückmeldung kommt dort an. | Passt der Sender seine Pakete an und funktioniert der Wiederholungstest? |
| Kleinere Testpakete funktionieren wiederholt | Eine Größenabhängigkeit ist plausibel. | Den tatsächlichen Engpass und die Rückmeldung im Mitschnitt belegen. |
Die 1.400 Byte sind hier eine Annahme. Tunneltypen, zusätzliche Header und die äußere MTU unterscheiden sich. Übernehmen Sie diesen Wert deshalb nicht ungeprüft in eine Konfiguration. IPv6 verlangt grundsätzlich eine Link-MTU von mindestens 1.280 Byte; kleinere darunterliegende Übertragungseinheiten müssen unterhalb von IPv6 behandelt werden. Eine beliebig niedrige IPv6-MTU ist keine allgemeine Reparatur.
Diagnose in sechs Schritten
- 1Ziel und Fehler festhalten: Hostname, tatsächlich verwendete IPv6-Adresse, Uhrzeit mit Zeitzone, Quellnetz und betroffener Vorgang. Vergleichen Sie denselben Dienst über IPv4 und IPv6. Unterschiedliche CDN-Endpunkte oder Backends machen den Vergleich weniger eindeutig.
- 2Die Fehlerphase bestimmen: Scheitert schon die Namensauflösung, der TCP-Aufbau, der TLS-Handshake oder erst die Antwort? Testen Sie eine kleine und eine größere bekannte Ressource. Ein TLS-Fehler allein ist noch kein MTU-Befund.
- 3Paketgrößen kontrolliert variieren: Nutzen Sie passende Diagnosewerkzeuge zwischen eigenen oder freigegebenen Endpunkten. Unterscheiden Sie Test-Nutzlast und gesamte IP-Paketgröße. Protokollheader zählen mit; fragmentierte Testpakete dürfen nicht mit unfragmentierten verglichen werden.
- 4Zeitgleich mitschneiden: Beobachten Sie den sendenden Host und, soweit zugänglich, beide Seiten einer vermuteten Engstelle. Suchen Sie nach passenden ICMPv6-Packet-Too-Big-Meldungen, angegebener MTU und erneut gesendeten Daten. Eine an einem Messpunkt fehlende Meldung beweist noch nicht, an welchem Gerät sie verloren ging.
- 5Richtungen und Wege getrennt prüfen: Upload und Download vertauschen die Senderrolle. Wiederholen Sie den Test mit gleichem Ziel und dokumentieren Sie den verwendeten Pfad. Ein anderer Quellhost, Tunnel oder Upstream kann ein anderes Ergebnis liefern.
- 6Eine Änderung gezielt abnehmen: Vorherigen Zustand dokumentieren, nur den belegten Fehler korrigieren und denselben Anwendungstest wiederholen. Zusätzlich größere Transfers, neue Verbindungen und die Gegenrichtung prüfen. So bleibt erkennbar, welche Änderung geholfen hat.
ICMPv6 nicht mit Ping gleichsetzen
Echo Request und Echo Reply sind andere Nachrichtentypen als Packet Too Big. Eine Regel, die Ping erlaubt, genügt daher nicht. RFC 4890 führt Packet Too Big (Typ 2) unter den für die Kommunikation notwendigen Fehlermeldungen auf, die nicht verworfen werden sollen. Prüfen Sie die tatsächlich wirksamen Router-ACLs, Firewalls und Hostfilter entlang des Rückwegs zum Sender. Die Meldung kann von einem Zwischenrouter kommen, nicht nur vom angesprochenen Server.
Bei zustandsbehafteten Filtern reicht der Blick auf eine Regelbezeichnung wie „related“ nicht: Der konkrete Test muss zeigen, dass die passende Rückmeldung den Sender erreicht. Prüfen Sie außerdem, ob lokale Rate-Limits die Diagnose beeinflussen. Die Lösung ist eine fachlich passende ICMPv6-Policy mit überprüfbarer Wirkung, keine pauschale Freigabe aller Nachrichtentypen.
Tunnel und UDP gesondert betrachten
Bei einem Tunnel kann die Rückmeldung zunächst dessen Eingang erreichen. Die Tunnelimplementierung muss sie korrekt verarbeiten und dem ursprünglichen Sender die nötige Information vermitteln. RFC 8899 beschreibt solche Fehlerquellen sowie Datagram Packetization Layer Path MTU Discovery: geeignete Transporte können nutzbare Paketgrößen anhand bestätigter Testpakete ermitteln, ohne sich ausschließlich auf ICMP-Rückmeldungen zu verlassen. Ob Ihre Anwendung das unterstützt, muss konkret geprüft werden.
TCP-MSS-Anpassungen können ein begrenzter Workaround für TCP sein. Sie ersetzen weder eine korrekte MTU-Konfiguration noch die Prüfung von UDP-basierten Diensten wie QUIC. Halten Sie einen Workaround ausdrücklich fest und testen Sie alle betroffenen Protokolle, statt einen erfolgreichen Browseraufruf mit einer vollständig behobenen Störung gleichzusetzen.
Welche Angaben dem Netzbetreiber helfen
- Quell- und Zieladresse, Richtung, Protokoll sowie ein genaues Testzeitfenster.
- Interface- und Tunnel-MTU, Paketgrößen der erfolgreichen und fehlgeschlagenen Versuche sowie bekannte Kapselungen.
- Ein begrenzter, datensparsam geteilter Mitschnitt mit zugehörigen Packet-Too-Big-Meldungen und beobachteten Wiederholungen.
- Ergebnis vor und nach der Änderung sowie Angaben dazu, ob alternative Wege betroffen sind.
Bei der Planung einer IP-Transit-Anbindung gehört die MTU zusammen mit VLAN und Übergabe in die technische Abstimmung. Ergänzen Sie die Abnahme um IPv6-Anwendungstests in beiden Richtungen. Für eine Anfrage an AS51202 nennen Sie Standort, gewünschte Bandbreite und vorhandene Tunnel; so lassen sich Übergabe und Testumfang konkret besprechen. Die verlinkten Beiträge vertiefen Voraussetzungen, Multihoming und Standortvernetzung.