5 IPv6 and 6LoWPAN for IoT

5.1 Start With One Compressed Packet

This section: Start With One Compressed Packet — Internet Protocol is a set of rules for naming devices and moving packets between networks.

Internet Protocol is a set of rules for naming devices and moving packets between networks. IPv6 is version 6 of those rules. IEEE 802.15.4 is a standard for low-rate radio links used by small devices. 6LoWPAN is short for IPv6 over Low-Power Wireless Personal Area Networks. It helps IPv6 packets fit those small radio frames.

Picture a battery sensor sending one reading through a mesh to a border router. The IPv6 address says where the packet starts and ends. The 6LoWPAN layer shortens parts that both sides can infer. It may also split a packet that is too large for one radio frame.

Shortening a header is safe only when both sides share the same context. Splitting a packet adds risk because every piece must arrive before the packet can be rebuilt. A border router joins the small radio mesh to the wider IPv6 network and expands the short form.

This plain path assumes one known mesh and one border router. Real sites can use several address scopes, context rules, routes, and security checks. The Practitioner section explains those choices. Under the Hood shows the byte and fragment limits that can force a message redesign.

Use one packet as the test. Write its source and end address. Save the full header. Save the short form sent on the small link. List which fields were left out and where each missing value came from.

Then send a packet that does not fit. Count the pieces. Drop one piece on purpose. The far side must not treat a part packet as a full one. Record the wait, retry, and way the fault can be seen.

Restart the border router. Change a shared context. Try a local address and a wider address. Each case should show who owns the prefix, route, short form, and check after a change.

Keep the small message small when you can. A large message may need many pieces, more radio time, and more chances to fail. Change the message design when that cost is too high.

Mark the address scope in plain words. State whether a device must work on one link, inside one site, or across the wider net. Do not infer reach from the length of an address.

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?

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

The 32-bit and 128-bit address fields in Figure 5.1 explain why IPv6 can give many devices distinct addresses; they do not decide which 6LoWPAN fields can be compressed on a small frame. Address space is only one part of the claim: a compressed header must still fit the link budget and decode to the intended IPv6 endpoints.

In Figure 5.1, the visual shows 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. Address size establishes the addressing need, while the frame budget and shared compression context decide what can actually cross the low-power link.

+

Three labels organize Figure 5.1: “Overview: IPv6 Gives Addressing; 6LoWPAN Adapts The Link” establishes context, “IPv4 vs IPv6 Address Space” narrows the decision, and “Decision factor” states the evidence boundary. Their combined meaning is that iPv6 review starts with scope, prefix ownership, interface identity, neighbor behavior, and route ownership, which advances Overview: IPv6 Gives Addressing; 6LoWPAN Adapts The Link.

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.

Before accepting reachability, use Figure 5.2 to locate where IPv6 compression, fragmentation, link delivery, and border-router expansion must produce evidence.

+

Follow one packet down the stack. Check each changed form. Read Figure 5.2 from the IPv6 packet into the 6LoWPAN adaptation layer, where shared context compresses headers and oversized datagrams may be fragmented for constrained frames. Link and mesh support carry those pieces toward the border router, which expands the packet back into ordinary IPv6 form. Each boundary needs paired evidence: device-side and expanded captures, context version, fragment counters, reassembly result, and border policy. A successful join or formed mesh proves none of those transformations, so application delivery and return traffic remain the final reachability checks.

Hands-on lab · 90 min · Contiki-NG Cooja

Measure 6LoWPAN addresses and the fragment gate

I have explained 6LoWPAN adaptation; now let's inspect addresses, compression context, and fragment boundaries in a trace.

Open the lab

Hands-on lab · 35 min · Python 3 in your browser (JupyterLite)

6LoWPAN header-size budget

I have explained compression context; now let’s calculate how many payload bytes each address case leaves.

Open the lab

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

5.3 Practitioner: Prove Compression Context And Fragmentation Limits

This section: Practitioner: Prove Compression Context And Fragmentation Limits — 6LoWPAN compression depends on context.

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.

Use Figure 5.3 to determine which IPv6 fields were inferred from context, which remained inline, and how the expanded packet will be verified.

+

Read Figure 5.3 from the 40-byte IPv6 header to the 2–7-byte IPHC form. Version and length defaults can be inferred, while source and destination fields may be elided only when both ends share the relevant address context; exceptions remain inline. Next-header handling and Hop Limit still affect policy and troubleshooting after expansion. Capture the same representative packet before compression and after border-router reconstruction, then record the context and stack versions. Matching IPv6 semantics at those two points proves the byte saving without treating a brochure header size as universal behaviour.

In Figure 5.4, FRAG1 and FRAGN add reassembly work when a datagram exceeds the usable frame budget; the release check must include loss and buffer limits. Check the fragment sequence under loss and a full reassembly buffer before accepting the datagram path.

+

In Figure 5.4, the visual shows 6LoWPAN fragmentation evidence path from measured datagram and usable frame budgets through FRAG1 and FRAGN placement, bounded reassembly and missing-range discard to packet-size, loss, buffer, fallback, owner and retest release checks. A missing fragment must cause bounded discard, and the packet-size limit should be retested when the frame budget or payload changes.

5.4 Under the Hood: Border Router Boundaries Decide Release Readiness

This section: Under the Hood: Border Router Boundaries Decide Release Readiness — The 6LoWPAN border router is not just a cable between networks.

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.

The mesh-to-IPv6 boundary in Figure 5.5 puts compression, fragmentation, and route ownership at the border router. Test both directions through the border router; successful mesh forwarding does not establish that an IPv6 peer can return traffic.

+

For the greenhouse packet in Figure 5.5, pair a capture on the compressed mesh side with one after IPv6 expansion. Check that both identify the intended source and destination under the recorded context. Then test the return command separately. Successful header reconstruction establishes the adaptation step; route and policy checks still determine whether the command reaches the sensor.

Before accepting the failure counters, use Figure 5.6 to check whether address, adaptation, fragmentation, security, observability, and recheck evidence all support release.

+

Read Figure 5.6 from addressing and context through fragments and border policy. End at security and logs. Each gate asks one failure question. Does the address fit the planned scope? Does each side rebuild the same packet? Do packets stay within the tested fragment limit? Does border policy allow the flow? Can the team detect and explain loss? The last row makes approval short lived. A new context, larger payload, stack update, policy change, or route change must reopen the right test before release can stand.

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.

5.5 Summary

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

5.6 Key Takeaway

This section: Key Takeaway

5.7 See Also

This section: See Also — Carry the constrained-link result into Routing for IoT Networks, then use RPL Core Concepts to identify the protocol state above it.

Carry the constrained-link result into Routing for IoT Networks, then use RPL Core Concepts to identify the protocol state above it. Follow route formation in RPL DODAG Construction before comparing where downward state lives in Storing and Non-Storing Modes. That order preserves the chapter’s running boundary: link adaptation makes IPv6 carriage possible, while RPL state and mode determine how packets actually move.