IPv4/Fragmentierung: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| (19 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
''' | '''IPv4/Fragmentierung''' - Anpassung der Datagramgrösse an die [[MTU]] der lokalen Netz-Technologie | ||
== Beschreibung == | == Beschreibung == | ||
=== Warum Fragmentierung? === | === Warum Fragmentierung? === | ||
; 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 | ||
Paketlänge in verschiedenen Netzen | ; Paketlänge in verschiedenen Netzen | ||
* Token Ring32768 bit | * Token Ring32768 bit | ||
* Ethernet12144 bit | * Ethernet12144 bit | ||
| Zeile 12: | Zeile 13: | ||
=== Fragmentierung === | === Fragmentierung === | ||
; Felder: DF, MF, Identifikation, Fragmentabstand | |||
* kann nur bei DF=0 durchgeführt werden | * kann nur bei DF=0 durchgeführt werden | ||
* wird von den Routern eigenständig vorgenommen | * wird von den Routern eigenständig vorgenommen | ||
| Zeile 20: | Zeile 21: | ||
; Fragmentierung | ; Fragmentierung | ||
* Alle Fragmente haben dieselbe Kennung | * 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 | |||
* Stationen, die nicht alle Fragmente eines IP-Datagrams innerhalb einer bestimmten Zeitspanne (i.d.R. 30-40s) zum Reassemblieren erhalten, verwerfen alle empfangenen Pakete | * 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 === | === 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 | * 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 | * Bei vollständigem Datagram (keine Fragmentierung) und beim ersten Fragment hat der Fragment Offset immer den Wert 0 | ||
: Fragment Offset (Grafik) | |||
=== Beispiel === | === Beispiel === | ||
| Zeile 39: | Zeile 41: | ||
* Wenn nach Ablauf eines Timers nicht alle Teilpakete angekommen sind, wird das Paket verworfen. | * Wenn nach Ablauf eines Timers nicht alle Teilpakete angekommen sind, wird das Paket verworfen. | ||
: Beispiel - Paketlänge 1044 Byte | |||
== Anwendung == | == Anwendung == | ||
| Zeile 49: | Zeile 51: | ||
==== Sicherheit ==== | ==== Sicherheit ==== | ||
=== Dokumentation === | |||
===== RFC ===== | ===== RFC ===== | ||
=== Links === | |||
==== Projekt ==== | |||
==== Weblinks ==== | |||
=== TMP === | === TMP === | ||
== Datagrammfragmentierung == | ==== 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. | ; 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). | * 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. | * 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) | * Aufteilen der Nutzdaten an einer 64-Bit-Grenze (das zweite Fragment enthält dann nicht unbedingt ein Vielfaches von 64 Bit Daten) | ||
* Kopieren der | * Kopieren der Header-Daten des Originaldatagramms in die neuen Header | ||
* Setzen des | * 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. | * 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 | * 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. | * 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. | 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. | * 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. | * 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> | </noinclude> | ||
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.