IPv4/Fragmentierung: Unterschied zwischen den Versionen
Zeile 2: | Zeile 2: | ||
== Beschreibung == | == Beschreibung == | ||
=== Warum Fragmentierung? === | === 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 | * Definition des Protokolls / Beschränkung durch Norm | ||
Version vom 11. Januar 2024, 02:06 Uhr
topic - Kurzbeschreibung
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.