IPv6 MTU und Path MTU Discovery: Fragmentierungsprobleme vermeiden

Paketfragmentierung ist eines jener Probleme, die Sie nicht bemerken, bis alles kaputt geht.

Warum MTU in IPv6 wichtiger ist#

IPv6 hat die Router-basierte Fragmentierung vollständig entfernt. In IPv4 kann ein Router, wenn er ein Paket empfängt, das zu groß für den nächsten Hop ist, es fragmentieren. IPv6-Router können das nicht – sie verwerfen das Paket und senden eine ICMPv6-„Packet Too Big"-Nachricht zurück zur Quelle.

Der Quell-Host ist für alle Fragmentierung verantwortlich. Diese Design-Entscheidung verbessert die Router-Leistung und vereinfacht das Protokoll, verlagert aber die Last auf Endpunkte und macht Path MTU Discovery (PMTUD) kritisch.

Wenn PMTUD fehlschlägt, hängen Ihre Verbindungen mysteriös. TCP-Handshakes werden abgeschlossen, aber die Datenübertragung stockt. HTTP-Anfragen laufen in Timeouts. SSH-Sitzungen frieren nach der Authentifizierung ein. Dies sind klassische MTU-Blackhole-Symptome.

IPv6-Mindest-MTU#

Alle IPv6-Links müssen mindestens 1280 Bytes unterstützen. Dies ist die Mindest-MTU und nicht verhandelbar. Wenn Ihr Link keine 1280-Byte-Pakete verarbeiten kann, ist er nicht IPv6-konform.

Die meisten Netzwerke verwenden 1500 Bytes (Standard-Ethernet-MTU), was Platz für den 40-Byte-IPv6-Header plus 1460 Bytes Payload bietet. Das entspricht der typischen TCP-MSS von 1460 bei IPv4.

Tunnel und Kapselungsprotokolle reduzieren die verfügbare MTU. Wenn Sie IPv6-in-IPv4 (6in4), 6to4 oder ISATAP betreiben, verlieren Sie Bytes an den äußeren Header. VPNs, IPsec, GRE und VXLAN verbrauchen alle MTU-Platz.

Häufige MTU-Werte, denen Sie begegnen werden:

• 1500: Standard-Ethernet
• 1480: PPPoE (verliert 8 Bytes für PPP-Overhead)
• 1460: 6in4-Tunnel (verliert 20 Bytes für IPv4-Header)
• 1420: 6in4 über PPPoE
• 1280: Mindest-IPv6-MTU, Fallback-Wert
• 9000: Jumbo-Frames (Rechenzentren-Netzwerke)

Wie Path MTU Discovery funktioniert#

PMTUD bestimmt die größte Paketgröße, die den Pfad zwischen Quelle und Ziel ohne Fragmentierung durchqueren kann.

Der Prozess ist einfach:

1. Host sendet Pakete mit der aktuellen MTU
2. Wenn ein Router entlang des Pfads eine kleinere MTU hat, verwirft er das Paket
3. Router sendet ICMPv6-Typ-2-„Packet Too Big"-Nachricht zurück zur Quelle
4. Nachricht enthält die MTU des nächsten Hops
5. Host reduziert seine Pfad-MTU und sendet erneut
6. Prozess wiederholt sich, bis Pakete den gesamten Pfad durchqueren

Die „Packet Too Big"-Nachricht (ICMPv6 Typ 2, Code 0) enthält den MTU-Wert in der Nachrichten-Payload. Dies teilt der Quelle genau mit, wie groß Pakete sein können, nicht nur, dass sie zu groß sind.

So sieht die ICMPv6-Nachricht aus:

ICMPv6 Packet Too Big:
  Type: 2
  Code: 0
  MTU: 1280
  [Original-Paket-Header bis Mindest-MTU]

Der Host unterhält einen Pfad-MTU-Cache mit Einträgen, die typischerweise nach 10 Minuten ablaufen (RFC 8201-Empfehlung). Wenn sich Netzwerkpfade ändern, könnten veraltete Cache-Einträge Probleme verursachen, bis sie ablaufen.

PMTUD-Blackholes#

Das System bricht, wenn ICMPv6-Typ-2-Nachrichten blockiert werden. Dies schafft „PMTUD-Blackholes", in denen Pakete stillschweigend verschwinden.

Häufige Ursachen:

Übereifrige Firewalls: Administratoren blockieren manchmal allen ICMP-Traffic und behandeln ihn als Sicherheitsrisiko. Das ist falsch. ICMPv6 ist integraler Bestandteil des IPv6-Betriebs, kein optionales Diagnoseprotokoll wie Ping.

Stateful-Inspection-Probleme: Einige Firewalls assoziieren ICMPv6-Fehlernachrichten nicht ordnungsgemäß mit bestehenden Verbindungen und verwerfen sie als unerwünschten Traffic.

Rate-Limiting: Sicherheitsgeräte können ICMPv6 begrenzen und legitime PMTUD-Nachrichten während geschäftiger Zeiten verwerfen.

NAT64-Gateways: Übersetzung zwischen IPv6 und IPv4 kann PMTUD-Informationen verlieren, wenn das Gateway ICMP-Nachrichten nicht ordnungsgemäß übersetzt.

Symptome von PMTUD-Blackholes:

• TCP-Verbindung wird hergestellt (SYN, SYN-ACK, ACK abgeschlossen)
• Kleine Pakete funktionieren (DNS-Abfragen, SSH-Login-Banner)
• Große Pakete schlagen fehl (Dateiübertragungen, HTTP POST mit Body, SSH-interaktive Sitzung nach Auth)
• Keine Fehlermeldungen, nur Timeouts
• Problem erscheint intermittierend (hängt von Paketgröße ab)

MTU-Probleme diagnostizieren#

Beginnen Sie mit Ping. Senden Sie Pakete bestimmter Größen, um die Pfad-MTU zu testen:

# Test mit 1280 Bytes (Mindest-MTU)
ping6 -M do -s 1232 2001:db8::1
 
# Test mit 1500 Bytes (Standard-Ethernet)
ping6 -M do -s 1452 2001:db8::1
 
# Test mit 1280 Bytes Payload
ping6 -c 5 -s 1280 2001:db8::1

Das -M do-Flag verbietet Fragmentierung (Don't Fragment). Das -s-Argument gibt die Payload-Größe an – fügen Sie 8 Bytes für ICMPv6-Header und 40 für IPv6-Header hinzu, um die Gesamtpaketgröße zu erhalten.

Wenn 1452 Bytes fehlschlagen, aber 1232 erfolgreich sind, liegt Ihre Pfad-MTU zwischen 1280 und 1500. Binäre Suche, um den genauen Wert zu finden:

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

Verwenden Sie Traceroute, um zu identifizieren, wo sich die MTU ändert:

traceroute6 -n 2001:db8::1

Testen Sie dann die MTU zu jedem Hop einzeln. Der Hop, wo große Pakete zu versagen beginnen, ist Ihr Problempunkt.

Für TCP-Verbindungen beobachten Sie das tatsächliche Verhalten:

# Pakete erfassen
tcpdump -i eth0 -n 'ip6 and (icmp6 or tcp)'

Suchen Sie nach:

• TCP-Neuübertragungen nach initialem Handshake
• ICMPv6-Typ-2-Nachrichten (sollten erscheinen, wenn PMTUD funktioniert)
• Abwesenheit von ICMPv6 Typ 2 (zeigt Blockierung oder Blackhole an)

Moderne Tools können dies automatisieren. MTR kombiniert Traceroute mit Paketgrößentest:

# Test mit 1400-Byte-Paketen
mtr -6 -s 1400 2001:db8::1

TCP MSS Clamping#

MSS (Maximum Segment Size) ist die TCP-Option, die dem anderen Ende mitteilt, wie viele Daten es in jedem Segment senden kann. MSS = MTU - IP-Header - TCP-Header.

Für IPv6: MSS = MTU - 40 (IPv6) - 20 (TCP) = MTU - 60

Mit Standard-1500-Byte-MTU: MSS = 1440

MSS-Clamping erzwingt, dass TCP-Verbindungen einen niedrigeren MSS-Wert verwenden und MTU-Probleme umgehen, ohne sich auf PMTUD zu verlassen. Dies ist üblich auf Routern, die Tunnel oder PPPoE-Verbindungen terminieren.

MSS-Clamping unter Linux konfigurieren:

# MSS auf 1280 für IPv6 begrenzen
ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1220

Der Wert 1220 berücksichtigt 1280 MTU minus 60 Bytes für Header.

Für PPPoE mit 1492 MTU:

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

MSS-Clamping betrifft nur TCP. UDP, SCTP und andere Protokolle verlassen sich weiterhin auf PMTUD oder Anwendungsebenen-Fragmentierung.

Firewall-Konfiguration#

Ihre Firewall muss ICMPv6-Typ-2-Nachrichten für das Funktionieren von PMTUD zulassen. Dies ist nicht verhandelbar für produktive IPv6-Netzwerke.

Minimal erforderliche ICMPv6-Typen für IPv6-Betrieb:

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

iptables-Regel für PMTUD:

# ICMPv6 Packet Too Big erlauben
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

Besserer Ansatz – alle notwendigen ICMPv6 erlauben:

# Established ICMPv6 erlauben
ip6tables -A INPUT -p ipv6-icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Notwendige ICMPv6-Typen erlauben
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

Rate-Limiting ist akzeptabel, aber setzen Sie großzügige Grenzen:

# ICMPv6 mit Rate-Limit erlauben
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 \
  -m limit --limit 10/sec --limit-burst 20 -j ACCEPT

Blockieren Sie niemals ICMPv6 vollständig. Es ist kein Sicherheitsrisiko – es ist eine Protokollanforderung.

Tunnel-MTU-Überlegungen#

Tunnel reduzieren die effektive MTU durch den Overhead der Kapselungs-Header.

Häufige Tunnel-Typen und Overhead:

Tunnel-MTU explizit konfigurieren, um Probleme zu vermeiden:

# 6in4-Tunnel
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

Für WireGuard:

[Interface]
MTU = 1420

Einige Tunnel-Protokolle unterstützen MTU-Discovery, aber explizite Konfiguration ist zuverlässiger.

Jumbo-Frames und Rechenzentren#

Rechenzentren-Netzwerke verwenden oft 9000-Byte-MTU (Jumbo-Frames), um den Durchsatz für Massendatenübertragungen zu verbessern.

Jumbo-Frames auf Schnittstellen aktivieren:

ip link set eth0 mtu 9000

Stellen Sie sicher, dass alle Switches und Router im Pfad Jumbo-Frames unterstützen. Ein Gerät mit 1500-Byte-MTU wird zum Engpass.

PMTUD gilt weiterhin. Wenn ein Paket Ihr Jumbo-Frame-Netzwerk in Richtung Internet verlässt, muss es auf 1500 oder weniger reduziert werden.

Tests und Verifizierung#

MTU-Konfiguration Ihres Hosts überprüfen:

ip -6 link show

Suchen Sie nach dem MTU-Wert auf jeder Schnittstelle.

Aktuellen Pfad-MTU-Cache prüfen:

ip -6 route get 2001:db8::1

Ausgabe zeigt die gecachte MTU für dieses Ziel.

End-to-End-Konnektivität mit variierenden Paketgrößen testen:

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

Netcat verwenden, um TCP-MSS-Verhandlung zu testen:

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

Pakete mit tcpdump erfassen und MSS-Werte in SYN-Paketen überprüfen.

Häufige Szenarien und Lösungen#

Problem: Webseiten laden langsam, Bilder schlagen fehl Ursache: PMTUD-Blackhole aufgrund Firewall, die ICMPv6 Typ 2 blockiert Lösung: Firewall konfigurieren, um ICMPv6 Typ 2 zu erlauben

Problem: SSH verbindet, friert aber nach Login ein Ursache: MTU zu groß, PMTUD funktioniert nicht Lösung: MTU auf Client-Schnittstelle reduzieren oder MSS-Clamping auf Router aktivieren

Problem: VPN funktioniert für kleine Übertragungen, schlägt bei großen Dateien fehl Ursache: Tunnel-MTU nicht korrekt konfiguriert Lösung: Tunnel-MTU reduzieren, um Kapselungs-Overhead zu berücksichtigen

Problem: IPv6 funktioniert im lokalen Netzwerk, schlägt über Internet fehl Ursache: Upstream-Router hat kleinere MTU, bewirbt sie nicht ordnungsgemäß Lösung: ISP kontaktieren oder lokale MTU auf 1280 (Minimum) reduzieren

Problem: Einige Ziele funktionieren, andere schlagen fehl Ursache: Pfadspezifische MTU-Probleme Lösung: Mit Ping testen, um funktionierende MTU zu identifizieren, Schnittstelle entsprechend konfigurieren

Best Practices#

1. Immer ICMPv6 Typ 2 in Firewalls erlauben
2. Tunnel-MTU explizit konfigurieren anstatt sich auf Auto-Erkennung zu verlassen
3. Mit Mindest-MTU (1280) testen, um Basis-Konnektivität sicherzustellen
4. MSS-Clamping verwenden auf Tunnel-Endpunkten und PPPoE-Verbindungen
5. PMTUD-Fehler überwachen mit Paket-Captures während Fehlerbehebung
6. MTU Ihres Netzwerks dokumentieren auf jeder Ebene (physisch, Tunnel, Anwendung)
7. Konservative MTU-Werte setzen, wenn im Zweifel (1280 funktioniert immer)

Verwandte Artikel#

• ICMPv6 erklärt - IPv6s Kontrollprotokoll verstehen
• IPv6-Firewall-Konfiguration - IPv6 sichern ohne Funktionalität zu brechen
• IPv6-Fehlerbehebung - Häufige IPv6-Konnektivitätsprobleme debuggen

Zusätzliche Ressourcen#

• RFC 8201: Path MTU Discovery for IPv6
• RFC 4821: Packetization Layer Path MTU Discovery
• IPv6 MTU Issues - RIPE Labs