Zum Inhalt springen

IPv6/Header: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
K Textersetzung - „Obsoleted by“ durch „Ersetzt durch“
 
(307 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' - Kurzbeschreibung
'''IPv6/Header''' - Aufbau des Protokollkopfes von [[IPv6]]
== Beschreibung ==
== IPv4 Header ==
[[File:ipv4Ipv6Heaser.png|800px]]


– IPv6-Header ist gegenüber IPv4 stark vereinfacht
=== Beschreibung ===
• Enthält nur grundlegende Forwarding-Information
; IPv6-Header hat eine feste Größe von 40 Byte (320 Bit)
• Zusätzliche Informationen in variablen zusätzlichen Erweiterungs-Headern,
* [[IPv4/Header]] hat eine variable Größe
welche durch das „Next Header“ Feld identifiziert werden
• Damit trotz vierfacher IPv6-Adresslänge (16 Byte) nur doppelte Headerlänge


[[File:img-003-000.png|600px]]
Trotz vierfacher IPv6-Adresslänge (16 Byte) nur doppelte Headerlänge


== Die folgenden Felder wurden weggelassen ==
=== IPv6 Header ===
{{:IPv6/Header/Format}}
[[IPv6/Header/Format]]


HL
=== Header-Felder ===
● weil der IPv6Header eine feste Länge hat.
{| class="wikitable options big col2center"
|-
! Feld !! Länge (bit) !! Inhalt
|-
| | Version
| | 4
| | IP-Versionsnummer (6)
|-
| | Traffic Class
| | 8
| | Quality of Service (QoS) Priorisierung ([[RFC/2474|RFC/2474]])
|-
| | Flow Label
| | 20
| | Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
|-
| | Payload Length
| | 16
| | Länge der Daten nach dem IPv6 Header; Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
|-
| | Next Header
| | 8
| | 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).
Protokoll Nummer oder Extension-Header
|-
| | Hop Limit
| | 8
| | 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.
Anzahl der Routerhops
|-
| | Source Address
| | 128
| | Adresse des Senders
|-
| | Destination Address
| | 128
| | Adresse des Empfängers
|-
|Summe (bit)
|'''360'''
|}


Protocol
=== Vereinfachung des Headers ===
● wurde herausgenommen, weil das Feld Next-Header angibt welches Protokoll auf der
; Enthält nur grundlegende Forwarding-Information
Transportschicht verwendet wird.
Zusätzliche Informationen in [[Erweiterungs-Header]]n
* In "[[#Next Header]]" angegeben


Alle Felder in Bezug auf Fragmentierung
==== Header im Vergleich ====
● wurden weggelassen, weil IPv6 Fragmentierung anders handhabt.
[[File:img-013-007.png|900px]]
● IPv6-Router fragmentieren keine Pakete, sondern schicken der Quelle eine Nachricht kleinere
Pakete zu schicken.


Checksum
==== Entfallene Felder ====
● ist verschwunden, weil die Berechnung der Prüfsumme bei jedem Hop sich negativ auf die
{| class="wikitable options big"
Performance auswirkte,
|-
● und auf den Schichten über und unter der Vermittlungsschicht schon genug Prüfsummen
! Option !! Beschreibung
berechnet werden.
|-
 
| [[HL]] || IPv6Header eine feste Länge hat
Padding
|-
 
| [[Protocol]] || Feld Next-Header angibt welches Protokoll auf der Transportschicht verwendet wird.
== Extension-Prinzip ==
|-
[[File:ipv6HeaderExtension.png|mini|300px]]
| Felder zur</br>[[IP/Fragmentierung]] || IPv6 Fragmentierung wird anders handhabt, IPv6-Router fragmentieren keine Pakete, sondern schicken der Quelle eine Nachricht kleinere Pakete zu schicken.
; IPv6-Header ist durch Extension-Prinzip flexibel erweiterbar
|-
* Per Hop ausgewertete Header
| [[Checksum]] || die Berechnung der Prüfsumme bei jedem Hop sich negativ auf die Performance auswirkt, auf den Schichten über und unter der Vermittlungsschicht werden bereits Prüfsummen berechnet
** Hop-by-Hop Options (z.B. Jumbogramm Notifier)
|-
** Routing Information Header
| [[Padding]] ||
* 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 ==
[[File:img-006-001.png|800px]]
 
== IPv6 - 6 ==
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 ==
[[File:img-008-002.png|800px]]
 
== Kopfdaten laut RFC 2460 ==
 
{| style="border-spacing:0;margin:auto;width:17cm;"
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Feld
|| Länge
|| Inhalt
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Version
|| 4&nbsp;Bit
|| IP-Versionsnummer (6)
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Traffic&nbsp;Class
|| 8&nbsp;Bit
|| Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe.
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Flow&nbsp;Label
|| 20&nbsp;Bit
|| Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Payload&nbsp;Length
|| 16&nbsp;Bit
|| Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Next&nbsp;Header
|| 8&nbsp;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.&nbsp;B. TCP (Typ 6) oder UDP (Typ 17).
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Hop&nbsp;Limit
|| 8&nbsp;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.
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Source&nbsp;Address
|| 128&nbsp;Bit
|| Adresse des Senders
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Destination&nbsp;Address
|| 128&nbsp;Bit
|| Adresse des Empfängers
|}
|}


== Next Header Werte ==
<noinclude>
[[File:img-010-003.png|600px]]
[[File:img-010-004.png|600px]]


== IPv6 Header in einem Trace File ==
=== Next Header ===
[[File:img-011-005.png|800px]]
{| class="wikitable options col1center big"
 
! Werte !! Beschreibung
== IPv4 und IPv6 Header im Vergleich ==
|-
[[File:img-012-006.png|800px]]
| 0 ||in IPv4 reserviert und nicht benutzt
 
|-
== IPv6 - 12 ==
| 1 || |[[ICMP]] IPv4
[[File:img-013-007.png|800px]]
|-
 
| 2 || |[[IGMP]] IPv4
== IPv4 Header Felder ==
|-
 
| 4 || IP in IP encapsulation
Version
|-
● always 4
| 6 || |[[TCP]]
 
|-
TOS (type of service)
| 8 || |[[EGP]]
● precedence (3 bits) and “minimize delay”, “maximize throughput”, “maximize reliability”,
|-
“minimize cost” bits
| 9 || |[[IGP]] (Cisco [[IGRP]])
 
|-
Identifier
| 17 || |[[UDP]]
● identifier, different for each packet
|-
 
| 41 || IPv6
TTL
|-
● time to live field; initialized to 64; decremented at each router; drop if TTL = 0
| 43 || |Routing Header
 
|-
Protocol
| 44 || |Fragmentation Header
● next header proto (TCP 6, UDP 17)
|-
 
| 45 || [[IDRP]]
Header checksum
|-
● add together 16-bit words using one’s complement: software optimized
| 46 || |[[RSVP]]
 
|-
== IPv6-Erweiterungsheader ==
| 47 || [[GRE]]
 
|-
Einige der gestrichenen Felder sind manchmal doch noch notwendig
| 50 || |Encryted Security Payload Header
● für diese Fälle sind derzeit 6 Erweiterungsheader definiert,
|-
● die benutzt werden um zusätzliche Informationen zu kodieren.
| 51 || Authentication Header
● Alle Erweiterungsheader sind optional.
|-
● Werden mehrere benutzt müssen sie direkt nach dem Hauptheader erscheinen.
| 58 || ICMPv6
 
|-
Optionen für Teilstrecken
| 59 || No Next Header für IPv6
● 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
| 60 || |Destination Options Header
sind.
|-
● Routing
| 88 || [[EIGRP]] v4 und EIGRPv6
– Mit diesem Header kann eine Route vollständig oder teilweise spezifiziert werden.
|-
– Fragmentierung Dieser Header enthält Optionen für die Fragmentierung von Paketen.
| 89 || [[OSPF]]
– Nanu, hatten wir nicht eben gesagt IPv6 fragmentiert nicht? Im Prinzip ja.
|-
– Der Quellhost darf Pakete immer noch fragmentieren.
| 108 || IP Payload Compression Protocol
– Nur die Router auf der Strecke sind nicht mehr dazu berechtigt.
|-
● Authentifikation
| 115 || [[L2TP]]
– 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.
| 132 || [[SCTP]]
● Verschlüsselte Sicherheitsdaten
|-
– Dieser Header enthält Informationen über das verwendete Verschlüsselungsverfahren.
| 135 || Mobility Header (Draft)
 
|-
Optionen für Ziele
| 136-252 || nicht zugewiesen
● Dieser Header ist für Optionen vorgesehen, die nur vom Zielhost interpretiert werden müssen.
|-
● Er wird derzeit nicht benutzt.
| 253-254 || Experimente und Testzwecke
 
== Optionale Erweiterungsheader ==
[[File:img-016-008.png|800px]]
 
== IPv6 - 16 ==
[[File:img-017-009.png|800px]]
 
== IPv6 - 17 ==
[[File:img-018-010.png|800px]]
 
== 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 ==
{| style="border-spacing:0;margin:auto;width:17cm;"
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| '''Name'''
|| '''Typ'''
|| '''Größe'''
|| '''Beschreibung'''
|| '''RFCs'''
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Hop-By-Hop Options
|| 0
|| variabel
|| Optionenvon allen IPv6-Geräten zu beachtenwird z.B. für Jumbograms benutzt
|| RFC 2460RFC 2675
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| 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
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Fragment
|| 44
|| 64&nbsp;Bit
|| Parameter zur Fragmentierung
|| RFC 2460
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Authentication Header (AH)
|| 51
|| variabel
|| Daten zur Vertraulichkeit (IPsec)
|| RFC 4302
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Encapsulating Security Payload (ESP)
|| 50
|| variabel
|| Daten zur Verschlüsselung (IPsec)
|| RFC 4303
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Destination Options
|| 60
|| variabel
|| Optionennur vom Zielrechner zu beachten
|| RFC 2460
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Mobility
|| 135
|| variabel
|| Daten für Mobile IPv6
|| RFC 6275
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| No Next Header
|| 59
|| leer
|| Platzhalterzeigt Ende eines Header-Stapels an
|| RFC 2460
|-
|-
| 255 || Reserviert
|}
|}


== Verwendung von Extension Headers ==
=== Trace Files ===
[[File:img-021-011.png|600px]]
; IPv4 und IPv6 Header im Vergleich
[[File:img-012-006.png|950px]]


== Reihenfolge der Extension Header ==
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
* [[Maximum Transmission Unit]]
* [[IPv4/Header/Format]]


1) IPv6 Header
=== Dokumentation ===
2) Hop-by-Hop Options Header (für Optionen, welche von Routern auf dem Pfad zum endgültigen Empfänger verarbeitet werden müssen)
==== RFC ====
3) Routing Header
{| class="wikitable big options col1center col3center"
4) Fragment Header
|-
5) Authentication Header
! RFC !! Titel !! Date !! Status
6) Encapsulating Security Payload Header
|-
7) Destination Options Header (für Optionen, welche vom endgültigen Empfänger des Paketes verarbeitet werden müssen)
| [https://www.rfc-editor.org/info/2460 2460] || Internet Protocol, Version 6 (IPv6) Specification || 1998 || Ersetzt durch [https://www.rfc-editor.org/info/rfc8200 RFC 8200]
8) Upper-Layer Header
|-
 
| [https://www.rfc-editor.org/info/rfc8200 8200] || Internet Protocol, Version 6 (IPv6) Specification || 2017 || Updated by [https://www.rfc-editor.org/info/rfc9673 RFC 9673]
== IPv6 - 22 ==
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 ==
[[File:img-024-012.png|700px]]
 
== Format des Routing Headers ==
[[File:img-025-013.png|700px]]
 
== Maximum Transmission Unit (MTU) ==
 
Beschreibt die 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 ==
{| style="border-spacing:0;margin:auto;width:17cm;"
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| '''Medium'''
|| '''MTU in Bytes'''
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Hyperchannel
|| 65535
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Token Ring(4)(802.5)
|| 4464
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Token Ring(16)
|| 17914
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| FDDI
|| 4352
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Ethernet
|| 1500
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| Gigabit Ethernet mit Jumboframes
|| 9000
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| PPPoE (z.&nbsp;B. DSL)
|| ≤ 1492
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| SLIP/PPP (low delay)
|| 296
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| X.25
|| 576
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| FibreChannel
|| theoretisch unbegrenzt
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| ISDN
|| 576
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| ATM
|| 4500
|- style="border:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.053cm;padding-right:0.053cm;"
|| 802.11
|| 2312 (WiFi)
|-
|-
| [https://www.rfc-editor.org/info/rfc9673 9673] || IPv6 Hop-by-Hop Options Processing Procedures || 2024 || [[Proposed Standard]]
|}
|}


== Path MTU (PMTU) ==
=== Links ===
 
==== Weblinks ====
Path MTU (PMTU)
● beschreibt die 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 z. B. 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.
 
== Format des Fragment Headers ==
[[File:img-036-014.png|600px]]
 
== Fragmentierung mit IPv6 ==
[[File:img-037-015.png|600px]]
 
== Der Fragment Header in einem Trace File ==
[[File:img-038-016.png|400px]]
 
== Letztes Paket des Fragment Sets ==
[[File:img-039-017.png|400px]]
 
== Format des Destination Options Headers ==
[[File:img-040-018.png|400px]]
 
<noinclude>
 
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Dokumentation ====
==== Links ====
===== Projekt =====
===== Weblinks =====


[[Kategorie:IPv6/Header]]
[[Kategorie:IPv6/Header]]


</noinclude>
</noinclude>

Aktuelle Version vom 5. Juli 2025, 09:15 Uhr

IPv6/Header - Aufbau des Protokollkopfes von IPv6

Beschreibung

IPv6-Header hat eine feste Größe von 40 Byte (320 Bit)

Trotz vierfacher IPv6-Adresslänge (16 Byte) nur doppelte Headerlänge

IPv6 Header

00-03 04-07 08-11 12-15 16-19 20-23 24-27 28-31
Version Traffic Class Flow Label H
e
a
d
e
r
Payload Length Next Header Hop Limit
Source-Address
Destination-Address

Payload


IPv6/Header/Format

Header-Felder

Feld Länge (bit) Inhalt
Version 4 IP-Versionsnummer (6)
Traffic Class 8 Quality of Service (QoS) Priorisierung (RFC/2474)
Flow Label 20 Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
Payload Length 16 Länge der Daten nach dem IPv6 Header; Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
Next Header 8 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).

Protokoll Nummer oder Extension-Header

Hop Limit 8 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.

Anzahl der Routerhops

Source Address 128 Adresse des Senders
Destination Address 128 Adresse des Empfängers
Summe (bit) 360

Vereinfachung des Headers

Enthält nur grundlegende Forwarding-Information

Zusätzliche Informationen in Erweiterungs-Headern

Header im Vergleich

Entfallene Felder

Option Beschreibung
HL IPv6Header eine feste Länge hat
Protocol Feld Next-Header angibt welches Protokoll auf der Transportschicht verwendet wird.
Felder zur
IP/Fragmentierung		 IPv6 Fragmentierung wird anders handhabt, IPv6-Router fragmentieren keine Pakete, sondern schicken der Quelle eine Nachricht kleinere Pakete zu schicken.
Checksum die Berechnung der Prüfsumme bei jedem Hop sich negativ auf die Performance auswirkt, auf den Schichten über und unter der Vermittlungsschicht werden bereits Prüfsummen berechnet
Padding


Next Header

Werte Beschreibung
0 in IPv4 reserviert und nicht benutzt
1 ICMP IPv4
2 IGMP IPv4
4 IP in IP encapsulation
6 TCP
8 EGP
9 IGP (Cisco IGRP)
17 UDP
41 IPv6
43 Routing Header
44 Fragmentation Header
45 IDRP
46 RSVP
47 GRE
50 Encryted Security Payload Header
51 Authentication Header
58 ICMPv6
59 No Next Header für IPv6
60 Destination Options Header
88 EIGRP v4 und EIGRPv6
89 OSPF
108 IP Payload Compression Protocol
115 L2TP
132 SCTP
135 Mobility Header (Draft)
136-252 nicht zugewiesen
253-254 Experimente und Testzwecke
255 Reserviert

Trace Files

IPv4 und IPv6 Header im Vergleich

Anhang

Siehe auch

Dokumentation

RFC

RFC Titel Date Status
2460 Internet Protocol, Version 6 (IPv6) Specification 1998 Ersetzt durch RFC 8200
8200 Internet Protocol, Version 6 (IPv6) Specification 2017 Updated by RFC 9673
9673 IPv6 Hop-by-Hop Options Processing Procedures 2024 Proposed Standard

Links

Weblinks


Abgerufen von „https://wiki.foxtom.de/index.php?title=IPv6/Header&oldid=148797“