5 6LoWPAN Header Compression

5.1 Start With the Packet That Must Fit

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

• 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

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

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

5.6 Compression Claim

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

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

Before IPHC Review Path, inspect Figure 5.1 to compare “ports, checksum” with “prefix lifetime”. Their juxtaposition makes 6LoWPAN IPHC review path visible.

Read Figure 5.1 from “ports, checksum” to “prefix lifetime”. Taken together, “ports, checksum” and “prefix lifetime” express 6LoWPAN IPHC review path. For IPHC Review Path, the observed relationship between “ports, checksum” and “prefix lifetime” is evidence that “ports, checksum” carries into the next decision.

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

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.

Before header Size and Recoverability, inspect Figure 5.2 to compare “SAM” with “Up to”. Their juxtaposition makes 6LoWPAN IPHC header compression field map visible.

Read Figure 5.2 from “SAM” to “Up to”. Taken together, “SAM” and “Up to” express 6LoWPAN IPHC header compression field map. For header Size and Recoverability, the observed relationship between “SAM” and “Up to” is evidence that “SAM” carries into the next decision.

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

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

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

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

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

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

Use Figure 5.3 to connect the compressed frame to the reconstructed packet and the application result.

Before capture Comparison, inspect Figure 5.3 to compare “(40 bytes)” with “Compress”. Their juxtaposition makes 6LoWPAN IPHC header compression of the IPv6 header visible.

Read Figure 5.3 from “(40 bytes)” to “Compress”. Taken together, “(40 bytes)” and “Compress” express 6LoWPAN IPHC header compression of the IPv6 header. For capture Comparison, the observed relationship between “(40 bytes)” and “Compress” is evidence that “(40 bytes)” carries into the next decision.

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

5.16 Link-Local Telemetry

5.17 Routed Prefix With Context

5.18 Application Port Surprise

5.19 Common Mistakes

5.20 Release Checklist

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

5.21 Stateless Address Autoconfiguration and Dispatch

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

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

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

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

5.26 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

5.28 Knowledge Check: Context Drift

5.29 Concept Match

Match each compression item with the evidence it should produce.

5.30 Evidence Order

Place the IPHC review steps in the strongest order.