Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
updated by
- rfc-8066 — IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines
updates
- rfc-4944 — Transmission of IPv6 Packets over IEEE 802.15.4 Networks
Extracted elements (35)
LOWPAN_HC1 (RFC 4944) is insufficient because it requires full 128-bit addresses for routable or multicast destinations, cannot shorten IIDs derived from 16-bit short addresses, and cannot compress Hop Limit values other than 1. LOWPAN_IPHC remedies all three limitations.
Short 802.15.4 addresses are mapped to the restricted EUI-64 space (0000:00ff:fe00:XXXX) rather than the unrestricted space used by real EUI-64 identifiers, ensuring no overlap with IIDs generated from extended addresses and avoiding collisions with other locally managed IIDs.
The Traffic Class field is rotated right by 2 bits in compressed form so that the ECN bits always appear at a fixed position (bits 0–1) across all TF encoding variants, allowing ECN processing without requiring the full Traffic Class to be in-line.
UDP checksum elision requires upper-layer authorization (not just compressor judgment) to guarantee the destination has sufficient means to detect data corruption. This preserves end-to-end integrity semantics even when the lower-layer path lacks the checksum.
All headers compressed with LOWPAN_NHC must be contiguous — each encoded header must immediately follow a header encoded with LOWPAN_IPHC or LOWPAN_NHC. A plain uncompressed header in the chain breaks the encoding and prevents further LOWPAN_NHC use.
Fragment payload size and offset values in RFC 4944 fragmentation are defined relative to the IPv6 datagram before compression, so all fragments beyond the first must carry their respective uncompressed IPv6 datagram portions; this document does not change that requirement.
A compressor MUST NOT set the UDP checksum C bit (elide the checksum) unless it has received explicit authorization from the upper layer. The upper layer MUST NOT authorize elision unless tunneling with its own integrity check or an in-payload MIC covers at least the same data as the UDP checksum.
A compressor MUST verify the UDP checksum before eliding it and MUST ensure the additional integrity check is in place before doing so; if verification fails, the compressor MUST drop the packet.
A decompressor expanding a packet with C=1 MUST recompute the UDP checksum and place it in the restored UDP header. If it cannot unambiguously determine that an integrity check was in place or verification fails, it MUST drop the packet.
A decompressor MUST ensure that a compressed IPv6 Hop-by-Hop or Destination Options header is padded out to a multiple of 8 octets using Pad1 or PadN if necessary; Pad1/PadN at non-trailing positions MUST be carried in-line.
An additional integrity check (e.g., L2 MIC) MUST be used whenever transmitting link frames that carry a compressed UDP datagram with the checksum elided, to prevent undetected corruption of pseudo-header data.
IID bits not covered by context information MAY be elided only if they match the link-layer address mapping; they MUST NOT be elided if they do not match.
Implementation of Section 10 of RFC 4944 (LOWPAN_HC1/HC2) is NOT RECOMMENDED. New implementations MAY implement decompression of RFC 4944 Section 10 but SHOULD NOT send packets compressed according to it.
LOWPAN_NHC MUST NOT be used to encode IPv6 Extension Headers that have more than 255 octets following the Length field after compression, due to the Length field being redefined in units of octets (single byte).
The IPv6 Payload Length field MUST always be elided in LOWPAN_IPHC and inferred from lower layers (6LoWPAN Fragmentation header or IEEE 802.15.4 header).
The Reserved field in stateful unicast-prefix-based multicast address compression (M=1, DAC=1, DAM=00) MUST carry the reserved bits from RFC 3306; when a Rendezvous Point is encoded per RFC 3956, it MUST carry the RIID bits in-line.
The UDP Length field MUST always be elided in LOWPAN_NHC UDP encoding and inferred from lower layers.
When an IPv6-in-IPv6 header is identified (EID=7) in LOWPAN_NHC, the NH bit MUST be set to zero and the following bytes MUST be encoded using LOWPAN_IPHC.
When using RFC 4944 fragmentation, any header that cannot fit within the first fragment MUST NOT be compressed.
LOWPAN_NHC Extension Header encoding redefines the IPv6 Extension Header Length field to be in units of octets (not 8-octet units), eliminating internal fragmentation waste that the RFC 2460 definition creates for small compressed headers.
LOWPAN_NHC uses a variable-length bit-pattern identifier to distinguish compression formats for different next headers. The number of bits used for the NHC ID SHOULD reflect the expected frequency of use and respect octet alignment.
Stateful address compression (SAC=1 or DAC=1) derives addresses from a shared context identified by a 4-bit Context Identifier (0–15). Context 0 is the default when CID=0. The context used for source and destination addresses may differ.
UDP ports in the range 0xf0b0–0xf0bf can be compressed to 4 bits using stateless compression (P=11 in UDP LOWPAN_NHC). This is a 16-port range inherited from RFC 4944 and is not IANA-reserved.
A new IANA registry for LOWPAN_NHC header types is created with policy IETF Review. Initial assignments cover IPv6 extension headers (1110xxxN), UDP (11110CPP), and reserved ranges; unassigned ranges are 00000000–11011111 and 11111000–11111110.
RFC 6282 allocates 32 LOWPAN_IPHC dispatch type field values (01 100000 through 01 111111) in the 6LoWPAN dispatch namespace, preempting the ESC value 01 111111. The value 01 000000 is reserved as an ESC replacement.
How shared context is assigned and managed is out of scope for RFC 6282. Prefix injection via a rogue context could redirect traffic; the security of context distribution is a deployment concern not addressed by this specification.
Using ports 0xf0b0–0xf0bf increases the risk of delivering the wrong payload type or misinterpreting content because 16 applications may share the same compressed port value. It is recommended to protect these communications with a TLS/MIC integrity mechanism.
A short IEEE 802.15.4 16-bit address is mapped to a 64-bit IID as 0000:00ff:fe00:XXXX (XXXX = short address), placing 0xfffe in the middle 16 bits and setting the universal/local bit to zero to indicate local scope.
IPv6 Extension Header LOWPAN_NHC encoding is a single octet: bits 0–3 are '1110', bits 4–6 are EID (extension header type), and bit 7 (NH) indicates whether the following header also uses LOWPAN_NHC.
LOWPAN_IPHC base encoding occupies 2 octets (bits 0–1 are '01', bit 2 is '1', followed by TF[2], NH[1], HLIM[2], CID[1], SAC[1], SAM[2], M[1], DAC[1], DAM[2]). An optional third octet (Context Identifier Extension) is appended when CID=1, containing SCI[4] and DCI[4].
Stateful unicast-prefix-based multicast addresses (M=1, DAC=1, DAM=00) are compressed to 6 octets carrying 4-bit Flags, 4-bit Scope, 8-bit Rsvd/RIID, and 32-bit Group Identifier in-line; prefix length and network prefix are taken from context.
Stateless multicast addresses (M=1, DAC=0) can be compressed to 48 bits (ffXX::00XX:XXXX:XXXX), 32 bits (ffXX::00XX:XXXX), or 8 bits (ff02::00XX), carrying Flags, Scope, and the least-significant Group Identifier bits in-line.
The Context Identifier Extension is a single octet split into SCI (bits 0–3) and DCI (bits 4–7), each identifying a 4-bit context index (0–15) for stateful source and destination address compression respectively.
Traffic Class is rotated right by 2 bits in the compressed header so ECN always occupies bits 0–1. Four encoding variants are defined: TF=00 carries ECN+DSCP+pad+Flow Label (4 bytes); TF=01 carries ECN+pad+Flow Label (3 bytes, DSCP elided); TF=10 carries ECN+DSCP (1 byte, Flow Label elided); TF=11 elides both.
UDP LOWPAN_NHC encoding is a single octet: bits 0–4 are '11110', bit 5 (C) indicates checksum elision, and bits 6–7 (P) indicate port compression mode—00 full ports in-line, 01 destination upper byte elided (0xf0), 10 source upper byte elided (0xf0), 11 both upper 12 bits elided (0xf0b).