9 6LoWPAN Hands-On and Security
6LoWPAN hands-on, 6LoWPAN security, 6LoWPAN border router lab, constrained IPv6 lab evidence, 6LoWPAN packet capture
Hands-on 6LoWPAN work should prove that a constrained IPv6 design can be built, observed, secured, and recovered. It is not enough to compile a demo or copy a border-router command. The lab must show which traffic was tested, which prefix and compression context were used, where packets were captured, which security boundary was trusted, and what happened when the network failed.
This chapter turns hands-on work into a security evidence workflow. It keeps the practical ideas from Contiki-NG, RIOT, border routers, UDP or CoAP messages, RPL routes, and IEEE 802.15.4 security, but removes brittle code listings and replaces them with checks that a learner can apply to real hardware, simulation, or a controlled lab.
9.1 Start With the Observable Result
Start with the result a learner should be able to show after 6LoWPAN Hands-On and Security: a packet trace, commissioning step, mesh behavior, security decision, or lab record that someone else can inspect. The exercise matters because it turns protocol vocabulary into evidence.
Keep the first run small. Make one device join, route, fragment, commission, or report; record what happened; then use the deeper sections to explain why the result is trustworthy and what would force a retest.
9.2 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.
- The strongest lab record includes setup evidence, expected observations, actual observations, failure tests, and retest triggers.
9.3 Learning Objectives
By the end of this chapter, 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.
- Produce a release record that separates lab success from production readiness.
9.4 Quick Check: 6LoWPAN Lab Security
9.5 Prerequisites
This chapter assumes you have already reviewed:
- 6LoWPAN Fundamentals and Architecture Evidence, for the adaptation-layer boundary.
- 6LoWPAN Header Compression, for IPHC context and packet reconstruction.
- 6LoWPAN Fragmentation, for split-packet and reassembly risk.
- 6LoWPAN Routing with RPL, for route-over behavior and root duties.
- 6LoWPAN Deployment Evidence Framework, for pilot and release planning.
9.6 Hands-On Claim
Use a claim that can be tested:
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.
Lab scope Name the nodes, radio or simulator, border router, traffic type, security mode, and observation tools.
Evidence boundary State what the lab proves and what it does not prove about deployment scale, battery life, compliance, range, or production reliability.
Retest trigger Record which changes reopen review, such as a new prefix, firmware, radio channel, route policy, payload size, or security mode.
9.7 Lab Evidence Path
Use Figure 9.1 as the review path before accepting any hands-on result.
The path is intentionally ordered. A learner should not jump from “the node printed an address” to “the network is ready.” The lab should prove the address belongs to the intended prefix, the route exists, the packet is compressed or fragmented as expected, the security boundary matches the threat model, and failure is visible.
9.8 Lab Setup Evidence
A setup record should be short but precise. It should identify the tested environment without turning the chapter into a tool manual.
Device roles Which device is the 6LoWPAN node, relay, border router, capture point, service endpoint, and operator console?
Software stack Which OS, firmware build, 6LoWPAN stack, RPL mode, and application protocol are under test?
Radio context Which channel, PAN identity, link-layer security setting, and interference assumption are in scope?
Traffic path Which message is being sent, how often, to which destination, and with what expected response?
Observation points Where are serial logs, border-router logs, packet captures, route state, and application records collected?
Acceptance result What observation would count as pass, limit, redesign, or retest-required?
This record works whether the learner uses Contiki-NG, RIOT, OpenThread, a simulator, or a hardware testbed. The tool name matters less than the evidence trail.
9.9 Simulation Evidence Boundary
A simulator can make 6LoWPAN behavior observable, but it should be reviewed as a model with limits rather than proof of every deployment condition.
Model scope Record node roles, topology, radio assumptions, queue limits, link-loss model, RPL behavior, and what real hardware behavior is outside the run.
Packet behavior Observe IPHC context, fragmentation, reassembly, RPL changes, retries, security overhead, and application response timing in the trace.
Failure injection Run prefix mismatch, lost parent, oversized payload, route repair, replay rejection, and border-router outage cases before accepting the lab.
Release limit State which conclusion transfers to a hardware or field test and which conclusion requires new evidence.
Simulation evidence is strongest when it teaches what to look for in captures and logs, then names the remaining field checks.
9.10 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.
Prefix custody The advertised prefix, node addresses, compression context, and upstream route agree.
Route state The lab records parent choice, root role, route repair, and whether nodes disappear after reboot or movement.
Forwarding evidence The same application exchange is visible on the constrained side and the service side, with expected address translation or forwarding behavior.
Failure visibility The operator can see prefix mismatch, route loss, reassembly timeout, replay rejection, or authentication failure without guessing from silence.
9.11 Packet Capture Evidence
Packet capture should answer a question, not produce a decorative screenshot. Capture before and after the border router when possible, and pair the capture with a short explanation of what the learner expected to see.
Compression check Show whether addresses, hop limit, and UDP fields are compressed, carried, or reconstructed from context.
Fragmentation check Show whether the tested payload stays in one frame or enters a named fragmentation path with reassembly evidence.
Route check Show whether the packet crosses the expected parent, relay, root, and border-router path.
Security check Show which fields are visible at the radio capture point, border router, and service endpoint.
Do not teach learners to use a single best-case capture as proof of a system. Capture normal telemetry, a retry or route repair event, a larger diagnostic response, and at least one failed security or prefix condition.
9.12 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.
1. Record intended prefix Write the prefix and scope in the lab record, including whether it is only for documentation, lab, private test, or routed deployment.
2. Compare node address Confirm that the node address shown in logs or neighbor state belongs to the intended prefix and not a firmware default.
3. Inspect compression context Check whether compressed addresses reconstruct to the same prefix at sender and receiver.
4. Test service path Send a named message through the border router and confirm it reaches the intended service with the expected identity.
5. Break it deliberately Change one context or prefix in a controlled test and record the visible failure signal.
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.
9.13 Security Boundary
Use Figure 9.2 to separate link protection, end-to-end payload protection, and operations custody.
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. Transport or object security can protect payload meaning across untrusted infrastructure, but it also changes packet size, handshake behavior, retry behavior, and key management.
9.14 Security Layer Stack
6LoWPAN security is layered because the network is still an IPv6 stack. IEEE 802.15.4 can protect radio frames with AES-CCM* at the link layer. DTLS can protect UDP application exchanges such as CoAP across a path. 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. 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. The border-router log proves prefix, route, and forwarding custody. The service endpoint proves whether the application payload arrived with the expected identity and protection.
9.15 Link-Layer Security Evidence
IEEE 802.15.4 link-layer security can provide frame confidentiality, integrity, and replay protection on the radio link when configured correctly. The lab should prove configuration and behavior, not just state that AES exists.
Key scope Record whether the key is network-wide, per-pair, temporary, or provisioned by a commissioning process.
Frame counter Show how replay protection is initialized, persisted, and recovered after reset or replacement.
Capture result Show that payloads expected to be protected are not readable at the radio capture point.
Failure result Show what happens when a wrong key, stale counter, or unauthorized node tries to join or transmit.
The security record should avoid universal claims. Link-layer security may be enough for a trusted private lab, but it is not a replacement for end-to-end payload protection when the border router, relay path, cloud path, or support process is outside the same trust boundary.
9.16 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.
Make the nonce rule testable. Record the frame counter before reboot, reboot the node, send one protected frame, and confirm that the counter continues forward rather than restarting from an earlier value. Then test the receiver side: replay an old protected frame or simulate a stale counter and confirm the frame is rejected with a visible failure signal.
This is also where constrained-device choices matter. Symmetric AES is cheap and often hardware-accelerated by the radio, so it is common at the link layer. DTLS or object-security setup may use pre-shared keys, raw public keys, or elliptic-curve credentials to avoid heavyweight certificate handling. The lab should record credential type, replay-window behavior, packet growth, and the operator-visible log for wrong or stale credentials.
9.17 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.
Protected meaning State which fields must remain confidential or authenticated beyond the border router.
Handshake or setup Record whether security setup creates larger or burstier packets that need separate fragmentation review.
Key lifecycle Document how keys are created, rotated, revoked, and recovered after device replacement.
Observable failure Show how authentication failure, expired credentials, replay rejection, and clock or counter problems appear to the operator.
Security evidence is strong when it links a threat to a measured path. It is weak when it assumes a named library or cipher automatically proves the deployment.
9.18 Worked Lab Reviews
9.18.1 UDP Telemetry Path
Scenario: A constrained node sends a small periodic telemetry message through a 6LoWPAN border router to a local IPv6 service.
Review: The lab should capture node address formation, compression context, parent route, border-router forwarding, service receipt, and a controlled route-repair event. If the message is protected only at the link layer, the record should state where plaintext is visible.
Decision: Accept as a hands-on telemetry lab only if the learner can explain the packet path and reproduce the evidence after a node or border-router restart.
9.18.2 CoAP Command With Security
Scenario: A controller sends a command to a node and expects a constrained response.
Review: The command path should prove request identity, response identity, replay behavior, and what an observer can see at the radio, border-router, and service endpoints. If end-to-end or object security is used, the lab should confirm that the protected payload still fits the allowed packet path or has its own fragmentation review.
Decision: Mark release-ready only for the named command and response shape. A larger diagnostic response remains review-required.
9.18.3 Failed Prefix Or Key Test
Scenario: The instructor deliberately changes a node prefix context or security key so the lab fails.
Review: A strong lab shows the failure in more than one place: node logs, border-router logs, packet capture, route or neighbor state, and application timeout. It also explains which signal distinguishes prefix failure from route failure or authentication failure.
Decision: Keep the failure test in the lab record. It is the evidence that learners can troubleshoot the system instead of only following a happy path.
9.19 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.
Hidden fragmentation Security handshakes, diagnostics, and support payloads can become large enough to need separate review.
Production overclaim A lab result does not prove range, battery life, cost, compliance, or operational readiness at scale.
9.20 Release Checklist
Before accepting a hands-on and security chapter or lab, require evidence for each item:
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.
Security boundary stated The record says where link, transport, object, and operations trust boundaries sit.
Failure tested Wrong prefix, wrong key, route loss, replay rejection, timeout, or oversized payload behavior is observed.
Limits preserved The lab says what remains unproven and which change triggers retest.
9.21 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.
Security belongs in the same evidence flow. 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. Strong chapters show those boundaries without making broad cost, battery, or compliance promises.
9.22 Key Takeaway
6LoWPAN Hands-On and Security Evidence should leave deployment evidence for compression, fragmentation, routing, security behavior, loss recovery, and observed packet traces.
9.23 Concept Relationships
Hands-on and architecture The lab proves the architecture path with observable setup, packet, route, and border-router evidence.
Hands-on and compression Packet captures show whether IPHC behavior matches the expected context rather than a best-case diagram.
Hands-on and fragmentation Larger payloads and security setup traffic must pass a separate fragmentation and reassembly review.
Hands-on and security Security evidence ties key scope, trust boundary, replay behavior, packet growth, and operator visibility together.
9.24 What’s Next
Continue with these chapters:
- 6LoWPAN Common Pitfalls, to review common configuration, packet, and routing failures.
- 6LoWPAN Comprehensive Review, to test the complete protocol story.
- Thread Network Architecture, to compare a managed product mesh built on constrained IPv6 foundations.
- Zigbee Hands-On and Future, to contrast a non-IP IEEE 802.15.4 stack.
9.25 Knowledge Check: Border Router Evidence
9.26 Knowledge Check: Security Boundary
9.27 Concept Match
Match each hands-on evidence item with the question it answers.
9.28 Evidence Order
Place the hands-on review steps in the strongest order.