Das Kefk Network Wiki befindet sich im Testbetrieb.
IP-Fragmentierung
Aus Kefk.
Die IP-Fragmentierung bezeichnet die Aufteilung eines IP-Datenpaketes auf mehrere physikalische Datenblöcke, falls die Gesamtlänge des Datenpaketes größer als die Maximum Transmission Unit der Netzwerkschnittstelle ist.
Inhaltsverzeichnis |
Hintergrund
Im einfachsten Fall passt das gesamte IP-Datagramm in einen physikalischen Datenblock und erreicht somit die höchste Effizienz. Es gibt jedoch keine festen Vorgaben bzgl. einer festen Paketgröße von IP-Datenpaketen. Des Weiteren ist die maximal mögliche Paketgröße abhängig von den verwendeten Infrastrukturkomponenten, da jede Paket-Switching Technik unterschiedliche maximale Paketgrößen aufweist.
Zielsetzung
Ziel bei der Einführung der Fragmentierung im Internetprotokoll (IP) war es, die zugrundeliegende Netzwerkstruktur für den Benutzer zu verstecken (Schichtenmodell) und somit die Protokollimplementierung von der Hardware unabhängig zu gestalten.
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. zwischengschaltete Firewalls, die speziell angewiesen wurden ein sog. Reassembly durch zu führen, bevor die Daten weiter geleitet werden). Sollte es nötig sein, kann auch ein bereits fragmentiertes Paket weiter fragmentiert werden (etwa bei einem Wechsel der Übertragungstechnik).
Jedes Datagramm, das fragmentiert wurde, erhält und enthält statt des Datagramm-Headers des Originalpaketes einen sog. Fragmentheader, der u.a. den sog. Offset der in diesem Paket versendeten Datenportion in Relation zum Originalpaket angibt. Der Fragment-Offset (13bit im IP-Header) wird dabei in 8Byte-Blöcken angegeben, d.h. wenn das erste Datagramm 1000Byte Nutzdaten enthält, dann ist der Fragment-Offset des zweiten Paketes 125 (=1000Byte / 8Byte). Somit kann nur das letzte Fragment eine Nutzdaten-Menge haben, die nicht ein Vielfaches von 8Byte 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-Checksumme 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 verloren gehen 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 sog. 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 gesendet, dass das Ziel nicht erreichbar sei – „fragmentation required but don’t fragment bit set“.
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 die Performance und 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. 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 als möglich zu vermeiden.
IPv6
Bei dem IPv6 ist es Routern nicht mehr erlaubt, Pakete zu fragmentieren. Der Absender wird bei Fragmentierungsbedarf immer mit einer ICMP Nachricht informiert. So kann der Absender seine Paketgröße für diese Verbindung senken, und es muss nicht jedes Paket fragmentiert werden.
