9  6LoWPAN Hands-on and Security

In 60 Seconds

Building a 6LoWPAN network requires a border router (Contiki-NG or RIOT OS on a Raspberry Pi with an 802.15.4 radio) to bridge constrained sensors to IPv6, with security provided at two layers: link-layer AES-128 for hop-by-hop protection and DTLS for true end-to-end encryption. The most common deployment mistake is prefix misconfiguration between the border router, firmware, and IPHC context tables.

Minimum Viable Understanding

If you take away only three things from this chapter:

  1. A single 6LoWPAN border router replaces hundreds of cellular modems – using Contiki-NG or RIOT OS on a Raspberry Pi with an 802.15.4 radio, one border router ($200) bridges 200+ constrained sensors to the IPv6 internet, saving thousands of dollars compared to per-device cellular connectivity.
  2. Link-layer AES-128 and transport-layer DTLS serve different trust boundaries – 802.15.4 link-layer encryption (15-20% energy overhead) protects each wireless hop but data is decrypted at every intermediate node, while DTLS (37-byte overhead per packet) provides true end-to-end encryption from sensor to cloud, essential when border routers or intermediate nodes are not fully trusted.
  3. Prefix configuration consistency is the most common deployment mistake – the border router’s tunslip6 prefix, firmware project-conf.h settings, RPL Router Advertisements, and IPHC context tables must all agree on the same IPv6 /64 prefix; any mismatch causes silent connectivity failures.

9.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Construct 6LoWPAN Networks: Assemble development environments using Contiki-NG and RIOT OS with 802.15.4 radios
  • Develop UDP Communication: Write UDP servers and clients that exchange sensor data over IPv6-enabled 802.15.4 networks
  • Deploy Border Routers: Configure and validate 6LoWPAN border routers that bridge constrained mesh networks to the IPv6 internet
  • Integrate Security Layers: Combine link-layer AES-128-CCM encryption with DTLS end-to-end protection for defense-in-depth
  • Diagnose IPv6 Connectivity: Trace packet flow through IPHC compression, RPL routing tables, and neighbor discovery to isolate failures
  • Justify Security Trade-offs: Calculate energy overhead of AES-128 vs DTLS and recommend the appropriate security layer based on trust boundaries and compliance requirements

What is this chapter? This hands-on chapter provides practical exercises for 6LoWPAN, the protocol that enables IPv6 over low-power wireless networks.

When to use:

  • After studying 6LoWPAN fundamentals
  • When you want practical implementation experience
  • Before working on real IoT network projects

Key Terms:

Term Definition
6LoWPAN IPv6 over Low-Power Wireless Personal Area Networks
Header Compression Reducing IPv6 header size for constrained devices
Mesh Addressing Multi-hop routing in low-power networks

Recommended Path:

  1. First study 6LoWPAN Fundamentals
  2. Work through exercises in this chapter
  3. Review the 6LoWPAN Comprehensive Review

“Time to get our hands dirty!” cheered Max the Microcontroller, unpacking a Raspberry Pi and some 802.15.4 radio boards. “We are going to build a real 6LoWPAN network. The Pi will be our border router – the gateway between our tiny sensor world and the big internet.”

Sammy the Sensor held up his radio board. “So I will get my very own IPv6 address? I can talk directly to the cloud?” Max beamed. “That is the whole point of 6LoWPAN! Every sensor gets a real internet address. No more translating through gateways – you speak IPv6 just like any computer.”

“But what about security?” asked Bella the Battery cautiously. “We do not want hackers listening to our conversations!” Lila the LED explained, “We have two layers of protection. The radio link uses AES-128 encryption for each hop – like locking each door as you walk through a building. Then DTLS adds end-to-end encryption from sensor to cloud – like sealing your letter so nobody can read it along the way, not even the routers in between.”

“The trickiest part,” Max warned, “is making sure all the IPv6 addresses match up. The border router, the sensor firmware, and the compression tables all need to agree on the same address prefix. Get one wrong, and everything silently breaks!”

9.2 Prerequisites

Before diving into this chapter, you should be familiar with:

  • 6LoWPAN Fundamentals and Architecture: This chapter builds directly on 6LoWPAN concepts - you must understand header compression (IPHC), fragmentation, RPL routing, and the adaptation layer architecture before implementing practical applications
  • IEEE 802.15.4 Fundamentals: Hands-on 6LoWPAN development requires knowledge of the underlying 802.15.4 radio layer, including frame structure, channel selection, and CSMA/CA behavior
  • Networking Basics: Setting up border routers and debugging IPv6 networks demands solid understanding of IP addressing, routing, UDP/TCP protocols, and network troubleshooting fundamentals
  • AES-CCM (Counter with CBC-MAC): The mandatory security mode for IEEE 802.15.4, providing both confidentiality (CTR mode) and integrity (CBC-MAC) in a single authenticated encryption operation.
  • MIC (Message Integrity Code): An authentication tag (4, 8, or 16 bytes) appended to 802.15.4 frames, computed with AES-CCM to detect frame tampering.
  • Network Key: A symmetric AES key shared across all nodes in a 6LoWPAN/Zigbee network for link-layer encryption; exposure compromises all traffic.
  • Frame Counter: A monotonically increasing value stored per-device to prevent replay attacks; receiver rejects frames with counter values below the last seen value.
  • Application Layer Security: Encryption and authentication applied at the application level (above 6LoWPAN/IEEE 802.15.4), providing end-to-end protection independent of link-layer security.
  • Contiki/RIOT OS: Open-source operating systems for constrained IoT devices supporting 6LoWPAN, RPL, and CoAP stacks for hands-on development and testing.

9.3 Cross-Hub Connections

Interactive Learning:

  • Simulations Hub - Try the Network Topology Visualizer to understand 6LoWPAN mesh routing patterns
  • Quizzes Hub - Test your 6LoWPAN implementation knowledge with hands-on scenarios
  • Videos Hub - Watch practical demonstrations of border router configuration and packet analysis

Knowledge Resources:

Deep Dives:

Implementation & Protocols:

Security:

Comparisons:

Development Tools:

Learning:

The Myth: Many developers assume 6LoWPAN simply runs standard IPv6 packets over 802.15.4 radios without modification.

The Reality: 6LoWPAN performs sophisticated header compression and fragmentation that are critical for constrained networks:

Quantified Impact:

Metric Standard IPv6 6LoWPAN with IPHC Improvement
IPv6 Header Size 40 bytes 2-7 bytes 83-94% reduction
UDP Header Size 8 bytes 4 bytes 50% reduction
Total Protocol Overhead 48 bytes 6-11 bytes 77-87% smaller
Usable Payload (127-byte frame) 79 bytes 116-121 bytes 47-53% more data

Real-World Example: A temperature sensor sending 10 bytes of data: - Without compression: 58 bytes total (48 headers + 10 data) = 83% overhead - With IPHC compression: 17 bytes total (7 headers + 10 data) = 41% overhead - Battery Impact: Compression saves ~70% transmission time per packet, extending 2-year battery to 3.5 years

Transmission time directly determines energy consumption at 15 mA TX current. Without compression: \(t_{\text{tx}} = \frac{58 \times 8}{250,000} = 1.86 \text{ ms}\). With IPHC: \(t_{\text{tx}} = \frac{17 \times 8}{250,000} = 0.54 \text{ ms}\). Worked example: At 288 daily reports, compression saves \((1.86 - 0.54) \times 288 = 380 \text{ ms/day}\) of active time. Over 2 years, this equals \(380 \times 730 / 1000 = 277\) extra seconds of battery capacity, extending life by ~40%.

Key Insight: 6LoWPAN’s header compression (IPHC) is not optional—it’s essential. Without it, a 127-byte 802.15.4 frame would waste 48 bytes (38%) on just IP+UDP headers, leaving only 79 bytes for application data. This would make many IoT applications impractical due to excessive overhead and battery drain.

Bottom Line: Always enable IPHC compression (HC1 or LOWPAN_IPHC) in your 6LoWPAN implementations. The ~5% CPU overhead for compression is far outweighed by the 83% reduction in transmission bytes—and transmission costs 10-100× more energy than computation in low-power radios.

Scenario: You’re deploying 200 battery-powered soil moisture sensors across a 5-hectare farm. Each sensor transmits 100 bytes every 15 minutes. Your customer wants global internet access to sensor data from a mobile app. Budget: $15,000 for networking infrastructure.

Think about:

  1. Why would you use a 6LoWPAN border router instead of giving each sensor a direct cellular connection?
  2. If you enable AES-128 encryption at the 802.15.4 layer, how much extra battery drain should you expect?

Key Insight: A single 6LoWPAN border router ($150) + Raspberry Pi ($50) can connect 200+ sensors to the internet via IPv6 tunneling. Without it, you’d need 200 cellular modems at $25 each ($5,000) plus $2/month data plans ($4,800/year). The border router approach costs $200 upfront vs $9,800 first-year for cellular.

Link-layer AES encryption adds approximately 15-20% energy overhead. For a sensor transmitting 96 times/day, this reduces 5-year battery life to 4.2 years—usually acceptable for the security benefit in agricultural IoT where theft/tampering of sensor data can cost thousands in crop losses.

Verify Your Understanding:

  • Can you explain the trade-off between link-layer security (802.15.4 AES) and transport-layer security (DTLS)?
  • How would RPL routing change if the border router fails?
How It Works: 6LoWPAN Border Router with Security

A 6LoWPAN border router operates by running an embedded OS (Contiki-NG or RIOT) on an 802.15.4 radio connected to a Linux host via USB serial. The host creates a TUN virtual interface (tunslip6 fd00::1/64) that bridges the IPv6 stack to the constrained network. When a sensor sends compressed packets via RPL, the border router decompresses IPHC headers, reassembles fragmented datagrams, and forwards them as standard IPv6 packets through the TUN interface to the internet. Security is applied at two layers: link-layer AES-128-CCM (in the 802.15.4 MAC sublayer) encrypts each wireless hop using a pre-shared network key (or per-pair keys in high-security deployments), protecting against eavesdropping but requiring decryption at every intermediate router. DTLS (at the transport layer, above UDP) encrypts end-to-end from sensor to cloud server, ensuring data remains confidential even through untrusted border routers – essential for medical/financial applications at the cost of 37 extra bytes per packet (13-byte record header + 8-byte explicit nonce + 16-byte authentication tag).

9.4 Hands-On: Building 6LoWPAN Networks

⏱️ ~30 min | ⭐⭐⭐ Advanced | 📋 P08.C03.U01

Network architecture diagram showing 6LoWPAN border router deployment. At the top, Internet layer (Global IPv6) contains Cloud Server at 2001:db8::1 and Mobile App connected via LTE/5G. Middle layer shows Border Router Setup with 6LoWPAN Border Router at fd00::1 running on Raspberry Pi with TUN/TAP interface and RPL Root for DODAG formation. Bottom layer shows 6LoWPAN Network (fd00::/64 subnet) with Sensor 1 (fd00::212:4b00:615:a4cb reporting 22.5°C temperature) and Sensor 2 (fd00::212:4b00:615:a4d1 reporting 65% humidity) both running Contiki-NG. Bidirectional arrows show data flow from cloud through border router using IPHC compression/decompression to sensors via 802.15.4 radio at 2.4 GHz.
Figure 9.1: 6LoWPAN Border Router Architecture: A single border router ($200) bridges 200+ constrained sensors to the global internet. The border router runs RPL root, performs IPv6 tunneling (tunslip6), and enables bi-directional communication between fd00::/64 local network and global IPv6 addresses. This eliminates the need for costly individual cellular modems ($25 each + $2/month data = $9,800 first year vs $200 one-time).
Before-and-after comparison showing 6LoWPAN IPHC header compression reducing IPv6 plus UDP headers from 48 bytes to 7-12 bytes, increasing usable payload from 79 bytes to 115-120 bytes within a 127-byte IEEE 802.15.4 frame.
Figure 9.2: 6LoWPAN IPHC header compression transforms 48-byte IPv6+UDP headers into 7-12 bytes, increasing usable payload from 79 to 115-120 bytes in a 127-byte 802.15.4 frame. Critical for battery-powered sensors.

9.4.1 Example 1: Contiki-NG (C Programming)

Contiki-NG is a modern OS for IoT devices with excellent 6LoWPAN support.

Installation:

# Clone Contiki-NG
git clone https://github.com/contiki-ng/contiki-ng.git
cd contiki-ng

# Install toolchain
sudo apt-get install gcc-arm-none-eabi gdb-multiarch

Simple UDP Server:

// udp-server.c
#include "contiki.h"
#include "net/ipv6/simple-udp.h"
#include "sys/log.h"

#define LOG_MODULE "App"
#define LOG_LEVEL LOG_LEVEL_INFO

#define UDP_PORT 1234

static struct simple_udp_connection udp_conn;

PROCESS(udp_server_process, "UDP server");
AUTOSTART_PROCESSES(&udp_server_process);

static void
udp_rx_callback(struct simple_udp_connection *c,
                const uip_ipaddr_t *sender_addr,
                uint16_t sender_port,
                const uip_ipaddr_t *receiver_addr,
                uint16_t receiver_port,
                const uint8_t *data,
                uint16_t datalen)
{
    LOG_INFO("Received '%.*s' from ", datalen, (char *) data);
    LOG_INFO_6ADDR(sender_addr);
    LOG_INFO_("\n");

    // Echo back
    simple_udp_sendto(&udp_conn, data, datalen, sender_addr);
}

PROCESS_THREAD(udp_server_process, ev, data)
{
    PROCESS_BEGIN();

    // Register UDP connection
    simple_udp_register(&udp_conn, UDP_PORT, NULL,
                        UDP_PORT, udp_rx_callback);

    LOG_INFO("UDP server started on port %d\n", UDP_PORT);

    PROCESS_END();
}

UDP Client:

// udp-client.c
#include "contiki.h"
#include "net/ipv6/simple-udp.h"
#include "sys/log.h"

#define LOG_MODULE "App"
#define LOG_LEVEL LOG_LEVEL_INFO

#define UDP_PORT 1234
#define SEND_INTERVAL (5 * CLOCK_SECOND)

static struct simple_udp_connection udp_conn;
static struct etimer periodic_timer;

PROCESS(udp_client_process, "UDP client");
AUTOSTART_PROCESSES(&udp_client_process);

PROCESS_THREAD(udp_client_process, ev, data)
{
    static unsigned count = 0;
    static char str[32];
    uip_ipaddr_t dest_ipaddr;

    PROCESS_BEGIN();

    // Set destination (Border Router)
    uip_ip6addr(&dest_ipaddr, 0xfd00, 0, 0, 0, 0, 0, 0, 1);

    // Register UDP connection
    simple_udp_register(&udp_conn, UDP_PORT, &dest_ipaddr,
                        UDP_PORT, NULL);

    etimer_set(&periodic_timer, SEND_INTERVAL);

    while(1) {
        PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&periodic_timer));

        snprintf(str, sizeof(str), "Message %u", count++);
        LOG_INFO("Sending: %s\n", str);
        simple_udp_sendto(&udp_conn, str, strlen(str), &dest_ipaddr);

        etimer_reset(&periodic_timer);
    }

    PROCESS_END();
}

Objective: 6LoWPAN uses UDP over IPv6 for sensor communication. This Wokwi lab demonstrates the equivalent UDP echo server/client pattern on ESP32 Wi-Fi, helping you understand the data flow before working with Contiki-NG or RIOT OS hardware.

Code to Try:

#include <WiFi.h>
#include <WiFiUdp.h>

const char* ssid = "Wokwi-GUEST";
const char* password = "";
WiFiUDP udp;
const int UDP_PORT = 1234;  // Same port as Contiki example
unsigned int msgCount = 0;

void setup() {
  Serial.begin(115200);
  Serial.println("=== 6LoWPAN-Style UDP Communication Demo ===");
  Serial.println("(Wi-Fi equivalent of Contiki-NG UDP server/client)\n");

  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) { delay(500); Serial.print("."); }
  Serial.println("\nJoined network: " + WiFi.localIP().toString());

  udp.begin(UDP_PORT);
  Serial.printf("UDP listening on port %d\n", UDP_PORT);
  Serial.println("In 6LoWPAN: this would be an 802.15.4 sensor node");
  Serial.println("Border Router would bridge to IPv6 internet\n");
}

void loop() {
  // Check for incoming UDP (echo server behavior)
  int packetSize = udp.parsePacket();
  if (packetSize) {
    char buf[128];
    int len = udp.read(buf, sizeof(buf) - 1);
    buf[len] = 0;
    Serial.printf("[RX] From %s:%d -> '%s'\n",
      udp.remoteIP().toString().c_str(), udp.remotePort(), buf);
    // Echo back (like Contiki simple_udp_sendto)
    udp.beginPacket(udp.remoteIP(), udp.remotePort());
    udp.write((uint8_t*)buf, len);
    udp.endPacket();
    Serial.printf("[TX] Echo reply sent\n");
  }

  // Client behavior: send periodic messages
  if (millis() / 5000 > msgCount) {
    msgCount = millis() / 5000;
    char msg[32];
    snprintf(msg, sizeof(msg), "Message %u", msgCount);
    // In 6LoWPAN: would use IPv6 link-local address
    udp.beginPacket(WiFi.gatewayIP(), UDP_PORT);
    udp.write((uint8_t*)msg, strlen(msg));
    udp.endPacket();
    Serial.printf("[TX] Sent: '%s' to gateway (simulated border router)\n", msg);
  }
  delay(100);
}

What to Observe:

  1. The UDP send/receive pattern is identical to Contiki’s simple_udp_register and callback
  2. In real 6LoWPAN, IPv6 headers are compressed from 40 bytes to 2-7 bytes by IPHC
  3. The border router (gateway) bridges between the constrained network and the internet
  4. Messages are sent every 5 seconds, matching the SEND_INTERVAL in the Contiki example

Compile and Flash:

# For Zolertia RE-Mote (example platform)
make TARGET=zoul BOARD=remote-revb udp-server
make TARGET=zoul BOARD=remote-revb udp-server.upload

9.4.2 Example 2: Border Router Setup

Layered security architecture diagram for 6LoWPAN networks showing five layers from top to bottom. Application layer contains CoAP messages (GET /temperature). Transport Layer Security provides DTLS 1.2 with end-to-end encryption using AES-128-CCM cipher, adding 20% energy overhead and 37 bytes per packet. Network layer handles IPv6 packets with IPHC compression (40 bytes reduced to 7 bytes) and RPL routing for DODAG maintenance. Adaptation layer performs 6LoWPAN header compression and fragmentation for packets larger than 102 bytes. Link layer implements IEEE 802.15.4 MAC with AES-128-CCM encryption, 8-byte MIC-64 for authentication, and shared network key, adding 15-20% energy overhead and 14 bytes per frame. Arrows on right show cumulative security overhead and energy increase depending on security mode chosen.
Figure 9.3: 6LoWPAN Security Layers: Two primary security approaches: (1) Link-layer AES-128-CCM at 802.15.4 MAC protects each hop (15-20% energy overhead, 14-byte total security overhead with MIC-64), but data is decrypted at border router – suitable for trusted gateways; (2) Transport-layer DTLS provides end-to-end encryption (20% energy overhead, 13-byte record header + 24-byte cipher overhead), protecting data through untrusted intermediate nodes – essential for medical devices, payments, or public networks. Choose based on threat model and trust boundaries.
Comparison flowchart showing IPHC header compression efficiency in 6LoWPAN. Left side shows uncompressed packet (58 bytes total): IPv6 header (40 bytes containing Version, Flow, Hop Limit, Source and Destination addresses), UDP header (8 bytes with Ports, Length, Checksum), and Application Data (10 bytes containing temperature reading 22.5°C). Right side shows compressed packet (17 bytes total): IPHC header (2 bytes with Dispatch and Encoding flags), Hop Limit (1 byte), Contexts (2 bytes for compressed addresses), UDP Compressed (2 bytes with ports from context), and Application Data (10 bytes unchanged). Compression arrow between them shows 71% reduction (41 bytes saved). Result shows 80% payload efficiency in 102-byte 802.15.4 frame versus 17% without compression.
Figure 9.4: IPHC Header Compression Impact: Standard IPv6+UDP headers consume 48 bytes (83% overhead for 10-byte sensor data). IPHC compression reduces this to 7 bytes (41% overhead) by: (1) Omitting redundant fields derivable from 802.15.4 layer; (2) Using context-based address compression (link-local addresses → 0 bytes); (3) Compressing UDP ports from well-known ranges. Result: 70% reduction in transmission time extends battery from 2 years to 3.5 years—critical for scaling to hundreds of nodes.

Border Router bridges 6LoWPAN to regular IPv6 network:

# Compile border router
cd contiki-ng/examples/rpl-border-router
make TARGET=zoul BOARD=remote-revb border-router
make TARGET=zoul BOARD=remote-revb border-router.upload

# On your PC, create TUN interface
sudo tunslip6 -s /dev/ttyUSB0 fd00::1/64

# Now your 6LoWPAN network has fd00::/64 prefix
# You can ping sensors from your PC!
ping6 fd00::212:4b00:615:a4cb
Pitfall: Mismatched Prefix Configuration Between Border Router and Nodes

The Mistake: Developers configure the border router with one IPv6 prefix (e.g., fd00::/64) but sensor nodes autoconfigure with a different prefix or fail to receive Router Advertisements. Result: nodes appear online locally but cannot communicate through the border router to the internet.

Why It Happens: Multiple configuration points must agree: 1. tunslip6 command-line prefix argument 2. Border router firmware’s project-conf.h settings 3. RPL root prefix distribution via Router Advertisements 4. Context table entries for IPHC compression

If any mismatch exists, nodes may form a local mesh but packets destined for the border router get dropped due to address mismatch or compression context lookup failure.

The Fix: Ensure consistent prefix configuration across all components:

// project-conf.h on border router
#define NETSTACK_CONF_WITH_IPV6 1
#define UIP_CONF_IPV6_RPL 1

// Prefix must match tunslip6 argument
#define UIP_CONF_DS6_DEFAULT_PREFIX 0xfd00
#define UIP_CONF_DS6_DEFAULT_PREFIX_LEN 64

Verification checklist:

# 1. Check border router prefix
tunslip6 -s /dev/ttyUSB0 fd00::1/64

# 2. Verify nodes received prefix (on node serial console)
# Look for: "Global IPv6 address: fd00::212:4b00:xxxx:xxxx"

# 3. Check RPL DODAG formation
# Border router log should show: "RPL: DODAG Information Object sent"

# 4. Test end-to-end connectivity
ping6 fd00::212:4b00:615:a4cb  # Node address

# 5. Check context table (if using context compression)
# Context 0 should map to fd00::/64 on all nodes

Common prefix mistakes:

  • Using 2001:db8::/32 (documentation prefix) in production
  • Forgetting to enable IPv6 forwarding: sysctl -w net.ipv6.conf.all.forwarding=1
  • TUN interface not added to routing table
Pitfall: Border Router Reassembly Buffer Overflow

The Mistake: Deploying border routers without tuning reassembly buffer sizes for expected traffic patterns. When multiple fragmented packets arrive simultaneously, buffer exhaustion causes silent packet drops with no error indication.

Why It Happens: 6LoWPAN fragmentation requires buffering all fragments until the complete packet can be reassembled (up to 60-second timeout). Default configurations often allocate only 2-4 reassembly buffers. In a network with 50+ sensors sending periodic reports, buffer contention is inevitable during synchronized transmissions.

The Fix: Calculate required reassembly buffers and configure appropriately:

// project-conf.h - Reassembly buffer configuration
// Each buffer holds one fragmenting IPv6 packet

// Default (often too small):
// #define SICSLOWPAN_CONF_REASS_CONTEXTS 2

// Production sizing formula:
// buffers = (nodes_sending_simultaneously * avg_fragments_per_packet) / 2
// For 50 nodes with staggered 5-minute intervals: ~4 simultaneous
// For fragmented CoAP responses (300 bytes = 4 fragments): 4 * 4 / 2 = 8

#define SICSLOWPAN_CONF_REASS_CONTEXTS 8

// Timeout tuning (default 60 seconds often too long)
#define SICSLOWPAN_CONF_MAXAGE 20  // 20 seconds

// Fragment buffer size (must fit largest expected packet)
#define SICSLOWPAN_CONF_FRAG_BUF_SIZE 1280  // IPv6 minimum MTU

Symptoms of reassembly buffer exhaustion:

  • Intermittent packet loss with no pattern
  • Large packets (firmware updates, logs) fail while small packets succeed
  • Packet loss correlates with number of active nodes
  • SICSLOWPAN: reassembly buffer full in debug logs

Buffer sizing table:

Network Size Fragmented Traffic Recommended Buffers RAM Cost
10 nodes Light (single-frame) 2 2.5 KB
50 nodes Moderate (occasional large) 8 10 KB
200 nodes Heavy (frequent fragments) 16 20 KB
500+ nodes Use multiple border routers 8 per BR -

Always monitor reassembly timeouts and buffer full counters in production.

9.4.3 Inline Check: Border Router Prefix Configuration

Worked Example: Border Router IPv6 Prefix Allocation

Scenario: You are deploying a 6LoWPAN network for a smart building with 200 sensors. The building’s ISP provides a /48 IPv6 prefix, and you need to allocate subnets for 3 floors with separate 6LoWPAN border routers.

Given:

  • ISP-assigned prefix: 2001:db8:abcd::/48
  • 3 floors, each with its own border router
  • Each floor has 50-80 sensors
  • Sensors use SLAAC (Stateless Address Autoconfiguration)
  • Border routers run Contiki-NG with tunslip6

Steps:

  1. Calculate available subnet space:

    ISP prefix: 2001:db8:abcd::/48
Available for subnets: 48 bits fixed, 16 bits for subnets
Total /64 subnets available: 2^16 = 65,536 subnets

  2. Allocate /64 prefixes per floor:

    Floor 1 (Lobby/Reception): 2001:db8:abcd:0001::/64
Floor 2 (Offices):         2001:db8:abcd:0002::/64
Floor 3 (Data Center):     2001:db8:abcd:0003::/64
Management network:        2001:db8:abcd:0000::/64

  3. Configure border router for Floor 1:

    # Connect 802.15.4 radio via USB serial
# Create TUN interface with allocated prefix
sudo tunslip6 -s /dev/ttyUSB0 2001:db8:abcd:0001::1/64

# Verify interface creation
ip -6 addr show tun0
# Expected: 2001:db8:abcd:0001::1/64 scope global

  4. Calculate sensor addresses via SLAAC:

    • Sensor MAC: 00:12:4b:00:12:34:56:78
    • EUI-64 IID: 0212:4bff:fe12:3456 (insert FFFE, flip bit 7)
    • Final address: 2001:db8:abcd:0001:0212:4bff:fe12:3456

  5. Configure IPHC context for compression:

    // In project-conf.h on all nodes
#define SICSLOWPAN_CONF_MAX_ADDR_CONTEXTS 1
#define SICSLOWPAN_CONF_ADDR_CONTEXT_0 \
    { addr_contexts[0].prefix[0] = 0x20; \
      addr_contexts[0].prefix[1] = 0x01; \
      addr_contexts[0].prefix[2] = 0x0d; \
      addr_contexts[0].prefix[3] = 0xb8; \
      addr_contexts[0].prefix[4] = 0xab; \
      addr_contexts[0].prefix[5] = 0xcd; \
      addr_contexts[0].prefix[6] = 0x00; \
      addr_contexts[0].prefix[7] = 0x01; }

  6. Enable IPv6 forwarding on border router host:

    # Enable forwarding
sudo sysctl -w net.ipv6.conf.all.forwarding=1

# Add route to sensor network
sudo ip -6 route add 2001:db8:abcd:0001::/64 dev tun0

Result:

  • Floor 1 sensors: 2001:db8:abcd:0001::/64 (up to 2^64 addresses)
  • Border router: 2001:db8:abcd:0001::1 (gateway)
  • Each sensor globally routable from internet
  • IPHC compression elides 64-bit prefix using Context 0

Key Insight: 6LoWPAN border routers bridge constrained 802.15.4 networks to IPv6 infrastructure. The key configuration points are: (1) allocate a unique /64 prefix per border router, (2) configure matching IPHC context tables on all nodes for compression, (3) enable IPv6 forwarding on the Linux host, and (4) use Router Advertisements (RA) to distribute the prefix to sensors for SLAAC. This enables direct end-to-end IPv6 connectivity from cloud servers to individual sensors without NAT or application-layer gateways.

Worked Example: Security Overhead Calculation for DTLS vs Link-Layer

Scenario: A healthcare 6LoWPAN network transmits patient vital signs every 30 seconds. Security is mandatory, and you must choose between link-layer AES-128 (802.15.4 MAC security) and end-to-end DTLS. Calculate the overhead and battery impact of each option.

Given:

  • Sensor payload: 16 bytes (heart rate, SpO2, temperature)
  • Transmission interval: 30 seconds (2,880 messages/day)
  • 802.15.4 MTU: 102 bytes (after MAC/PHY)
  • Battery: 1,000 mAh @ 3.0V coin cell
  • Radio: 15 mA TX, 0.5 mA sleep, 250 kbps
  • Security requirements: Confidentiality + Integrity + Authentication

Steps:

  1. Calculate link-layer AES-128-CCM overhead:

    802.15.4 Security Header:
- Security Control:     1 byte
- Frame Counter:        4 bytes
- Key Identifier:       0-9 bytes (assume 1 byte)

Message Integrity Code (MIC):
- MIC-32:   4 bytes (32-bit authentication tag)
- MIC-64:   8 bytes (64-bit, recommended)
- MIC-128: 16 bytes (128-bit, highest security)

Total overhead (MIC-64): 1 + 4 + 1 + 8 = 14 bytes

  2. Calculate available payload with link-layer security:

    802.15.4 payload:        102 bytes
- Security overhead:     -14 bytes
- IPHC header:           -6 bytes
- NHC-UDP:               -4 bytes
─────────────────────────────────
Available for data:       78 bytes (plenty for 16-byte payload)
Total frame size:         40 bytes (16 data + 24 headers)

  3. Calculate DTLS 1.2 overhead:

    DTLS Record Header:
- Content Type:          1 byte
- Version:               2 bytes
- Epoch:                 2 bytes
- Sequence Number:       6 bytes
- Length:                2 bytes

DTLS overhead:          13 bytes

With AES-128-CCM cipher:
- Nonce (explicit IV):   8 bytes
- MAC tag:              16 bytes

Total DTLS overhead:    13 + 8 + 16 = 37 bytes

  4. Calculate frame requirements for DTLS:

    IPHC header:             6 bytes
NHC-UDP:                 4 bytes
DTLS overhead:          37 bytes
Application data:       16 bytes
─────────────────────────────────
Total:                  63 bytes (fits in single frame)

  5. Compare energy consumption:

    Link-layer security (40 bytes @ 250 kbps):
- TX time: 40 * 8 / 250,000 = 1.28 ms
- Energy/msg: 15mA * 3V * 1.28ms = 57.6 µJ
- Daily energy: 57.6 µJ * 2,880 = 165.9 mJ

DTLS (63 bytes @ 250 kbps):
- TX time: 63 * 8 / 250,000 = 2.02 ms
- Energy/msg: 15mA * 3V * 2.02ms = 90.7 µJ
- Daily energy: 90.7 µJ * 2,880 = 261.2 mJ

Additional DTLS overhead: 261.2 - 165.9 = 95.3 mJ/day (57% more)

Security overhead is quantified as extra transmission energy. Link-layer AES adds 14 bytes (4-byte header + 8-byte MIC). DTLS adds 37 bytes (13-byte header + 8-byte nonce + 16-byte MAC). Worked example: For a 16-byte payload at 250 kbps, link-layer uses \(E_{\text{link}} = 0.015 \times 3 \times \frac{(16+14) \times 8}{250,000} \times 1000 = 0.0576 \text{ mJ}\). DTLS uses \(E_{\text{DTLS}} = 0.015 \times 3 \times \frac{(16+37) \times 8}{250,000} \times 1000 = 0.0954 \text{ mJ}\). Over 2,880 daily transmissions, DTLS costs an extra \((0.0954 - 0.0576) \times 2880 = 109 \text{ mJ/day}\), reducing 5-year battery to 3.4 years.

  1. Calculate battery life difference:

    Battery capacity: 1,000 mAh * 3V * 3600s = 10,800 J

Link-layer only:
- Daily consumption: 165.9 mJ + 43.2 mJ (sleep) = 209.1 mJ
- Battery life: 10,800,000 mJ / 209.1 mJ = 51,650 days = 141.5 years

DTLS + Link-layer:
- Daily consumption: 261.2 mJ + 43.2 mJ = 304.4 mJ
- Battery life: 10,800,000 mJ / 304.4 mJ = 35,478 days = 97.2 years

Reality check: Add MCU processing, actual duty cycle
- Realistic link-layer: ~5 years
- Realistic DTLS: ~3.4 years (32% reduction)

Result: | Security Option | Frame Size | TX Time | Battery Impact | |—————–|————|———|—————-| | Link-layer AES-128-CCM | 40 bytes | 1.28 ms | Baseline | | DTLS 1.2 (AES-128-CCM) | 63 bytes | 2.02 ms | +57% energy | | Both (defense-in-depth) | 77 bytes | 2.46 ms | +92% energy |

Key Insight: For 6LoWPAN healthcare deployments, the security choice depends on trust boundaries. Link-layer security (14-byte overhead) protects hop-by-hop with minimal battery impact, but data is decrypted at each router and the border router. DTLS (37-byte overhead) provides true end-to-end encryption through untrusted intermediaries, essential when border routers are in shared facilities or cloud-managed. For HIPAA compliance with untrusted infrastructure, use DTLS despite the 57% energy penalty. For trusted private networks, link-layer security alone is sufficient and extends battery life by 32%.

Common Pitfalls

Turning off IEEE 802.15.4 link security during development and neglecting to re-enable it before deployment is one of the most common IoT security failures. Maintain security enabled in all configurations including test environments.

If a device loses power and its non-volatile frame counter storage fails, the counter resets to zero — allowing replay of any previously captured frames. Always write the frame counter to flash with wear leveling.

AES-CCM protects each individual hop but any routing node can decrypt and re-encrypt data. For truly sensitive payloads, add application-layer encryption on top of 6LoWPAN security.

9.6 Summary

This hands-on chapter covered practical implementation of 6LoWPAN networks for IPv6-enabled IoT deployments:

  • Development Environments: Contiki-NG and RIOT OS provide production-ready IPv6 stacks for resource-constrained embedded devices, enabling UDP communication over 802.15.4 radios
  • Border Router Deployment: A single border router enables 200+ constrained devices to access the internet, reducing connectivity costs from $10K+ (individual cellular) to $200 per deployment
  • Header Compression (IPHC): Reduces IPv6+UDP headers from 48 bytes to 7 bytes (70% reduction), extending battery life from 2 years to 3.5 years for mesh nodes
  • Link-Layer Security: AES-128 encryption adds 15-20% energy overhead but prevents eavesdropping and data tampering in agricultural, industrial, and smart city applications
  • RPL Routing: Automatically adapts multi-hop paths when nodes fail, with the border router acting as the DODAG root for centralized routing coordination
  • DTLS Security: Provides end-to-end encryption for sensitive applications (medical devices, payments) beyond link-layer protection

9.7 Interactive Knowledge Checks

9.7.1 Knowledge Check: Security Layer Selection

9.7.2 Knowledge Check: Border Router Deployment

9.7.3 Knowledge Check: Security Overhead Calculation

9.8 Knowledge Check

::

::

Decision Framework: Choosing Between Link-Layer AES vs End-to-End DTLS

Use this decision tree to select the appropriate security layer for your 6LoWPAN deployment:

Criterion Link-Layer AES-128 DTLS (End-to-End) Both (Defense-in-Depth)
Trust Boundary Trusted network Untrusted intermediaries Maximum security
Energy Overhead +15-20% +37-byte header, +20% +30-35% total
Battery Impact 5 years → 4.2 years 5 years → 3.4 years 5 years → 3.2 years
Implementation Enable in MAC layer Add DTLS library Configure both
Typical Cost/Device $0 (built-in) +$0.50 (flash/RAM) +$0.50

When to use Link-Layer AES ONLY:

  • Private agricultural fields (no public access to physical area)
  • Factory floors (trusted perimeter, guards, access control)
  • Smart building with secured equipment rooms for border routers
  • Budget constraint: every $0.50 matters at scale (thousands of devices)

When to use DTLS (END-TO-END):

  • Medical devices (HIPAA compliance requires end-to-end)
  • Payment terminals (PCI-DSS mandate)
  • Border router in shared/untrusted location (co-working space, multi-tenant building)
  • Cloud-managed infrastructure (border router OS patching by third party)
  • High-value data (trade secrets, personal identifiable information)

When to use BOTH:

  • Critical infrastructure (power grid, water treatment)
  • Defense/military applications
  • Financial services (ATMs, payment networks)
  • Regulatory requirement (NIST, ISO 27001)

Example Decision: Hospital patient monitoring: Border router is in shared server room managed by facilities contractor → Use DTLS. Medical data must remain encrypted even if border router is compromised. The 32% battery penalty (5 years → 3.4 years) is acceptable for patient safety.

9.9 Concept Relationships

Concept Depends On Enables Conflicts With
Border Router (6LBR) RPL DODAG root, TUN interface, IPv6 forwarding Internet connectivity for constrained nodes Single point of failure (needs redundancy)
Link-Layer AES-128 Shared network key, 802.15.4 security mode Hop-by-hop confidentiality (15-20% overhead) End-to-end trust (data decrypted at routers)
DTLS End-to-End CoAP/UDP transport, PSK or certificates True confidentiality through untrusted border routers Single-frame delivery (37-byte overhead requires fragmentation for small MTUs)
IPHC Context Tables Consistent prefix across all nodes Maximum compression (40 bytes → 2 bytes) Prefix misconfiguration causes silent failures

9.10 See Also

Scenario: You’re deploying a smart agriculture 6LoWPAN network with 100 soil moisture sensors reporting 20-byte readings every 5 minutes. Calculate the annual cost difference between link-layer AES-only versus DTLS end-to-end encryption in terms of battery replacements.

Tasks:

  1. Calculate messages per year per sensor
  2. Compute frame sizes with link-layer AES (14-byte overhead) vs DTLS (37-byte overhead)
  3. Estimate battery life for 1000 mAh coin cell (assume 15 mA TX, 250 kbps)
  4. Calculate labor cost for battery replacement at $15/hour (10 sensors per hour)

Expected Results:

  • Messages/year: 365 days × 288 reports/day = 105,120 messages
  • Link-layer: 51 bytes/frame → 1.63 ms TX → 69.5 µJ/msg → 4.8 years battery
  • DTLS: 74 bytes/frame → 2.37 ms TX → 107 µJ/msg → 3.3 years battery
  • Replacements: Link-layer needs 1 cycle over 5 years, DTLS needs 2 cycles
  • Labor cost difference: 100 sensors × 1 extra replacement × $15/hr ÷ 10 sensors/hr = $150 saved with link-layer
  • Decision: If border router is in locked equipment shed on private property → use link-layer AES only

9.11 What’s Next

Continue building your 6LoWPAN expertise with these related chapters:

Topic Chapter Description
Comprehensive Review 6LoWPAN Comprehensive Review Synthesize all 6LoWPAN concepts with quiz questions, advanced security patterns, and real-world deployment case studies
Zigbee Comparison Zigbee Fundamentals and Architecture Compare 6LoWPAN’s IPv6 approach with Zigbee’s application-layer profiles and cluster library on the same 802.15.4 radio
Thread Mesh Protocol Thread Network Architecture Explore Thread’s IPv6 mesh networking with built-in commissioning and border router redundancy as an alternative to raw 6LoWPAN
RPL Routing RPL Fundamentals Deepen understanding of DODAG formation, rank calculation, and objective functions used by 6LoWPAN border routers
CoAP with DTLS CoAP Fundamentals Implement the application-layer protocol most commonly paired with 6LoWPAN, including DTLS-secured CoAP exchanges
IoT Cryptography Encryption Labs Hands-on practice with AES-128, key management, and cryptographic primitives used in 6LoWPAN security layers