Skript/IPv6/Fragmentierung
IP/Fragmentierung
IP/Fragmentierung - Aufteilung eines IP-Datagramms, wenn es größer als die Maximum Transmission Unit der Netzwerkschnittstelle ist
Beschreibung
Fragmentierung von Paketen auf einem Übertragungsnetzwerk, wenn das Paket größer ist als die MTU-Size des Netzwerks oder einer Teilstrecke
- Zielsetzung
Ziel bei der Einführung der Fragmentierung im Internetprotokoll (IP) war es
- die zugrundeliegende Netzwerkstruktur für den Benutzer zu verbergen (OSI-Modell)
- Implementierung des Netzwerkprotokolls Hardware-unabhängig zu gestalten
- Hintergrund
Im einfachsten Fall passt das gesamte IP-Datagramm in einen Datenblock
- Höchste Effizienz
- Maximale Größe eines IP-Datagramms
- 64 kB
- Die maximal mögliche Paketgröße (MTU) ist abhängig von den verwendeten Infrastrukturkomponenten
- Moderne Paket-Switching-Techniken lassen unterschiedliche maximale Paketgrößen zu
- Relevanz
| Bereich | Beschreibung |
|---|---|
| LAN | Router, WLAN |
| Sicherheit | Angriffe |
| Internet | 2007 machte der fragmentierte Datenverkehr 0,06 % aus, 91 % der IPv4-Pakete hatten das don’t fragment (DF) Bit gesetzt, zuvor wurden 1-2% gemessen |
Arbeitsweise
Sobald der IP-Stack (vgl. auch OSI-Modell oder TCP/IP-Referenzmodell) ein Datenpaket zum Versenden enthält, prüft dieser, ob die Paketgröße eine Aufteilung anhand der für die zu verwendende Netzwerkschnittstelle gegebene MTU notwendig macht
- Ist dies nötig, so teilt dieser das vorhandene Datenpaket in mehrere Datenpakete auf
- Dieser Vorgang wird als Fragmentierung bezeichnet
- Diese Fragmentierung kann sowohl beim ursprünglichen Sender stattfinden oder auch auf Routern, die zwischen Sender und Empfänger liegen
- Wird ein IP-Datagramm fragmentiert, so wird es erst beim Empfänger wieder zusammengesetzt (Ausnahme: ggf. zwischengeschaltete Firewalls, die speziell angewiesen wurden, ein sogenanntes reassembly durchzuführen, bevor die Daten weitergeleitet werden)
Sollte es nötig sein, kann auch ein bereits fragmentiertes Paket weiter fragmentiert werden (etwa bei einem Wechsel der Übertragungstechnik)
Jedes IP-Datagramm, das fragmentiert wurde, erhält einen neuen Header auf Basis des originalen Headers und spezieller aktualisierter Felder
- Der Fragment-Offset (13 bit im IP-Header) wird dabei in 8-Byte-Blöcken angegeben
- Wenn also das erste Datagramm 1000 Byte Nutzdaten enthält, dann ist der Fragment-Offset des zweiten Paketes 125 (= 1000 Byte/8 Byte)
- Somit kann nur das letzte Fragment eine Nutzdaten-Menge haben, die nicht ein Vielfaches von 8 Byte ist
- Weiterhin ist zu beachten, dass der Fragment-Offset bei 0 beginnt (der Eintrag im ersten Fragment) und deswegen der Offset des zweiten Paketes im genannten Beispiel 125 und nicht etwa 126 ist
Bei allen Fragmenten, außer dem letzten, wird das More-Fragments-Flag gesetzt
- Ins Längen-Feld des IP-Headers wird bei allen Fragmenten die Länge des jeweiligen Fragments eingetragen, und für jeden Header wird die IP-Header-Prüfsumme separat berechnet, während der Rest des Headers dem Originalheader vor der Fragmentierung entspricht
Der Empfänger hat nun die Aufgabe, das Original aus den in den Paketheadern vorhandenen Informationen wieder zusammenzusetzen, indem er alle Fragmente mit gleichem IP-Header (mit Ausnahme der für jedes Fragment separaten Information) nimmt und sie anhand ihres Offsets in die richtige Reihenfolge bringt
- Da jedes einzelne Fragment ein eigenständiges Paket darstellt, kann es auch vorkommen, dass diese Einzelteile nicht geordnet ankommen
- Es ist auch möglich, dass einzelne Fragmente verlorengehen oder defekt sind
- Es ist dann Sache des Empfängers, das Paket zu verwerfen und die Daten erneut anzufordern, wodurch eine höhere Netzwerklast entstehen kann
Per Definition kann die IP-Schicht keine Angaben darüber machen, ob ein Paket im Verlauf seiner Übertragung fragmentiert wird oder nicht
- Einzige Ausnahme: Der Sender kann das sogenannte Don’t-Fragment-Flag setzen, welches alle beteiligten Kommunikationssysteme (Router, Gateways und weitere) anweist, keine Fragmentierung vorzunehmen
- Für den Fall, dass eine Fragmentierung doch notwendig wäre, wird das Paket verworfen und dem Sender eine ICMP Fehlermeldung vom Typ 3 (destination unreachable) mit Code 4 (fragmentation required but don’t fragment bit set) gesendet, welche besagt, dass das Ziel für unfragmentierbare Pakete dieser Größe nicht erreichbar sei
Auswirkungen
Obwohl die Zielsetzung eine für höhere Schichten (z. B. TCP/UDP) transparente Implementierung ist, gibt es zwei Punkte, in denen dieses nicht ganz erreicht wird:
- Die Fragmentierung kann großen Einfluss auf den Datendurchsatz haben und beeinflusst diesen im Allgemeinen negativ
- Geht ein fragmentiertes Paket des originalen Paketes verloren, so muss das gesamte Original erneut übertragen werden. IP hat jedoch keine Sicherungs- bzw.ggf.Timeoutmechanismen und ist hierbei auf die Sicherungsfunktionen höherer Schichten wie die des TCP angewiesen
Aus genannten Gründen wird versucht, Fragmentierung immer so weit wie möglich zu vermeiden
Maximum Transmission Unit
- Maximum Transmission Unit - Maximale Datagramm-Größe (OSI-Schicht 3)
Beschreibung
Maximum Transmission Unit - Maximale Datagramm-Größe (OSI-Schicht 3), das ohne Zerlegung in einen Frame auf OSI-Schicht 2 passt (MTU)
MTU (Maximum Transmission Unit) beschreibt die maximale Paketgröße eines Protokolls der Vermittlungsschicht (Schicht 3) des OSI-Modells in Byte, die ohne Zerlegung in den Rahmen (Frame) eines Netzes der Sicherungsschicht (Schicht 2) passt
- Das Paket passt in die Nutzlast (Payload) des Protokolls der Sicherungsschicht
- Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet
Die Maximum Transmission Unit (MTU; deutsch maximale Übertragungseinheit) beschreibt die maximale Paketgröße eines Protokolls der Vermittlungsschicht (Schicht 3) des OSI-Modells, gemessen in Oktetten (Bytes), welche ohne Fragmentierung in den Rahmen (Frame) eines Netzes der Sicherungsschicht (Schicht 2) übertragen werden kann
- Diese Paketgröße passt also in die Nutzlast (Payload) des Protokolls der Sicherungsschicht
- Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet
- Berechnung
Die maximale Größe eines Rahmens der Sicherungsschicht lässt sich so berechnen
| Maximale Rahmengröße = | Größte MTU aller benutzten Protokolle der Vermittlungsschicht + Größe der Sicherungsschichtheader |
Die MTU wird durch Einstellungen im Rahmen der Möglichkeiten der verwendeten Hardware und Technik bestimmt
- Sie kann auf derselben Schnittstelle unterschiedliche Werte für unterschiedliche Protokolle der Vermittlungsschicht (beispielsweise IPv4 oder IPv6) annehmen
- Alle an einem Schicht-2-Netz beteiligten Schnittstellen, welche Protokolle höherer Schichten verarbeiten, müssen auf denselben Wert für die jeweiligen Schicht-3-Protokolle eingestellt werden
Im OSI-Modell spricht man auf der Vermittlungsschicht von einem Paket (engl. 'packet'), während man auf der Sicherungsschicht von einem Rahmen spricht
- Die Terminologie, welche das OSI-Modell für die Einheiten auf den verschiedenen OSI-Modellschichten verwendet, hat zu einiger Verwirrung um den Begriff der MTU geführt (siehe abweichende Verwendung bei wichtigen Herstellern)
- Unter der "packet size" (Paketgröße) wird fälschlicherweise teils die "frame size" (Rahmengröße) verstanden, jedoch stellt die obige Definition (siehe RFC 1122 und RFC 791) dies eindeutig klar
Ein Spezialfall liegt vor, wenn ein Schicht-2-Protokoll über ein anderes Schicht-2-Protokoll getunnelt wird, denn dann nennt man auch die Nutzlast selbst "Rahmen"
Path MTU (PMTU)
Die Path MTU (PMTU) beschreibt die maximale Paketgröße, die entlang der gesamten Wegstrecke übertragen werden kann, ohne einer Fragmentierung zu unterliegen
- Sie ist damit gleich der kleinsten MTU aller Schicht-2-Teilstücke im Pfad
- Die PMTU kann automatisch durch PMTU Discovery (PMTUD) ermittelt werden
Beispiel Brief
- Das Konzept der MTU kann auf den Briefverkehr adaptiert werden
- Ein Kompaktbrief darf maximal 50 g wiegen
- Zum Transport benötigt der Brief einen Briefumschlag beispielsweise 4 g und eine Briefmarke 0,3 g
- Diese 4,3 g entsprechen der Größe der Sicherungsschichtheader
- Daraus ergibt sich, dass die MTU (der maximale Inhalt für einen Kompaktbrief oder Packet Size) 50 g - 4,3 g = 45,7 g beträgt
Will man mehr Gewicht verschicken, muss man auf ein anderes Protokoll (einen Großbrief mit mehr Porto) ausweichen oder den Inhalt auf mehrere Briefe aufteilen, also fragmentieren
- Typische MTU-Größen
| Medium | MTU in Bytes |
|---|---|
| Hyperchannel | 65535 |
| Token Ring(4)(802.5) | 4464 |
| Token Ring(16) | 17914 |
| FDDI | 4352 |
| Ethernet | 1500 |
| Gigabit Ethernet mit Jumboframes |
9000 |
| PPPoE (beispielsweise DSL) | ≤ 1492 |
| SLIP/PPP (low delay) | 296 |
| X.25 | 576 |
| FibreChannel | theoretisch unbegrenzt |
| ISDN | 576 |
| DQDB | |
| HIPPI | |
| ATM | 4500, s. u |
| ARCNET | |
| 802.11 | 2312 (WiFi) |
- Maximale Paketgröße eines Protokolls der Vermittlungsschicht
- Schicht 3 des OSI-Modells
- gemessen in Oktetten
- welche ohne Fragmentierung in den Rahmen (engl. "Frames") eines Netzes der Sicherungsschicht (Schicht 2) übertragen werden kann
- Diese Paketgröße passt also in die Nutzlast (Payload) des Protokolls der Sicherungsschicht
- Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet
- Die maximale Größe eines Rahmens der Sicherungsschicht lässt sich so berechnen
| Maximale Rahmengröße = | Größte MTU aller benutzten Protokolle der Vermittlungsschicht + Größe der Sicherungsschichtheader |
- Hardware und Technik
- Die MTU wird durch Einstellungen im Rahmen der Möglichkeiten der verwendeten Hardware und Technik bestimmt
- Sie kann auf derselben Schnittstelle unterschiedliche Werte für unterschiedliche Protokolle der Vermittlungsschicht (beispielsweise IPv4 oder IPv6) annehmen
- Alle an einem Schicht-2-Netz beteiligten Schnittstellen, welche Protokolle höherer Schichten verarbeiten, müssen auf denselben Wert für die jeweiligen Schicht-3-Protokolle eingestellt werden
Terminologie
- Im OSI-Modell spricht man auf der Vermittlungsschicht von einem Paket (engl. 'packet'), während man auf der Sicherungsschicht von einem Rahmen (engl. 'frame') spricht
- Die Terminologie, welche das OSI-Modell für die Einheiten auf den verschiedenen OSI-Modellschichten verwendet, hat zu einiger Verwirrung um den Begriff der MTU geführt
Abweichende Verwendung
Abweichende Verwendung des Begriffs
- Cisco und Juniper
Verwenden den Begriff MTU in ihrer Konfigurationssyntax als maximale Rahmen- bzw. Paketgröße der zu konfigurierenden Netzwerkschicht
- Folgende Einstellungen entsprechen einander
- Bei beiden Herstellern bedeutet das erste Auftauchen des Begriffes die maximale Ethernet Rahmengröße und nicht die maximale Größe der Nutzlast (Maximum Segment Size)
- diese muss folglich einige Byte größer gewählt werden als die dann folgenden Einstellungen für die verschiedenen Schicht-3 Protokolle
- Paket- und Rahmengröße
- Unter der "packet size" (Paketgröße) wird fälschlicherweise teils die "frame size" (Rahmengröße) verstanden, jedoch stellt die obige Definition (siehe RFC 1122 und RFC 791) dies eindeutig klar
- Ein Spezialfall liegt vor, wenn ein Schicht-2-Protokoll über ein anderes Schicht-2-Protokoll getunnelt wird, denn dann nennt man auch die Nutzlast selbst "Rahmen" (engl. 'frame')
Path MTU
- Path MTU (PMTU)
Maximale Paketgröße, die entlang der gesamten Wegstrecke übertragen werden kann, ohne einer Fragmentierung zu unterliegen
- Sie ist die kleinsten MTU aller Schicht-2-Teilstücke im Pfad
- Die PMTU kann automatisch durch PMTU Discovery (PMTUD) ermittelt werden
- Beispiel Brief
Das Konzept der MTU auf die Post adaptiert
- Eine MTU 50 g heißt, dass man max. 50 g Inhalt (entspricht der Packet Size) in den Brief einpacken kann
- Der Brief insgesamt kann selbst aber schwerer als 50 g sein, da im Normalfall noch ein Briefumschlag beispielsweise 4 g und eine Briefmarke 0,3 g hinzukommt
- Bezahlt und verschickt wird der ganze Brief von 54,3 g Masse entsprechend der Frame Size
Anwendung
Konfiguration
Dateien
| Datei | Beschreibung |
|---|---|
IP/Fragmentierung/IPv4
IP/Fragmentierung/IPv6
- Router fragmentieren keine Pakete
Der Absender wird bei Fragmentierungsbedarf immer mit einer ICMPv6-Nachricht vom Typ 2 (Packet Too Big) informiert
- Dieser kann daraufhin seine Paketgrößen dadurch senken, dass die kommunizierende Anwendung kleinere, unfragmentierte Pakete erzeugt, oder dadurch, dass fragmentiert wird
- Im zweiten Fall beginnt der Sender nach dem IPv6-Header einen Fragment Extension Header (Protokoll 44) einzufügen, der die Parameter der Fragmentierung enthält, denn diese sind im IPv6-Header nicht mehr vorgesehen
- Beim Filtern von Paketen sollte beachtet werden, dass das Next Header Feld im IPv6-Header bei fragmentiertem Datenverkehr auf Protokoll 44 verweist und nicht mehr auf die ursprüngliche Protokollnummer, wie beispielsweise 17 für UDP, diese verschiebt sich in das Next Header Feld des Fragment Extension Headers
IPv6/Header/Extension
- IPv6/Header/Extension - IPv6 Extension Header
Beschreibung
Zusätzliche Informationen für die Netzwerkschicht (IP-Layer)
- IPv6-Header durch Extension-Header erweiterbar
Werden bei Bedarf eingefügt
- Zusätzliche Funktionen
- Zukünftige Erweiterungen
- Folgen direkt auf den IPv6-Header
Außerhalb des IP-Headers
- Vielfaches von 64 Bit
- Speicherzugriffe im Router beschleunigen
- Die meisten IPv6-Pakete kommen ohne Extension Header aus
Nur IPv6-Header, TCP-Header und Daten
- Typen
| Typ | Beschreibung |
|---|---|
| Hop-to-Hop | Von jedem Hop auzuwerten
|
| End-to-End | Nur vom Endsystem auszuwerten |
Hop-to-Hop
- Optionen für Teilstrecken
- Informationen, die alle Router auf der Strecke prüfen
- Bisher ist eine Option definiert
- Unterstützung von Jumbogrammen (Paketen größer 64 kByte)
- Routing
- Mit diesem Header kann eine Route vollständig oder teilweise spezifiziert werden
End-to-End
- Optionen für Ziele
Optionen, die nur vom Zielhost interpretiert werden
- Authentifikation
Der Authentifizierungsheader bietet einen Mechanismus, durch den der Empfänger sicher sein kann, das der in der Adresse angegebene Sender auch tatsächlich der ist, der er behauptet zu sein
- Verschlüsselte Sicherheitsdaten
Dieser Header enthält Informationen über das verwendete Verschlüsselungsverfahren
Extension Headers
| Name | Typ | Größe | Beschreibung | RFC |
|---|---|---|---|---|
| Hop-By-Hop Options | 0 | variabel | Optionenvon allen IPv6-Geräten zu beachtenwird beispielsweise für Jumbograms benutzt | 2460 2675 |
| Routing | 43 | variabel | Hier kann der Weg des Paketes durch das Netzwerk beeinflusst werde. Wird u. a. für Mobile IPv6 verwendet | 2460 6275 5095 |
| Fragment | 44 | 64 Bit | Parameter zur Fragmentierung | 2460 |
| Authentication (AH) | 51 | variabel | Daten zur Authentifizierung (IPsec) | 4302 |
| Encapsulating Security Payload (ESP) | 50 | variabel | Daten zur Verschlüsselung (IPsec) | 4303 |
| Destination Options | 60 | variabel | Optionen nur vom Zielrechner zu beachten | 2460 |
| Mobility | 135 | variabel | Daten für Mobile IPv6 | 6275 |
| No Next | 59 | leer | Platzhalter, zeigt Ende eines Header-Stapels an | 2460 |
Auftreten
Basis Extension Header
Von jedem IPv6-Node zu implementieren
- IPv6-Header
- Hop-by-Hop Options
- Routing
- Fragment
- Destination Options
- Authentication
- Encapsulating Security Payload
Extension Header dürfen höchstens einmal vorkommen
- Ausnahme
- Destination Options Header dürfen zweimal vorkommen
- Befindet sich ein Routing Extension Header im Paket, so darf davor ein weiterer Destination Options Header stehen
Reihenfolge
| Header | Type | |
|---|---|---|
| 1 | IPv6/Header | Hop-to-Hop |
| 2 | Hop-by-Hop Options | Hop-to-Hop |
| 3 | Routing | Hop-to-Hop |
| 4 | Fragment | Hop-to-Hop |
| 5 | Authentication | End-to-End |
| 6 | Encapsulating Security Payload | End-to-End |
| 7 | Destination Options | End-to-End |
| 8 | Upper-Layer | End-to-End |
Anhang
Siehe auch
RFC
| RFC | Titel | Date | Status |
|---|---|---|---|
| 2460 | Internet Protocol, Version 6 (IPv6) Specification | 1998 | Ersetzt durch RFC 8200 |
| 2675 | |||
| 4302 | |||
| 4303 | |||
| 5095 | |||
| 6275 | |||
| 8200 | Internet Protocol, Version 6 (IPv6) Specification | 2017 | Updated by RFC 9673 |
| 9673 | IPv6 Hop-by-Hop Options Processing Procedures | 2024 | Proposed Standard |
Links
Weblinks
</noinclude>
Path MTU Discovery
PathMTU/Discovery - Path MTU Discovery
Beschreibung
Path MTU Discovery ist eine Funktion von IP, um die optimale MTU (Maximum Transmission Unit) für den gesamten Weg zwischen Sender und Empfänger zu ermitteln
- Optimale Maximum Transmission Unit für den gesamten Weg zwischen Sender und Empfänger ermitteln
- Die MTU ist die maximale Paketlänge, die das Übertragungssystem unterhalb von IP unterstützt
- Ist ein Paket zu groß, dann muss es IP teilen
- Wenn der Sender eines Datenpakets von Anfang an weiß, wie groß die MTU maximal sein darf, dann kann er gleich diese anpassen
- Path MTU Discovery
Ermittlung der Maximum Transfer Unit zu einem entfernten IP-Netzwerk
- Verfahren zum dynamischen Erkennen der Maximum Transmission Unit (MTU)
- maximale Paketgröße für einen bestimmten Pfad im Netzwerk
Im Allgemeinen kann mit dieser Information Overhead vermindert und Fragmentierung von Datenpaketen verhindert werden
- Muss von jedem Router unterstützt werden
- Ermittlung der MTU
- Der Sender generiert ein IP-Paket mit der MTU des lokalen Netzes und gesetztem Don't Fragment-Bit
- Wird auf dem Weg ein Transfernetz erreicht, dessen MTU überschritten wird, sodass dessen Router das Paket fragmentieren müsste, wird das Paket verworfen und der Absender durch eine ICMP-Nachricht vom Typ 3 Code 4 (Destination Unreachable,Fragmentation required, and DF flag set) benachrichtigt
- Da der Absender nun die MTU der Gegenseite kennt, kann er die seine entsprechend anpassen und die Daten erneut versenden
IPv4
Um in IPv4-Netzen die maximale Größe zu bestimmen, die ein Datenpaket haben sollte, muss die Stelle des Pfades gefunden werden, die die kleinsten Datenpakete zulässt
- Dazu wird ein IPv4-Paket versendet, bei dem das DF-Bit (Don’t Fragment) gesetzt ist und das die Größe der lokal eingestellten Maximum Transmission Unit hat
- Kommt das Paket an eine Stelle im Netz, an dem nur eine kleinere MTU verarbeitet werden kann, wird ein ICMP-Error Typ 3 Code 4 (Destination Unreachable Fragmentation Needed, DF Set) zurückgeschickt, der auch die eigene MTU enthält
- Der lokale Rechner erhält dieses ICMP-Paket und kann die Größe seiner Nachrichten nun an die zurückgeschickte MTU anpassen
- Dies wird so lange wiederholt, bis die Paketgröße gering genug gewählt wurde, damit das Paket den gesamten Pfad ohne Fragmentierung durchlaufen kann
- Path MTU Discovery bei IPv4 (RFC 1191)
Path MTU Discovery bei IPv4 sieht vor, dass das DF-Bit (Don't Fragment) im IP-Header gesetzt wird
- Mit diesem Flag bekommen die Router auf dem Weg zum Empfänger mitgeteilt, dass dieses Paket nicht fragmentiert werden darf
- Wenn der Router es zerschneiden muss, dann verwirft er es und schickt eine Mitteilung an den den Absender mit der Fehlermeldung zurück, dass das Paket zu groß ist und wie groß das Paket maximal groß sein darf (MTU)
- Der Client schickt dann das Paket mit der kleineren MTU, in der Hoffnung, dass es jetzt durchgeht
- Wenn nicht, dann muss der Client das Paket noch mal verkleinern
- Solange, bis das Paket erfolgreich beim Empfänger ankommt
Für die Fehlermeldung ist ICMP verantwortlich
- Leider gibt es einige Paranoide Netzwerk-Administratoren, die in den Netzwerken, die sie betreuen, die ICMP-Pakete von Firewalls sperren bzw. verwerfen lassen
- Das heißt, das ursprüngliche Datenpaket wird nie beim Empfänger ankommen und der wird nie erfahren, worin das Problem liegt
Dieses Problem tritt zum Beispiel bei VPN-Verbindungen auf
- Hier müsste wegen dem Tunneling die MTU meist kleiner sein
IPv6
In IPv6-Netzen findet keine Fragmentierung von weitergeleiteten Paketen auf Routern statt, daher ist Path MTU Discovery hier entscheidend dafür, ob Kommunikation mittels großer Pakete zustande kommt
- In IPv6 werden zu große Pakete von den Routern mit dem ICMPv6-Fehler Typ 2 (Packet Too Big) zurückgewiesen
- Dieser Typ ICMPv6-Paket wird für IPv6 statt des ICMP-Error Typ 3 Code 4 Paketes von IPv4 zur Path MTU Discovery verwendet
- Path MTU Discovery bei IPv6 (RFC/1981)
Zu große Datenpakete werden von IPv6-Routern nicht mehr fragmentiert
- Ist ein Paket zu groß, dann wird dem Absender eine Fehlermeldung geschickt (MTU Size Error Feedback)
- Der Absender muss dann die maximale Paketlänge (MTU) anpassen
- Dieses Verfahren nennt sich Path MTU Discovery und existiert in ähnlicher Form auch in IPv4
- Dort muss im Datenpaket das Don't-Fragment-Flag (DF) gesetzt werden
- War in IPv4 dieses Verfahren optional, ist es in IPv6 Pflicht
- Kommt es zum Verlust eines Datenpakets oder kommt es zu Fehlern bei der Fragmentierung, schlägt das Path MTU Discovery fehl
- In IPv4 wurde die MTU dann auf 68 Byte abgesenkt
- Das führte zu einer höheren Paketanzahl und einem unwirtschaftlichen Protokoll-Overhead
- IPv6 hat als kleinste einstellbare MTU 1.280 Byte
- Dadurch werden die Router nicht mehr unnötig belastet
- Selbstverständlich können auch kleinere Pakete als 1.280 Byte übertragen werden
Firewall
Werden die ICMP-Typ-3-Code-4- bzw. ICMPv6-Typ-2-Pakete an einem Punkt des Pfades gefiltert, zum Beispiel durch ein einfaches „ICMP deny“ auf einer Firewall, kann es zu Übertragungsproblemen kommen, wie im Artikel Maximum Transmission Unit beschrieben
- Ein anderes Verfahren zur Bestimmung der Path MTU erfolgt über TCP (oder ein anderes Protokoll zu Paketierung)
- Dabei werden schrittweise größere Pakete gesendet, wobei die maximale Größe über erfolgreich übertragene Pakete festgelegt wird