IPv4/Fragmentierung: Unterschied zwischen den Versionen

Aus Foxwiki
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.