11  IPv6 and 6LoWPAN for IoT

Addressing Evidence, Adaptation Boundaries, Fragmentation Risk, and Border Router Checks

routing-rpl
iot
protocols
ipv6

11.1 Start With One Compressed Packet

6LoWPAN becomes practical when you inspect one IPv6 packet before and after adaptation. The packet still needs addresses, headers, next-header meaning, and hop behavior, but the constrained link cannot afford to carry every byte in the usual way.

Start with the compression record. Which fields were inferred, which stayed inline, which context was used, and which fragment or border-router behavior would a reviewer need to reproduce the packet path?

Overview: IPv6 Gives Addressing; 6LoWPAN Adapts The Link

IPv6 gives IoT networks a consistent way to describe prefixes, scopes, routing domains, neighbor behavior, and reachability. 6LoWPAN is the adaptation layer that lets those IPv6 packets cross low-power links by compressing predictable fields, fragmenting packets when needed, and handing traffic to a border router.

The practical reason is size and ownership. An IPv6 packet expects a much larger network-layer envelope than a low-power IEEE 802.15.4 frame can usually carry after MAC, security, and application bytes are accounted for. 6LoWPAN therefore has to answer two release questions: which header fields can be inferred safely from shared context, and which oversized packets must be fragmented or redesigned before they are allowed onto the mesh. A good design note states the prefix owner, the context distributed to devices, the border router that expands compressed traffic, and the fallback when the packet no longer fits.

IPv4 versus IPv6 address space compared by size (32 versus 128 bits), notation, and scale, showing how IPv6 restores end-to-end addressing for global device identity.
IPv6 review starts with scope, prefix ownership, interface identity, neighbor behavior, and route ownership.

Address scope

Link-local, unique-local, and global unicast addresses each imply different reachability and operations expectations.

Prefix ownership

Prefix advertisement, delegation, renewal, and route policy must be known before devices depend on the prefix.

Identity

Interface identifiers can be derived, assigned, randomized, or managed; privacy and troubleshooting needs may conflict.

Reachability

Direct routing, gateway mediation, firewall policy, and application authorization are separate decisions from address size.

6LoWPAN adaptation stack between IPv6 and constrained link layers, showing compression, fragmentation, mesh support, border router expansion, and operations evidence.
6LoWPAN sits at an adaptation boundary: it preserves IPv6 semantics while accounting for constrained frames.

Review Rule

Do not treat IPv6 address space as a security control or 6LoWPAN compression as a fixed savings number. Record what the deployment actually needs: address scope, shared compression context, fragment limits, border-router ownership, security policy, and operations evidence.

For example, a greenhouse sensor may use a link-local address during neighbor discovery, a unique-local prefix for site traffic, and a routed prefix only through the border router. Those three scopes are not interchangeable. If a service ticket only says "IPv6 enabled", the reviewer still cannot tell whether a pump command is local-only, site-routed, or reachable from a platform API. The 6LoWPAN evidence should close that gap by showing the address scope, the compressed packet trace, and the route boundary together.

Practitioner: Prove Compression Context And Fragmentation Limits

6LoWPAN compression depends on context. Fields can be inferred only when the receiver has the same assumptions. Fragmentation is also contextual: it is acceptable only when packet size, frame budget, loss behavior, and reassembly buffers have been tested.

Start with representative packet captures rather than a brochure value. Capture a normal telemetry packet, a command packet, and a diagnostic or firmware-status packet at the device side and again after border-router expansion. For each trace, mark the IPv6 source and destination treatment, traffic-class or flow-label handling, hop-limit behavior, next-header compression, and any fields left inline for policy or troubleshooting. If two devices use different address contexts, the same application payload can produce different adaptation behavior, so the release record should name the context version as well as the stack version.

6LoWPAN IPHC header compression reducing the 40-byte IPv6 header to a 2-7 byte compressed header by inferring version and length defaults and eliding context-derived source and destination address fields.
A compression record distinguishes inferred fields, inline exceptions, next-header handling, and trace evidence.
Compression Question Evidence Failure Sign
Can address fields be inferred? Prefix context, link-layer identity, address scope, and packet trace. Packets expand differently at devices and border router.
Can next headers compress? Stack support for the transport profile actually used. Expected savings appear only in examples, not in deployment traces.
Which fields must stay inline? Policy, routing, telemetry, and diagnostic requirements. Compression hides a value that operations need for review.
6LoWPAN fragmentation review gate showing packet size, frame budget, fragment count, reassembly buffer, loss behavior, and retry policy.
Fragmentation is a release gate because each extra fragment adds loss, latency, buffering, and reassembly risk.

Payload budget

Know the largest telemetry, command, and diagnostic messages before choosing the link and adaptation strategy.

Reassembly memory

Devices and border routers must hold fragments without starving application, security, or routing work.

Loss counters

Operations need counters that reveal missing fragments before the application sees only missing messages.

Fallback path

Chunking, payload reduction, rate limits, or a different maintenance path may be safer than repeated fragmentation.

Under the Hood: Border Router Boundaries Decide Release Readiness

The 6LoWPAN border router is not just a cable between networks. It expands compressed headers, owns prefix advertisements, enforces routing and reachability policy, and often becomes the place where device-side evidence meets platform-side evidence.

The boundary also decides what operators can prove after a failure. If compressed traffic stops at the mesh but the cloud dashboard only reports "device offline", the team cannot distinguish context mismatch, fragment loss, parent-route churn, firewall rejection, or application back pressure. The border router should therefore expose counters for dropped fragments, reassembly timeout, context lookup failure, prefix advertisement changes, rejected routes, and security policy denial. Those counters turn a low-power packet path into an auditable service boundary.

6LoWPAN border router architecture bridging a low-power 6LoWPAN mesh network to the IPv6 internet through protocol translation, header compression, fragmentation, and RPL routing.
The border router is a controlled boundary between constrained traffic and the wider IPv6 domain.

Prefix advertisements

The team knows which prefixes are advertised, how they are renewed, and what happens when the border router changes.

Context expansion

Devices and border routers share the context needed to reconstruct valid IPv6 packets.

Reachability policy

Firewall, routing, and application authorization define who can reach device addresses and services.

Failure counters

Operations can distinguish context mismatch, fragment drops, routing failures, and platform-side rejection.

IPv6 and 6LoWPAN release gate with checks for addressing, compression context, fragmentation limits, border router policy, security, observability, and recheck triggers.
Release requires address, adaptation, fragmentation, security, observability, and recheck evidence.

Release Evidence

  1. Address scope, prefix ownership, configuration method, and privacy expectations are documented.
  2. Representative packet traces prove compression and expansion behavior.
  3. Maximum normal message size, fragment count, reassembly buffer, and fallback path are tested.
  4. Border-router routing policy, firewall posture, and security controls are reviewed.
  5. Logs, counters, alerts, runbooks, and recheck triggers name who acts on failures.

A useful release rehearsal walks through one normal packet and one failure packet. The normal path should show a constrained device sending a compressed frame, the border router expanding it into an IPv6 packet, the routing policy allowing the destination, and the platform accepting the message. The failure path should show what happens when a context identifier changes, a fragment is missing, or a message exceeds the agreed budget. If the runbook cannot identify the owner and next action from those two traces, the deployment is not ready even if the happy-path demo works.

11.2 Summary

  • IPv6 gives IoT systems a scalable addressing and routing foundation, but address size is not a security control.
  • 6LoWPAN adapts IPv6 to constrained links through context-dependent compression, fragmentation, and border-router expansion.
  • Compression evidence must name inferred fields, inline exceptions, shared context, next-header support, and representative traces.
  • Fragmentation needs payload budgets, buffer checks, loss counters, and fallback behavior before release.
  • Border routers own prefix advertisement, context expansion, routing policy, security posture, observability, and recheck triggers.

11.3 Key Takeaway

IPv6 and 6LoWPAN are ready for constrained IoT only when address scope, adaptation behavior, fragmentation limits, border-router policy, security controls, and operations evidence are all reviewable.

11.4 See Also