Beim Feld Verkehrs-Klasse ist die genaue Verwendung noch offen. Ein erster Vorschlag sah vor, daß die Werte 8 ... 15 für "Echtzeit-Pakete" (Videokonferenz, ...) reserviert sind. Für die anderen Werte wurde folgende Belegung empfohlen:
0 | Verkehrstyp nicht bekannt |
1 | nicht dringender Datentransfer (NetNews, ...) |
2 | "unbeaufsichtigter" Datentransfer (E-Mail, ...) |
3 | reserviert |
4 | "beaufsichtigter" Datentransfer (FTP, NFS, WWW, ...) |
5 | reserviert |
6 | interaktiver Verkehr (Telnet, X, ...) |
7 | Verkehr zur Steuerung des Netzes (Routing-Protokolle, SNMP, ...) |
Neu ist die Flußmarkierung (Flow Label).
Sie wird dazu verwendet, einem Datenstrom
zwischen Quelle und Ziel bestimmte Dienstgütemerkmale
(Quality of Service) zu gewährleisten.
So kann man beispielsweise einer Videokonferenz-Anwendung eine
Mindestbandbreite und eine maximale Verzögerungszeit
bereitstellen.
Die Einstellung solcher Reservierungen ist Aufgabe anderer Protokolle.
Aussichtsreichster Kandidat dafür ist RSVP (Resource ReserVation Protocol).
Das Feld Hop Limit wird in jedem durchlaufenen Router heruntergezählt. Das Paket wird vernichtet, wenn der Wert 0 erreicht ist. Diese Information dient wie das TTL-Feld bei IPv4 der Vermeidung von Endlosschleifen. Allerdings ist die Bezeichnung treffender, da ohnehin auch bei üblichen IPv4-Implementierungen das ursprünglich vorgesehene Messen der Zeitspanne praktisch gegen ein reines Zählen der durchlaufenen Router ersetzt wird.
Der Typ des nächsten Kopfes hat dieselbe Bedeutung wie bei IPv4, d.h., hier wird festgelegt, ob die Nutzlast aus TCP oder UDP besteht. Alternativ können hier auch weitere (verschachtelte) Köpfe der IP-Schicht angezeigt werden. Bei IPv6 werden "Sonderwünsche" nicht durch Optionen, sondern durch weitere Protokollköpfe signalisiert (das soll die Verarbeitung in Routern beschleunigen). Die wichtigsten Erweiterungsköpfe mit ihren dezimalen Typkodes zeigt die folgende Aufstellung:
0 | Optionen, die für jedes durchlaufene System bestimmt sind (hop-by-hop options) |
6 | TCP |
17 | UDP |
43 | Routing (explizite Angabe eines Weges) |
44 | Fragmentierung |
50 | Verschlüsselung - Encapsulating Security Payload |
51 | Authentifizierung und Integritätssicherung - Authentication Header |
58 | Internet Control Message Protocol (ICMP IPv6) |
60 | Optionen, die nur für das Zielsystem bestimmt sind (destination options) |
Aufbau und Verwendung von Authentication Header und Encapsulating Security Payload werden im Abschnitt IP-Sicherheit erläutert.
Wenn beispielsweise eine Routingangabe und Fragmentierungsinformationen in dem IP-Paket unterzubringen sind, werden neben dem eigentlichen IPv6-Kopf zwei weitere Köpfe verwendet:
Bezüglich der Kopf-Länge gibt es folgende Besonderheit: Sie wird in 64-Bit-Worten angegeben, wobei man das erste Wort nicht zählt. Das heißt, der Wert 0 bezeichnet eine Länge von einem 64-Bit-Wort. Damit erreicht man eine effiziente Implementierung.
Die Optionen selbst bestehen aus Optionstyp, Optionslänge (diesmal in Bytes) und den eigentlichen Optionsdaten:
Als Beispiel für eine Option, die für jedes durchlaufene System bestimmt ist, soll die "Jumbo Payload"-Option dienen. Wie der Name schon vermuten läßt, kann man auf diese Weise IP-Pakete bilden, deren Nutzlast größer als 64 kByte ist (das war die bisherige Grenze durch die 16-Bit-Längenangabe):
Die Typkodes wurden etwas gestrafft:
Typ | Kode | Nachricht |
---|---|---|
1 | Destination Unreachable | |
0 | no route to destination | |
1 | communication with destination administratively prohibited | |
2 | not a neighbor | |
3 | address unreachable | |
4 | port unreachable | |
2 | Packet Too Big | |
3 | Time Exceeded | |
4 | Parameter Problem | |
128 | Echo Request | |
129 | Echo Reply |
Im Abschnitt Autokonfiguration werden Sie eine weitere ICMPv6-Anwendung kennenlernen.
Das Feld Segments Left gibt die Anzahl der verbleibenden Adressen der im Header explizit spezifizierten Adreß-Liste an. Das sind also die Adressen derjenigen Router, die auf dem Weg zum Ziel noch durchlaufen werden sollen. Segments Left zeigt jedem Router "seine" (d.h. die aktuell auszuwertende) Adresse an und wird nach der Adreß-Auswertung dekrementiert. Da die Adreß-Liste eine Maximallänge von 24 Einträgen hat, darf Segments Left höchstens den Wert 23 annehmen.
Mit der Bitmaske kann jeder der (maximal) 24 nachfolgenden Adressen die Bedeutung "strikt" oder "lose" gegeben werden:
Der Fragment-Offset gibt an, an welche Stelle das jeweilige Teilstück gehört. Das folgende Beispiel zeigt, wie eine Nutzlast von 1400 Bytes auf drei Fragmente aufgeteilt wird, wobei die ersten beiden je 600 Bytes transportieren. Die restlichen 200 Bytes werden im dritten Fragment übertragen.
Das M Flag bzw. More Fragments Flag ist nur beim letzten Fragment 0, sonst 1.
Identifikation hat für alle zusammengehörigen Fragmente denselben eindeutigen Wert.