Skip to main content

4.2. IPv6 Extension Header Compression

A necessary property of encoding headers using LOWPAN_NHC is that the immediately preceding header must be encoded using either LOWPAN_IPHC or LOWPAN_NHC. In other words, all headers encoded using the 6LoWPAN encoding format defined in this document must be contiguous. As a result, this document defines a set of LOWPAN_NHC encodings for selected IPv6 Extension Headers such that the UDP Header Compression defined in Section 4.3 may be used in the presence of those extension headers.

The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a single LOWPAN_NHC octet followed by the IPv6 Extension Header. The format of the LOWPAN_NHC octet is shown in Figure 13. The first 7 bits serve as an identifier for the IPv6 Extension Header immediately following the LOWPAN_NHC octet. The remaining bit indicates whether or not the following header utilizes LOWPAN_NHC encoding.

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

              Figure 13: IPv6 Extension Header Encoding

EID: IPv6 Extension Header ID:

  • 0: IPv6 Hop-by-Hop Options Header [RFC2460]
  • 1: IPv6 Routing Header [RFC2460]
  • 2: IPv6 Fragment Header [RFC2460]
  • 3: IPv6 Destination Options Header [RFC2460]
  • 4: IPv6 Mobility Header [RFC6275]
  • 5: Reserved
  • 6: Reserved
  • 7: IPv6 Header

NH: Next Header:

  • 0: Full 8 bits for Next Header are carried in-line.
  • 1: The Next Header field is elided and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4.1.

For the most part, the IPv6 Extension Header is carried unmodified in the bytes immediately following the LOWPAN_NHC octet, with two important exceptions: Length field and Next Header field.

The Next Header field contained in IPv6 Extension Headers is elided when the NH bit is set in the LOWPAN_NHC encoding octet. Note that doing so allows LOWPAN_NHC to utilize no more overhead than the non-encoded IPv6 Extension Header.

The Length field contained in a compressed IPv6 Extension Header indicates the number of octets that pertain to the (compressed) extension header following the Length field. Note that this changes the Length field definition in [RFC2460] from indicating the header size in 8-octet units, not including the first 8 octets. Changing the Length field to be in units of octets removes wasteful internal fragmentation.

IPv6 Hop-by-Hop and Destination Options Headers may use a trailing Pad1 or PadN to achieve 8-octet alignment. When there is a single trailing Pad1 or PadN option of 7 octets or less and the containing header is a multiple of 8 octets, the trailing Pad1 or PadN option MAY be elided by the compressor. A decompressor MUST ensure that the containing header is padded out to a multiple of 8 octets in length, using a Pad1 or PadN option if necessary. Note that Pad1 and PadN options that appear in locations other than the end MUST be carried in-line as they are used to align subsequent options.

Note that specifying units in octets means that LOWPAN_NHC MUST NOT be used to encode IPv6 Extension Headers that have more than 255 octets following the Length field after compression.

When the identified next header is an IPv6 Header (EID=7), the NH bit of the LOWPAN_NHC encoding is unused and MUST be set to zero. The following bytes MUST be encoded using LOWPAN_IPHC as defined in Section 3.

Last updated on