6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
Extracted elements (22)
GHC uses an LZ77-style bytecode approach rather than a full general data compression scheme (like DEFLATE/RFC 1951) because the objective is an extremely simple specification implementable in a small number of lines of code, suitable for constrained devices.
RFC 6282 lacks an extensibility scheme like ROHC profiles, requiring new specifications for every new header type. 6LoWPAN-GHC addresses this by plugging into the existing NHC concept with a generic, slightly less efficient but vastly more general compression scheme that can be defined on a single page.
The Length field of extension headers is completely elided (not compressed, but omitted) in GHC encoding and reconstructed only on decompression. This is the easiest and most efficient approach given that the length cannot be extracted before decoding the GHC bytecodes.
Specifications using the 6CIO must be designed so that receivers that do not receive or do not process a capability indication can still interoperate, presumably without exploiting the indicated capability. The option is meant to be sent sparsely—once the sender has reason to believe the indication was received, there is no need to continue sending it.
Flag numbers 0 to 7 in the 6LoWPAN Capability Bits registry are reserved for experimental use and MUST NOT be used for actual deployments.
Unassigned bits in the 6CIO MUST be sent as zero and MUST be ignored on reception until assigned by IANA. Length values larger than 1 MUST be accepted by implementations to enable future extensions.
Where GHC capability has not been recently confirmed, a node SHOULD make use of Neighbor Unreachability Detection (NUD) failures to switch back to basic 6LoWPAN header compression (RFC 6282), similar to how PLPMTUD detects network changes.
Decompression variables 'sa' and 'na' are initialized to zero at the start of decompressing each header or payload within an L2 packet (fragment). The 101nssss instruction accumulates extended offset/length for subsequent backreferences, and the 11nnnkkk instruction resets both to zero after use.
The decompression buffer is prefixed by a 48-byte predefined dictionary consisting of the source IPv6 address (16 bytes), destination IPv6 address (16 bytes), and a 16-byte static dictionary (16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00). These bytes are available for backreferencing but not copied into the final payload.
The stop code (bytecode 0b10010000) terminates a GHC-encoded extension header. It is required for extension headers because the Length field is elided and there is no other way to detect the end of the compressed header; it is not needed for final payloads, which end with the packet.
IANA allocated ND option number 36 for the '6LoWPAN Capability Indication Option (6CIO)' in the 'IPv6 Neighbor Discovery Option Formats' registry (RFC 4861).
IANA assigned three NHC byte values in the 'LOWPAN_NHC Header Type' registry: 10110EEN for Extension Header GHC, 11010CPP for UDP GHC, and 11011111 for ICMPv6 GHC.
IANA created a '6LoWPAN Capability Bits' subregistry under ICMPv6 Parameters with bits numbered 0–47 (16th bit onward of the 6CIO). Initial assignments: bits 0–7 reserved for experimental use, bits 8–14 unassigned, bit 15 is the GHC capable (G) bit, bits 16–47 unassigned. Assignment policy is IETF Review or IESG Approval.
An attacker may forge a packet causing a node to believe a victim node is GHC capable when it is not, preventing packets from reaching the victim until NUD failure triggers fallback to basic 6LoWPAN-HC. With secured ND, the 6CIO is also secured, mitigating this attack.
Deployments relying solely on MAC-layer security may be vulnerable to compression side-channel attacks: an attacker in radio range who can inject a known value into the same packet as a secret value may recover information about the secret through compression ratio observation. Mitigation: do not expose secret values at the adaptation layer, or use transport/application/IP-layer security instead.
GHC decompression bombs (crafted packets that expand to consume excessive resources) are bounded by the MTU. Worst-case GHC amplification is 17x, enabling an MTU-size packet to be generated from a 76-byte 6LoWPAN packet, potentially turning a 250 kbit/s 802.15.4 network into a 3.8 Mbit/s attacker at the edge router. All such attacks are mitigated by network access control.
Implementations must guard against buffer overflows and out-of-area backreferences during decompression. The backreferencing mechanism could be exploited to reference memory outside the valid expansion buffer if not carefully bounds-checked.
The 6LoWPAN Capability Indication Option (6CIO) is a Neighbor Discovery option (Figure 5) with Type=36, Length=1, and a G bit at position 15 (the 31st bit of the option) indicating GHC capability. All unassigned bits MUST be sent as zero and MUST be ignored on reception.
The GHC bytecode table defines five instruction types encoded in a single code byte: literal copy (0kkkkkkk, k<96 bytes of data follow), zero-fill (1000nnnn, appends nnnn+2 zero bytes), stop code (10010000), extended backreference setup (101nssss, modifies sa/na variables), and backreference (11nnnkkk, copies n=na+nnn+2 bytes from s=kkk+sa+n bytes back in the output buffer).
The NHC byte for Extension Header GHC is formatted as 1011EID NH (Figure 4), where EID is the Extension Header ID (0–3 per RFC 6282) and NH indicates whether the next header is compressed.
The NHC byte for ICMPv6 GHC is 11011111 (Figure 3), chosen to stay in the same general numbering space as the UDP GHC NHC byte.
The NHC byte for UDP GHC is formatted as 11010CPP (Figure 2), analogous to RFC 6282's 11110CPP for UDP, where C and PP have the same semantics but the UDP payload is GHC-compressed rather than supplied literally.