Zigbee, Thread & Matter · Study deck
6LoWPAN Hands-On and Security
Hands-on 6LoWPAN work should prove that a constrained IPv6 design can be built, observed, secured, and recovered.
Radio Remi is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Build a 6LoWPAN hands-on plan that names hardware or simulator roles, traffic classes, and acceptance evidence.
- Review border-router setup without relying on copied commands as proof of connectivity.
- Capture and interpret evidence for prefix consistency, IPHC compression, fragmentation behavior, RPL routing, and UDP or CoAP traffic.
- Choose link-layer, transport, or object security boundaries based on trust assumptions and packet-growth evidence.
Major section
Start With the Observable Result
A protocol means agreed rules for exchanging messages.
- 6LoWPAN is an adaptation method for carrying network packets across constrained low-power links.
- A payload means the useful content inside a message.
- A protected radio hop must not be reported as protection across every later service.
- This lab does not prove production readiness.
Major section
In 60 Seconds
A hands-on 6LoWPAN lab needs a scoped claim, not just a working demo.
- Border-router evidence must include prefix ownership, route state, neighbor state, packet capture, and failure visibility.
- Packet checks should prove header compression, fragmentation boundaries, and application traffic behavior on the tested path.
- Link-layer security protects a radio hop or mesh boundary; end-to-end or object security protects payload meaning across untrusted infrastructure.
Major section
Hands-On Claim
Hands-on claim:: The lab proves the named 6LoWPAN traffic path because setup records, border-router custody, prefix and compression context, route state, packet captures, security boundary, failure behavior, and retest triggers are documented.
- The claim prevents two weak outcomes.
- One is a code-only lab that compiles but does not explain the network behavior.
- The other is a security-only discussion that names encryption without showing where plaintext, keys, routes, and operator access actually exist.
Major section
Border Router Evidence
The border router is both a network component and an operations boundary.
- It may advertise a prefix, act as an RPL root, forward packets to a Linux or gateway interface, log route state, and expose failure signals.
- A hands-on chapter should teach the learner to inspect those duties rather than copy a command and hope the mesh is healthy.
- Route state: The lab records parent choice, root role, route repair, and whether nodes disappear after reboot or movement.
Major section
Prefix And Context Checks
Prefix errors are common because several components must agree: the border router, node firmware, route advertisement, compression context, and upstream route.
- The lab should make this explicit.
- A lab that cannot show the failure mode is not ready to teach troubleshooting.
- Learners need to see how a prefix or context mismatch appears in route state, packet capture, logs, and application behavior.
Major section
Security Boundary
Security is not one switch.
- A link-layer mechanism can protect radio frames on a hop or within a mesh, but relay or border-router behavior may still expose payloads depending on the stack and application design.
Major section
Security Layer Stack
IEEE 802.15.4 can protect radio frames with AES-CCM* at the link layer.
- Object security can protect the payload meaning even when intermediaries route, log, or transform metadata.
- These mechanisms answer different trust questions and should not be treated as interchangeable switches.
- A hands-on lab should show the boundary with one named packet.
Major section
Security Layer Stack (continued)
With only link-layer security, a radio capture should not reveal the protected frame on that hop, but each forwarding device that participates in link security can process plaintext before re-encrypting for the next hop.
- With DTLS or object security added, the application payload remains protected beyond those forwarding points, so the border router can route without understanding the measurement.
- The release record should therefore name three observation points: radio capture, border-router logs, and service endpoint.
- The radio capture proves what is visible on the constrained hop.
- 6LoWPAN security is layered because the network is still an IPv6 stack.
Major section
Frame Counter And Replay Evidence
AES-CCM* uses counter-mode encryption with authentication.
- Like all counter-mode designs, it depends on a nonce that is never reused with the same key.
- In IEEE 802.15.4 security, the frame counter is part of that nonce.
- If a node reboots and repeats old counter values with the same key, the lab has not just lost a statistic; it has broken the cryptographic assumption behind confidentiality and integrity.
Major section
End-To-End And Object Security Evidence
For UDP and CoAP traffic, end-to-end or object security protects the application data beyond a single radio hop.
- That may involve DTLS, OSCORE, or another application-specific protection model.
- The review question is not "which acronym is strongest." The question is whether the security boundary matches the trust boundary and whether packet growth stays compatible with the constrained path.
- Security evidence is strong when it links a threat to a measured path.
Major section
Common Mistakes
Code as proof: A compiled UDP example does not prove address, route, compression, security, or failure behavior.
- Prefix drift: The border router, node firmware, route advertisement, and compression context can silently disagree.
- Security slogan: Saying "AES is enabled" or "DTLS is enabled" does not show trust boundaries, key lifecycle, or packet growth.
- Happy-path-only lab: Learners need at least one controlled failure so they can identify real faults later.
Major section
Release Checklist
Scope recorded: Node roles, software stack, radio context, traffic class, and observation points are named.
- Border router verified: Prefix custody, route state, neighbor state, forwarding, and restart behavior are visible.
- Packet path captured: Compression, fragmentation boundary, route behavior, and service receipt are evidenced.
- Failure tested: Wrong prefix, wrong key, route loss, replay rejection, timeout, or oversized payload behavior is observed.
Major section
Summary
Hands-on 6LoWPAN and security work should leave behind a lab record, not just working code.
- The record should prove setup, prefix consistency, compression context, route behavior, border-router custody, packet capture, security boundary, and failure visibility.
- This lets learners understand why the lab works and how to diagnose the first real failure.
- Link-layer protection, end-to-end protection, object security, key lifecycle, replay behavior, and packet growth all affect whether a constrained IPv6 path is acceptable.
Deck summary
Key takeaways
A protocol means agreed rules for exchanging messages.
- A hands-on 6LoWPAN lab needs a scoped claim, not just a working demo.
- Hands-on claim:: The lab proves the named 6LoWPAN traffic path because setup records, border-router custody, prefix and compression context, route state, packet captures, security boundary, failure behavior, and retest triggers are documented.
- The border router is both a network component and an operations boundary.
- Prefix errors are common because several components must agree: the border router, node firmware, route advertisement, compression context, and upstream route.
Retrieval practice
Recall check 1 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q1In a 6LoWPAN lab, how do link-layer security and object (end-to-end) security differ?
Show answer
Answer: A Link-layer security protects a radio hop or mesh boundary; object security protects payload meaning across untrusted paths.
Retrieval practice
Recall check 2 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q2Why must an IEEE 802.15.4 device keep its AES-CCM* frame counter from rolling back after reboot?
Show answer
Answer: A The IEEE 802.15.4 frame counter is part of the AES-CCM* nonce, so rollback can reuse a nonce with the same key and break security.
Retrieval practice
Recall check 3 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q3A learner says a 6LoWPAN border-router lab is complete because the node printed an IPv6 address and a UDP message was sent once. What evidence is still needed before accepting the lab?
Show answer
Answer: B Hands-on evidence must prove the network path, not only a successful printout or one message.
Retrieval practice
Recall check 4 of 4
Radio Remi says: answer from memory, then check your reasoning.
Q4A 6LoWPAN lab enables IEEE 802.15.4 link-layer security. The border router is operated by a different team and should not see payload meaning. What should the review require next?
Show answer
Answer: C Security review ties protection mechanism to trust boundary, packet behavior, and operations evidence.
Print reference
Answers
Answer key.
- A · Link-layer security protects a radio hop or mesh boundary; object security protects payload meaning across untrusted paths.
- A · The IEEE 802.15.4 frame counter is part of the AES-CCM* nonce, so rollback can reuse a nonce with the same key and break security.
- B · Hands-on evidence must prove the network path, not only a successful printout or one message.
- C · Security review ties protection mechanism to trust boundary, packet behavior, and operations evidence.