IP/Fragmentierung: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
(11 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 2: | Zeile 2: | ||
== Beschreibung == | == Beschreibung == | ||
Die '''IP-Fragmentierung''' bezeichnet die Aufteilung eines [[Internet Protocol|IP]]-[[IP-Paket|Datenpakets]] auf mehrere Datenblöcke, falls die Gesamtlänge des Datenpakets größer als die [[Maximum Transmission Unit]] der Netzwerkschnittstelle ist | Die '''IP-Fragmentierung''' bezeichnet die Aufteilung eines [[Internet Protocol|IP]]-[[IP-Paket|Datenpakets]] auf mehrere Datenblöcke, falls die Gesamtlänge des Datenpakets größer als die [[Maximum Transmission Unit]] der Netzwerkschnittstelle ist | ||
; Zielsetzung | |||
Ziel bei der Einführung der Fragmentierung im [[Internet Protocol|Internetprotokoll]] (IP) war es, die zugrundeliegende Netzwerkstruktur für den Benutzer zu verbergen ([[OSI-Modell]]) und somit die Implementierung des [[Netzwerkprotokoll]]s Hardware-unabhängig zu gestalten | |||
; Hintergrund | ; Hintergrund | ||
Im einfachsten Fall passt das gesamte IP-[[Datagramm]] in einen Datenblock und erreicht somit die höchste Effizienz | Im einfachsten Fall passt das gesamte IP-[[Datagramm]] in einen Datenblock und erreicht somit die höchste Effizienz | ||
Grundsätzlich ist die maximale Größe eines IP-Datagramms 64 kB | * Grundsätzlich ist die maximale Größe eines IP-Datagramms 64 kB | ||
Die maximal mögliche Paketgröße ([[MTU]]) ist abhängig von den verwendeten Infrastrukturkomponenten | |||
* da verschiedene Paket-[[Switch (Netzwerktechnik)|Switching]]-Techniken unterschiedliche maximale Paketgrößen zulassen | |||
== Relevanz == | |||
{| class="wikitable options" | |||
|- | |||
! Bereich !! Beschreibung | |||
|- | |||
| LAN || Router, WLAN | |||
|- | |||
| Sicherheit || Angriffe | |||
|- | |||
| Internet || 2007 machte der fragmentierte Datenverkehr 0,06 % aus, 91 % der [[IPv4]]-Pakete hatten das ''don’t fragment'' (DF) Bit gesetzt, zuvor wurden 1-2% gemessen | |||
|} | |||
== Arbeitsweise == | == Arbeitsweise == | ||
Sobald der IP-Stack (vgl. auch [[OSI-Modell]] oder [[TCP/IP-Referenzmodell]]) ein Datenpaket zum Versenden enthält, prüft dieser, ob die Paketgröße eine Aufteilung anhand der für die zu verwendende Netzwerkschnittstelle gegebene [[Maximum Transmission Unit|MTU]] notwendig macht | Sobald der IP-Stack (vgl. auch [[OSI-Modell]] oder [[TCP/IP-Referenzmodell]]) ein Datenpaket zum Versenden enthält, prüft dieser, ob die Paketgröße eine Aufteilung anhand der für die zu verwendende Netzwerkschnittstelle gegebene [[Maximum Transmission Unit|MTU]] notwendig macht | ||
* Ist dies nötig, so teilt dieser das vorhandene Datenpaket in mehrere Datenpakete auf | * Ist dies nötig, so teilt dieser das vorhandene Datenpaket in mehrere Datenpakete auf | ||
* Dieser Vorgang wird als Fragmentierung bezeichnet | * Dieser Vorgang wird als Fragmentierung bezeichnet | ||
* Diese Fragmentierung kann sowohl beim ursprünglichen Sender stattfinden oder auch auf Routern, die zwischen Sender und Empfänger liegen | * Diese Fragmentierung kann sowohl beim ursprünglichen Sender stattfinden oder auch auf Routern, die zwischen Sender und Empfänger liegen | ||
* Wird ein IP-Datagramm fragmentiert, so wird es erst beim Empfänger wieder zusammengesetzt (Ausnahme: ggf. zwischengeschaltete [[Firewall]]s, die speziell angewiesen wurden, ein sogenanntes ''reassembly'' durchzuführen, bevor die Daten weitergeleitet werden) | * Wird ein IP-Datagramm fragmentiert, so wird es erst beim Empfänger wieder zusammengesetzt (Ausnahme: ggf. zwischengeschaltete [[Firewall]]s, die speziell angewiesen wurden, ein sogenanntes ''reassembly'' durchzuführen, bevor die Daten weitergeleitet werden) | ||
Sollte es nötig sein, kann auch ein bereits fragmentiertes Paket weiter fragmentiert werden (etwa bei einem Wechsel der Übertragungstechnik) | Sollte es nötig sein, kann auch ein bereits fragmentiertes Paket weiter fragmentiert werden (etwa bei einem Wechsel der Übertragungstechnik) | ||
Jedes IP-Datagramm, das fragmentiert wurde, erhält einen neuen Header auf Basis des originalen Headers und spezieller aktualisierter Felder | Jedes IP-Datagramm, das fragmentiert wurde, erhält einen neuen Header auf Basis des originalen Headers und spezieller aktualisierter Felder | ||
* Der Fragment-Offset (13 bit im [[IP-Header]]) wird dabei in 8-Byte-Blöcken angegeben | * Der Fragment-Offset (13 bit im [[IP-Header]]) wird dabei in 8-Byte-Blöcken angegeben | ||
* Wenn also das erste Datagramm 1000 Byte [[Nutzdaten]] enthält, dann ist der Fragment-Offset des zweiten Paketes 125 (= 1000 Byte/8 Byte) | * Wenn also das erste Datagramm 1000 Byte [[Nutzdaten]] enthält, dann ist der Fragment-Offset des zweiten Paketes 125 (= 1000 Byte/8 Byte) | ||
* Somit kann nur das letzte Fragment eine Nutzdaten-Menge haben, die nicht ein Vielfaches von 8 Byte ist | * Somit kann nur das letzte Fragment eine Nutzdaten-Menge haben, die nicht ein Vielfaches von 8 Byte ist | ||
* Weiterhin ist zu beachten, dass der Fragment-Offset bei 0 beginnt (der Eintrag im ersten Fragment) und deswegen der Offset des zweiten Paketes im genannten Beispiel 125 und nicht etwa 126 ist | * Weiterhin ist zu beachten, dass der Fragment-Offset bei 0 beginnt (der Eintrag im ersten Fragment) und deswegen der Offset des zweiten Paketes im genannten Beispiel 125 und nicht etwa 126 ist | ||
Bei allen Fragmenten, außer dem letzten, wird das More-Fragments-Flag gesetzt | Bei allen Fragmenten, außer dem letzten, wird das More-Fragments-Flag gesetzt | ||
* Ins Längen-Feld des [[IP-Header]]s wird bei allen Fragmenten die Länge des jeweiligen Fragments eingetragen, und für jeden Header wird die IP-Header-Prüfsumme separat berechnet, während der Rest des Headers dem Originalheader vor der Fragmentierung entspricht | * Ins Längen-Feld des [[IP-Header]]s wird bei allen Fragmenten die Länge des jeweiligen Fragments eingetragen, und für jeden Header wird die IP-Header-Prüfsumme separat berechnet, während der Rest des Headers dem Originalheader vor der Fragmentierung entspricht | ||
Der Empfänger hat nun die Aufgabe, das Original aus den in den Paketheadern vorhandenen Informationen wieder zusammenzusetzen, indem er alle Fragmente mit gleichem IP-Header (mit Ausnahme der für jedes Fragment separaten Information) nimmt und sie anhand ihres Offsets in die richtige Reihenfolge bringt | Der Empfänger hat nun die Aufgabe, das Original aus den in den Paketheadern vorhandenen Informationen wieder zusammenzusetzen, indem er alle Fragmente mit gleichem IP-Header (mit Ausnahme der für jedes Fragment separaten Information) nimmt und sie anhand ihres Offsets in die richtige Reihenfolge bringt | ||
* Da jedes einzelne Fragment ein eigenständiges Paket darstellt, kann es auch vorkommen, dass diese Einzelteile nicht geordnet ankommen | * Da jedes einzelne Fragment ein eigenständiges Paket darstellt, kann es auch vorkommen, dass diese Einzelteile nicht geordnet ankommen | ||
* Es ist auch möglich, dass einzelne Fragmente verlorengehen oder defekt sind | * Es ist auch möglich, dass einzelne Fragmente verlorengehen oder defekt sind | ||
* Es ist dann Sache des Empfängers, das Paket zu verwerfen und die Daten erneut anzufordern, wodurch eine höhere Netzwerklast entstehen kann | * Es ist dann Sache des Empfängers, das Paket zu verwerfen und die Daten erneut anzufordern, wodurch eine höhere Netzwerklast entstehen kann | ||
Per Definition kann die [[Internet Protocol|IP]]-Schicht keine Angaben darüber machen, ob ein Paket im Verlauf seiner Übertragung fragmentiert wird oder nicht | Per Definition kann die [[Internet Protocol|IP]]-Schicht keine Angaben darüber machen, ob ein Paket im Verlauf seiner Übertragung fragmentiert wird oder nicht | ||
* Einzige Ausnahme: Der Sender kann das sogenannte ''Don’t-Fragment''-Flag setzen, welches alle beteiligten Kommunikationssysteme (Router, Gateways etc.) anweist, keine Fragmentierung vorzunehmen | * Einzige Ausnahme: Der Sender kann das sogenannte ''Don’t-Fragment''-Flag setzen, welches alle beteiligten Kommunikationssysteme (Router, Gateways etc.) anweist, keine Fragmentierung vorzunehmen | ||
* Für den Fall, dass eine Fragmentierung doch notwendig wäre, wird das Paket verworfen und dem Sender eine [[Internet Control Message Protocol|ICMP]] Fehlermeldung vom Typ 3 (destination unreachable) mit Code 4 (fragmentation required but don’t fragment bit set) gesendet, welche besagt, dass das Ziel für unfragmentierbare Pakete dieser Größe nicht erreichbar sei | * Für den Fall, dass eine Fragmentierung doch notwendig wäre, wird das Paket verworfen und dem Sender eine [[Internet Control Message Protocol|ICMP]] Fehlermeldung vom Typ 3 (destination unreachable) mit Code 4 (fragmentation required but don’t fragment bit set) gesendet, welche besagt, dass das Ziel für unfragmentierbare Pakete dieser Größe nicht erreichbar sei | ||
== Auswirkungen == | == Auswirkungen == | ||
Obwohl die Zielsetzung eine für höhere Schichten (z. B. [[Transmission Control Protocol|TCP]]/[[User Datagram Protocol|UDP]]) transparente Implementierung ist, gibt es zwei Punkte, in denen dieses nicht ganz erreicht wird: | Obwohl die Zielsetzung eine für höhere Schichten (z. B. [[Transmission Control Protocol|TCP]]/[[User Datagram Protocol|UDP]]) transparente Implementierung ist, gibt es zwei Punkte, in denen dieses nicht ganz erreicht wird: | ||
* Die Fragmentierung kann großen Einfluss auf den Datendurchsatz haben und beeinflusst diesen im Allgemeinen negativ | * Die Fragmentierung kann großen Einfluss auf den Datendurchsatz haben und beeinflusst diesen im Allgemeinen negativ | ||
* Geht ein fragmentiertes Paket des originalen Paketes verloren, so muss das gesamte Original erneut übertragen werden. [[Internet Protocol|IP]] hat jedoch keine Sicherungs- bzw.ggf.Timeoutmechanismen und ist hierbei auf die Sicherungsfunktionen höherer Schichten wie die des [[Transmission Control Protocol|TCP]] angewiesen | * Geht ein fragmentiertes Paket des originalen Paketes verloren, so muss das gesamte Original erneut übertragen werden. [[Internet Protocol|IP]] hat jedoch keine Sicherungs- bzw.ggf.Timeoutmechanismen und ist hierbei auf die Sicherungsfunktionen höherer Schichten wie die des [[Transmission Control Protocol|TCP]] angewiesen | ||
Aus genannten Gründen wird versucht, Fragmentierung immer so weit wie möglich zu vermeiden | Aus genannten Gründen wird versucht, Fragmentierung immer so weit wie möglich zu vermeiden | ||
== IPv6 == | == IPv6 == | ||
Bei [[IPv6]] ist es Routern nicht mehr erlaubt, Pakete zu fragmentieren | ; Bei [[IPv6]] ist es Routern nicht mehr erlaubt, Pakete zu fragmentieren | ||
* Der Absender wird bei Fragmentierungsbedarf immer mit einer [[ICMPv6]]-Nachricht vom Typ 2 (Packet Too Big) informiert | * Der Absender wird bei Fragmentierungsbedarf immer mit einer [[ICMPv6]]-Nachricht vom Typ 2 (Packet Too Big) informiert | ||
* Dieser kann daraufhin seine Paketgrößen dadurch senken, dass die kommunizierende Anwendung kleinere, unfragmentierte Pakete erzeugt, oder dadurch, dass fragmentiert wird | * Dieser kann daraufhin seine Paketgrößen dadurch senken, dass die kommunizierende Anwendung kleinere, unfragmentierte Pakete erzeugt, oder dadurch, dass fragmentiert wird | ||
* Im zweiten Fall beginnt der Sender nach dem [[Ipv6#Header-Format|IPv6-Header]] einen [[Ipv6#Header-Format|Fragment Extension Header]] ([[Protokoll (IP)|Protokoll 44]]) einzufügen, der die Parameter der Fragmentierung enthält, denn diese sind im ''IPv6-Header'' nicht mehr vorgesehen | * Im zweiten Fall beginnt der Sender nach dem [[Ipv6#Header-Format|IPv6-Header]] einen [[Ipv6#Header-Format|Fragment Extension Header]] ([[Protokoll (IP)|Protokoll 44]]) einzufügen, der die Parameter der Fragmentierung enthält, denn diese sind im ''IPv6-Header'' nicht mehr vorgesehen | ||
* Beim Filtern von Paketen sollte beachtet werden, dass das ''Next Header'' Feld im ''IPv6-Header'' bei fragmentiertem Datenverkehr auf Protokoll 44 verweist und nicht mehr auf die ursprüngliche Protokollnummer, wie beispielsweise 17 für UDP, diese verschiebt sich in das ''Next Header'' Feld des ''Fragment Extension Headers'' | * Beim Filtern von Paketen sollte beachtet werden, dass das ''Next Header'' Feld im ''IPv6-Header'' bei fragmentiertem Datenverkehr auf Protokoll 44 verweist und nicht mehr auf die ursprüngliche Protokollnummer, wie beispielsweise 17 für UDP, diese verschiebt sich in das ''Next Header'' Feld des ''Fragment Extension Headers'' | ||
<noinclude> | <noinclude> | ||
Zeile 65: | Zeile 76: | ||
# https://de.wikipedia.org/wiki/IP-Fragmentierung | # https://de.wikipedia.org/wiki/IP-Fragmentierung | ||
[[Kategorie: | [[Kategorie:IP]] | ||
</noinclude> | </noinclude> |
Aktuelle Version vom 15. Februar 2024, 12:24 Uhr
IP-Fragmentierung - Aufteilung eines IP-Datenpakets auf mehrere Datenblöcke
Beschreibung
Die IP-Fragmentierung bezeichnet die Aufteilung eines IP-Datenpakets auf mehrere Datenblöcke, falls die Gesamtlänge des Datenpakets größer als die Maximum Transmission Unit der Netzwerkschnittstelle ist
- Zielsetzung
Ziel bei der Einführung der Fragmentierung im Internetprotokoll (IP) war es, die zugrundeliegende Netzwerkstruktur für den Benutzer zu verbergen (OSI-Modell) und somit die Implementierung des Netzwerkprotokolls Hardware-unabhängig zu gestalten
- Hintergrund
Im einfachsten Fall passt das gesamte IP-Datagramm in einen Datenblock und erreicht somit die höchste Effizienz
- Grundsätzlich ist die maximale Größe eines IP-Datagramms 64 kB
Die maximal mögliche Paketgröße (MTU) ist abhängig von den verwendeten Infrastrukturkomponenten
- da verschiedene Paket-Switching-Techniken unterschiedliche maximale Paketgrößen zulassen
Relevanz
Bereich | Beschreibung |
---|---|
LAN | Router, WLAN |
Sicherheit | Angriffe |
Internet | 2007 machte der fragmentierte Datenverkehr 0,06 % aus, 91 % der IPv4-Pakete hatten das don’t fragment (DF) Bit gesetzt, zuvor wurden 1-2% gemessen |
Arbeitsweise
Sobald der IP-Stack (vgl. auch OSI-Modell oder TCP/IP-Referenzmodell) ein Datenpaket zum Versenden enthält, prüft dieser, ob die Paketgröße eine Aufteilung anhand der für die zu verwendende Netzwerkschnittstelle gegebene MTU notwendig macht
- Ist dies nötig, so teilt dieser das vorhandene Datenpaket in mehrere Datenpakete auf
- Dieser Vorgang wird als Fragmentierung bezeichnet
- Diese Fragmentierung kann sowohl beim ursprünglichen Sender stattfinden oder auch auf Routern, die zwischen Sender und Empfänger liegen
- Wird ein IP-Datagramm fragmentiert, so wird es erst beim Empfänger wieder zusammengesetzt (Ausnahme: ggf. zwischengeschaltete Firewalls, die speziell angewiesen wurden, ein sogenanntes reassembly durchzuführen, bevor die Daten weitergeleitet werden)
Sollte es nötig sein, kann auch ein bereits fragmentiertes Paket weiter fragmentiert werden (etwa bei einem Wechsel der Übertragungstechnik)
Jedes IP-Datagramm, das fragmentiert wurde, erhält einen neuen Header auf Basis des originalen Headers und spezieller aktualisierter Felder
- Der Fragment-Offset (13 bit im IP-Header) wird dabei in 8-Byte-Blöcken angegeben
- Wenn also das erste Datagramm 1000 Byte Nutzdaten enthält, dann ist der Fragment-Offset des zweiten Paketes 125 (= 1000 Byte/8 Byte)
- Somit kann nur das letzte Fragment eine Nutzdaten-Menge haben, die nicht ein Vielfaches von 8 Byte ist
- Weiterhin ist zu beachten, dass der Fragment-Offset bei 0 beginnt (der Eintrag im ersten Fragment) und deswegen der Offset des zweiten Paketes im genannten Beispiel 125 und nicht etwa 126 ist
Bei allen Fragmenten, außer dem letzten, wird das More-Fragments-Flag gesetzt
- Ins Längen-Feld des IP-Headers wird bei allen Fragmenten die Länge des jeweiligen Fragments eingetragen, und für jeden Header wird die IP-Header-Prüfsumme separat berechnet, während der Rest des Headers dem Originalheader vor der Fragmentierung entspricht
Der Empfänger hat nun die Aufgabe, das Original aus den in den Paketheadern vorhandenen Informationen wieder zusammenzusetzen, indem er alle Fragmente mit gleichem IP-Header (mit Ausnahme der für jedes Fragment separaten Information) nimmt und sie anhand ihres Offsets in die richtige Reihenfolge bringt
- Da jedes einzelne Fragment ein eigenständiges Paket darstellt, kann es auch vorkommen, dass diese Einzelteile nicht geordnet ankommen
- Es ist auch möglich, dass einzelne Fragmente verlorengehen oder defekt sind
- Es ist dann Sache des Empfängers, das Paket zu verwerfen und die Daten erneut anzufordern, wodurch eine höhere Netzwerklast entstehen kann
Per Definition kann die IP-Schicht keine Angaben darüber machen, ob ein Paket im Verlauf seiner Übertragung fragmentiert wird oder nicht
- Einzige Ausnahme: Der Sender kann das sogenannte Don’t-Fragment-Flag setzen, welches alle beteiligten Kommunikationssysteme (Router, Gateways etc.) anweist, keine Fragmentierung vorzunehmen
- Für den Fall, dass eine Fragmentierung doch notwendig wäre, wird das Paket verworfen und dem Sender eine ICMP Fehlermeldung vom Typ 3 (destination unreachable) mit Code 4 (fragmentation required but don’t fragment bit set) gesendet, welche besagt, dass das Ziel für unfragmentierbare Pakete dieser Größe nicht erreichbar sei
Auswirkungen
Obwohl die Zielsetzung eine für höhere Schichten (z. B. TCP/UDP) transparente Implementierung ist, gibt es zwei Punkte, in denen dieses nicht ganz erreicht wird:
- Die Fragmentierung kann großen Einfluss auf den Datendurchsatz haben und beeinflusst diesen im Allgemeinen negativ
- Geht ein fragmentiertes Paket des originalen Paketes verloren, so muss das gesamte Original erneut übertragen werden. IP hat jedoch keine Sicherungs- bzw.ggf.Timeoutmechanismen und ist hierbei auf die Sicherungsfunktionen höherer Schichten wie die des TCP angewiesen
Aus genannten Gründen wird versucht, Fragmentierung immer so weit wie möglich zu vermeiden
IPv6
- Bei IPv6 ist es Routern nicht mehr erlaubt, Pakete zu fragmentieren
- Der Absender wird bei Fragmentierungsbedarf immer mit einer ICMPv6-Nachricht vom Typ 2 (Packet Too Big) informiert
- Dieser kann daraufhin seine Paketgrößen dadurch senken, dass die kommunizierende Anwendung kleinere, unfragmentierte Pakete erzeugt, oder dadurch, dass fragmentiert wird
- Im zweiten Fall beginnt der Sender nach dem IPv6-Header einen Fragment Extension Header (Protokoll 44) einzufügen, der die Parameter der Fragmentierung enthält, denn diese sind im IPv6-Header nicht mehr vorgesehen
- Beim Filtern von Paketen sollte beachtet werden, dass das Next Header Feld im IPv6-Header bei fragmentiertem Datenverkehr auf Protokoll 44 verweist und nicht mehr auf die ursprüngliche Protokollnummer, wie beispielsweise 17 für UDP, diese verschiebt sich in das Next Header Feld des Fragment Extension Headers