IPv6/Header: Unterschied zwischen den Versionen

Aus Foxwiki
Subpages:
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
K Textersetzung - „</abbr>“ durch „]] “
 
(196 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== IPv6 - 1 ==
'''IPv6/Header'''
IPv4 Header


Ver HL TOS Length Ver Pri. Flow Label
== Beschreibung ==
ID Offset/Frag.
Definiert im [[RFC]] 2460
Length Nxt. Hdr. Hop L.
; Feste Größe
TTL Proto Checksum
* 40 Bytes
24 Byte 48 Byte
* davon je 16 Bytes für Absender- und Empfängeradresse
  Source Address Source Address


  Dest. Address
== Header-Format ==
Dest. Address
Options Padd.


  – IPv6-Header ist gegenüber IPv4 stark vereinfacht
==== Feste Länge ====
• Enthält nur grundlegende Forwarding-Information
Bei IPv6 eine feste Länge von 40&nbsp;Byte (320&nbsp;Bit)
• Zusätzliche Informationen in variablen zusätzlichen Erweiterungs-Headern,
* Im Gegensatz zu IPv4 hat der IP-Kopfdatenbereich (Header)
welche durch das „Next Header“ Feld identifiziert werden
• Damit trotz vierfacher IPv6-Adreßlänge (16 Byte) nur doppelte Headerlänge


== IPv6 - 2 ==
==== Extension Headers  ====
IPv6 - Einführung Dirk Wagner Berlin III - 3
Die folgenden Felder wurden weggelassen


HL
Optionale, seltener benutzte Informationen werden in so genannten Erweiterungs-Kopfdaten (engl.: Extension Headers) eingebettet * zwischen dem IPv6-Kopfdatenbereich und der eigentlichen Nutzlast (engl. Payload)
● 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
=== Header-Felder ===
  ● ist verschwunden, weil die Berechnung der Prüfsumme bei jedem Hop sich negativ auf die
; Kopfdatenbereich nach RFC 2460
  Performance auswirkte,
{| class="wikitable options big"
  ● und auf den Schichten über und unter der Vermittlungsschicht schon genug Prüfsummen
|-
  berechnet werden.
|-
! Feld !! Länge !! Inhalt
|-
|  | Version
|  | 4&nbsp;Bit
|  | IP-Versionsnummer (6)
|-
|  | Traffic&nbsp;Class
|  | 8&nbsp;Bit
|  | Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe.
|-
|  | Flow&nbsp;Label
|  | 20&nbsp;Bit
| | Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
|-
|  | Payload&nbsp;Length
|  | 16&nbsp;Bit
|  | Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
|-
|  | 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).
|-
|  | 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.
|-
|  | Source&nbsp;Address
|  | 128&nbsp;Bit
|  | Adresse des Senders
|-
|  | Destination&nbsp;Address
|  | 128&nbsp;Bit
|  | Adresse des Empfängers


Padding


== IPv6 - 4 ==
|-
IPv6-Header
|}
Extension-Prinzip


  IPv6-Header ist durch Extension-
=== Extension Headers ===
Prinzip flexibel erweiterbar
[[IPv6/Header/Extension]]
● Per Hop ausgewertete Header
Ver Pri. Flow Label
– Hop-by-Hop Options
(z.B. Jumbogramm Notifier) Length Nxt. Hdr.: 0. Hop Limit
– Routing Information Header
Source Address
● Nur im Endsystem ausgewertete Header
– Fragmentation Header
Dest. Address
– Authetication Header
● Header-Extensions u.U. auf Nxt. Hdr.: 43 Hdr. Length
Applikationsniveau direkt nutzbar Hop-by-Hop Options
● Die meisten IPv6 Pakete werden nur aus
Nxt. Hdr.: 44
IPv6- und TCP Header sowie Daten Hdr. Length


bestehen Routing Information
== Vereinfachung des Headers ==
[[File:img-006-001.png]]


Nxt. Hdr.: 51 Reserved Fragment Offset M
; Enthält nur grundlegende Forwarding-Information
* Zusätzliche Informationen in variablen zusätzlichen Erweiterungs-Headern, welche durch das „Next Header“ Feld identifiziert werden
* Trotz vierfacher IPv6-Adresslänge (16 Byte) nur doppelte Headerlänge


Fragment Identification
=== IPv6 (Felder)===
{|
! style="text-align:center !important; font-weight: normal;" "width="3%"| Byte/Bin
! width="12%"| 00–03
! width="12%"| 04–07
! width="17%"| 08–11
! width="15%"| 12–15
! width="12%"| 16-19
! width="12%"| 20–23
! width="12%"| 24–27
! width="12%"| 28–31
|-
| 01
| style="background-color:#d6c4ff;" colspan="1"| [[IPv6/Header#Version|Version]]
| style="background-color:#dfffcb;" colspan="2"| [[IPv6/Header#Traffic Class|Traffic Class]]
| style="background-color:#ffbfc0;" colspan="5"| [[IPv6/Header#Flow Label|Flow Label]]
! style="text-align:center !important; font-weight: normal;" "width="3%" rowspan="4"| H</br>e</br>a</br>d</br>e</br>r
|-
| 02
| style="background-color:#fff1b0;" colspan="4"| [[IPv6/Header#Payload Length|Payload Length]]
| style="background-color:#d6c4ff;" colspan="2"| [[IPv6/Header#Next Header|Next Header]]
| style="background-color:#fff1b0;" colspan="2"| [[IPv4/Header#Hop Limit|Hop Limit]]
|-
| 03 - 06
|style="background-color:#d1ffac;" colspan="8" | Quell-IP-Adresse
|-
| 07 - 10
|style="background-color:#ffbfc0;" colspan="8"| Ziel-IP-Adresse
|-
| 11+
| style="background-color:#d9e4ff;" colspan="8" | [[IPv6/Header#Payload|Payload]]
|}


Nxt. Hdr.: 6 Hdr. Length
=== IPv4 Header Felder ===
{| class="wikitable big options"
|-
! Option !! Beschreibung
|-
| 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
|}


Authentication Data
=== Entfallene Felder ===
{| class="wikitable big options"
|-
! Option !! Beschreibung
|-
| 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 || entfernt, weil 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 ||
|}


TCP Header und Daten
== 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)


== IPv6 - 5 ==
=== Kopfdaten ===
IPv6
; Kopfdaten laut RFC 2460
{| class="wikitable big options"
|-
! Feld
! Länge
! Inhalt
|-
|| Version
|| 4&nbsp;Bit
|| IP-Versionsnummer (6)
|-
|| Traffic&nbsp;Class
|| 8&nbsp;Bit
|| Für Quality of Service (QoS) verwendeter Wert. Eine Art Prioritätsvergabe.
|-
|| Flow&nbsp;Label
|| 20&nbsp;Bit
|| Ebenfalls für QoS oder Echtzeitanwendungen verwendeter Wert. Pakete, die dasselbe Flow Label tragen, werden gleich behandelt.
|-
|| Payload&nbsp;Length
|| 16&nbsp;Bit
|| Länge des IPv6-Paketinhaltes (ohne Kopfdatenbereich, aber inklusive der Erweiterungs-Kopfdaten) in Byte
|-
|| 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).
|-
|| 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.
|-
|| Source&nbsp;Address
|| 128&nbsp;Bit
|| Adresse des Senders
|-
|| Destination&nbsp;Address
|| 128&nbsp;Bit
|| Adresse des Empfängers
|}


== IPv6 - 6 ==
== IPv6 Header in einem Trace File ==
Header-Format
[[File:img-011-005.png|800px]]


Feste Länge
== IPv4 und IPv6 Header im Vergleich ==
● Bei IPv6 eine feste Länge von 40 Byte (320 Bit)
[[File:img-012-006.png|800px]]
● 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)


== IPv6 - 7 ==
[[File:img-013-007.png|800px]]
Felder im IPv6-Header


== IPv6 - 8 ==
== IPv6-Erweiterungsheader ==
Kopfdatenbereich eines IPv6-Paketes laut RFC 2460
[[IPv6/Header/Erweiterungsheader]]


Feld Länge Inhalt
== Maximum Transmission Unit (MTU) ==
Version 4 Bit IP-Versionsnummer (6)
[[Maximum Transmission Unit]]
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
<noinclude>
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


== IPv6 - 9 ==
== Der IPv6 Header ==
Next Header Werte
=== Die Felder im IPv6 Header ===
{| class="wikitable big"
!Feldname
!Länge
!Inhalt des Feldes
|-
| colspan="3" |Die Felder im IPv6 Header
|-
|Version
|4 bits
|6 (0110, 0x6)
|-
|Traffic Class
|1 Byte
|Priorisierung (s. <nowiki>RFC 2474</nowiki>)
|-
|Flow Label
|20 bits
|für gleichartige Pakete -> effizientes Routing
|-
|Payload Length
|2 Bytes
|Länge der Daten nach dem IPv6 Header
|-
|Next Header
|1 Byte
|Protokoll Nummer oder Extension-Header
|-
|Hop Limit
|1 Byte
|Anzahl der Routerhops
|-
|Quelladresse
|16 Bytes
|
|-
|Zieladresse
|16 Bytes
|endgültiger Empfänger [[bzw.]]  Adresse des nächsten Hops ([[z.B.]]  wenn ein Routing Header vorhanden ist)
|-
!Summe der Bytes
!40
|
|}


== IPv6 - 10 ==
; Die aktuelle Liste aller Protokoll- und Headerwerte findet man bei der IANA.
IPv6 Header in einem Trace File
{| class="wikitable big"
!Wert
!Beschreibung
|-
| colspan="2" |Next Header Werte
|-
|0 (0, 0x0)
|in IPv4 reserviert und nicht benutzt
in IPv6 Hop-by-Hop Option   Header
|-
|1 (0001, 0x1)
|[[ICMP]]  IPv4
|-
|2 (0010, 0x2)
|[[IGMP]] IPv4
|-
|4 (0100, 0x4)
|IP in IP encapsulation
|-
|6 (0110, 0x6)
|[[TCP]]
|-
|8 (1000, 0x8)
|[[EGP]]
|-
|9 (1001, 0x9)
|[[IGP]]  (Cisco [[IGRP]] )
|-
|17 (0001 0001, 0x11)
|[[UDP]]
|-
|41 (0010 1001, 0x29)
|IPv6
|-
|43 (0010 1011, 0x2B)
|Routing Header
|-
|44 (0010 1100, 0x2C)
|Fragmentation Header
|-
|45 (0010 1101, 0x2D)
|[[IDRP]]
|-
|46 (0010 1110, 0x2E)
|[[RSVP]]
|-
|47 (0010 1111, 0x2F)
|[[GRE]]
|-
|50 (0011 0010, 0x32)
|Encryted Security Payload Header
|-
|51 (0011 0011, 0x33)
|Authentication Header
|-
|58 (0011 1010, 0x3A)
|ICMPv6
|-
|59 (0011 1011, 0x3B)
|No Next Header für IPv6
|-
|60 (0011 1100, 0x3C)
|Destination Options Header
|-
|88 (0101 1000, 0x58)
|[[EIGRP]] v4 und EIGRPv6
|-
|89 (0101 1001, 0x59)
|[[OSPF]]
|-
|108 (0110 1100, 0x6C)
|IP Payload Compression Protocol
|-
|115 (0111 0011, 0x73)
|[[L2TP]]
|-
|132 (1000 0100, 0x84)
|[[SCTP]]
|-
|135 (1000 0111, 0x87)
|Mobility Header (Draft)
|-
|136-252
|nicht zugewiesen
|-
|253-254
|für Experimente und Testzwecke
|-
|255 (1111 1111, 0xFF)
|Reserviert
|}


== IPv6 - 11 ==
== Anhang ==
IPv4 und IPv6 Header im Vergleich
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
==== Dokumentation ====
==== Links ====
===== Weblinks =====


== IPv6 - 12 ==
[[Kategorie:IPv6/Header]]
IPv6
 
== IPv6 - 13 ==
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 - 14 ==
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.
 
== IPv6 - 15 ==
IPv6
 
== IPv6 - 16 ==
IPv6
 
== IPv6 - 17 ==
IPv6
 
== IPv6 - 18 ==
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
 
== IPv6 - 19 ==
Extension Headers
 
Name Typ Größe Beschreibung RFCs
Hop-By-Hop Options 0 variabel Optionen RFC 2460
von allen IPv6-Geräten zu beachten RFC 2675
wird z.B. für Jumbograms benutzt
Routing 43 variabel Hier kann der Weg des Paketes durch das RFC 2460
Netzwerk beeinflusst werden RFC 6275
wird u.a. für Mobile IPv6 verwendet RFC 5095
Fragment 44 64 Bit Parameter zur Fragmentierung RFC 2460
Authentication Header (AH) 51 variabel Daten zur Vertraulichkeit (IPsec) RFC 4302
Encapsulating Security 50 variabel Daten zur Verschlüsselung (IPsec) RFC 4303
Payload (ESP)
Destination Options 60 variabel Optionen RFC 2460
nur vom Zielrechner zu beachten
Mobility 135 variabel Daten für Mobile IPv6 RFC 6275
 
No Next Header 59 leer Platzhalter RFC 2460
zeigt Ende eines Header-Stapels an
 
== IPv6 - 20 ==
Verwendung von Extension Headers
 
== IPv6 - 21 ==
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
 
== 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
 
== IPv6 - 23 ==
Format des Hop-by-Hop Options Headers
 
== IPv6 - 24 ==
Format des Routing Headers
 
== IPv6 - 25 ==
Die 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
 
== IPv6 - 26 ==
Die 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').
 
== IPv6 - 27 ==
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 9000
Jumboframes
 
PPPoE (z. B. DSL) ≤ 1492
 
SLIP/PPP (low delay) 296
 
X.25 576
 
FibreChannel theoretisch unbegrenzt
 
ISDN 576
 
ATM 4500
 
802.11 2312 (WiFi)
 
== IPv6 - 28 ==
Path MTU (PMTU)
 
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.
 
== IPv6 - 29 ==
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)
 
== IPv6 - 30 ==
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.
== IPv6 - 31 ==
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.
 
== IPv6 - 32 ==
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.
 
== IPv6 - 33 ==
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.
 
== IPv6 - 34 ==
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.
 
== IPv6 - 35 ==
Format des Fragment Headers
 
== IPv6 - 36 ==
Fragmentierung mit IPv6
 
== IPv6 - 37 ==
Der Fragment Header in einem Trace File
 
== IPv6 - 38 ==
Das letzte Paket des Fragment Sets
 
== IPv6 - 39 ==
Format des Destination Options Headers
 
== IPv6 - 40 ==
IPv6 – Header
Zusammenfassung
 
III - 41
Review: The IPv4 header consists of 15 fields
including 3 flags and the options and padding
 
Version – Indicates IP version 4
 
IPv4 Header IHL = Internet Header Length, which must be specified since the options allow for
varying length headers
ToS = Type of Service, which allows for differentiating packets into different classes
for specific forwarding treatment.
Ver IHL ToS Total Length
Total Length – indicates the total length of the IP packet, including the header, upper
Fragment layer protocols and payload
Identifier Flag
s Offset
Identifier – Unique identifier for the packet, seldom used
 
TTL Protocol Header Checksum Flags – Used to indicate fragmentation
 
Fragment Offset – indicates this fragment’s position in the datagram
Source Address TTL = Time to Live, the packet life remaining in router hops (and initially in seconds)
 
Protocol – The next protocol header above IP, e.g., TCP, UDP, IPSec, etc.
Destination Address
Header Checksum – used in checking to ensure the header was received as it was
transferred and without error
Options and Padding
Addresses – 32-bit designators for the sending (source) host and receiving
(destination) host
 
Options – Seldom used options set by sender
 
Several of the fields initially envisioned for use either went unused, became obsolete in favor of
other technologies or OSI layers, or morphed into other uses
 
III - 42
Review: The IPv4 header can vary in size
 
IPv4 Header
Ver IHL ToS Total Length
 
Flag
Fragment
Identifier
s Offset
 
TTL Protocol Header Checksum 20 bytes
Source Address
 
Destination Address
 
Options and Padding Header size can vary if options are used
 
The IPv6 header was designed to optimize the protocol and fix the header to a
consistent size to expedite packet forwarding
 
III - 43
IPv6 set out to retire obsolete IPv4 header fields
 
IPv4 Header
Ver IHL ToS Total Length
 
Fragment
Identifier
Fla
gs
Offset IPv4 header fields that were obsolete
or superfluous to other protocol
TTL Protocol Header Checksum
layers were identified for deletion or
Source Address
modification
 
Destination Address
 
Options and Padding
 
III - 44
IPv6 header is fixed to 40 bytes
 
IPv4 Header Internet Header Length (IHL) field is no
Ver IHL ToS Total Length
longer needed
 
Flag
Fragment
Identifier
s Offset
 
TTL Protocol Header Checksum
 
Source Address
 
Destination Address
 
Options and Padding
 
III - 45
The largely unused Identification field was trashed
 
IPv4 Header
Ver ToS Total Length
 
Flag
Fragment
Identifier
s Offset
 
TTL Protocol Header Checksum
 
Source Address
 
Destination Address
 
Options and Padding
 
III - 46
The 3-bit Flags field is no longer needed
 
Flags dealt primarily with Fragmentation,
IPv4 Header which has been moved to an optional
extension header
Ver ToS Total Length
 
Flag
Fragment
s Offset


TTL Protocol Header Checksum
</noinclude>
 
Source Address
 
Destination Address
 
Options and Padding
 
III - 47
Fragmentation by routers in IPv6 is not permitted
 
Hosts must fragment packets.
IPv4 Header Fragmentation was moved to an optional
extension header
Ver ToS Total Length
 
Fragment
Offset
 
TTL Protocol Header Checksum
 
Source Address
 
Destination Address
 
Options and Padding
 
III - 48
Header checksum was deemed redundant
 
Layer 2 and upper layer protocols are
IPv4 Header performing checksums, so an IP header
checksum is unnecessary
Ver ToS Total Length
 
TTL Protocol Header Checksum
 
Source Address
 
Destination Address
 
Options and Padding
 
III - 49
The Options field was removed
 
Options forms the basis of the Extension
IPv4 Header Header concept
Ver ToS Total Length
 
TTL Protocol
 
Source Address
 
Destination Address
 
Options and Padding
 
III - 50
The Version field was maintained
 
IPv4 Header IPv6 Header
Ver ToS Total Length Ver
 
Of course, the version
TTL Protocol
numbers was changed to
Source Address
“6”
 
Destination Address
 
III - 51
ToS field was kept but renamed to Traffic Class
 
IPv4 Header IPv6 Header
Traffic
Ver ToS Total Length Ver
Class
 
Traffic Class is functionally
TTL Protocol
identical to DiffServ (DSCP)
Source Address
 
Destination Address
 
III - 52
A new QoS Field called Flow Label was added
 
IPv4 Header IPv6 Header
Traffic
Ver ToS Total Length Ver Flow Label
Class
 
Flow label allows for flow
TTL Protocol identification at layer 3 and within
the IP header, instead of a mix of
Source Address
layer 3 and 4 parameters.
Destination Address
 
III - 53
Total Length field changed to Payload Length
 
IPv4 Header IPv6 Header
Traffic
Ver ToS Total Length Ver Flow Label
Class
 
Payload Length
 
TTL Protocol
 
Header length is fixed to 40
Source Address
bytes, thus only the payload
Destination Address
length needs be identified
 
III - 54
Protocol field was changed to Next Header
 
IPv4 Header IPv6 Header
Traffic
Ver ToS Total Length Ver Flow Label
Class
 
Next Header
Payload Length
 
TTL Protocol
 
Next Header could indicate the layer 4
Source Address
protocol (TCP, UDP), ICMP, another
layer 3 IP protocol or an IPv6 extension
Destination Address
header.
 
III - 55
TTL field was kept but changed to Hop Limit
 
IPv4 Header IPv6 Header
Traffic
Ver ToS Total Length Ver Flow Label
Class
 
Next Header Hop
Payload Length
Limit
 
TTL Protocol
 
Over time, the “time” to live field came
Source Address
to mean “router hop count”, thus it
Destination Address
was changed in IPv6 to “hop limit”
 
III - 56
Source and Destination addresses are increased from 32 to 128
bits each
 
IPv4 Header IPv6 Header
Traffic
Ver ToS Total Length Ver Flow Label
Class
 
Next Header Hop
Payload Length
Limit
 
TTL Protocol
 
Source Address
Source Address (128 bits)
 
Destination Address
 
Destination Address
(128 bits)
 
III - 57
IPv6 basic header length
 
Traffic Class
Ver Flow Label
 
Next Header Hop
Payload Length
Limit
Always 40 bytes
Source Address
 
Destination Address
 
Extension headers are
added after the
addresses, indicated by
the Next Header value
 
III - 58
No Next Header
 
Traffic Class
Ver Flow Label
 
Next Header value = 59 Payload Length
Next Header Hop
Limit
 
Source Address
 
Destination Address
 
III - 59
Hop-by-Hop header
 
Traffic Class
Ver Flow Label
 
Next Header value = 0 Payload Length
Next Header Hop
Limit
 
Source Address
 
Destination Address
Provides information that
must be examined by every Hop-by-Hop Options Header
node along the packet’s
delivery path, unlike other
headers, which are only
viewed by the receiving
node.
 
III - 60
Destination Options header
 
Traffic Class
Ver Flow Label
 
Next Header Hop
Payload Length
Limit
 
Source Address
 
Destination Address
 
Next Header value = 60 Hop-by-Hop Options Header
Destination Options header
Destination Options Header
follows Hop-by-Hop header
Carries optional only when the Routing
information that needs to header is present.
be examined by only the
packet’s destination
node(s)
 
III - 61
Routing header
 
Traffic Class
Ver Flow Label
 
Next Header Hop
Payload Length
Limit
 
Source Address
 
Destination Address
 
Hop-by-Hop Options Header
 
Next Header value = 43 Destination Options Header
 
Used by an IPv6 source to Routing Header
list one or more intermediate
nodes to be visited on the
way to a packet’s
destination. Provides a
means to do source or
policy routing.
 
III - 62
Fragment header
 
Traffic Class
Ver Flow Label
 
Next Header Hop
Payload Length
Limit
 
Source Address
 
Destination Address
 
Hop-by-Hop Options Header
 
Destination Options Header
 
Next Header value = 44 Routing Header
 
Indicates that the datagram Fragment Header
was fragmented and what
position this fragment is in
the overall datagram
 
III - 63
Authentication Header
 
Traffic Class
Ver Flow Label
 
Next Header Hop
Payload Length
Limit
 
Source Address
 
Destination Address
 
Hop-by-Hop Options Header
 
Destination Options Header
 
Routing Header
 
Next Header value = 51 Fragment Header
 
Provides authentication of Authentication Header Same as AH in IPSec for
the packet IPv4
 
III - 64
Encapsulating Security Payload header
 
Traffic Class
Ver Flow Label
 
Next Header Hop
Payload Length
Limit
 
Source Address
 
Destination Address
 
Hop-by-Hop Options Header
 
Destination Options Header
 
Routing Header
 
Fragment Header
 
ESP provides
Next Header value = 50
confidentiality and integrity Authentication Header
 
of the packet through Same as ESP in IPSec for
encryption Encapsulating Security Payload Header
IPv4
 
III - 65
Mobility header
 
Traffic Class
Ver Flow Label
 
Next Header Hop
Payload Length
Limit
 
Source Address
 
Destination Address
 
Hop-by-Hop Options Header
 
Fragment Header
 
Used by mobile nodes, Authentication Header
correspondent nodes and
home agents in Encapsulating Security Payload Header Next Header value = 135
messaging related to the
creation and management Mobility Header
of mobile bindings
 
III - 66
Destination Options header
 
Traffic Class
Ver Flow Label
 
Next Header Hop
Payload Length
Limit
 
Source Address
 
Destination Address
 
Hop-by-Hop Options Header
 
Fragment Header
 
Authentication Header
 
Encapsulating Security Payload Header
Destination Options
header moves to the end Mobility Header
Next Header value = 60
if the Routing header is
not present Destination Options Header
 
III - 67
Next header is TCP
 
Traffic Class
Ver Flow Label
 
Next Header value = 6 Payload Length
Next Header Hop
Limit
 
Source Address
 
Destination Address
 
TCP Header
 
III - 68
Next header is UDP
 
Traffic Class
Ver Flow Label
 
Next Header value = 17 Payload Length
Next Header Hop
Limit
 
Source Address
 
Destination Address
 
UDP Header
 
III - 69
Next header is ICMPv6
 
Traffic Class
Ver Flow Label
 
Next Header value = 58 Payload Length
Next Header Hop
Limit
 
Source Address
 
Destination Address
 
ICMPv6 Header
 
III - 70
[[Kategorie:IPv6/Header]]

Aktuelle Version vom 29. Juni 2024, 12:13 Uhr

IPv6/Header

Beschreibung

Definiert im RFC 2460

Feste Größe
  • 40 Bytes
  • davon je 16 Bytes für Absender- und Empfängeradresse

Header-Format

Feste Länge

Bei IPv6 eine feste Länge von 40 Byte (320 Bit)

  • Im Gegensatz zu IPv4 hat der IP-Kopfdatenbereich (Header)

Extension Headers

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


Header-Felder

Kopfdatenbereich nach 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


Extension Headers

IPv6/Header/Extension

Vereinfachung des Headers

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

IPv6 (Felder)

Byte/Bin 00–03 04–07 08–11 12–15 16-19 20–23 24–27 28–31
01 Version Traffic Class Flow Label H
e
a
d
e
r
02 Payload Length Next Header Hop Limit
03 - 06 Quell-IP-Adresse
07 - 10 Ziel-IP-Adresse
11+ Payload

IPv4 Header Felder

Option Beschreibung
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

Entfallene Felder

Option Beschreibung
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 entfernt, weil 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

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)

Kopfdaten

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

IPv6 Header in einem Trace File

IPv4 und IPv6 Header im Vergleich


IPv6-Erweiterungsheader

IPv6/Header/Erweiterungsheader

Maximum Transmission Unit (MTU)

Maximum Transmission Unit


Der IPv6 Header

Die Felder im IPv6 Header

Feldname Länge Inhalt des Feldes
Die Felder im IPv6 Header
Version 4 bits 6 (0110, 0x6)
Traffic Class 1 Byte Priorisierung (s. RFC 2474)
Flow Label 20 bits für gleichartige Pakete -> effizientes Routing
Payload Length 2 Bytes Länge der Daten nach dem IPv6 Header
Next Header 1 Byte Protokoll Nummer oder Extension-Header
Hop Limit 1 Byte Anzahl der Routerhops
Quelladresse 16 Bytes
Zieladresse 16 Bytes endgültiger Empfänger bzw. Adresse des nächsten Hops (z.B. wenn ein Routing Header vorhanden ist)
Summe der Bytes 40
Die aktuelle Liste aller Protokoll- und Headerwerte findet man bei der IANA.
Wert Beschreibung
Next Header Werte
0 (0, 0x0) in IPv4 reserviert und nicht benutzt

in IPv6 Hop-by-Hop Option Header

1 (0001, 0x1) ICMP IPv4
2 (0010, 0x2) IGMP IPv4
4 (0100, 0x4) IP in IP encapsulation
6 (0110, 0x6) TCP
8 (1000, 0x8) EGP
9 (1001, 0x9) IGP (Cisco IGRP )
17 (0001 0001, 0x11) UDP
41 (0010 1001, 0x29) IPv6
43 (0010 1011, 0x2B) Routing Header
44 (0010 1100, 0x2C) Fragmentation Header
45 (0010 1101, 0x2D) IDRP
46 (0010 1110, 0x2E) RSVP
47 (0010 1111, 0x2F) GRE
50 (0011 0010, 0x32) Encryted Security Payload Header
51 (0011 0011, 0x33) Authentication Header
58 (0011 1010, 0x3A) ICMPv6
59 (0011 1011, 0x3B) No Next Header für IPv6
60 (0011 1100, 0x3C) Destination Options Header
88 (0101 1000, 0x58) EIGRP v4 und EIGRPv6
89 (0101 1001, 0x59) OSPF
108 (0110 1100, 0x6C) IP Payload Compression Protocol
115 (0111 0011, 0x73) L2TP
132 (1000 0100, 0x84) SCTP
135 (1000 0111, 0x87) Mobility Header (Draft)
136-252 nicht zugewiesen
253-254 für Experimente und Testzwecke
255 (1111 1111, 0xFF) Reserviert

Anhang

Siehe auch

Dokumentation

Links

Weblinks


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