4 6LoWPAN Header Compression
6LoWPAN header compression, IPHC evidence, 6LoWPAN NHC UDP, constrained IPv6 packet capture, compression context custody
6LoWPAN header compression is a reconstruction contract. The sender omits IPv6 and UDP fields only when the receiver can rebuild them from the IPHC flags, the link-layer frame, shared context, and protocol defaults. A strong review therefore asks a simple question: which fields were omitted, where did the missing information come from, and how do we know the receiver reconstructed the intended packet?
This chapter treats IP Header Compression (IPHC) and Next Header Compression (NHC) as packet evidence, not as a best-case savings slogan. It focuses on field decisions, address reconstruction, context custody, UDP port limits, capture review, failure signals, and release records.
4.1 Start With the Packet That Must Fit
Start with the packet pressure behind 6LoWPAN Header Compression: IPv6 semantics have to survive on a small, lossy, low-power frame. The useful question is not which field is shortened first, but what evidence proves the adaptation still carries the right meaning.
Follow one payload from the original packet to the constrained link and back to the review record. Compression, fragmentation, reassembly, and retries make sense when they are tied to that visible journey.
4.2 In 60 Seconds
- 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.
- Stateful context compression can reduce global prefix overhead, but only when context tables are synchronized and observable.
- UDP NHC can reduce transport-header overhead, but port compression has specific range limits and checksum handling must be reviewed.
- Packet captures should prove both the compressed frame and the reconstructed IPv6 packet.
- A release record must state when compression assumptions need retesting.
4.3 Learning Objectives
By the end of this chapter, 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.
- Build a compression review record that links captures, context tables, reconstructed packets, and failure tests.
4.4 Quick Check: 6LoWPAN Compression
4.5 Prerequisites
This chapter assumes you have reviewed:
- 6LoWPAN Fundamentals and Architecture Evidence, for the adaptation-layer boundary.
- 6LoWPAN Fragmentation and Reassembly Evidence, for why compressed packet size matters before fragmentation.
- 6LoWPAN Deployment Evidence Framework, for border-router and context-custody planning.
- 6LoWPAN Hands-On and Security Evidence, for packet-capture and lab-record expectations.
- IEEE 802.15.4 Fundamentals, for constrained frame context.
4.6 Compression Claim
Use a claim that can be inspected:
Compression claim: The packet path is acceptable because every omitted IPv6 or UDP field can be reconstructed from a named source, the compressed and decompressed views agree, and context or port assumptions are monitored for drift.
The claim avoids two weak shortcuts. One shortcut is saying “headers shrink from 40 bytes to 2 bytes” without proving that the tested addresses, hop limit, traffic class, context, and next header actually permit that result. The other is treating compression as harmless by default even when context mismatch, multicast, external prefixes, extension headers, or security wrapping may change the packet shape.
Compression decision State which fields are inline, compressed, or elided for the tested traffic.
Reconstruction source Name whether each omitted value comes from link-layer addresses, default values, context tables, packet length, or NHC rules.
Evidence boundary State whether the proof applies only to link-local traffic, one routed prefix, one port pair, one security mode, or one payload family.
4.7 IPHC Review Path
Use Figure 4.1 as the review sequence before accepting an IPHC claim.
The path starts with traffic scope because compression is traffic-specific. 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.
4.8 Header Size and Recoverability
A standard IPv6 header is 40 bytes. 6LoWPAN IPHC, defined by RFC 6282, can reduce that header to a few bytes in favorable cases by eliding fields that are constant, derivable from the link-layer frame, or reconstructable from shared context. NHC then applies the same evidence idea to the next header, commonly UDP.
The important evidence rule is simple: compression omits bytes, not meaning. Version is known, payload length can be derived from the lower layer, common hop limits can be encoded compactly, and address fields can be shortened only when the receiver has the link-layer or context evidence needed to rebuild them.
4.9 Knowledge Check: Compression Target
4.10 IPHC Field Decisions
IPHC does not magically shrink a packet. It encodes decisions about specific IPv6 fields. A reviewer should identify the decision for each field before accepting a packet-size claim.
Traffic class and flow label These fields can be carried, shortened, or elided only when the value and policy permit it. A QoS-marked path needs evidence, not assumption.
Next header The next-header field can point to compressed follow-on headers. UDP is commonly reviewed with NHC; unsupported headers need inline evidence.
Hop limit Common hop-limit values can be encoded compactly. Other values need explicit carriage and should be visible in reconstructed packets.
Source and destination addresses Address fields are reviewed independently. One address may be fully reconstructed while the other needs context or inline bytes.
Context identifier Stateful compression uses shared context. The context index is evidence only if both sender and receiver agree on the same prefix and lifetime.
Multicast and special addresses Multicast, external, temporary, or unusual addresses may compress differently and should not inherit a link-local best-case claim.
4.11 Address Reconstruction
Address compression is usually the largest part of the review. The key question is not “how many bytes were saved?” The key question is “how can the receiver rebuild the address without ambiguity?”
1. Identify address scope Separate link-local, mesh-local, global, multicast, and external destinations before estimating compression.
2. Check link-layer derivation For stateless reconstruction, prove that the IPv6 interface identifier is derivable from the link-layer address used on the tested hop.
3. Check context prefix For stateful reconstruction, record the context index, prefix, lifetime, distribution path, and border-router owner.
4. Compare reconstructed packet Use the capture tool or stack logs to compare the reconstructed IPv6 source and destination with the intended application path.
5. Test a mismatch Use a controlled stale or missing context test so learners can distinguish compression failure from routing or application failure.
Fully elided link-local addresses are a special case. They are valid only because the receiver has enough link-layer information to reconstruct the missing IPv6 address. Context-based global compression is different: it relies on shared state. A stale or mismatched context can produce a plausible but wrong decompressed address.
4.12 Context Custody
Stateful compression shifts responsibility from bytes on the wire to shared context. That context needs an owner, a distribution method, and a failure signal.
Context owner Which border router, root, gateway, or commissioning process defines the prefix and context index?
Context lifetime How long may a node use a context, and what forces refresh after reboot, gateway change, or prefix change?
Context visibility Can an operator see current and previous context tables when troubleshooting a decompression failure?
Context failure What does the stack report when a packet references an unknown, expired, or mismatched context?
Do not treat context compression as free. It can be the right answer for routed prefixes, but it adds state that must survive updates, failover, replacement, and mixed firmware versions.
In IPHC terms, a context identifier points to a shared IPv6 prefix entry. It is not evidence by itself. 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.
4.13 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.
Next-header flag Confirm that the IPHC decision says the next header is compressed and that the follow-on NHC encoding is present.
Port mode Record whether both ports, one port, or neither port matches a compressible range used by the stack.
Length handling Confirm how UDP length is reconstructed from the IPv6 payload length or lower-layer packet length.
Checksum handling Record whether the checksum is carried and validated. Do not assume checksum behavior from a diagram.
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. The release record should name the exact port pattern that was tested.
4.14 Capture Comparison
Use Figure 4.3 to connect the compressed frame to the reconstructed packet and the application result.
The capture record should include both views. The compressed view proves what was actually transmitted on the constrained link. The reconstructed view proves what the IPv6 stack delivered to the next layer. The application view proves that the packet identity and payload still mean what the lab or deployment intended.
4.15 Worked Reviews
4.15.1 Link-Local Telemetry
Scenario: A sensor sends a small telemetry message to a border router using link-local addressing and UDP.
Review: The record should show IPHC field decisions, link-layer address reconstruction for source and destination, hop-limit handling, UDP NHC mode, and reconstructed IPv6 packet identity. If a best-case size is claimed, the capture must prove the specific address and port conditions that make it true.
Decision: Accept only for the named link-local path. Routed global traffic still needs context evidence.
4.15.2 Routed Prefix With Context
Scenario: A node sends a message through a border router to a service prefix shared through context compression.
Review: The record should include context index, prefix, context lifetime, distribution method, sender table, receiver table, compressed capture, and reconstructed destination. A gateway failover or prefix change should trigger retest.
Decision: Accept when context custody and failure visibility are documented. Do not reuse the result for a different prefix or border-router owner.
4.15.3 Application Port Surprise
Scenario: A learner expects maximum UDP NHC compression, but the application uses ports that do not match the stack’s most compact mode.
Review: The packet should still be valid, but the release record must show the actual NHC port mode and revised packet-size evidence. If the larger header pushes the packet toward fragmentation, the fragmentation chapter becomes part of the approval path.
Decision: Accept the application port choice only with the observed NHC mode and packet-fit result.
4.16 Common Mistakes
Best-case reuse Applying a link-local best-case result to global, multicast, security-wrapped, or routed traffic.
Context invisibility Using stateful compression without a way to inspect context index, prefix, lifetime, and owner.
Port assumption Assuming UDP ports compress maximally without checking the actual source and destination port mode.
Capture without reconstruction Showing a compressed frame but not proving the decompressed IPv6 source, destination, next header, and payload meaning.
Ignoring failure mode Not testing stale context, unknown context, unsupported next header, or noncompressible address behavior.
Fragmentation blind spot Forgetting that weaker compression can push a packet into fragmentation and change the reliability review.
4.17 Release Checklist
Before accepting an IPHC or NHC claim, require evidence for each item:
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.
Captures compared Compressed frame, reconstructed IPv6 packet, and application receipt agree.
Failure tested Wrong context, missing context, noncompressible port, unsupported header, or packet-growth behavior is observed.
Retest triggers named Prefix, border router, firmware, security mode, application port, payload size, and route changes reopen review.
4.18 Summary
6LoWPAN header compression is reliable when it is treated as evidence. IPHC decisions must explain how omitted IPv6 fields are reconstructed. Address compression must separate link-local stateless reconstruction from stateful context-based prefix compression. UDP NHC must be checked against the real port and checksum behavior of the tested traffic.
The strongest chapter record compares the compressed frame, reconstruction sources, decompressed IPv6 packet, and application result. It also includes at least one failure test so a learner can recognize stale context, unsupported header, port-mode surprise, or packet growth before those problems appear in a deployment.
4.19 Key Takeaway
6LoWPAN Header Compression Evidence should tie compression choices to IPv6 addressing, context state, packet size, interoperability, debugging visibility, and deployment evidence.
4.20 Concept Relationships
IPHC and architecture Compression belongs to the 6LoWPAN adaptation layer and must preserve the IPv6 packet meaning above it.
IPHC and fragmentation Compression should be reviewed before fragmentation because packet growth can change whether splitting is needed.
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.
4.21 What’s Next
Continue with these chapters:
- 6LoWPAN Fragmentation and Reassembly Evidence, to review packet growth and reassembly risk.
- 6LoWPAN Routing with RPL, to connect reconstructed IPv6 packets to route-over mesh behavior.
- 6LoWPAN Deployment Evidence Framework, to place context custody into a release plan.
- 6LoWPAN Pitfalls and Debugging, to recognize compression-context and packet-size failures.
- 6LoWPAN Hands-On and Security Evidence, to practice capture-based validation.
4.22 Knowledge Check: Address Reconstruction
4.23 Knowledge Check: Context Drift
4.24 Concept Match
Match each compression item with the evidence it should produce.
4.25 Evidence Order
Place the IPHC review steps in the strongest order.