IPv6/Header: Unterschied zwischen den Versionen

Version vom 26. Juli 2023, 01:27 Uhr

topic - Kurzbeschreibung

Beschreibung

IPv4 Header

IPv6-Header ist gegenüber IPv4 stark vereinfacht

Enthält nur grundlegende Forwarding-Information
Zusätzliche Informationen in variablen zusätzlichen Erweiterungs-Headern, welche durch das „Next Header“ Feld identifiziert werden
Damit trotz vierfacher IPv6-Adresslänge (16 Byte) nur doppelte Headerlänge

Die folgenden Felder wurden weggelassen

HL

weil der IPv6Header eine feste Länge hat.

Protocol

wurde herausgenommen, weil das Feld Next-Header angibt welches Protokoll auf der Transportschicht verwendet wird.

Alle Felder in Bezug auf Fragmentierung

wurden weggelassen, weil IPv6 Fragmentierung anders handhabt.
IPv6-Router fragmentieren keine Pakete, sondern schicken der Quelle eine Nachricht kleinere Pakete zu schicken.

Checksum

ist verschwunden, weil die Berechnung der Prüfsumme bei jedem Hop sich negativ auf die Performance auswirkte,
und auf den Schichten über und unter der Vermittlungsschicht schon genug Prüfsummen berechnet werden.

Padding

Extension-Prinzip

IPv6-Header ist durch Extension-Prinzip flexibel erweiterbar

Per Hop ausgewertete Header
- Hop-by-Hop Options (z.B. Jumbogramm Notifier)
- Routing Information Header
Nur im Endsystem ausgewertete Header
- Fragmentation Header
- Authetication Header
Header-Extensions u.U. auf Applikationsniveau direkt nutzbar
Die meisten IPv6 Pakete bestehen nur aus IPv6- und TCP Header sowie Daten

Unterschiede IPv4/IPv6

Header-Format

Feste Länge

Bei IPv6 eine feste Länge von 40 Byte (320 Bit)
Im Gegensatz zu IPv4

Extension Headers

Optionale, seltener benutzte Informationen werden in Erweiterungs-Kopfdaten (engl.: Extension Headers) eingebettet
zwischen IPv6-Kopfdatenbereich und der eigentlichen Nutzlast (Payload)

Felder im IPv6-Header

Kopfdaten laut RFC 2460

Feld	Länge	Inhalt
Version	4 Bit	IP-Versionsnummer (6)
Traffic Class	8 Bit	Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe.
Flow Label	20 Bit	Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
Payload Length	16 Bit	Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
Next Header	8 Bit	Identifiziert den Typ des nächsten Kopfdatenbereiches, dieser kann entweder einen Erweiterungs-Kopfdatenbereich (siehe nächste Tabelle) oder ein Protokoll höherer Schicht (engl.: Upper Layer Protocol) bezeichnen, wie z. B. TCP (Typ 6) oder UDP (Typ 17).
Hop Limit	8 Bit	Maximale Anzahl an Zwischenschritten über Router, die ein Paket zurücklegen darf; wird beim Durchlaufen eines Routers („Hops“) um eins verringert. Pakete mit null als Hop Limit werden verworfen. Es entspricht dem Feld Time to Live (TTL) bei IPv4.
Source Address	128 Bit	Adresse des Senders
Destination Address	128 Bit	Adresse des Empfängers

Next Header Werte

IPv6 Header in einem Trace File

IPv4 und IPv6 Header im Vergleich

IPv6 - 12

IPv4 Header Felder

Version

always 4

TOS (type of service)

precedence (3 bits) and “minimize delay”, “maximize throughput”, “maximize reliability”, “minimize cost” bits

Identifier

identifier, different for each packet

TTL

time to live field; initialized to 64; decremented at each router; drop if TTL = 0

Protocol

next header proto (TCP 6, UDP 17)

Header checksum

add together 16-bit words using one’s complement: software optimized

IPv6-Erweiterungsheader

Einige der gestrichenen Felder sind manchmal doch noch notwendig

für diese Fälle sind derzeit 6 Erweiterungsheader definiert,
die benutzt werden um zusätzliche Informationen zu kodieren.
Alle Erweiterungsheader sind optional.
Werden mehrere benutzt müssen sie direkt nach dem Hauptheader erscheinen.

Optionen für Teilstrecken

Dieser Header wird für Informationen benutzt die alle Router auf der Strecke prüfen müssen.
Bisher ist eine Option definiert, die Unterstützung von Jumbogrammen, also Paketen die größer als 64 kByte sind.
Routing

– Mit diesem Header kann eine Route vollständig oder teilweise spezifiziert werden. – Fragmentierung Dieser Header enthält Optionen für die Fragmentierung von Paketen. – Nanu, hatten wir nicht eben gesagt IPv6 fragmentiert nicht? Im Prinzip ja. – Der Quellhost darf Pakete immer noch fragmentieren. – Nur die Router auf der Strecke sind nicht mehr dazu berechtigt.

Authentifikation

– Der Authentifizierungsheader bietet einen Mechanismus, durch den der Empfänger sicher sein kann, das der in der Adresse angegebene Sender auch tatsächlich der ist, der er behauptet zu sein.

Verschlüsselte Sicherheitsdaten

– Dieser Header enthält Informationen über das verwendete Verschlüsselungsverfahren.

Optionen für Ziele

Dieser Header ist für Optionen vorgesehen, die nur vom Zielhost interpretiert werden müssen.
Er wird derzeit nicht benutzt.

Optionale Erweiterungsheader

IPv6 - 16

IPv6 - 17

Extension Headers

Die meisten IPv6-Pakete sollten ohne Extension Headers auskommen

Extension Headers können bis auf den Destination Options Header nur einmal in jedem Paket vorkommen
Befindet sich ein Routing Extension Header im Paket, so darf davor ein weiterer Destination Options Header stehen
Die Reihenfolge bei einer Verkettung ist bis auf die genannte Ausnahme die der folgenden Tabelle
Wie im Next Header Feld verwiesen sind einige Extension Headers und ein Platzhalter definiert

Extension Headers

Name	Typ	Größe	Beschreibung	RFCs
Hop-By-Hop Options	0	variabel	Optionenvon allen IPv6-Geräten zu beachtenwird z.B. für Jumbograms benutzt	RFC 2460RFC 2675
Routing	43	variabel	Hier kann der Weg des Paketes durch das Netzwerk beeinflusst werdenwird u.a. für Mobile IPv6 verwendet	RFC 2460RFC 6275RFC 5095
Fragment	44	64 Bit	Parameter zur Fragmentierung	RFC 2460
Authentication Header (AH)	51	variabel	Daten zur Vertraulichkeit (IPsec)	RFC 4302
Encapsulating Security Payload (ESP)	50	variabel	Daten zur Verschlüsselung (IPsec)	RFC 4303
Destination Options	60	variabel	Optionennur vom Zielrechner zu beachten	RFC 2460
Mobility	135	variabel	Daten für Mobile IPv6	RFC 6275
No Next Header	59	leer	Platzhalterzeigt Ende eines Header-Stapels an	RFC 2460

Verwendung von Extension Headers

Reihenfolge der Extension Header

1) IPv6 Header 2) Hop-by-Hop Options Header (für Optionen, welche von Routern auf dem Pfad zum endgültigen Empfänger verarbeitet werden müssen) 3) Routing Header 4) Fragment Header 5) Authentication Header 6) Encapsulating Security Payload Header 7) Destination Options Header (für Optionen, welche vom endgültigen Empfänger des Paketes verarbeitet werden müssen) 8) Upper-Layer Header

Extension Headers

Next-Header

Alle Extension Headers enthalten ein Next-Header-Feld, in dem
der nächste Extension Header oder
das Upper Layer Protocol genannt wird
Größen immer Vielfache von 64 Bit
Speicherzugriffe im Router beschleunigen
die meisten Felder der Kopfdatenbereiche sind auf 64-Bit-Grenzen ausgerichtet

Keine Prüfsummen

Es werden keine Prüfsummen über die IP-Kopfdaten berechnet
im Gegensatz zu IPv4
Fehlerkorrektur auf Schichten 2 und 4

Format des Hop-by-Hop Options Headers

Format des Routing Headers

Maximum Transmission Unit (MTU)

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 Sicherungsschicht-Header

Maximum Transmission Unit (MTU)

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 (z. B. 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

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').

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 (z. B. DSL)	≤ 1492
SLIP/PPP (low delay)	296
X.25	576
FibreChannel	theoretisch unbegrenzt
ISDN	576
ATM	4500
802.11	2312 (WiFi)

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 ist verständlicher.
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 z.B. 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.

Beispiel Ethernet

Ethernetrahmen bestehen aus zwei Teilen

dem „Header“, in dem Quell- und Zieladressen und andere wichtige Parameter für den Versand kodiert sind, und der Nutzlast, deren Größe durch die MTU bestimmt ist.
In diesem Versuch ist die Größe der MTU mit 1500 Byte vorgegeben.
Mit Hilfe des ping-Programmes wird ein „Frame“ erzeugt, der dann im Netzwerk über das Ethernet-Protokoll versendet wird.
Die Verwendung des Begriffes Nutzlast ist hier mehrdeutig, da im OSI-Modell die verschiedenen Protokolle ineinander eingepackt (gekapselt) werden.

ping -s 1472 10.0.0.1 (Windows-Befehl ping -l 1472 10.0.0.1)

sendet ein ICMP-Paket mit der Nutzlast von 1472 Bytes an die IP-Adresse 10.0.0.1.

ping -f -l 1472 10.0.0.1
1472 bytes Nutzlast des ICMP-Protokolles (Transportschicht)
+ 8 bytes ICMP-Header (Transportschicht)
+ 20 bytes IPv4-Header (der Vermittlungsschicht)
-------------
= 1500 bytes (Nutzlast von Ethernet)
+ 14 bytes (Header der Sicherungsschicht)
+ 4 bytes (Frame Check Sequence)
-------------
= 1518 bytes (kompletter Ethernetrahmen)

Beispiel Ethernet

Mit einem Sniffer (wie Wireshark)

wird als Ethernet Header nur die Größe von 14 Byte angezeigt.
Hierzu kommt noch die 4 Byte große Frame Check Sequence am Ende des Frames.

Falls VLANs verwendet werden

besteht der Header der Sicherungsschicht aus 18 Byte
der gesamte Ethernetrahmen kann eine Größe von bis zu 1522 Byte annehmen

Würde IPv6 verwendet

änderte sich obige Berechnung dahingehend, dass der IPv6-Header der Vermittlungsschicht 40 statt 20 Byte beträgt und damit statt 1472 Byte ICMP-Nutzlast nur 1452 Byte möglich wären.
Oft ist es hilfreich dem ping-Programm vorzugeben das „don’t fragment (DF) bit“ für die Testpakete im IPv4-Header zu setzen,

für Linux z. B.

ping -M do -s 1472 10.0.0.1

für Windows

ping -l 1472 -f 10.0.0.1

denn dann erhält man eine Nachricht, falls die MTU überschritten wird.
Leicht sichtbar machen lässt sich die Path MTU mit dem Programm tracepath für IPv4 bzw. tracepath6 für IPv6.

Jumbo Frames für Gigabit Ethernet

Jumbo Frames können deutlich mehr als 1518 Oktette beinhalten

und damit ist es möglich, größere Pakete unfragmentiert zu übertragen

Positiv

wiegt, dass der Protokoll-Overhead bei der Verwendung von Jumbo Frames reduziert werden kann und Router weniger Pakete behandeln müssen.

Allerdings

ist die Terminologie bzgl. MTU derart uneinheitlich unter den Herstellern, dass es in der Praxis schwierig ist, von den Standardeinstellungen abzuweichen.

Jumbo Frames sind nicht im IEEE-802.3-Standard spezifiziert

trotzdem unterstützen die meisten Hersteller von Gigabit Ethernet Switches und Routern MTUs bis 9000 Oktette.

Quasistandard eine Path MTU um ca. 1500 Byte

So hat sich als Quasistandard eine Path MTU um ca. 1500 Byte im Internet eingebürgert, die durch das weit verbreitete Fast Ethernet sowieso meist nicht überschritten werden kann.

Jumbo Frames für Gigabit Ethernet

Tunnelprotokolle

Mit dem Aufkommen von Internetzugängen, die auf Tunnelprotokollen basieren, zum Beispiel beim Verbindungsaufbau über das PPPoE-Protokoll hat die MTU an Bedeutung gewonnen.
Obwohl die PMTUD in diesem Fall dafür sorgen soll, dass die Kommunikation trotz der durch den Tunnel abgesenkten MTU möglich ist, gibt es immer wieder fehlkonfigurierte Firewalls, die durch Verwerfen von ICMP-Steuerpaketen die PMTUD stören.
Auch große Websites sind oft von diesem Konfigurationsfehler betroffen, sodass die Nutzer von getunnelten Zugängen die MTU ihrer Geräte verkleinern müssen, um auch mit diesen Sites kommunizieren zu können.

Optimale MTU

Diskussionen über die optimale MTU

Einfache Optimierung

So groß wie möglich, ohne dass Probleme auftreten

Komplexe Optimierung

so viel kleiner als o. g. Maximum, dass der Verschnitt der Transportzellen der unter der DSL-Schicht liegenden ATM-Transportschicht möglichst klein wird.

Oder: Einfach probieren

Die MTU bei ATM (4500) ist nicht zu verwechseln mit der Zellengröße (53 Bytes, 48 davon Nutzlast).
Bei der Übertragung über einen ATM-Link werden IP-Pakete in Stücke zu je 48 Bytes zerlegt und für die Übertragung auf mehrere ATM-Zellen verteilt.
Der Router am anderen Ende des ATM-Links sammelt diese Zellen und setzt das ursprüngliche IP-Paket wieder zusammen.
Im Gegensatz dazu wird bei der IP-Fragmentierung das Paket nicht vom Router reassembliert, sondern erst von dem Host, für den das Paket bestimmt war.
Probleme, die durch einen falschen MTU-Wert auftreten können, sind Webseiten, die gar nicht oder nur teilweise angezeigt werden.

Paketgrößen

MTU und PMTU

Die Maximum Transmission Unit (MTU) darf in einem IPv6-Netzwerk 1280 Byte nicht unterschreiten.
Somit unterschreitet auch die Path MTU (PMTU) diesen Wert nicht und es können Pakete bis zu dieser Größe garantiert ohne Fragmentierung übertragen werden.
Minimale IPv6-Implementierungen verlassen sich auf diesen Fall.
Ein IPv6-fähiger Rechner muss in der Lage sein, aus Fragmenten wieder zusammengesetzte Pakete mit einer Größe von mindestens 1500 Byte zu empfangen.
Für IPv4 beträgt dieser Wert nur 576 Byte.
Im anderen Extrem darf ein IPv6-Paket auch fragmentiert laut Payload-Length-Feld im IPv6-Header die Größe von 65.575 Byte einschließlich Kopfdaten nicht überschreiten, da dieses Feld 16 Bit lang ist (216 − 1 Byte zzgl. 40 Byte Kopfdaten).

Jumbograms

RFC 2675 stellt aber über eine Option des Hop-by-Hop Extension Headers die Möglichkeit zur Verfügung, Pakete mit Größen bis zu 4.294.967.335 Byte, sogenannte Jumbograms zu erzeugen.
Dies erfordert allerdings Anpassungen in Protokollen höherer Schichten, wie z. B. TCP oder UDP, da diese oft auch nur 16 Bit für Größenfelder definieren, außerdem muss bei jedem Paket, welches einen Jumbogram beinhaltet, im IPv6-Header die Payload-Length auf 0 gesetzt werden.