4.2. Kompression von IPv6-Erweiterungsheadern

IPv6-Erweiterungsheader können unter Verwendung des LOWPAN_NHC-Formats codiert werden. Dieses Dokument definiert die Codierung für IPv6 Hop-by-Hop Options, Routing, Fragment und Destination Options Header.

    0   1   2   3   4   5   6   7
  +---+---+---+---+---+---+---+---+
  | 1 | 1 | 1 | 0 |EID|NH |   |   |
  +---+---+---+---+---+---+---+---+

        Abbildung 12: IPv6-Erweiterungsheader-Codierung

EID: Extension Header ID (Erweiterungsheader-ID):

• 0: IPv6 Hop-by-Hop Options Header
• 1: IPv6 Routing Header
• 2: IPv6 Fragment Header
• 3: IPv6 Destination Options Header

NH: Next Header:

• 0: Volle 8 Bits für Next Header werden inline transportiert.
• 1: Das Next Header-Feld wird komprimiert und der nächste Header wird unter Verwendung von LOWPAN_NHC codiert.

Die verbleibenden Bits im LOWPAN_NHC-Oktett sind reserviert und SOLLTEN (SHOULD) auf Null gesetzt werden.

Für IPv6 Hop-by-Hop Options und Destination Options Header wird das Header Length-Feld (in 8-Oktett-Einheiten) durch das Payload Length-Feld (in Oktetten) ersetzt. Da die Länge des Hop-by-Hop Options und Destination Options Headers in 8-Oktett-Einheiten angegeben wird, ist es möglich, das Padding am Ende des Headers zu entfernen, sodass die Länge nur noch in Oktetten angegeben werden muss. Das Payload Length-Feld wird inline transportiert und gibt die Länge der Optionen in Oktetten an, abzüglich 2 Oktetten (für den Next Header und die Länge selbst).

Für den IPv6 Fragment Header wird das Reserved-Feld vollständig entfernt.

Für den IPv6 Routing Header bleibt das Header Length-Feld in 8-Oktett-Einheiten.