Skript/IPv6/Fragmentierung
Skript/IPv6/Fragmentierung
Inhalt
IP/Fragmentierung |
Maximum Transmission Unit |
IP/Fragmentierung/IPv4 |
IP/Fragmentierung/IPv6 |
IPv6/Header/Extension/Fragment |
Path MTU Discovery |
IP/Fragmentierung
IP/Fragmentierung - Aufteilung eines IP-Datagramms, wenn es größer als die Maximum Transmission Unit der Netzwerkschnittstelle ist
Beschreibung
Fragmentierung von Paketen auf einem Übertragungsnetzwerk, wenn das Paket größer ist als die MTU-Size des Netzwerks oder einer Teilstrecke
- Zielsetzung
Ziel bei der Einführung der Fragmentierung im Internetprotokoll (IP) war es
- die zugrundeliegende Netzwerkstruktur für den Benutzer zu verbergen (OSI-Modell)
- Implementierung des Netzwerkprotokolls Hardware-unabhängig zu gestalten
- Hintergrund
Im einfachsten Fall passt das gesamte IP-Datagramm in einen Datenblock
- Höchste Effizienz
- Maximale Größe eines IP-Datagramms
- 64 kB
- Die maximal mögliche Paketgröße (MTU) ist abhängig von den verwendeten Infrastrukturkomponenten
- Moderne Paket-Switching-Techniken lassen unterschiedliche maximale Paketgrößen zu
- 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 und weitere) 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
Maximum Transmission Unit
Maximum Transmission Unit - Maximale Datagramm-Größe (OSI-Schicht 3)
Beschreibung
Maximum Transmission Unit - Maximale Datagramm-Größe (OSI-Schicht 3), das ohne Zerlegung in einen Frame auf OSI-Schicht 2 passt (MTU)
MTU (Maximum Transmission Unit) beschreibt die maximale Paketgröße eines Protokolls der Vermittlungsschicht (Schicht 3) des OSI-Modells in Byte, die ohne Zerlegung in den Rahmen (Frame) eines Netzes der Sicherungsschicht (Schicht 2) passt
- Das Paket passt in die Nutzlast (Payload) des Protokolls der Sicherungsschicht
- Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet
Die Maximum Transmission Unit (MTU; deutsch maximale Übertragungseinheit) beschreibt die maximale Paketgröße eines Protokolls der Vermittlungsschicht (Schicht 3) des OSI-Modells, gemessen in Oktetten (Bytes), welche ohne Fragmentierung in den Rahmen (Frame) eines Netzes der Sicherungsschicht (Schicht 2) übertragen werden kann
- Diese Paketgröße passt also in die Nutzlast (Payload) des Protokolls der Sicherungsschicht
- Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet
- Berechnung
Die maximale Größe eines Rahmens der Sicherungsschicht lässt sich so berechnen
Maximale Rahmengröße = | Größte MTU aller benutzten Protokolle der Vermittlungsschicht + Größe der Sicherungsschichtheader |
Die MTU wird durch Einstellungen im Rahmen der Möglichkeiten der verwendeten Hardware und Technik bestimmt
- Sie kann auf derselben Schnittstelle unterschiedliche Werte für unterschiedliche Protokolle der Vermittlungsschicht (beispielsweise IPv4 oder IPv6) annehmen
- Alle an einem Schicht-2-Netz beteiligten Schnittstellen, welche Protokolle höherer Schichten verarbeiten, müssen auf denselben Wert für die jeweiligen Schicht-3-Protokolle eingestellt werden
Im OSI-Modell spricht man auf der Vermittlungsschicht von einem Paket (engl. 'packet'), während man auf der Sicherungsschicht von einem Rahmen spricht
- Die Terminologie, welche das OSI-Modell für die Einheiten auf den verschiedenen OSI-Modellschichten verwendet, hat zu einiger Verwirrung um den Begriff der MTU geführt (siehe abweichende Verwendung bei wichtigen Herstellern)
- Unter der "packet size" (Paketgröße) wird fälschlicherweise teils die "frame size" (Rahmengröße) verstanden, jedoch stellt die obige Definition (siehe RFC 1122 und RFC 791) dies eindeutig klar
Ein Spezialfall liegt vor, wenn ein Schicht-2-Protokoll über ein anderes Schicht-2-Protokoll getunnelt wird, denn dann nennt man auch die Nutzlast selbst "Rahmen"
Path MTU (PMTU)
Die Path MTU (PMTU) beschreibt die maximale Paketgröße, die entlang der gesamten Wegstrecke übertragen werden kann, ohne einer Fragmentierung zu unterliegen
- Sie ist damit gleich der kleinsten MTU aller Schicht-2-Teilstücke im Pfad
- Die PMTU kann automatisch durch PMTU Discovery (PMTUD) ermittelt werden
Beispiel Brief
- Das Konzept der MTU kann auf den Briefverkehr adaptiert werden
- Ein Kompaktbrief darf maximal 50 g wiegen
- Zum Transport benötigt der Brief einen Briefumschlag beispielsweise 4 g und eine Briefmarke 0,3 g
- Diese 4,3 g entsprechen der Größe der Sicherungsschichtheader
- Daraus ergibt sich, dass die MTU (der maximale Inhalt für einen Kompaktbrief oder Packet Size) 50 g - 4,3 g = 45,7 g beträgt
Will man mehr Gewicht verschicken, muss man auf ein anderes Protokoll (einen Großbrief mit mehr Porto) ausweichen oder den Inhalt auf mehrere Briefe aufteilen, also fragmentieren
- Typische MTU-Größen
Medium | MTU in Bytes |
---|---|
Hyperchannel | 65535 |
Token Ring(4)(802.5) | 4464 |
Token Ring(16) | 17914 |
FDDI | 4352 |
Ethernet | 1500 |
Gigabit Ethernet mit Jumboframes |
9000 |
PPPoE (beispielsweise DSL) | ≤ 1492 |
SLIP/PPP (low delay) | 296 |
X.25 | 576 |
FibreChannel | theoretisch unbegrenzt |
ISDN | 576 |
DQDB | |
HIPPI | |
ATM | 4500, s. u |
ARCNET | |
802.11 | 2312 (WiFi) |
- Maximale Paketgröße eines Protokolls der Vermittlungsschicht
- Schicht 3 des OSI-Modells
- gemessen in Oktetten
- welche ohne Fragmentierung in den Rahmen (engl. "Frames") eines Netzes der Sicherungsschicht (Schicht 2) übertragen werden kann
- Diese Paketgröße passt also in die Nutzlast (Payload) des Protokolls der Sicherungsschicht
- Die maximale Größe der Nutzlast der Sicherungsschicht wird auch oft als MTU der Sicherungsschicht (engl. 'link MTU') bezeichnet
- Die maximale Größe eines Rahmens der Sicherungsschicht lässt sich so berechnen
Maximale Rahmengröße = | Größte MTU aller benutzten Protokolle der Vermittlungsschicht + Größe der Sicherungsschichtheader |
- Hardware und Technik
- Die MTU wird durch Einstellungen im Rahmen der Möglichkeiten der verwendeten Hardware und Technik bestimmt
- Sie kann auf derselben Schnittstelle unterschiedliche Werte für unterschiedliche Protokolle der Vermittlungsschicht (beispielsweise IPv4 oder IPv6) annehmen
- Alle an einem Schicht-2-Netz beteiligten Schnittstellen, welche Protokolle höherer Schichten verarbeiten, müssen auf denselben Wert für die jeweiligen Schicht-3-Protokolle eingestellt werden
Terminologie
- Im OSI-Modell spricht man auf der Vermittlungsschicht von einem Paket (engl. 'packet'), während man auf der Sicherungsschicht von einem Rahmen (engl. 'frame') spricht
- Die Terminologie, welche das OSI-Modell für die Einheiten auf den verschiedenen OSI-Modellschichten verwendet, hat zu einiger Verwirrung um den Begriff der MTU geführt
Abweichende Verwendung
Abweichende Verwendung des Begriffs
- Cisco und Juniper
Verwenden den Begriff MTU in ihrer Konfigurationssyntax als maximale Rahmen- bzw. Paketgröße der zu konfigurierenden Netzwerkschicht
- Folgende Einstellungen entsprechen einander
- Bei beiden Herstellern bedeutet das erste Auftauchen des Begriffes die maximale Ethernet Rahmengröße und nicht die maximale Größe der Nutzlast (Maximum Segment Size)
- diese muss folglich einige Byte größer gewählt werden als die dann folgenden Einstellungen für die verschiedenen Schicht-3 Protokolle
- Paket- und Rahmengröße
- Unter der "packet size" (Paketgröße) wird fälschlicherweise teils die "frame size" (Rahmengröße) verstanden, jedoch stellt die obige Definition (siehe RFC 1122 und RFC 791) dies eindeutig klar
- Ein Spezialfall liegt vor, wenn ein Schicht-2-Protokoll über ein anderes Schicht-2-Protokoll getunnelt wird, denn dann nennt man auch die Nutzlast selbst "Rahmen" (engl. 'frame')
Path MTU
- Path MTU (PMTU)
Maximale Paketgröße, die entlang der gesamten Wegstrecke übertragen werden kann, ohne einer Fragmentierung zu unterliegen
- Sie ist die kleinsten MTU aller Schicht-2-Teilstücke im Pfad
- Die PMTU kann automatisch durch PMTU Discovery (PMTUD) ermittelt werden
- Beispiel Brief
Das Konzept der MTU auf die Post adaptiert
- Eine MTU 50 g heißt, dass man max. 50 g Inhalt (entspricht der Packet Size) in den Brief einpacken kann
- Der Brief insgesamt kann selbst aber schwerer als 50 g sein, da im Normalfall noch ein Briefumschlag beispielsweise 4 g und eine Briefmarke 0,3 g hinzukommt
- Bezahlt und verschickt wird der ganze Brief von 54,3 g Masse entsprechend der Frame Size
Anwendung
Konfiguration
Dateien
Datei | Beschreibung |
---|---|
IP/Fragmentierung/IPv4
IP/Fragmentierung/IPv6
- Router fragmentieren keine Pakete
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
IPv6/Header/Extension
IPv6/Header/Extension/Fragment - Fragment Header
Beschreibung
Fragment Header wird im vorhergegangenen Header mit dem Wert 44 angezeigt
Feldname | Länge | Inhalt des Feldes |
---|---|---|
Format des Fragment Headers | ||
Next Header | 1 Byte | Erster Header Type des fragmentierbaren Teils des ursprünglichen Pakets |
Reserved | 1 Byte | auf 0 gesetzt |
Fragement Offset | 13 bits | Offset der Daten in 8 Byte Einheiten |
Reserved | 2 bits | auf 0 gesetzt |
M-Flag | 1 bit | 0 -> letztes Paket, 1 -> weitere Pakete |
Identification | 4 Bytes | kennzeichnet den Fragment Set |
Die Fragmentierung erfolgt ausschließlich beim sendenden Host, der vorher mittels Path MTU Discovery die größtmögliche Paketgröße ermittelt hat.
Format
IPv6-Fragmentierung
Trace File
- Letztes Paket des Fragment Sets