Site icon bintorosoft.com

MTU in IPv6: Fragmentation Header, PMTUD und Blackholes

Red Snapper

Transmitter WiFi with screwdriver and screw

MTU in IPv6 ist eine der häufigsten versteckten Fehlerquellen in modernen Netzwerken – gerade weil IPv6 viele „alte“ IPv4-Gewohnheiten nicht mehr erlaubt. Wenn die Path MTU nicht passt, entstehen Blackholes, die sich für Anwender wie Zufall anfühlen: kleine Requests funktionieren, große Uploads hängen; TLS-Handshakes brechen sporadisch ab; VPNs und Overlays verhalten sich inkonsistent; oder Dual-Stack-Clients wechseln dank Happy Eyeballs plötzlich auf IPv4. Die Ursache liegt oft nicht im „Routing“, sondern in der Kombination aus Paketgröße, Fragmentation Header, PMTUD und gefiltertem ICMPv6. In IPv6 dürfen Router unterwegs nicht fragmentieren – Fragmentierung ist Aufgabe des Senders. Das macht PMTUD (Path MTU Discovery) zwingend, und genau hier entstehen die klassischen IPv6-PMTUD-Blackholes: ICMPv6 „Packet Too Big“ wird gedroppt, die MTU bleibt zu groß, der Sender sendet weiter große Pakete, und der Pfad verwirft sie still. Dieses Troubleshooting ist gleichzeitig technisch und organisatorisch: Es betrifft Firewall-Regeln, Security-Policies, Tunnel-Designs, Host-Stack-Verhalten, Load Balancer, Proxy-Ketten und Monitoring. Dieser Artikel erklärt MTU in IPv6 praxisnah: wie Fragmentation Header funktionieren, wie PMTUD in IPv6 wirklich arbeitet, woran Sie Blackholes sicher erkennen und wie Sie sie nachhaltig beheben – ohne „ICMP einfach komplett erlauben“ oder wahlloses MTU-Raten.

IPv6 und MTU: Die Regel, die alles verändert

Der zentrale Unterschied zu IPv4 lautet: IPv6-Router fragmentieren nicht. Wenn ein Paket zu groß für den nächsten Hop ist, wird es verworfen und der Router sendet (idealerweise) ein ICMPv6 „Packet Too Big“ an den Sender. Der Sender muss daraufhin seine Paketgröße reduzieren. Diese Designentscheidung ist in der IPv6-Spezifikation verankert und sorgt für klare Zuständigkeiten, aber auch für neue Fehlerbilder. Hintergrund: RFC 8200 (IPv6).

Fragmentation Header: Was wirklich passiert, wenn IPv6 fragmentiert

Wenn ein IPv6-Endhost fragmentieren muss, fügt er einen Fragmentation Header ein. Damit wird das Paket in mehrere Fragmente zerlegt, die beim Ziel wieder zusammengesetzt werden. Wichtig: Fragmentierung ist in IPv6 bewusst selten und meist ein Notfallmechanismus – nicht der Normalbetrieb.

Warum Fragmentierung in IPv6 problematisch sein kann

Details zur Fragmentierung und zum Fragmentation Header finden Sie in RFC 8200 (Kapitel zu Extension Headers) und ergänzend im Kontext von PMTUD in RFC 8201 (Path MTU Discovery for IPv6).

PMTUD in IPv6: Wie der Mechanismus wirklich funktioniert

PMTUD in IPv6 (IPv6 Path MTU Discovery) basiert darauf, dass ein Router, der ein zu großes Paket sieht, es verwirft und dem Sender eine ICMPv6-Meldung „Packet Too Big“ sendet. Diese Meldung enthält die zulässige MTU des nächsten Hops. Der Sender passt anschließend die Paketgröße an. Das ist elegant – solange diese ICMPv6-Meldungen zuverlässig ankommen.

Der Standard ist klar beschrieben in RFC 8201. Der entscheidende Punkt für Troubleshooting: PMTUD ist nicht „optional“ und nicht „nice to have“. Wenn PMTUD scheitert, entstehen Blackholes.

PMTUD-Blackholes: Warum IPv6-Verbindungen „still“ sterben

Ein PMTUD-Blackhole entsteht, wenn ICMPv6 „Packet Too Big“ auf dem Rückweg zum Sender blockiert wird. Der Sender merkt dann nicht, dass er zu große Pakete sendet. Viele Geräte droppen das zu große Paket einfach; es gibt keine automatische Fragmentierung im Netz; und ohne ICMPv6 PTB gibt es keinen Hinweis. Das Ergebnis ist ein „stiller“ Drop.

Typische Symptome eines IPv6-PMTUD-Blackholes

Warum gerade Tunnels und Overlays MTU-Probleme verstärken

Die meisten IPv6-MTU-Probleme entstehen nicht auf „blankem Ethernet“, sondern in Netzen mit Encapsulation: VPNs, Overlays, Provider-Transport, Cloud-VPCs, MPLS-Interconnects, GRE/IP-in-IP. Jede Encapsulation frisst Bytes, reduziert die effektive MTU für Nutzdaten und verschiebt damit die Grenze, ab der PMTUD greifen muss.

Praktischer Tipp: Wenn ein Tunnel im Pfad ist, ist PMTUD- und MTU-Debugging fast immer ein Top-Kandidat – auch wenn „IPv6 grundsätzlich funktioniert“.

ICMPv6 „Packet Too Big“ und Firewall-Policies: Der Klassiker

Viele Security-Policies sind historisch aus IPv4 abgeleitet und blocken ICMP pauschal oder „so viel wie möglich“. In IPv6 ist das gefährlich. ICMPv6 ist integraler Bestandteil von ND (Neighbor Discovery), Fehlerdiagnose und PMTUD. Wenn Sie ICMPv6 „Packet Too Big“ blocken, bauen Sie ein Blackhole ein. Punkt.

Die Relevanz von ICMPv6 für PMTUD ergibt sich direkt aus RFC 8201.

Nachweis statt Vermutung: So beweisen Sie ein IPv6-MTU-Problem

Professionelles Troubleshooting bedeutet, die Hypothese „PMTUD-Blackhole“ zu beweisen. Dazu brauchen Sie nicht zwingend exotische Tools; Sie brauchen eine saubere Beweiskette: (1) Große Pakete gehen raus, (2) sie kommen nicht an, (3) ICMPv6 PTB fehlt oder wird gedroppt, (4) nach MTU-Anpassung verschwindet das Problem.

Beweis mit Packet Capture

Für Capture-Strategien sind Wireshark Dokumentation und die tcpdump Manpage nützliche Referenzen.

Beweis mit „Follow the Packet“ an mehreren Punkten

Gerade bei Blackholes ist ein Multi-Point Capture besonders stark: Sie capturen denselben Flow vor und nach dem vermuteten Engpass (z. B. vor einem VPN-Gateway und hinter dem Tunnel). Wenn große Pakete vor dem Tunnel sichtbar sind, aber hinter dem Tunnel fehlen, ist der Drop-Ort stark eingegrenzt. Wenn zusätzlich ICMPv6 PTB auf dem Rückweg „verschwindet“, ist die Blackhole-Ursache praktisch bewiesen.

Beweis durch kontrollierte Anpassung

TCP, MSS und IPv6: Warum die „richtige“ Stellschraube oft MSS ist

In vielen Umgebungen ist es operativ einfacher, TCP MSS zu steuern als die echte Link-MTU überall konsistent zu machen. MSS (Maximum Segment Size) beeinflusst die TCP-Payloadgröße, sodass IP-Pakete kleiner bleiben und nicht in PMTUD-Grenzen laufen. Das ist besonders hilfreich bei Tunneln, wo die effektive MTU niedriger ist.

Fragmentation Header und Middleboxes: Wenn Sicherheit IPv6 bricht

Ein weiterer Stolperstein: Manche Security-Geräte behandeln IPv6 Extension Headers (inkl. Fragmentation Header) restriktiv oder droppen sie standardmäßig. Das kann zu einem zweiten Blackhole führen: Der Sender fragmentiert (weil er keine andere Wahl hat), aber Fragmente werden unterwegs gedroppt. Die Symptome sind ähnlich wie bei PMTUD-Problemen, aber die Ursache ist anders.

Fehlerbilder nach Umgebung: Campus, Datacenter, WAN, Cloud

IPv6-MTU-Probleme sind universell, aber ihre Ursachen unterscheiden sich je nach Umgebung. Das hilft bei der Priorisierung.

Mitigation-Strategien: Stabilisieren, ohne „IPv6 aus“ zu spielen

Im Incident wollen Sie schnell stabilisieren, aber nachhaltig beheben. Für IPv6-MTU-Probleme ist die beste Strategie eine abgestufte Reihenfolge: erst funktionale ICMPv6 sicherstellen, dann MTU konsistent machen, dann MSS/Workarounds nur dort einsetzen, wo sie operativ sinnvoll sind.

Runbook-Baustein: IPv6 PMTUD Blackhole in 15 Minuten verifizieren

Weiterführende Quellen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version