4. IPv6-Erweiterungsheader
In IPv6 werden optionale Informationen der Internetschicht in separaten Headern kodiert, die zwischen dem IPv6-Header und dem Header der oberen Schicht platziert werden können. Es gibt eine kleine Anzahl solcher Erweiterungsheader (extension headers), von denen jeder durch einen eigenen Next Header-Wert identifiziert wird. Wie in den folgenden Beispielen dargestellt, kann ein IPv6-Paket null, einen oder mehrere Erweiterungsheader tragen, von denen jeder durch das Next Header-Feld des vorherigen Headers identifiziert wird:
+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
Mit einer Ausnahme werden Erweiterungsheader von keinem Knoten auf dem Übertragungsweg des Pakets untersucht oder verarbeitet, bis das Paket den Knoten (oder bei Multicast jeden Knoten der Gruppe) erreicht, der im Destination Address-Feld des IPv6-Headers angegeben ist. Dort ruft die normale Demultiplexierung des Next Header-Feldes des IPv6-Headers das Modul auf, das den ersten Erweiterungsheader verarbeitet, oder – falls kein Erweiterungsheader vorhanden ist – den Header der oberen Schicht. Der Inhalt und die Semantik jedes Erweiterungsheaders bestimmen, ob mit der Verarbeitung des nächsten Headers fortgefahren wird. Daher MÜSSEN Erweiterungsheader strikt in der Reihenfolge verarbeitet werden, in der sie im Paket erscheinen; ein Empfänger DARF NICHT das Paket nach einem bestimmten Erweiterungsheadertyp durchsuchen und diesen verarbeiten, bevor alle vorherigen Header verarbeitet wurden.
Die oben erwähnte Ausnahme ist der Hop-by-Hop Options Header (Hop-by-Hop-Optionsheader), der Informationen trägt, die von jedem Knoten auf dem Übertragungsweg des Pakets (einschließlich Quell- und Zielknoten) untersucht und verarbeitet werden MÜSSEN. Wenn ein Hop-by-Hop Options Header vorhanden ist, MUSS er unmittelbar auf den IPv6-Header folgen. Sein Vorhandensein wird durch den Wert null im Next Header-Feld des IPv6-Headers angezeigt.
Wenn ein Knoten als Ergebnis der Verarbeitung eines Headers mit der Verarbeitung des nächsten Headers fortfahren muss, der Next Header-Wert im aktuellen Header jedoch vom Knoten nicht erkannt wird, SOLLTE er das Paket verwerfen und eine ICMP-Parameter-Problem-Nachricht (ICMP Parameter Problem) an die Quelladresse des Pakets senden, mit dem ICMP-Code-Wert 1 („unrecognized Next Header type encountered"), wobei das ICMP-Zeigerfeld den Offset des nicht erkannten Wertes im ursprünglichen Paket enthält. Dieselbe Maßnahme SOLLTE ergriffen werden, wenn ein Knoten in einem anderen Header als dem IPv6-Header einen Next Header-Wert von null antrifft.
Die Länge jedes Erweiterungsheaders ist ein Vielfaches von 8 Oktetten, um eine 8-Oktett-Ausrichtung für nachfolgende Header beizubehalten. Felder mit mehreren Oktetten in jedem Erweiterungsheader sind an ihren natürlichen Grenzen ausgerichtet, d. h. Felder mit einer Breite von n Oktetten werden an einem ganzzahligen Vielfachen von n Oktetten vom Beginn des Headers platziert, wobei n = 1, 2, 4 oder 8.
Eine vollständige IPv6-Implementierung umfasst die Implementierung der folgenden Erweiterungsheader:
Hop-by-Hop Options
Routing (Type 0)
Fragment
Destination Options
Authentication
Encapsulating Security Payload
Die ersten vier sind in diesem Dokument spezifiziert; die letzten beiden sind in [RFC-2402] bzw. [RFC-2406] spezifiziert.