5 6LoWPAN Header Compression

5.1 Start With the Packet That Must Fit

This section: Start With the Packet That Must Fit — Picture a soil sensor sending one small reading over a radio frame with little spare room.

Check What Was Removed and Restored

Picture a soil sensor sending one small reading over a radio frame with little spare room. 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. 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.

Send one reading, change an address, enlarge the payload, drop a piece, repeat it, and restart a relay. Compare the original and rebuilt headers at the receiver. 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.

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.

5.2 In 60 Seconds

This section: 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.

5.3 Learning Objectives

This section: 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.

5.4 Quick Check: 6LoWPAN Compression

This section: Quick Check: 6LoWPAN Compression

5.5 Prerequisites

This section: 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.

5.6 Compression Claim

This section: Compression Claim — The claim avoids two weak shortcuts.

Use a claim that can be inspected:

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.

5.7 IPHC Review Path

This section: IPHC Review Path — Use Figure 5.1 as the review sequence before accepting an IPHC claim.

Use Figure 5.1 as the review sequence before accepting an IPHC claim.

Inspect Figure 5.1 to ask which IPv6 and UDP fields may be shortened and which shared context must still stay valid at both ends.

+

Follow Figure 5.1 from the original IPv6 and UDP fields into the compressed frame. Shared context may elide predictable prefixes and link-derived addresses, while port patterns can shorten UDP fields; the checksum and any non-inferable value still need correct treatment. Move next to decompression at the receiving boundary, where the full header must be reconstructed before forwarding or delivery. Prefix lifetime and context version close the path. A small frame is useful only when both ends share current context and packet capture proves the recovered addresses, ports, length, and checksum.

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.

5.8 Header Size and Recoverability

This section: Header Size and Recoverability — A standard IPv6 header is 40 bytes.

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.

5.9 Knowledge Check: Compression Target

This section: Knowledge Check: Compression Target

5.10 IPHC Field Decisions

This section: IPHC Field Decisions — IPHC does not magically shrink a packet.

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.

5.11 Address Reconstruction

This section: Address Reconstruction — Address compression is usually the largest part of the review.

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?”

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.

5.12 Context Custody

This section: Context Custody — Stateful compression shifts responsibility from bytes on the wire to shared context.

Stateful compression shifts responsibility from bytes on the wire to shared context. That context needs an owner, a distribution method, and a failure signal.

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.

5.13 UDP NHC Evidence

This section: UDP NHC Evidence — UDP NHC is a second review, not an automatic consequence of IPHC.

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. The release record should name the exact port pattern that was tested.

5.14 Capture Comparison

This section: Capture Comparison — Use Figure 5.3 to connect the compressed frame to the reconstructed packet and the application result.

Use Figure 5.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.

5.15 Worked Reviews

This section: Worked Reviews

5.16 Link-Local Telemetry

This section: Link-Local Telemetry

5.17 Routed Prefix With Context

This section: Routed Prefix With Context

5.18 Application Port Surprise

This section: Application Port Surprise

5.19 Common Mistakes

This section: Common Mistakes

5.20 Release Checklist

This section: Release Checklist

Before accepting an IPHC or NHC claim, require evidence for each item:

5.21 Stateless Address Autoconfiguration and Dispatch

This section: Stateless Address Autoconfiguration and Dispatch — Header compression works because the receiver can reconstruct omitted values from link context and shared prefix state.

Header compression works because the receiver can reconstruct omitted values from link context and shared prefix state. Address configuration must establish that context before an IPHC packet can safely depend on it.

Start with the link-local prefix fe80::/64. An IEEE 802.15.4 extended address is already an EUI-64; forming the IPv6 interface identifier inverts its universal/local bit. A 16-bit short address XXXX maps into the locally scoped 64-bit interface identifier

0000:00ff:fe00:XXXX

so short address 0x4a21 yields link-local address fe80::ff:fe00:4a21. 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.

A conventional autoconfiguration exchange proceeds in this order:

1. The node creates a tentative link-local address from fe80::/64 and its link-derived IID.
2. It sends a Router Solicitation when it needs router and prefix information rather than waiting for a periodic advertisement.
3. A router sends a Router Advertisement containing the on-link prefix and flags that describe autonomous or managed configuration.
4. The node combines an autonomous /64 prefix with an IID, or follows the network’s managed policy.
5. Before normal use, it establishes uniqueness. Classic IPv6 uses a Neighbor Solicitation for Duplicate Address Detection; constrained 6LoWPAN deployments often use registration-aware neighbour discovery so a border router can arbitrate addresses without expensive multicast.
6. Only after prefix, IID, lifetime, and registration state agree may the compressor elide address bits that the decompressor can reproduce.

The LOWPAN_IPHC base encoding occupies two octets, beginning with the dispatch pattern that identifies IPHC. 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. Count the actual IPHC base, optional CID, inline Traffic Class/Flow Label, Next Header, Hop Limit, source bits, and destination bits for the capture in front of you.

Use this release check: decode the dispatch, record every IPHC control bit, name the link field or context that reconstructs each elided value, and then rebuild the full IPv6 header. If any omitted bit has no single authoritative reconstruction source, the compressed packet is not operational evidence; it is an ambiguity waiting for a context change.

5.22 Figure Review: Parse, Fragment, Reconstruct

This section: Figure Review: Parse, Fragment, Reconstruct — The fastest way to debug a compressed packet is to reconstruct its header stack in parser order and ask why every optional header exists.

The fastest way to debug a compressed packet is to reconstruct its header stack in parser order and ask why every optional header exists.

+

Figure 5.4 makes the two omission tests concrete: MULTIHOP / ONE FRAME adds MESH, while SINGLE / FRAGMENTED adds FRAG; every row still preserves DISPATCH → IPHC → PAYLOAD order.

Once fragmentation or mesh-under routing is present, individual bit fields become byte offsets, address widths, and forwarding state.

+

In Figure 5.5, FRAGN · 5 bytes carries an offset[7:0] measured in eight-byte units, while the MESH ADDRESSING HEADER grows from 5 to 17 bytes and drops a packet after its hop limit reaches zero.

Compression is safe only when the receiver can identify a trusted source for every omitted IPv6 field.

+

The SAME LINK case in Figure 5.6 reaches a two-byte compressed header because prefix and IID are inferable; NO SHARED STATE keeps the full header inline, and the RS → RA → NS / DAD → READY rail shows how reconstruction state is established first.

5.23 Summary

This section: Summary — 6LoWPAN header compression is reliable when it is treated as evidence.

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.

5.24 Key Takeaway

This section: Key Takeaway — 6LoWPAN Header Compression Evidence should tie compression choices to IPv6 addressing, context state, packet size, interoperability, debugging visibility, and deployment evidence.

6LoWPAN Header Compression Evidence should tie compression choices to IPv6 addressing, context state, packet size, interoperability, debugging visibility, and deployment evidence.

5.25 Concept Relationships

This section: Concept Relationships

5.26 What’s Next

This section: 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.

5.27 Knowledge Check: Address Reconstruction

This section: Knowledge Check: Address Reconstruction

5.28 Knowledge Check: Context Drift

This section: Knowledge Check: Context Drift

5.29 Concept Match

This section: Concept Match — Match each compression item with the evidence it should produce.

Match each compression item with the evidence it should produce.

5.30 Evidence Order

This section: Evidence Order — Place the IPHC review steps in the strongest order.

Place the IPHC review steps in the strongest order.