IPv4/Fragmentierung: Unterschied zwischen den Versionen

Aktuelle Version vom 10. Juli 2025, 08:46 Uhr

IPv4/Fragmentierung - Anpassung der Datagramgrösse an die MTU der lokalen Netz-Technologie

Beschreibung

Warum Fragmentierung?

Anpassung der Datagramgrösse an die MTU der lokalen Netz-Technologie

Definition des Protokolls / Beschränkung durch Norm

Paketlänge in verschiedenen Netzen

Token Ring32768 bit
Ethernet12144 bit
X.25 (Maximum)8192 bit
X.25 (Standard)1024 bit

Fragmentierung

Felder: DF, MF, Identifikation, Fragmentabstand

kann nur bei DF=0 durchgeführt werden
wird von den Routern eigenständig vorgenommen
kann bei Bedarf wiederholt angewandt werden
Zielhost muss die Fragmente zusammensetzen

Fragmentierung

Alle Fragmente haben dieselbe Kennung
- diese definiert keine Reihenfolge

Zu fragmentierende Pakete mit DF-Flag werden verworfen, da sie nicht in das nächste Netzwerk geleitet werden können

Stationen, die nicht alle Fragmente eines IP-Datagrams innerhalb einer bestimmten Zeitspanne (i.d.R. 30-40s) zum Reassemblieren erhalten, verwerfen alle empfangenen Pakete

Fragment Offset

Gibt die Länge relativ in Byte zum Beginn des Datenbereichs im ursprünglichen Datagram an

Ermöglicht dem Empfänger mehrere Fragmente in der richtigen Reihenfolge zusammenzusetzen
Bei vollständigem Datagram (keine Fragmentierung) und beim ersten Fragment hat der Fragment Offset immer den Wert 0

Fragment Offset (Grafik)

Beispiel

Netz1: MTU 1200Byte
Netz2: MTU 532 Byte
Netz3: MTU 276 Byte
Paket mit Länge 1044Byte (= 20Byte Header + 1024Byte Daten) und nicht gesetztem DF-Bit soll über die 3 Netze übertragen werden
Die Reihenfolge der Ankunft beim Zielhost spielt keine Rolle.
Wenn nach Ablauf eines Timers nicht alle Teilpakete angekommen sind, wird das Paket verworfen.

Beispiel - Paketlänge 1044 Byte

Anwendung

Anhang

Siehe auch

Sicherheit

Dokumentation

RFC

Links

Projekt

Weblinks

TMP

Datagrammfragmentierung

Auf dem Weg vom Sender zum Empfänger kann es vorkommen, dass ein Datagramm ein Netz durchlaufen muss, welches nur kleine Datagramme unterstützt.

Jedes Datagramm erhält vom Sender eine Kennung (Identification).
Stellt ein Router auf dem Weg zum Ziel fest, dass das Datagramm für das nächste Teilnetz zu groß ist, so kann er es in zwei Fragmente aufteilen.

Dazu sind folgende Schritte notwendig

Aufteilen der Nutzdaten an einer 64-Bit-Grenze (das zweite Fragment enthält dann nicht unbedingt ein Vielfaches von 64 Bit Daten)
Kopieren der Header-Daten des Originaldatagramms in die neuen Header
Setzen des "more-fragments"-Flags beim ersten Fragment
Beim zweiten Fragment erhält das more-fragments Flag den Wert des Originaldatagramms, da das Originaldatagramm bereits ein Fragment gewesen sein kann.
Erneutes Setzen der Länge-Felder in den Headern
Beim zweiten Fragment enthält Fragment-Offset die Summe aus Fragment-Offset des Originaldatagramms und die Anzahl der (Nutzdaten-)Bytes des ersten Fragments.
Das Fragmentieren in n > 2 Fragmente funktioniert entsprechend.

Reassemblierung

Um ein Paket wieder zusammenzusetzen, kombiniert der Empfänger alle Fragmente, welche die gleiche Kennung (Identifikation), den gleichen Absender, Empfänger und das gleiche Protokoll haben.

Dabei erkennt er das erste Fragment daran, dass Fragment-Offset den Wert 0 hat.
Das jeweils nächste Fragment erkennt er ebenfalls am Fragment-Offset und das letzte Fragment daran, dass more-fragments den Wert 0 hat.

@@ Zeile 1: / Zeile 1: @@
+'''IPv4/Fragmentierung''' - Anpassung der Datagramgrösse an die [[MTU]] der lokalen Netz-Technologie
+== Beschreibung ==
 === Warum Fragmentierung? ===
-* Anpassung der Datagramgrösse an die MTU der lokalen Netz-Technologie
+; Anpassung der Datagramgrösse an die [[MTU]] der lokalen Netz-Technologie
 * Definition des Protokolls / Beschränkung durch Norm
-* Paketlänge in verschiedenen Netzen
+; Paketlänge in verschiedenen Netzen
 * Token Ring32768 bit
 * Ethernet12144 bit
@@ Zeile 9: / Zeile 13: @@
 === Fragmentierung ===
-* Felder: DF, MF, Identifikation, Fragmentabstand
+; Felder: DF, MF, Identifikation, Fragmentabstand
 * kann nur bei DF=0 durchgeführt werden
 * wird von den Routern eigenständig vorgenommen
-* kann bei Bedarf wiederholt angewendet werden
+* kann bei Bedarf wiederholt angewandt werden
 * Zielhost muss die Fragmente zusammensetzen
-=== Fragmentierung ===
+; Fragmentierung
 * Alle Fragmente haben dieselbe Kennung
-* diese definiert keine Reihenfolge
+** diese definiert keine Reihenfolge
-* Zu fragmentierende Pakete mit DF-Flag werden verworfen, da sie nicht in das nächste Netzwerk geleitet werden können
+Zu fragmentierende Pakete mit DF-Flag werden verworfen, da sie nicht in das nächste Netzwerk geleitet werden können
 * Stationen, die nicht alle Fragmente eines IP-Datagrams innerhalb einer bestimmten Zeitspanne (i.d.R. 30-40s) zum Reassemblieren erhalten, verwerfen alle empfangenen Pakete
 === Fragment Offset ===
-* Gibt die Länge relativ in Byte zum Beginn des Datenbereichs im ursprünglichen Datagram an
+; Gibt die Länge relativ in Byte zum Beginn des Datenbereichs im ursprünglichen Datagram an
 * Ermöglicht dem Empfänger mehrere Fragmente in der richtigen Reihenfolge zusammenzusetzen
 * Bei vollständigem Datagram (keine Fragmentierung) und beim ersten Fragment hat der Fragment Offset immer den Wert 0
-=== Fragment Offset (Grafik) ===
+: Fragment Offset (Grafik)
 === Beispiel ===
@@ Zeile 36: / Zeile 41: @@
 * Wenn nach Ablauf eines Timers nicht alle Teilpakete angekommen sind, wird das Paket verworfen.
-=== Beispiel - Paketlänge 1044 Byte ===
+: Beispiel - Paketlänge 1044 Byte
-[[Kategorie:IPv4]]
+== Anwendung ==
+<noinclude>
+== Anhang ==
+=== Siehe auch ===
+{{Special:PrefixIndex/IPv4}}
+==== Sicherheit ====
+=== Dokumentation ===
+===== RFC =====
+=== Links ===
+==== Projekt ====
+==== Weblinks ====
+=== TMP ===
+==== Datagrammfragmentierung ====
+; Auf dem Weg vom Sender zum Empfänger kann es vorkommen, dass ein [[Datagramm]] ein Netz durchlaufen muss, welches nur kleine Datagramme unterstützt.
+* Jedes Datagramm erhält vom Sender eine Kennung (Identification).
+* Stellt ein Router auf dem Weg zum Ziel fest, dass das Datagramm für das nächste Teilnetz zu groß ist, so kann er es in zwei Fragmente aufteilen.
+; Dazu sind folgende Schritte notwendig:
+* Aufteilen der Nutzdaten an einer 64-Bit-Grenze (das zweite Fragment enthält dann nicht unbedingt ein Vielfaches von 64 Bit Daten)
+* Kopieren der Header-Daten des Originaldatagramms in die neuen Header
+* Setzen des "more-fragments"-Flags beim ersten Fragment
+* Beim zweiten Fragment erhält das more-fragments Flag den Wert des Originaldatagramms, da das Originaldatagramm bereits ein Fragment gewesen sein kann.
+* Erneutes Setzen der Länge-Felder in den Headern
+* Beim zweiten Fragment enthält Fragment-Offset die Summe aus Fragment-Offset des Originaldatagramms und die Anzahl der (Nutzdaten-)Bytes des ersten Fragments.
+* Das Fragmentieren in n > 2 Fragmente funktioniert entsprechend.
+; Reassemblierung
+Um ein Paket wieder zusammenzusetzen, kombiniert der Empfänger alle Fragmente, welche die gleiche Kennung (Identifikation), den gleichen Absender, Empfänger und das gleiche Protokoll haben.
+* Dabei erkennt er das erste Fragment daran, dass Fragment-Offset den Wert 0 hat.
+* Das jeweils nächste Fragment erkennt er ebenfalls am Fragment-Offset und das letzte Fragment daran, dass ''more-fragments'' den Wert 0 hat.
+[[Kategorie:IPv4/ICMP]]
+</noinclude>