A2. IPv6 Extension Headers (IPv6-Erweiterungsheader)
Diese Tabelle zeigt, wie die IPv6-Erweiterungsheader hinsichtlich "Veränderbarkeit" klassifiziert werden.
MUTABLE BUT PREDICTABLE (Veränderlich aber vorhersagbar) -- in ICV-Berechnung einbezogen
| Option/Extension Name | Reference |
|---|---|
| Routing (Type 0) | [DH98] |
BIT INDICATES IF OPTION IS MUTABLE (Bit zeigt an, ob Option veränderlich ist) (ändert sich unvorhersehbar während der Übertragung)
| Option/Extension Name | Reference |
|---|---|
| Hop-by-Hop options | [DH98] |
| Destination options | [DH98] |
NOT APPLICABLE (Nicht anwendbar)
| Option/Extension Name | Reference |
|---|---|
| Fragmentation | [DH98] |
Detaillierte Beschreibung
Options (Optionen) -- IPv6-Optionen in den Hop-by-Hop- und Destination Extension Headers enthalten ein Bit, das anzeigt, ob sich die Option während der Übertragung (unvorhersehbar) ändern könnte. Für jede Option, deren Inhalt sich unterwegs ändern kann, muss das gesamte "Option Data"-Feld als auf Null gesetzte Oktette behandelt werden, wenn der ICV berechnet oder überprüft wird. Der Option Type und Opt Data Len sind in die ICV-Berechnung einbezogen. Alle Optionen, für die das Bit Unveränderlichkeit anzeigt, sind in die ICV-Berechnung einbezogen. Siehe die IPv6-Spezifikation [DH98] für weitere Informationen.
Routing (Type 0) -- Der IPv6 Routing Header "Type 0" ordnet die Adressfelder innerhalb des Pakets während der Übertragung von der Quelle zum Ziel neu an. Der Inhalt des Pakets, wie es beim Empfänger erscheinen wird, ist jedoch dem Sender und allen Zwischenhops bekannt. Daher wird der IPv6 Routing Header "Type 0" in die Integrity Check Value-Berechnung als veränderlich aber vorhersagbar einbezogen. Der Sender muss das Feld so ordnen, dass es erscheint, wie es beim Empfänger sein wird, bevor die ICV-Berechnung durchgeführt wird.
Fragmentation (Fragmentierung) -- Fragmentierung erfolgt nach ausgehender IPsec-Verarbeitung (Abschnitt 3.3) und Wiederzusammensetzung erfolgt vor eingehender IPsec-Verarbeitung (Abschnitt 3.4). Daher wird der Fragmentation Extension Header, falls er existiert, von IPsec nicht gesehen.
Beachten Sie, dass auf der Empfangsseite die IP-Implementierung einen Fragmentation Extension Header an Ort und Stelle lassen könnte, wenn sie die Wiederzusammensetzung durchführt. Wenn dies geschieht, dann MUSS AH, bevor es die ICV-Verarbeitung durchführt, diesen Header "entfernen" (oder überspringen) und das "Next Header"-Feld des vorherigen Headers ändern, um das "Next Header"-Feld im Fragmentation Extension Header zu sein.
Beachten Sie, dass auf der Sendeseite die IP-Implementierung dem IPsec-Code ein Paket mit einem Fragmentation Extension Header mit Offset von 0 (erstes Fragment) und einem More Fragments Flag von 0 (letztes Fragment) geben könnte. Wenn dies geschieht, dann MUSS AH, bevor es die ICV-Verarbeitung durchführt, zuerst diesen Header "entfernen" (oder überspringen) und das "Next Header"-Feld des vorherigen Headers ändern, um das "Next Header"-Feld im Fragmentation Extension Header zu sein.