Zigbee, Thread & Matter · Study deck
6LoWPAN Header Compression
6LoWPAN header compression is a reconstruction contract.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain the IPHC field decisions that control traffic class, flow label, next header, hop limit, source address, destination address, and context use.
- Review whether an IPv6 address can be elided, shortened, context-compressed, or must remain inline.
- Distinguish stateless link-local reconstruction from stateful context-based compression.
- Interpret UDP NHC evidence, including port-compression limits and checksum handling.
Major section
Start With the Packet That Must Fit
A normal network header may be larger than the useful data.
- Compression helps only if the receiver rebuilds the exact meaning.
- Internet Protocol means the addressing rules used to move network packets.
- IPv6 means version 6 of those rules.
- IEEE 802.15.4 means a low-power radio and link standard.
Major section
Start With the Packet That Must Fit (continued)
The useful question is not which field is shortened first, but what evidence proves the adaptation still carries the right meaning.
- 6LoWPAN means a way to carry IPv6 over that small radio.
- User Datagram Protocol (UDP) means sending separate messages without a lasting connection.
- A payload means the useful data inside one message.
Major section
Start With the Packet That Must Fit (continued)
A shorter frame must not hide a changed source or stale result.
- This runway does not prove the best context or radio budget.
- The deeper sections show which fields can be inferred, when context is shared, how UDP shrinks, and where tests must catch a bad rebuild.
- Compression, fragmentation, reassembly, and retries make sense when they are tied to that visible journey.
Major section
In 60 Seconds · Compression Claim
Packet captures should prove both the compressed frame and the reconstructed IPv6 packet.
- IPHC compresses IPv6 by recording which fields are carried, shortened, or reconstructed.
- Address compression is strongest when link-local addresses can be rebuilt from IEEE 802.15.4 link-layer addresses.
- A release record must state when compression assumptions need retesting.
Major section
IPHC Review Path · Header Size and Recoverability
A link-local telemetry message, a global CoAP request, a multicast control message, and a routed diagnostic response can produce different compression evidence even inside the same mesh.
- A standard IPv6 header is 40 bytes.
- The important evidence rule is simple: compression omits bytes, not meaning.
Major section
IPHC Field Decisions · Address Reconstruction
IPHC does not magically shrink a packet.
- A reviewer should identify the decision for each field before accepting a packet-size claim.
- A QoS-marked path needs evidence, not assumption.
- UDP is commonly reviewed with NHC; unsupported headers need inline evidence.
- Hop limit: Common hop-limit values can be encoded compactly.
Major section
Context Custody
The sender and receiver must agree on the same prefix, index, lifetime, and owner; otherwise the packet can decompress to a plausible but wrong destination and look like a routing or application failure.
- That context needs an owner, a distribution method, and a failure signal.
- A successfully formed global IPv6 address is not automatically removable from a 6LoWPAN frame.
- The joined trace names the reconstruction source for both omitted addresses and shows why the same payload now fits one frame.
Major section
UDP NHC Evidence
UDP NHC is a second review, not an automatic consequence of IPHC.
- The reviewer should confirm how the next header is encoded, which UDP fields are carried, and whether port compression actually applies to the tested ports.
- Port compression is often where best-case examples drift away from real application traffic.
- A default application port, an ephemeral port, or a security-wrapped exchange can produce a different NHC result.
Major section
Routed Prefix With Context · Application Port Surprise
Scenario:: A node sends a message through a border router to a service prefix shared through context compression.
- A gateway failover or prefix change should trigger retest.
- Scenario:: A learner expects maximum UDP NHC compression, but the application uses ports that do not match the stack's most compact mode.
- If the larger header pushes the packet toward fragmentation, the fragmentation chapter becomes part of the approval path.
Major section
Common Mistakes · Release Checklist
Fragmentation blind spot: Forgetting that weaker compression can push a packet into fragmentation and change the reliability review.
- Traffic scoped: The message type, address scope, route boundary, security mode, and application ports are named.
- Field decisions recorded: The record says which IPv6 and UDP fields are inline, compressed, or reconstructed.
- Context verified: Any stateful prefix context has an owner, index, lifetime, distribution method, and visible failure path.
Major section
Stateless Address Autoconfiguration and Dispatch
An IEEE 802.15.4 extended address is already an EUI-64; forming the IPv6 interface identifier inverts its universal/local bit.
- The mapping is reversible only while the link-layer address assignment remains valid.
- A short address change, PAN rejoin, or context change is therefore a header-decompression and neighbour-cache event, not just an administrative rename.
- The LOWPAN_IPHC base encoding occupies two octets, beginning with the dispatch pattern that identifies IPHC.
Major section
Stateless Address Autoconfiguration and Dispatch (continued)
A third context-identifier octet appears when source or destination compression selects one of up to 16 shared contexts.
- The remaining IPHC bits say whether Traffic Class and Flow Label are carried, whether Next Header is compressed, how Hop Limit is represented, and which source/destination address parts are inline, statelessly derived, or context-derived.
- That final distinction prevents a common error. "2, 12, or 20 bytes" are worked outcomes for particular field and context choices, not three packet types.
- Header compression works because the receiver can reconstruct omitted values from link context and shared prefix state.
Major section
Figure Review: Parse, Fragment, Reconstruct · Summary
The fastest way to debug a compressed packet is to reconstruct its header stack in parser order and ask why every optional header exists.
- Once fragmentation or mesh-under routing is present, individual bit fields become byte offsets, address widths, and forwarding state.
- 6LoWPAN header compression is reliable when it is treated as evidence.
Major section
Key Takeaway · Concept Relationships
IPHC and fragmentation: Compression should be reviewed before fragmentation because packet growth can change whether splitting is needed.
- 6LoWPAN Header Compression Evidence should tie compression choices to IPv6 addressing, context state, packet size, interoperability, debugging visibility, and deployment evidence.
- IPHC and routing: Route-over forwarding still depends on correct reconstructed IPv6 addresses at each relevant boundary.
- IPHC and deployment: Stateful context compression is an operations responsibility, not just an encoding feature.
Deck summary
Key takeaways
A normal network header may be larger than the useful data.
- The useful question is not which field is shortened first, but what evidence proves the adaptation still carries the right meaning.
- A shorter frame must not hide a changed source or stale result.
- Packet captures should prove both the compressed frame and the reconstructed IPv6 packet.
- A link-local telemetry message, a global CoAP request, a multicast control message, and a routed diagnostic response can produce different compression evidence even inside the same mesh.
Retrieval practice
Recall check 1 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q1When is 6LoWPAN IPHC address compression strongest?
Show answer
Answer: A IPHC compresses most when link-local addresses can be reconstructed from the IEEE 802.15.4 link-layer address.
Retrieval practice
Recall check 2 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q2What does 6LoWPAN IPHC primarily compress, and what makes that safe?
Show answer
Answer: A IPHC reduces IPv6 header bytes only when the receiver can rebuild the logical IPv6 packet.
Retrieval practice
Recall check 3 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q3A compressed 6LoWPAN packet omits a link-local source address. What evidence should a reviewer require before accepting that omission?
Show answer
Answer: B IPHC address elision is a reconstruction claim and must be verified against link-layer evidence and the decompressed IPv6 packet.
Retrieval practice
Recall check 4 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q4A border router changes the global prefix used by a 6LoWPAN mesh, but some nodes still compress packets using the old context index. What is the strongest review response?
Show answer
Answer: C Context-based compression is safe only when context ownership, synchronization, and failure handling are explicit.
Print reference
Answers
Answer key.
- A · IPHC compresses most when link-local addresses can be reconstructed from the IEEE 802.15.4 link-layer address.
- A · IPHC reduces IPv6 header bytes only when the receiver can rebuild the logical IPv6 packet.
- B · IPHC address elision is a reconstruction claim and must be verified against link-layer evidence and the decompressed IPv6 packet.
- C · Context-based compression is safe only when context ownership, synchronization, and failure handling are explicit.