5 IPv6 and 6LoWPAN for IoT

5.1 Start With One Compressed Packet

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.

Before accepting the overview: ipv6 gives addressing; 6lowpan adapts the link claim, examine Figure 5.1 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.

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. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the overview: ipv6 gives addressing; 6lowpan adapts the link discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.

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 the reachability claim, examine Figure 5.2 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.

In Figure 5.2, the visual shows 6LoWPAN adaptation stack between IPv6 and constrained link layers, showing compression, fragmentation, mesh support, border router expansion, and operations evidence. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the reachability discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.

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

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.

Before accepting the practitioner: prove compression context and fragmentation limits claim, examine Figure 5.3 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.

In Figure 5.3, the visual shows 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. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the practitioner: prove compression context and fragmentation limits discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.

Before accepting the practitioner: prove compression context and fragmentation limits claim, examine Figure 5.4 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.

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. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the practitioner: prove compression context and fragmentation limits discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.

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

Before accepting the under the hood: border router boundaries decide release readiness claim, examine Figure 5.5 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.

In Figure 5.5, the visual shows 6LoWPAN border router architecture bridging a low-power 6LoWPAN mesh network to the IPv6 internet through protocol translation, header compression, fragmentation, and RPL routing. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the under the hood: border router boundaries decide release readiness discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.

Before accepting the failure counters claim, inspect Figure 5.6 to connect the protocol description to observable control-plane, route-state, and packet evidence. This matters because a routing label or formed topology alone cannot prove that the required traffic path works or recovers at its boundaries.

In Figure 5.6, the visual shows iPv6 and 6LoWPAN release gate with checks for addressing, compression context, fragmentation limits, border router policy, security, observability, and recheck triggers. Start with the input or initial condition, follow the labelled relationships through each intermediate stage, and finish at the decision, output, or feedback path; at every transition, identify what evidence would confirm the change. This ordered reading connects the failure counters discussion to the chapter’s running argument: a routing decision is credible only when its control state, forwarding result, failure response, and retest trigger can be checked together.

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

• 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

5.7 See Also

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.