1.14.2. Protokoll

Die Struktur des Protokollkopfs hat sich gegenüber IPv4 sogar geringfügig vereinfacht. Die wesentlichen Änderungen sind:

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

Kopfprüfsumme und Fragmentierungssteuerung fehlen gegenüber IPv4. Beides wurde nach einer Aufwands-Nutzen-Abwägung für entbehrlich gehalten (eine Fragmentierung ist mit weiteren Köpfen möglich).

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:

Optionen

Die allgemeine Struktur für einen Optionskopf enthält nur eine Information über den nächsten Kopftyp sowie eine Länge:

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.


Diskussion 1.14.2.1:
Wieso trägt das zur Effizienz bei?

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):

ICMP IPv6

Auch das Hilfsprotokoll ICMP wurde modifiziert, die Grundstruktur einer ICMP-Nachricht blieb aber erhalten:

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

Echo Request und Echo Reply sind wieder die Basis der Ping-Funktionalität (Test der Erreichbarkeit).

Im Abschnitt Autokonfiguration werden Sie eine weitere ICMPv6-Anwendung kennenlernen.

Routing-Kopf

Die Bedeutung des Routing-Kopfes entspricht ungefähr der Source Routing Option bei IPv4, d.h., die Quelle kann explizit einen Weg in Form einer Liste von Adressen der zu durchlaufenden Router festlegen. RFC 1883, die Spezifikation von IPv6, gestattet verschiedene Routing-Typen, beschreibt selbst allerdings lediglich den Typ 0:

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:

Fragment-Kopf

Eine ggf. notwendige Fragmentierung findet bei IPv6 nur noch beim Ursprungssystem statt. Jedes der Fragmente enthält (zusätzlich zum normalen IPv6-Kopf) einen Fragment-Kopf:

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.


© Uwe Hübner, 29.4.1998