<style> .reveal .slides { background: url(https://hedgedoc.xinux.net/uploads/xinux-weiss.png) no-repeat; background-position: right 10px bottom 10px; background-size: 80px; } .reveal section { text-align: left; padding: 20px 40px !important; } .reveal h2 { font-size: 34px !important; margin-bottom: 10px !important; } .reveal ul li { font-size: 26px !important; line-height: 1.25 !important; margin-bottom: 6px !important; } .reveal code { font-size: 24px !important; } .reveal pre { white-space: pre-wrap !important; word-break: break-word !important; overflow: visible !important; } </style> ## MTU - MTU ist entscheidend für Datenübertragung in Netzwerken - Definiert Umfang der Nutzlast in Netzwerkschicht (OSI 3) - Datagramm umfasst gesamtes Paket der OSI-Schicht 3 (z.B. IPv6 + TCP + Nutzdaten) - MTU-Länge in Bytes (Einheit oft weggelassen, z.B. MTU 1500) --- ## Ethernet Frame - Ethernet-Frame-Länge aus Header (14 Bytes), Netzwerkschicht-Paket (1500 Bytes) und Trailer (4 Bytes) - Bei VLAN bleibt MTU unbeeinflusst, auch wenn Ethernet-Header um 4 Bytes langes VLAN-Tag ergänzt wird --- ## Schaubild  --- ## MSS - MSS berechnet sich aus MTU minus IP-Header minus TCP-Header - MTU errechnet sich aus IP-Header plus TCP-Header plus Daten - Herausforderung: Daten so verschachteln, dass MTU nicht überschritten wird - Empfehlung: Anwendung „kleiner packen“ bei Bedarf --- ## Fragmentierung in IPv4 - **Don't Fragment (DF)-Feld** im IPv4-Header reguliert IP-Paket-Fragmentierung - Bei gesetztem DF-Bit: Keine automatische Fragmentierung - Router sendet ICMP-Fehler *Type 3, Code 4* – „Destination Unreachable: Fragmentation Needed, DF Set“ - Sender reduziert daraufhin die Paketgröße - Ohne DF-Bit: Router darf fragmentieren - Nachteil: Verlust eines Fragments → Neuanforderung des gesamten Pakets (hoher Overhead) --- ## Fragmentierung in IPv6 - IPv6-Header enthält **kein DF-Bit** - Fragmentierung erfolgt **nur durch den Absender (Host)**, niemals durch Router - Router, die zu große Pakete nicht weiterleiten können, senden: → **ICMPv6 Type 2 (Packet Too Big)** - Sender passt anschließend die Paketgröße an - IPv6-Router fragmentieren **nie** (Designentscheidung für Performance & Sicherheit) --- ## MTU Path Discovery (PMTUD) - Mechanismus zur Ermittlung der kleinsten MTU auf dem Übertragungsweg - Sender sendet große Pakete → Router antwortet mit ICMPv6 *Packet Too Big* - Sender reduziert Paketgröße, bis Übertragung ohne Fehler gelingt - PMTUD arbeitet dynamisch pro Zielroute - RFC 8201 beschreibt PMTUD für IPv6 --- ## ICMPv6 und MTU - ICMPv6 ist für PMTUD unverzichtbar - Typ 2: Packet Too Big - Enthält die maximale MTU des nächsten Hops - Blockierte ICMPv6-Nachrichten → PMTUD funktioniert nicht → Verbindungsabbrüche! - Firewalls müssen ICMPv6 Type 2 explizit erlauben --- ## Beispiel – Packet Too Big [Hier Bild] - Host sendet 1500-Byte-Paket - Router kann nur 1280 weiterleiten - Router antwortet mit ICMPv6 *Packet Too Big (MTU=1280)* - Host reduziert MTU für diese Route auf 1280 --- ## IPv6 Minimal MTU - IPv6 verlangt **minimale MTU von 1280 Bytes** - Geräte müssen mindestens 1280 Byte empfangen und verarbeiten können - Kleinere MTUs dürfen nur genutzt werden, wenn Fragmentierung möglich ist - Fragmentierungs-Header (Next Header = 44) kann genutzt werden, um Paket aufzuteilen --- ## Fragmentierungs-Header - Wird nur verwendet, wenn Host fragmentiert - Enthält: - Fragment Offset - More Fragments Flag - Identification Field - Fragment Identification bleibt pro Datenstrom eindeutig - RFC 8200 beschreibt Aufbau und Verhalten --- ## Fragmentierung vom Absender – Beispiel - Ursprüngliches Paket 2000 Byte - MTU im Pfad: 1280 - Host erzeugt zwei Fragmente: - Fragment 1: 1280 Byte - Fragment 2: 720 Byte - Empfänger setzt Fragmente wieder zusammen --- ## Path MTU Discovery (PMTUD) - Wird vom **Kernel** automatisch durchgeführt - Router senden **ICMPv6 Type 2 – "Packet Too Big"**, wenn ein Paket zu groß ist - Der Kernel **merkt sich die kleinere MTU** im Routing-Cache - Danach sendet er alle Pakete kleiner oder gleich dieser MTU - Funktioniert nur, wenn ICMPv6 nicht gefiltert wird 💡 **Merksatz:** Der Kernel testet nicht – er **lernt passiv** durch ICMP-Meldungen. --- ## Packetization Layer PMTUD (PLPMTUD) - Wird vom **Transportprotokoll oder der Anwendung** ausgeführt - **Testet aktiv** mit unterschiedlichen Paketgrößen - Erkennt fehlende Antworten / Timeouts und **passt Größe selbst an** - Funktioniert auch, wenn ICMPv6 blockiert ist - Definiert in **RFC 4821** 💡 **Merksatz:** Wenn Router nichts sagen dürfen, **testet die Anwendung selbst** --- ## Typische Probleme in der Praxis - ICMPv6 blockiert → PMTUD bricht zusammen - MTU-Mismatch zwischen VLANs/Tunneln - VPNs (IPsec, GRE) reduzieren effektive MTU - Jumbo Frames ohne Ende-zu-Ende-Support → Paketverlust - Lösung: `tracepath6` oder `ping6 -s` zur Ermittlung der funktionalen MTU --- ## Praxisbefehle - **Linux** ``` ip link show dev eth0 ip link set dev eth0 mtu 1400 ping6 -s 1472 fe80::1%eth0 tracepath6 2001:db8::1 ``` - **Cisco IOS** ``` show ipv6 interface ping ipv6 2001:db8::1 size 1400 df-bit ``` --- ## Zusammenfassung - MTU bestimmt maximale Nutzlast eines Frames - IPv6 fragmentiert nur am Sender - Router senden ICMPv6 *Packet Too Big* statt selbst zu fragmentieren - PMTUD und ICMPv6 Type 2 sind zwingend erforderlich - Blockiertes ICMPv6 = defekte Verbindungen - Empfehlung: MTU testen und ICMPv6-Filter prüfen