Routing & RPL · Study deck

IPv6 and 6LoWPAN for IoT

Internet Protocol is a set of rules for naming devices and moving packets between networks.

Packet Pete is your guide for this deck.

protocolsipv66lowpan

Packet Pete, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

separate what IPv6 addressing provides from what 6LoWPAN link adaptation provides
prove compression context and fragmentation limits before trusting a compressed packet
use border-router boundary evidence (prefix advertisement, context expansion, failure counters) to decide release readiness
Explain: 6LoWPAN is short for IPv6 over Low-Power Wireless Personal Area Networks.

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.

Major section

Start With One Compressed Packet

6LoWPAN is short for IPv6 over Low-Power Wireless Personal Area Networks.

It helps IPv6 packets fit those small radio frames.
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.

Major section

Start With One Compressed Packet (continued)

Shortening a header is safe only when both sides share the same context.

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.

Release requires address, adaptation, fragmentation, security, observability, and recheck evidence.

Major section

Start With One Compressed Packet (continued)

The far side must not treat a part packet as a full one.

Each case should show who owns the prefix, route, short form, and check after a change.
A large message may need many pieces, more radio time, and more chances to fail.
6LoWPAN becomes practical when you inspect one IPv6 packet before and after adaptation.

Major section

Overview: IPv6 Gives Addressing; 6LoWPAN Adapts The Link

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.

Address size establishes the addressing need, while the frame budget and shared compression context decide what can actually cross the low-power link.

IPv4 versus IPv6 chart compares address size, notation and scale, showing 32-bit versus 128-bit space and example dotted-decimal and compressed hexadecimal addresses.

Major section

Practitioner: Prove Compression Context And Fragmentation Limits

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.

A missing fragment must cause bounded discard, and the packet-size limit should be retested when the frame budget or payload changes.

A compression record distinguishes inferred fields, inline exceptions, next-header handling, and trace evidence.

Major section

Under the Hood: Border Router Boundaries Decide Release Readiness

Successful header reconstruction establishes the adaptation step; route and policy checks still determine whether the command reaches the sensor.

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.

The border router is a controlled boundary between constrained traffic and the wider IPv6 domain.

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

Fragmentation is a release gate because each extra fragment adds loss, latency, buffering, and reassembly risk.

Deck summary

Key takeaways

6LoWPAN is short for IPv6 over Low-Power Wireless Personal Area Networks.

Shortening a header is safe only when both sides share the same context.
The far side must not treat a part packet as a full one.
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.
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.

Retrieval practice

Recall check 1 of 3

Packet Pete says: answer from memory, then check your reasoning.

Q1A greenhouse control mesh runs IPv6 over 6LoWPAN for pump-status sensors and valve commands. The team says the 128-bit addresses make the mesh secure enough for release. What is the safest review response?

ALong IPv6 addresses prevent command misuse without access checks.

BIdentity, authorization, border policy, and monitoring need proof.

CIPv4 addresses secure pump commands better than IPv6 addresses.

D6LoWPAN encrypts application commands by default.

Show answer

Answer: B IPv6 is an addressing and routing foundation, not a complete security design.

Retrieval practice

Recall check 2 of 3

Packet Pete says: answer from memory, then check your reasoning.

Q2A 6LoWPAN design promises that every packet will compress to the same tiny header size. What evidence should a reviewer request?

AA single best-case compression diagram copied from a different stack.

BA guarantee that fragmentation can never happen on low-power links.

CPacket traces showing inferred fields, inline exceptions, headers, and fragments.

DOnly the application dashboard, because packet traces are unrelated to adaptation behavior.

Show answer

Answer: C 6LoWPAN review needs deployment-specific evidence for compression context, inline fields, next-header support, and fragment behavior.

Retrieval practice

Recall check 3 of 3

Packet Pete says: answer from memory, then check your reasoning.

Q3Which release evidence best proves an IPv6 and 6LoWPAN deployment is ready for constrained IoT traffic?

AA record assigning globally unique IPv6 addresses to the constrained nodes and the border router.

BA border-router diagram with no counters, logs, owner, or failure-mode evidence.

CA telemetry payload check showing that routine samples fit in a single compressed frame.

DA release record for address scope, compression, fragments, router policy, security, and rechecks.

Show answer

Answer: D Under the hood, IPv6 and 6LoWPAN readiness is proven at the boundary between constrained devices, adaptation behavior, border-router policy, and operations evidence.

Print reference

Answers

Answer key.

B · IPv6 is an addressing and routing foundation, not a complete security design.
C · 6LoWPAN review needs deployment-specific evidence for compression context, inline fields, next-header support, and fragment behavior.
D · Under the hood, IPv6 and 6LoWPAN readiness is proven at the boundary between constrained devices, adaptation behavior, border-router policy, and operations evidence.