12 Lab: 6LoWPAN Address and Fragment
Address Evidence, Compression Context, Fragment Gates, Border Routers, and Release Decisions
12.1 Start With the Trace Pair
The 6LoWPAN lab is strongest when every claim has a pair of traces. One trace shows the constrained-link frame, and the other shows the IPv6 packet as the border router or host interprets it.
Compare those traces before changing settings. The lab should explain address scope, compression context, fragmentation, hop limit, and payload identity so the learner can prove the adaptation layer preserved the traffic story rather than hiding it.
By the end of this lab, you will be able to:
- Build an IPv6 address-scope record for constrained devices and gateways.
- Explain which IPv6 and UDP fields can be carried, derived, or compressed by 6LoWPAN context.
- Decide when a payload should be held below a fragmentation gate.
- Verify what a border router must preserve when expanding or forwarding constrained traffic.
- Produce a release record with security controls, operations evidence, and recheck triggers.
Overview: 6LoWPAN Evidence Starts At The Boundary
This lab is about proving where an IPv6 claim changes as traffic crosses a constrained link. The address may look familiar, but the record still has to show address scope, prefix ownership, compression context, frame fit, fragmentation risk, and border-router behavior. A room sensor that responds to a link-local probe has not proved end-to-end reachability; it has proved only that one local neighbor interaction worked.
Use a concrete lab path. Suppose a sensor publishes a 52-byte temperature and humidity report over UDP every five minutes. The IPv6 and UDP headers are far larger than the application payload before compression, while the constrained link also needs MAC framing and security overhead. The release question is therefore not "does IPv6 work?" The question is whether the address record, compression context, and frame budget still leave a routine packet that can be sent, retried, logged, and troubleshot without hiding failure at the border router.
A defensible overview record names the constrained segment, the border router, the prefix owner, the compression context owner, and the operational symptom each failure would produce. If a prefix changes, the recheck is address evidence. If a context identifier changes, the recheck is compression evidence. If the payload grows, the recheck is fragmentation evidence. The practical question is whether this deployment has enough evidence to say the constrained segment can carry the required traffic without turning normal operations into guesswork.
Keep the boundary language precise. The constrained side may use short frames, sleepy radios, neighbor discovery shortcuts, and local retries; the IPv6 side may assume routed prefixes, longer paths, monitoring, and firewall policy. 6LoWPAN is the adaptation evidence between those assumptions. A good lab therefore treats the border router as a measured boundary, not as an invisible converter, and records exactly what it expands, drops, forwards, logs, and owns.
Practitioner: Build The Constrained-Link Release Record
Write the lab record as a release packet, not as a screenshot collection. Include the device identity, local and routed address evidence, shared compression context, payload and overhead estimate, single-frame or fragmentation decision, border-router controls, failure classification, and recheck trigger. Each line should answer a support question: who owns the prefix, what context was active, what packet size was tested, what the router logged, and what event forces a retest.
For example, a building monitor may use link-local discovery, a routed building prefix, UDP telemetry, link-layer security, and a border-router rule that permits only the collector address. If the normal encoded payload is 52 bytes and the compressed network headers plus security overhead leave it inside the single-frame budget, the record can mark routine telemetry as ready. If a firmware build adds a 70-byte diagnostic field, the same record should make the result obvious: the payload may cross the fragmentation gate, so release becomes ready with limits or redesign until the extra field is split, sampled less often, or moved to a less constrained transfer path.
That packet should support one of three decisions: ready, ready with named limits, or redesign. "Ready" means the evidence is complete for the named payload and path. "Ready with limits" means the design is acceptable only under recorded size, route, context, security, or logging constraints. "Redesign" means the lab found an unclear address owner, stale context risk, routine fragmentation, missing router evidence, or an operations gap that would make failures hard to diagnose.
Make the record reviewable by another team. Store the packet capture name, firmware build, context table version, router rule identifier, payload schema version, and expected counters. A reviewer should be able to rerun the lab after a schema or prefix change and compare the same fields. If the result depends on a special lab-only router configuration, mark the release as blocked until production configuration evidence replaces it.
Under the Hood: Compression And Fragmentation Move Failure
6LoWPAN header compression works only when both sides share enough context to rebuild the IPv6 and UDP meaning correctly. Version, traffic class, flow label, length, address prefix, interface identifier, next header, and UDP port information can be carried, inferred, elided, or compressed depending on the path. That is useful only if sender, receiver, and border router agree on the same assumptions. When that context is stale, missing, or inconsistent, the failure may appear as packet loss unless the border router logs the reason.
The lab should separate three failure modes that often look the same from the application side. First, an address-scope failure means the packet never had a valid routed path beyond the local link. Second, a compression-context failure means the receiving side cannot reconstruct the IPv6 or UDP meaning safely. Third, a fragmentation failure means the packet was valid in principle but depended on multiple constrained-link frames, reassembly state, and timeouts. Treating all three as "sensor offline" would erase the evidence needed to fix the actual layer.
Fragmentation changes the risk model too. A larger packet can be split across smaller link frames, but each fragment adds loss exposure, reassembly state, retry cost, and diagnostic work. If a 6LoWPAN packet needs three fragments, one lost fragment can invalidate the whole packet even when two fragments arrived. The release gate should keep routine telemetry below that risk unless the constraint is explicit, measured, and tied to a fallback such as chunking, reduced optional fields, slower reporting, or a nonroutine maintenance path.
The under-the-hood check should also connect counters to decisions. A capture can show that compression saved bytes, but the release record should show whether the receiver accepted the reconstructed header, whether the router classified any drops, whether reassembly timers were exercised, and whether retry counters stayed within the allowed budget. Those facts decide if the design is operationally safe, not the theoretical compression ratio alone.
12.2 Lab Scenario
You are reviewing a constrained building-sensing network. Room nodes send environmental readings to a local border router. The router connects the low-power segment to the rest of the IPv6 network. The design team wants end-to-end IP visibility without hiding constrained-link problems behind a gateway.
The lab starts with three records:
Who is reachable?
Device identifier, link-local address, routed prefix, next hop, and address owner.
What fits?
Payload size, compressed headers, security overhead, and whether the message stays in one link frame.
What changes?
Compression, expansion, routing, filtering, logging, and failure ownership at the border router.
12.3 Part 1: Build The Address Evidence
Start with address scope. A lab trace that only shows “an IPv6 address” is not enough. The review should identify where the address is valid, who assigned it, and which operational action depends on it.
Run it: Watch an address actually form in the SLAAC and neighbor-discovery workbench below. Let a node build its link-local address, take a router advertisement, and derive a routed prefix, then run neighbor discovery to resolve a next hop. Note which address is only link-local valid and which one carries a routed prefix, and use that to fill the scope, prefix, next-hop, and owner-action fields below instead of guessing from the raw address.
Record these fields:
- Device identity: The stable device record used by inventory, authorization, and support.
- Link-local address: The address used on the local constrained link.
- Routed prefix: The prefix used when the node or border router communicates beyond the local link.
- Next hop: The border router, route, or mesh path expected for forwarded traffic.
- Owner action: What support team should do when this address path fails.
12.4 Part 2: Inspect The Compression Context
6LoWPAN does not make IPv6 disappear. It uses context to avoid carrying information that can be derived safely. The lab should show which fields are carried, which are derived from link-layer context, and which must remain visible for routing, checks, and debugging.
Run it: Step the IPHC compression animation below through the same packet. Watch each IPv6 header field get elided when it can be derived from link-layer context and stay inline when it cannot, and see the dispatch byte that tells the receiver how to rebuild it. Use it to sort this trace’s fields into the carry, derive, check, and log rows below, so the evidence table reflects what compression actually removed rather than a guess.
Review the trace using this evidence table:
Still transmitted
Fields that cannot be inferred safely must remain in the compressed packet or an associated header.
Known from context
Addresses, prefixes, or ports may be reconstructed only when both sides share the same context.
Validate on receive
The receiver must rebuild the packet consistently and reject traffic that does not match policy.
Make failures visible
Compression-context mismatch should appear as a diagnosable error, not as a silent message loss.
Use exact byte arithmetic only as supporting evidence. The main decision is whether the compressed packet can be reconstructed correctly and operated safely.
12.5 Part 3: Apply The Fragmentation Gate
IPv6 expects links to support an IPv6 MTU, while constrained links may carry much smaller frames. 6LoWPAN can fragment larger packets, but fragmentation increases loss exposure and makes recovery harder to reason about. The lab should define a gate before release.
Run it: Push a packet through the fragmentation animation below to see the gate in action. Grow the payload past the frame budget and watch it split into 6LoWPAN fragments, then drop one fragment and watch reassembly fail for the whole packet. Use it to feel why routine telemetry belongs in the single-frame path, and record the fragment count, loss behavior, and fallback in the gate below.
The gate should answer:
What is the contract?
List required fields, optional fields, encoding, and how much growth is expected.
What remains?
Estimate compressed IPv6, UDP, 6LoWPAN dispatch, link, and security overhead for this path.
Single frame or review?
Keep routine telemetry in the single-frame path unless the release record explicitly accepts fragment risk.
What changes if it grows?
Split records, reduce optional fields, change reporting cadence, or move large transfer work out of the constrained path.
12.6 Part 4: Verify The Border-Router Boundary
The border router is not just a pipe. It owns context, route advertisement, filtering, translation between constrained and unconstrained link behavior, and operations evidence. A good lab trace shows what the router accepted, changed, forwarded, or rejected.
Check four router responsibilities:
- Context ownership: Which compression contexts and prefixes are valid for this constrained segment?
- Route behavior: What routes or prefixes does the router advertise, and where are they valid?
- Security control: Which traffic is allowed, filtered, rate-limited, or logged at the boundary?
- Failure evidence: Can operations distinguish node loss, context mismatch, fragment failure, and upstream route failure?
12.7 Part 5: Write The Release Decision
The release decision should be short and auditable. Avoid claiming that IPv6 or 6LoWPAN is automatically correct because it is a standard. The decision should say what the lab evidence proves for this deployment.
Use one of these outcomes:
Evidence is complete
Address scope, context, frame fit, router controls, and operations records are all verified.
Ready with limits
The design is acceptable only under named payload, routing, context, or operational limits.
Evidence fails
Unclear routes, routine fragments, stale context, or missing logs block release.
12.8 Lab Deliverable
Your deliverable is a one-page release record. Include:
- Address plan: Device identity, link-local address, routed prefix, next hop, and owner.
- Compression proof: Which fields are carried, derived, elided, and checked.
- Fragmentation gate: Routine payload limit, security margin, and redesign trigger.
- Border-router proof: Context, route, filtering, and failure evidence.
- Release outcome: Ready, ready with constraints, or redesign required.
- Recheck trigger: Payload schema change, prefix change, route change, security-control change, or link-condition change.
12.8.1 Label The Release Record
12.9 Common Pitfalls
A link-local address proves local-link behavior only. Record routed prefix and border-router evidence before claiming broader reachability.
Compression works only when sender and receiver agree on context. A context mismatch should be visible in logs and release checks.
Fragmentation may be valid, but routine telemetry that fragments by default is harder to operate. Define a gate and redesign trigger.
If the border router drops packets without classifying the reason, the team cannot separate node failure from route, context, or policy failure.
12.10 Summary
IPv6 gives constrained systems a common network layer, but 6LoWPAN is the adaptation evidence that makes it practical on small frames. A high-quality lab review separates address scope, compression context, fragmentation risk, border-router behavior, security controls, operations evidence, and lifecycle triggers. The final decision should be traceable to a release record, not to a generic statement that IPv6 or 6LoWPAN is efficient.
12.11 See Also
- IPv6 and 6LoWPAN - Addressing and adaptation concepts that support this lab.
- IoT Protocols Lab: CoAP vs MQTT - Application-layer trace review above the IPv6 path.
- IoT Protocols: Fundamentals - Layer responsibilities and protocol evidence.
- 6LoWPAN Architecture - Deeper adaptation-layer design.
- Border Router Design - Router boundary behavior for constrained networks.
12.12 What’s Next?
Protocol Overhead Analysis
Compare packet overhead while keeping operations evidence in view.
12.13 Key Takeaway
An IPv6/6LoWPAN lab should prove addressing, compression, routing, packet size, and loss behavior under constrained-link assumptions, not just show that packets can move once.