MTU/Path-Discovery: Unterschied zwischen den Versionen

Versionsgeschichte interaktiv durchsuchen

Aktuelle Version vom 10. Juli 2025, 11:56 Uhr

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

Anhang

Siehe auch

Dokumentation

RFC

RFC	Titel	Jahr	Status
879	The TCP Maximum Segment Size and Related Topics	1983	Obsoleted by: RFC/7805, RFC/9293
1191	Path MTU Discovery	1990
1981	Path MTU Discovery for IP version 6	1996
2923	TCP Problems with Path MTU Discovery	2000
4821	Packetization Layer Path MTU Discovery	2007	PROPOSED STANDARD, Updated by RFC/8899
7805	Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status	2016	INFORMATIONAL
9293	Transmission Control Protocol (TCP)	2022	DRAFT STANDARD

Links

Weblinks

@@ Zeile 1: / Zeile 1: @@
-'''{{BASEPAGENAME}}''' - Optimale [[Maximum Transmission Unit]] für den gesamten Weg zwischen Sender und Empfänger ermitteln
+'''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
+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''' ist ein Verfahren zum dynamischen Erkennen der [[Maximum Transmission Unit]] (MTU) und damit der maximalen Paketgröße für einen bestimmten Pfad im Netzwerk
+; Path MTU Discovery
-* Im Allgemeinen kann mit dieser Information [[Overhead (EDV)|Overhead]] vermindert und [[IP-Fragmentierung|Fragmentierung]] von Datenpaketen verhindert werden
+Ermittlung der '''''M'''aximum '''T'''ransfer '''U'''nit'' zu einem entfernten IP-Netzwerk
+* Verfahren zum dynamischen Erkennen der [[Maximum Transmission Unit]] (MTU)
+* maximale Paketgröße für einen bestimmten Pfad im Netzwerk
-; Path MTU Discovery
+Im Allgemeinen kann mit dieser Information [[Overhead (EDV)|Overhead]] vermindert und [[IP-Fragmentierung|Fragmentierung]] von Datenpaketen verhindert werden
-* Ermittlung der '''''M'''aximum '''T'''ransfer '''U'''nit'' zu einem entfernten IP-Netzwerk
 * Muss von jedem Router unterstützt werden
-''' Ermittlung der MTU '''
+; 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 ==
+{{:Path MTU Discovery/IPv4}}
-Um in [[IPv4]]-Netzen die maximale Größe zu bestimmen, die ein Datenpaket haben <!-- "nicht überschreiten" statt "haben"? --> sollte, muss die Stelle des Pfades gefunden werden, die die kleinsten Datenpakete zulässt
-* Dazu wird ein [[IP-Paket|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 [[Internet Control Message Protocol|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 [[Internet Control Message Protocol|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 [[IP-Fragmentierung|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.&nbsp;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 ==
+{{:Path MTU Discovery/IPv6}}
-In [[IPv6]]-Netzen findet keine [[IP-Fragmentierung|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&nbsp;2 (Packet Too Big) zurückgewiesen
-* Dieser Typ ICMPv6-Paket wird für IPv6 statt des [[Internet Control Message Protocol|ICMP]]-Error Typ&nbsp;3 Code&nbsp;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
-== Probleme ==
+{{:Path MTU Discovery/Firewall}}
-; Firewall
-Werden die ICMP-Typ-3-Code-4- bzw.&nbsp;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
 <noinclude>
@@ Zeile 70: / Zeile 33: @@
 == Anhang ==
 === Siehe auch ===
-<div style="column-count:3">
+<div style="column-count:2">
 <categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
 </div>
@@ Zeile 82: / Zeile 45: @@
 * [[Internet Control Message Protocol Version 6]] ([[ICMPv6]])
-=== RFC ===
+=== Dokumentation ===
-{| class="wikitable options big col1right"
+===== RFC =====
+{| class="wikitable big options col3center"
+|-
+! RFC !! Titel !! Jahr !! Status
+|-
+| [https://www.rfc-editor.org/info/rfc879 879] || The TCP Maximum Segment Size and Related Topics || 1983 || Obsoleted by: [[RFC/7805]], [[RFC/9293]]
 |-
-! RFC !! Titel !! Jahr
+| [https://www.rfc-editor.org/info/rfc1191 1191] || Path MTU Discovery || 1990 ||
 |-
-| [https://www.rfc-editor.org/info/rfc879 879] || The TCP Maximum Segment Size and Related Topics || 1983
+| [https://www.rfc-editor.org/info/rfc1981 1981] || Path MTU Discovery for IP version 6 || 1996 ||
 |-
-| [https://www.rfc-editor.org/info/rfc1191 1191] || Path MTU Discovery || 1990
+| [https://www.rfc-editor.org/info/rfc2923 2923] || TCP Problems with Path MTU Discovery || 2000 ||
 |-
-| [https://www.rfc-editor.org/info/rfc1981 1981] || Path MTU Discovery for IP version 6 || 1996
+| [https://www.rfc-editor.org/info/rfc4821 4821] || Packetization Layer Path MTU Discovery || 2007 || PROPOSED STANDARD, Updated by [[RFC/8899]]
 |-
-| [https://www.rfc-editor.org/info/rfc2923 2923] || TCP Problems with Path MTU Discovery || 2000
+| [https://www.rfc-editor.org/info/rfc7805 7805] || Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status || 2016 || INFORMATIONAL
 |-
-| [https://www.rfc-editor.org/info/rfc4821 4821] || Packetization Layer Path MTU Discovery || 2007
+| [https://www.rfc-editor.org/info/rfc9293 9293] || Transmission Control Protocol (TCP) || 2022 || DRAFT STANDARD
 |}
@@ Zeile 103: / Zeile 71: @@
 # https://www.elektronik-kompendium.de/sites/net/2012221.htm
+[[Kategorie:IP/Fragmentierung]]
 [[Kategorie:ICMP]]
 [[Kategorie:OSI/2 Data Link]]