4. IPv6 Extension Headers (IPv6-Erweiterungsheader)
Bei IPv6 werden optionale Internet-Schicht-Informationen in separaten Headern kodiert, die zwischen dem IPv6-Header eines Pakets und dem Header der höheren Schicht platziert werden können. Es gibt eine geringe Anzahl solcher Erweiterungsheader (Extension Headers), von denen jeder durch einen anderen Next-Header-Wert identifiziert wird.
Die Nummern der Erweiterungsheader stammen aus demselben IANA-IP-Protokollnummernraum [IANA-PN], der von IPv4 und IPv6 verwendet wird. Bei der Verarbeitung der Sequenz von Next-Header-Werten in einem Paket zeigt der erste Wert, der kein Erweiterungsheader [IANA-EH] ist, an, dass das nächste Element im Paket der entsprechende Header der höheren Schicht ist. Wenn kein Header einer höheren Schicht vorhanden ist, wird ein spezieller Wert "No Next Header" verwendet.
Wie in den folgenden Beispielen dargestellt, kann ein IPv6-Paket null, einen oder mehrere Erweiterungsheader enthalten, 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 Ausnahme des Hop-by-Hop-Options-Headers dürfen Erweiterungsheader von keinem Knoten auf dem Paket-Zustellungspfad verarbeitet, eingefügt oder gelöscht werden (MUST NOT), bis das Paket den durch das Destination-Address-Feld des IPv6-Headers identifizierten Knoten (oder Knotengruppe im Multicast-Fall) erreicht.
Der Hop-by-Hop-Options-Header wird nicht eingefügt oder gelöscht, kann jedoch von jedem Knoten auf dem Paket-Zustellungspfad untersucht oder verarbeitet werden, bis das Paket den durch das Destination-Address-Feld des IPv6-Headers identifizierten Knoten (oder Knotengruppe im Multicast-Fall) erreicht. Der Hop-by-Hop-Options-Header muss (MUST), falls vorhanden, unmittelbar auf den IPv6-Header folgen. Seine Anwesenheit wird durch den Wert Null im Next-Header-Feld des IPv6-Headers angezeigt.
Hinweis: Während [RFC2460] vorschrieb, dass alle Knoten den Hop-by-Hop-Options-Header untersuchen und verarbeiten müssen (MUST), wird nun erwartet, dass Knoten auf dem Paket-Zustellungspfad den Hop-by-Hop-Options-Header nur dann untersuchen und verarbeiten, wenn sie explizit dazu konfiguriert sind.
Am Zielknoten ruft die normale Demultiplexierung des Next-Header-Feldes des IPv6-Headers das Modul auf, um den ersten Erweiterungsheader zu verarbeiten, oder den Header der höheren Schicht, wenn keine Erweiterungsheader vorhanden sind. Der Inhalt und die Semantik jedes Erweiterungsheaders bestimmen, ob mit der Verarbeitung des nächsten Headers fortgefahren wird oder nicht. Daher müssen (MUST) Erweiterungsheader strikt in der Reihenfolge verarbeitet werden, in der sie im Paket erscheinen. Beispielsweise darf (MUST NOT) ein Empfänger nicht das Paket nach einem bestimmten Typ von Erweiterungsheader durchsuchen und diesen Header verarbeiten, bevor alle vorhergehenden Header verarbeitet wurden.
Wenn als Ergebnis der Verarbeitung eines Headers der Zielknoten mit der Verarbeitung des nächsten Headers fortfahren muss, aber der Next-Header-Wert im aktuellen Header von diesem Knoten nicht erkannt wird, sollte (SHOULD) er das Paket verwerfen und eine ICMP-Parameter-Problem-Nachricht (ICMP-Code-Wert 1 "nicht erkannter Next-Header-Typ angetroffen") an die Quelle des Pakets senden. Das ICMP-Zeiger-Feld sollte den Offset des nicht erkannten Werts im ursprünglichen Paket enthalten. Dasselbe Verhalten sollte (SHOULD) angewendet werden, wenn ein Knoten auf den Next-Header-Wert Null in einem anderen Header als einem IPv6-Header trifft.
Die Länge jedes Erweiterungsheaders ist ein ganzzahliges Vielfaches von 8 Oktetten, um eine 8-Oktetten-Ausrichtung für nachfolgende Header aufrechtzuerhalten. Multi-Oktett-Felder innerhalb jedes Erweiterungsheaders sind an ihren natürlichen Grenzen ausgerichtet, d.h. Felder mit einer Breite von n Oktetten werden an einem Vielfachen von n Oktetten vom Beginn des Headers aus platziert (n = 1, 2, 4 oder 8).
Eine vollständige Implementierung von IPv6 umfasst die Implementierung der folgenden Erweiterungsheader:
- Hop-by-Hop Options
- Fragment
- Destination Options
- Routing
- Authentication
- Encapsulating Security Payload
Die ersten vier werden in diesem Dokument spezifiziert. Die letzten zwei werden in [RFC4302] bzw. [RFC4303] spezifiziert. Eine aktuelle Liste der IPv6-Erweiterungsheader ist unter [IANA-EH] zu finden.
4.1 Extension Header Order (Reihenfolge der Erweiterungsheader)
Wenn mehr als ein Erweiterungsheader im selben Paket verwendet wird, wird empfohlen (RECOMMENDED), dass diese Header in der folgenden Reihenfolge erscheinen:
IPv6 header
Hop-by-Hop Options header
Destination Options header (Anmerkung 1)
Routing header
Fragment header
Authentication header (Anmerkung 2)
Encapsulating Security Payload header (Anmerkung 2)
Destination Options header (Anmerkung 3)
Upper-Layer header
Anmerkung 1: Für Optionen, die vom ersten Ziel verarbeitet werden sollen, das im IPv6-Destination-Address-Feld erscheint, sowie von nachfolgenden Zielen, die im Routing-Header aufgeführt sind.
Anmerkung 2: Zusätzliche Empfehlungen zur relativen Reihenfolge des Authentication-Headers und des Encapsulating-Security-Payload-Headers sind in [RFC4303] angegeben.
Anmerkung 3: Für Optionen, die nur vom endgültigen Ziel des Pakets verarbeitet werden sollen.
Jeder Erweiterungsheader sollte (SHOULD) höchstens einmal vorkommen, mit der Ausnahme, dass der Destination-Options-Header höchstens zweimal vorkommen sollte (SHOULD) (einmal vor einem Routing-Header und einmal vor dem Header der höheren Schicht).
Wenn der Header der höheren Schicht ein weiterer IPv6-Header ist (im Falle von IPv6-in-IPv6-Tunneling oder -Kapselung), kann er von eigenen Erweiterungsheadern gefolgt werden, die individuell denselben Reihenfolgeempfehlungen unterliegen.
Wenn andere Erweiterungsheader definiert sind, müssen (MUST) sie ihre Reihenfolgebeschränkungen in Bezug auf die oben aufgeführten Header spezifizieren.
IPv6-Knoten müssen (MUST) Erweiterungsheader in beliebiger Reihenfolge und in beliebiger Häufigkeit im selben Paket akzeptieren und versuchen zu verarbeiten, mit der Einschränkung, dass der Hop-by-Hop-Options-Header unmittelbar auf den IPv6-Header folgen muss. Trotzdem wird dringend empfohlen (STRONGLY ADVISED), dass Quellen von IPv6-Paketen der oben empfohlenen Reihenfolge folgen, bis und sofern nicht nachfolgende Spezifikationen diese Empfehlung revidieren.
4.2 Options (Optionen)
Zwei der derzeit definierten Erweiterungsheader, die in diesem Dokument spezifiziert sind - der Hop-by-Hop-Options-Header und der Destination-Options-Header - tragen eine variable Anzahl von "Optionen", die im Type-Length-Value (TLV)-Format wie folgt kodiert sind:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type 8-Bit-Kennung des Optionstyps.
Opt Data Len 8-Bit vorzeichenlose Ganzzahl. Länge des Option-Data-Feldes dieses Options in Oktetten.
Option Data Variable Länge. Optionsspezifische Daten.
Die Sequenz von Optionen innerhalb eines Headers muss ohne Padding zwischen ihnen verarbeitet werden. Einzelne Optionen können jedoch interne Padding haben, um Multi-Oktett-Felder innerhalb der Option Data an natürlichen Grenzen auszurichten.
Die höchstwertigen zwei Bits des Option-Type-Feldes spezifizieren die Aktion, die von einem Zielknoten ausgeführt werden muss, wenn der Optionstyp nicht erkannt wird:
00 - Option überspringen und mit der Verarbeitung des Headers fortfahren.
01 - Paket verwerfen.
10 - Paket verwerfen und unabhängig davon, ob die Zieladresse des Pakets eine
Multicast-Adresse war, eine ICMP-Parameter-Problem-Nachricht
(Code 2 "nicht erkannte IPv6-Option angetroffen") an die Quelladresse
des Pakets senden, wobei der ICMP-Zeiger auf das nicht erkannte
Option-Type-Oktett zeigt.
11 - Paket verwerfen und nur dann eine ICMP-Parameter-Problem-Nachricht
(Code 2 "nicht erkannte IPv6-Option angetroffen") an die Quelladresse
des Pakets senden, wenn die Zieladresse des Pakets keine Multicast-Adresse war,
wobei der ICMP-Zeiger auf das nicht erkannte Option-Type-Oktett zeigt.
Das dritte höchstwertige Bit des Option-Type-Feldes spezifiziert, ob die Option Data eines Options sich auf dem Weg zum endgültigen Ziel des Pakets ändern kann:
0 - Option Data ändert sich nicht unterwegs.
1 - Option Data kann sich unterwegs ändern.
Die drei hochwertigsten Bits des Option-Type-Feldes werden durch die fünf niederwertigen Bits für jeden Optionstyp separat behandelt.
Einzelne Optionsdefinitionen dürfen nicht die Bedeutung dieser drei hochwertigsten Bits ändern. Optionsdefinitionen sollten (SHOULD) darauf ausgelegt sein, mit der festgelegten Semantik für die drei hochwertigsten Bits auf vernünftige Weise zu arbeiten.
Es gibt zwei Padding-Optionen, die notwendig sind, wenn mehr als eine Option in demselben Hop-by-Hop- oder Destination-Options-Header enthalten ist, um die nachfolgenden Optionen an ihre natürlichen Grenzen auszurichten. Diese Padding-Optionen müssen (MUST) von allen IPv6-Implementierungen erkannt werden:
Pad1-Option (Ausrichtungsanforderung: keine):
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Hinweis: Das Format der Pad1-Option ist ein Sonderfall - sie hat weder die Felder Option-Data-Length noch Option-Data.
PadN-Option (Ausrichtungsanforderung: keine):
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Das Option-Data-Length-Feld enthält die Länge des Option-Data-Feldes in Oktetten. Das Option-Data-Feld besteht aus null oder mehr Nullen (0x00).
Anhang A enthält Richtlinien zur Formatierung von Optionen.
4.3 Hop-by-Hop Options Header (Hop-by-Hop-Optionen-Header)
Der Hop-by-Hop-Options-Header wird verwendet, um optionale Informationen zu übertragen, die von jedem Knoten auf dem Zustellungspfad eines Pakets untersucht werden müssen. Der Hop-by-Hop-Options-Header wird durch einen Next-Header-Wert von 0 im IPv6-Header identifiziert und hat das folgende Format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-Bit-Selektor. Identifiziert den Typ des Headers, der unmittelbar auf den Hop-by-Hop-Options-Header folgt. Verwendet dieselben Werte wie das IPv4-Protokollfeld [IANA-PN].
Hdr Ext Len 8-Bit vorzeichenlose Ganzzahl. Länge des Hop-by-Hop-Options-Headers in 8-Oktetten-Einheiten, ohne die ersten 8 Oktetten.
Options Variable Länge. Länge so, dass die vollständige Länge des Hop-by-Hop-Options-Headers ein ganzzahliges Vielfaches von 8 Oktetten ist. Enthält eine oder mehrere TLV-kodierte Optionen, wie in Abschnitt 4.2 beschrieben.
Die einzige derzeit im Hop-by-Hop-Options-Header definierte Hop-by-Hop-Option ist die Router-Alert-Option, die in [RFC2711] spezifiziert ist.
4.4 Routing Header (Routing-Header)
Der Routing-Header wird von einer IPv6-Quelle verwendet, um einen oder mehrere Zwischenknoten aufzulisten, die auf dem Weg zum Ziel eines Pakets "besucht" werden sollen. Diese Funktion ist den Loose-Source- und Record-Route-Optionen von IPv4 sehr ähnlich. Der Routing-Header wird durch einen Next-Header-Wert von 43 im unmittelbar vorhergehenden Header identifiziert und hat das folgende Format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-Bit-Selektor. Identifiziert den Typ des Headers, der unmittelbar auf den Routing-Header folgt. Verwendet dieselben Werte wie das IPv4-Protokollfeld [IANA-PN].
Hdr Ext Len 8-Bit vorzeichenlose Ganzzahl. Länge des Routing-Headers in 8-Oktetten-Einheiten, ohne die ersten 8 Oktetten.
Routing Type 8-Bit-Kennung eines bestimmten Routing-Header-Varianten.
Segments Left 8-Bit vorzeichenlose Ganzzahl. Anzahl der verbleibenden explizit aufgelisteten Zwischenknoten, die noch besucht werden müssen, bevor das endgültige Ziel des Pakets erreicht wird.
type-specific data Variable Länge. Länge so, dass die vollständige Länge des Routing-Headers ein ganzzahliges Vielfaches von 8 Oktetten ist. Format, das durch den Routing-Type-Wert bestimmt wird.
Wenn während der Zustellung eines Pakets an sein endgültiges Ziel ein Knoten auf einen Routing-Header mit einem nicht erkannten Routing-Type-Wert trifft, sollte (SHOULD) das erforderliche Verhalten des Knotens wie folgt sein:
-
Wenn Segments Left Null ist, sollte (SHOULD) der Knoten das Routing-Type-Feld ignorieren und mit der Verarbeitung des nächsten Headers im Paket fortfahren.
-
Wenn Segments Left ungleich Null ist, sollte (SHOULD) der Knoten das Paket verwerfen und eine ICMP-Parameter-Problem-Nachricht (Code 0 "fehlerhaftes Header-Feld angetroffen") an die Quelladresse des Pakets senden, wobei der ICMP-Zeiger auf das nicht erkannte Routing-Type-Oktett zeigt.
Die derzeit für IPv6 definierten Routing-Header-Typen finden Sie in der IANA-Registrierung [IANA-RH].
4.5 Fragment Header (Fragment-Header)
Der Fragment-Header wird von einer IPv6-Quelle verwendet, um Pakete zu senden, die größer sind als die Pfad-MTU (Path MTU) zu ihrem Ziel. Der Fragment-Header wird durch einen Next-Header-Wert von 44 im unmittelbar vorhergehenden Header identifiziert und hat das folgende Format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-Bit-Selektor. Identifiziert den Typ des Headers der ursprünglichen (unfragmentierten) Paket-Nutzlast (definiert als der erste Header nach dem IPv6-Header, der kein Hop-by-Hop-, Routing- oder Fragment-Header ist). Verwendet dieselben Werte wie das IPv4-Protokollfeld [IANA-PN].
Reserved 8-Bit-Reservierungsfeld. Bei der Übertragung auf Null initialisiert; beim Empfang ignoriert.
Fragment Offset 13-Bit vorzeichenlose Ganzzahl. Der Offset der Daten nach diesem Header relativ zum Beginn der fragmentierbaren Teile des ursprünglichen Pakets in 8-Oktetten-Einheiten.
Res 2-Bit-Reservierungsfeld. Bei der Übertragung auf Null initialisiert; beim Empfang ignoriert.
M flag 1 = weitere Fragmente; 0 = letztes Fragment.
Identification 32 Bits. Siehe Beschreibung unten.
Um ein Paket zu senden, das zu groß ist, um als ein einzelnes Paket über den Pfad zum Ziel übertragen zu werden, teilt die Quelle das Paket in Fragmente auf und sendet jedes Fragment als separates Paket, das von einem Fragment-Header gefolgt wird.
Am Ziel werden diese Fragmente zu ihrem ursprünglichen unfragmentierten Paket wieder zusammengesetzt (Reassembly). Das bedeutet, dass Fragmente am Zielknoten als vollständige Pakete ankommen können, die unabhängig vom IPv6-Netzwerk-Schicht-Code behandelt werden können.
Um den ursprünglichen unfragmentierten IPv6-Header zu rekonstruieren:
-
Der Header der höheren Schicht wird aus dem Fragment mit Fragment-Offset Null erhalten.
-
Der Payload-Length-Wert wird als die Summe der folgenden Größen berechnet:
- Die Länge aller Fragment-Data-Bereiche
- Die Länge aller Erweiterungsheader zwischen dem IPv6-Header und dem Fragment-Header im ersten Fragment
-
Der Next-Header-Wert des IPv6-Headers wird aus dem Next-Header-Feld des Fragment-Headers im ersten Fragment abgerufen.
Die Identification-Werte müssen (MUST) von der sendenden Quelle generiert werden, um fragmentierte Pakete eindeutig zu identifizieren. Implementierungen sollten (SHOULD) die Anleitungen in [RFC7739] befolgen.
Folgende Fehlerbehandlungs-Regeln gelten:
-
Wenn die Länge eines Fragments kleiner als 1280 Oktetten (die minimal erforderliche IPv6-MTU) ist, sollte (SHOULD) das Fragment verworfen werden und eine ICMP-Parameter-Problem-Nachricht (Code 0) an die Quelladresse gesendet werden.
-
Wenn sich überlappende Fragmente erkannt werden [RFC5722], sollten (SHOULD) sie verworfen werden.
4.6 Destination Options Header (Zieloptionen-Header)
Der Destination-Options-Header wird verwendet, um optionale Informationen zu übertragen, die nur vom Zielknoten (oder Zielknoten) eines Pakets untersucht werden müssen. Der Destination-Options-Header wird durch einen Next-Header-Wert von 60 im unmittelbar vorhergehenden Header identifiziert und hat das folgende Format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-Bit-Selektor. Identifiziert den Typ des Headers, der unmittelbar auf den Destination-Options-Header folgt. Verwendet dieselben Werte wie das IPv4-Protokollfeld [IANA-PN].
Hdr Ext Len 8-Bit vorzeichenlose Ganzzahl. Länge des Destination-Options-Headers in 8-Oktetten-Einheiten, ohne die ersten 8 Oktetten.
Options Variable Länge. Länge so, dass die vollständige Länge des Destination-Options-Headers ein ganzzahliges Vielfaches von 8 Oktetten ist. Enthält eine oder mehrere TLV-kodierte Optionen, wie in Abschnitt 4.2 beschrieben.
Der Destination-Options-Header kann bis zu zweimal in einem IPv6-Paket erscheinen: einmal vor einem Routing-Header (für von Zwischenzielen zu verarbeitende Optionen) und einmal vor dem Header der höheren Schicht (für nur vom endgültigen Ziel zu verarbeitende Optionen).
Derzeit sind keine spezifischen Destination-Optionen in diesem Dokument definiert. Zukünftige Dokumente können solche Optionen definieren.
4.7 No Next Header (Kein nächster Header)
Der Wert 59 im Next-Header-Feld eines IPv6-Headers oder eines Erweiterungsheaders zeigt an, dass nach diesem Header nichts folgt. Wenn das Payload-Length-Feld des IPv6-Headers ungleich Null ist, enthält das Paket Informationen (wie Padding), die nach dem Header erscheinen, der das Next-Header-Feld mit dem Wert 59 trägt. Wenn das Payload-Length-Feld Null ist, zeigt es an, dass nach dem IPv6-Header nichts folgt.