659  IPv6 and 6LoWPAN for IoT

Network Layer Addressing and Header Compression

NoteLearning Objectives

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

• Explain why IPv6 is essential for IoT deployments
• Calculate the address space advantage of IPv6 over IPv4
• Describe how 6LoWPAN compresses IPv6 headers for constrained networks
• Understand the fragmentation requirements for 802.15.4 frames
• Compare IPv4 NAT-based and IPv6 direct addressing architectures

659.1 Network Layer: IPv6 for IoT

The network layer provides addressing and routing for IoT devices. While IPv4 dominated the traditional internet, IPv6 is essential for IoT due to address space requirements and built-in features.

659.1.1 Why IPv6 for IoT?

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#E8F6F3', 'clusterBkg': '#E8F6F3', 'clusterBorder': '#16A085', 'fontSize': '11px'}}}%%
graph TB
    subgraph "IPv4 Challenge"
        IPv4_Addr["4.3 billion addresses<br/>(2³² = exhausted 2011)"]
        IPv4_NAT["Requires NAT<br/>Complex port mapping"]
        IPv4_Limit["~0.6 addresses/person<br/>Cannot scale to IoT"]
    end

    subgraph "IPv6 Solution"
        IPv6_Addr["340 undecillion addresses<br/>(2¹²⁸ = unlimited)"]
        IPv6_Direct["End-to-end connectivity<br/>No NAT required"]
        IPv6_Scale["48 quintillion addresses/person<br/>Every device = unique IP"]
    end

    IPv4_Addr -->|"Address exhaustion"| IPv6_Addr
    IPv4_NAT -->|"Simplified architecture"| IPv6_Direct
    IPv4_Limit -->|"IoT scalability"| IPv6_Scale

    style IPv4_Addr fill:#E74C3C,stroke:#2C3E50,color:#fff
    style IPv4_NAT fill:#E74C3C,stroke:#2C3E50,color:#fff
    style IPv4_Limit fill:#E74C3C,stroke:#2C3E50,color:#fff
    style IPv6_Addr fill:#16A085,stroke:#2C3E50,color:#fff
    style IPv6_Direct fill:#16A085,stroke:#2C3E50,color:#fff
    style IPv6_Scale fill:#16A085,stroke:#2C3E50,color:#fff

Figure 659.1: IPv4 limitations versus IPv6 solutions for IoT scalability

{fig-alt=“Comparison diagram showing IPv4 challenges (4.3 billion addresses exhausted, NAT complexity, limited scalability) versus IPv6 solutions (340 undecillion addresses, end-to-end connectivity, every device gets unique IP)”}

659.1.2 IPv4 vs IPv6 Address Space

The address space difference between IPv4 and IPv6 is staggering:

Metric	IPv4 (32-bit)	IPv6 (128-bit)	Ratio
Total addresses	4.3 billion (2³²)	340 undecillion (2¹²⁸)	79 octillion ×
Per person	~0.6 (7 billion people)	48 quintillion	80 billion trillion ×
Per mm² of Earth	0.008	667 quadrillion	83 quadrillion ×
Status	Exhausted (2011)	Unlimited for IoT	N/A

TipFor Beginners: How Big is IPv6’s Address Space?

IPv6 provides 340 undecillion addresses:

340,282,366,920,938,463,463,374,607,431,768,211,456

To put this in perspective: - Every grain of sand on Earth (7.5 quintillion) could have 45 million IPv6 addresses each - Every star in the observable universe (200 sextillion) could have 1.7 trillion addresses each - Every atom in the human body (7 octillion) could have 48 million addresses each

For practical IoT purposes: even if we deployed 1 trillion IoT devices per second, it would take 10 billion years to exhaust IPv6 addresses.

Why this matters for IoT: - No NAT translation needed = simpler architecture - Every sensor gets a globally unique address - Direct end-to-end communication is possible - Future-proof for decades of IoT growth

659.1.3 IPv6 Header Structure

Understanding the IPv6 header helps explain why 6LoWPAN compression is so effective:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |  4 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |  4 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +  16 bytes
|                            (128 bits)                         |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +  16 bytes
|                            (128 bits)                         |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Total: 40 bytes

Header Fields: - Version (4 bits): Always 6 for IPv6 - Traffic Class (8 bits): QoS priority (often unused in IoT) - Flow Label (20 bits): Flow identification (often unused in IoT) - Payload Length (16 bits): Size of payload after header - Next Header (8 bits): Protocol of encapsulated data (UDP=17, TCP=6) - Hop Limit (8 bits): TTL equivalent, decremented by each router - Source Address (128 bits): Sender’s IPv6 address - Destination Address (128 bits): Receiver’s IPv6 address

The Problem: The 40-byte IPv6 header is substantial for constrained networks. IEEE 802.15.4 frames have only 127 bytes total (102 bytes usable payload). Without compression, IPv6 header alone would consume 39% of available space!

659.1.4 IPv6 Address Types for IoT

Address Type	Prefix	Scope	IoT Use Case
Link-Local	fe80::/10	Single link	Local device discovery, neighbor communication
Global Unicast	2000::/3	Internet	Cloud connectivity, remote management
Unique Local	fc00::/7	Organization	Private networks, no internet
Multicast	ff00::/8	Various	Group communication, service discovery

IoT Address Configuration: - SLAAC (Stateless Address Auto-Configuration): Device generates own address from router prefix + interface identifier (derived from MAC address) - DHCPv6: Server assigns addresses (less common in constrained IoT) - Manual: Static configuration (used for servers, gateways)

NoteKnowledge Check: IPv6 Address Space

Question: A research team analyzes IPv6 addressing requirements for a smart city deploying 1 million IoT devices (streetlights, parking sensors, traffic cameras). IPv4 provides 4.3 billion addresses (2^32), IPv6 provides 340 undecillion addresses (2^128). Which statements accurately describe IPv6’s advantages for this deployment? (Select ALL that apply)

Explanation: IPv6 provides critical advantages for large-scale IoT: (A) Correct: 2^128 / 2^32 = 2^96 = 79,228,162,514,264,337,593,543,950,336 (79 octillion) more addresses. This provides ~48 million trillion trillion addresses per person (7 billion people), or 667 quadrillion per mm^2 of Earth’s surface. (B) Correct: SLAAC (Stateless Address Autoconfiguration) allows devices to automatically configure addresses using router advertisements (RA) without DHCP servers, critical for mass IoT deployment. (D) Correct: With unique global IPv6 addresses, devices communicate directly without NAT port mapping or STUN/TURN traversal servers, simplifying architecture. (C) Incorrect: Address length doesn’t inherently provide security; IPv6 includes IPsec in core specification, but security depends on implementation, not address space. (E) Incorrect: IPv6 header is 40 bytes (larger than IPv4’s 20 bytes minimum), but it’s simpler with fixed length and no options (reducing processing). For IoT, 6LoWPAN compresses IPv6 to 2-6 bytes, making it efficient.

659.2 Adaptation Layer: 6LoWPAN

6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks) is the critical adaptation layer that makes IPv6 practical on constrained networks like IEEE 802.15.4.

659.2.1 Why 6LoWPAN is Essential

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3'}}}%%
graph TB
    subgraph "The Problem"
        IPv6_Header["IPv6 Header<br/>40 bytes"]
        Frame_802154["802.15.4 Frame<br/>127 bytes total<br/>102 bytes payload"]
        Problem["Only 62 bytes for<br/>UDP + App + Data!"]
    end

    subgraph "6LoWPAN Solution"
        Compress["Header Compression<br/>IPHC + NHC"]
        Compressed["Compressed IPv6<br/>2-6 bytes"]
        Result["Now 96+ bytes<br/>for application!"]
    end

    IPv6_Header --> Frame_802154
    Frame_802154 --> Problem
    Problem -->|"6LoWPAN"| Compress
    Compress --> Compressed
    Compressed --> Result

    style IPv6_Header fill:#E74C3C,stroke:#2C3E50,color:#fff
    style Problem fill:#E74C3C,stroke:#2C3E50,color:#fff
    style Compress fill:#16A085,stroke:#2C3E50,color:#fff
    style Result fill:#16A085,stroke:#2C3E50,color:#fff

Figure 659.2: 6LoWPAN solves the IPv6 header overhead problem for constrained networks

{fig-alt=“Diagram showing the problem of 40-byte IPv6 headers in 127-byte 802.15.4 frames, and how 6LoWPAN compression reduces headers to 2-6 bytes, leaving more space for application data”}

The Challenge: - IEEE 802.15.4 maximum frame: 127 bytes - MAC header + FCS: ~25 bytes - Usable payload: ~102 bytes - IPv6 header: 40 bytes (39% of payload!) - UDP header: 8 bytes - Remaining for CoAP + data: only 54 bytes

The Solution: - 6LoWPAN compresses IPv6 header from 40 bytes to 2-6 bytes - UDP header compressed from 8 bytes to 4 bytes - Result: 90+ bytes available for application data

659.2.2 6LoWPAN Compression Techniques

6LoWPAN uses context-based compression (IPHC - IP Header Compression):

IPv6 Field	Size	Compression Strategy	Compressed Size
Version	4 bits	Omit (always 6)	0 bits
Traffic Class	8 bits	Omit (default 0) or compress	0-8 bits
Flow Label	20 bits	Omit (rarely used)	0-20 bits
Payload Length	16 bits	Derive from MAC layer	0 bits
Next Header	8 bits	Encode in dispatch byte	0-8 bits
Hop Limit	8 bits	Keep (needed for routing)	8 bits
Source Address	128 bits	Derive from MAC address	0-128 bits
Destination Address	128 bits	Derive from MAC or context	0-128 bits

Address Compression Examples:

Address Type	Uncompressed	Compressed	Savings
Link-local (fe80::MAC)	128 bits	0 bits (derive from MAC)	100%
Same-prefix unicast	128 bits	16-64 bits (suffix only)	50-88%
Multicast (ff02::1)	128 bits	8-48 bits (group ID)	63-94%

659.2.3 6LoWPAN Header Compression Example

Scenario: Sensor sends temperature to gateway on same link

Before Compression (40 bytes IPv6 + 8 bytes UDP = 48 bytes):

IPv6 Header:
  Version: 6, Traffic Class: 0, Flow Label: 0
  Payload Length: 12
  Next Header: 17 (UDP)
  Hop Limit: 64
  Source: fe80::0211:22ff:fe33:4455 (link-local from MAC 00:11:22:33:44:55)
  Destination: fe80::0a00:27ff:fe8b:1234 (link-local from MAC 08:00:27:8b:12:34)

UDP Header:
  Source Port: 5683 (CoAP)
  Destination Port: 5683
  Length: 12
  Checksum: calculated

After 6LoWPAN Compression (2 bytes IPHC + 4 bytes UDP = 6 bytes):

6LoWPAN IPHC Dispatch (2 bytes):
  01 1 HLIM TF NH SAC SAM M DAC DAM
  Encodes: elide version, compress addresses, inline hop limit

UDP NHC (1 byte) + Ports (2 bytes) + Checksum (2 bytes) = 5 bytes
  Or with port compression: 4 bytes total

Total compressed header: 6-7 bytes (vs 48 bytes)
Savings: 41-42 bytes = 85-88%

659.2.4 Fragmentation and Reassembly

When IPv6 packets exceed the 802.15.4 MTU (after compression), 6LoWPAN fragments them:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#E8F6F3'}}}%%
sequenceDiagram
    participant IPv6 as IPv6 Packet<br/>(200 bytes)
    participant LoWPAN as 6LoWPAN<br/>Fragmenter
    participant Frame1 as 802.15.4<br/>Frame 1
    participant Frame2 as 802.15.4<br/>Frame 2
    participant Frame3 as 802.15.4<br/>Frame 3

    IPv6->>LoWPAN: Large packet (200 bytes)
    LoWPAN->>Frame1: FRAG1 (96 bytes data + 4 byte header)
    LoWPAN->>Frame2: FRAGN (96 bytes data + 5 byte header)
    LoWPAN->>Frame3: FRAGN (8 bytes data + 5 byte header)

    Note over Frame1,Frame3: Receiver reassembles using datagram_tag and datagram_offset

Figure 659.3: 6LoWPAN fragmentation of large IPv6 packets across multiple 802.15.4 frames

{fig-alt=“Sequence diagram showing how 6LoWPAN fragments a 200-byte IPv6 packet into three 802.15.4 frames with FRAG1 and FRAGN headers for reassembly”}

Fragmentation Headers: - FRAG1 (first fragment): 4 bytes - datagram_size, datagram_tag, inline first header - FRAGN (subsequent fragments): 5 bytes - datagram_size, datagram_tag, datagram_offset

Best Practice: Avoid fragmentation when possible. Each additional frame: - Increases latency - Consumes more power (multiple transmissions) - Higher probability of packet loss (all fragments must arrive)

659.2.5 6LoWPAN in Thread Networks

Thread (used in Matter smart home) uses 6LoWPAN extensively:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#E8F6F3'}}}%%
graph TB
    subgraph "Thread Network"
        End1["End Device<br/>fe80::1"]
        End2["End Device<br/>fe80::2"]
        Router1["Thread Router<br/>fe80::100"]
        Router2["Thread Router<br/>fe80::200"]
        Border["Border Router<br/>2001:db8::1"]
    end

    subgraph "External Network"
        Cloud["Cloud Server<br/>2001:db8:1::100"]
    end

    End1 -->|"6LoWPAN<br/>802.15.4"| Router1
    End2 -->|"6LoWPAN<br/>802.15.4"| Router2
    Router1 <-->|"Mesh routing<br/>(RPL)"| Router2
    Router1 --> Border
    Router2 --> Border
    Border -->|"Native IPv6<br/>Ethernet/Wi-Fi"| Cloud

    style Border fill:#E67E22,stroke:#2C3E50
    style Cloud fill:#2C3E50,stroke:#16A085,color:#fff

Figure 659.4: Thread network architecture showing 6LoWPAN mesh with IPv6 border router

{fig-alt=“Thread network topology showing end devices connecting via 6LoWPAN over 802.15.4 to Thread routers in a mesh, with a border router bridging to native IPv6 for cloud connectivity”}

Thread + 6LoWPAN Features: - Mesh-under routing: 6LoWPAN routes packets at adaptation layer - Route-over routing: RPL routing at IPv6 layer for complex topologies - Mesh header: 6LoWPAN adds mesh addressing for multi-hop - Border router: Translates between compressed 6LoWPAN and native IPv6

NoteKnowledge Check: 6LoWPAN

Question: Which of the following are key benefits of 6LoWPAN for IoT networks? (Select ALL that apply)

Explanation: 6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks) provides three critical functions for IoT: (1) Header compression reduces 40-byte IPv6 headers to 2-6 bytes using context-based compression and header elision, (2) Fragmentation and reassembly splits IPv6 packets exceeding 102-byte 802.15.4 payload capacity, (3) Adaptation layer enables IPv6 over IEEE 802.15.4, Bluetooth Low Energy, and other constrained networks. Option A is incorrect because 6LoWPAN requires IPv6 (it’s IPv6 compression, not replacement). Option E is incorrect because 6LoWPAN operates at the adaptation layer, not application layer, and security is handled by other protocols like DTLS.

Question: A smart building deploys temperature sensors on battery power with 10-year replacement cycle. Sensors transmit 4-byte readings every 5 minutes over 802.15.4 to a gateway using 6LoWPAN header compression. Analysis shows compressed headers: 6LoWPAN (2 bytes), UDP (4 bytes), CoAP (4 bytes) = 10 bytes total overhead. If uncompressed IPv6 uses 40-byte header instead of 2-byte compressed, how much does IPv6 compression extend battery life?

Explanation: 6LoWPAN header compression provides dramatic battery life extension by reducing total packet size: Compressed stack: 6LoWPAN (2) + UDP (4) + CoAP (4) + payload (4) = 14 bytes total. Uncompressed: IPv6 (40) + UDP (8) + CoAP (4) + payload (4) = 56 bytes total (note: UDP needs full 8-byte header without compression). Energy consumption is proportional to bytes transmitted: ratio = 56/14 = 4x more energy without compression. For 2000 mAh battery: Compressed = 10+ years (0.055 mAh/day), Uncompressed = 2.7 years (0.22 mAh/day). The 38-byte header reduction (40 to 2) translates to 3.67x total packet size reduction for 4-byte payloads, where overhead dominates. This demonstrates why 6LoWPAN is essential for battery-powered IoT sensors.

659.3 Comparing Addressing Approaches

659.3.1 IPv4 with NAT vs IPv6 Direct Addressing

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E8F6F3'}}}%%
graph LR
    subgraph "IPv4 + NAT (Complex)"
        Sensor_v4["Sensor<br/>192.168.1.10"]
        NAT["NAT Gateway<br/>203.0.113.1:5000→192.168.1.10:5683"]
        Cloud_v4["Cloud Server<br/>198.51.100.1"]
    end

    subgraph "IPv6 Direct (Simple)"
        Sensor_v6["Sensor<br/>2001:db8::10"]
        Router["Router<br/>(no NAT)"]
        Cloud_v6["Cloud Server<br/>2001:db8:1::100"]
    end

    Sensor_v4 -->|"Private IP"| NAT
    NAT -->|"Port mapping<br/>State table"| Cloud_v4

    Sensor_v6 -->|"Global IP"| Router
    Router -->|"Direct route<br/>No state"| Cloud_v6

    style NAT fill:#E74C3C,stroke:#2C3E50,color:#fff
    style Router fill:#16A085,stroke:#2C3E50,color:#fff

Figure 659.5: IPv4 NAT complexity versus IPv6 direct addressing simplicity

{fig-alt=“Comparison of IPv4 with NAT requiring port mapping and state tables versus IPv6 direct addressing with simple routing and no state management”}

IPv4 + NAT Challenges for IoT: - NAT gateway maintains connection state (memory overhead) - Port mapping limits concurrent connections - Inbound connections require port forwarding configuration - P2P communication needs STUN/TURN traversal - Each NAT adds latency and potential failure point

IPv6 Direct Addressing Benefits: - Every device has globally unique address - End-to-end connectivity (no middleboxes) - Simplified network architecture - No state management at gateway - Easier debugging and troubleshooting

659.3.2 Cost Analysis: IPv6 vs IPv4+NAT for Large Deployments

Scenario: 10,000 soil moisture sensors across multiple farms

Factor	IPv4 + NAT	IPv6 + 6LoWPAN
Gateway hardware	NAT adds $15/device	No NAT needed
Total gateway cost	$150,000	$0
Header overhead	20 bytes (IPv4)	6 bytes (compressed)
Battery impact	Baseline	60% longer life
Management complexity	Port mapping, DHCP	Auto-configuration
Scalability	Limited by NAT table	Unlimited

Conclusion: For large-scale IoT, IPv6 + 6LoWPAN eliminates $150K in infrastructure while providing 60% longer battery life through header compression.

659.4 Summary

TipKey Takeaways

IPv6 for IoT: - 340 undecillion addresses (79 octillion times more than IPv4) - Every IoT device gets unique global address - No NAT required = simplified architecture - SLAAC enables zero-configuration deployment

6LoWPAN Compression: - Reduces IPv6 header from 40 bytes to 2-6 bytes (85%+ savings) - Essential for IEEE 802.15.4 networks (127-byte frame limit) - Context-based compression derives addresses from MAC - Fragmentation handles packets exceeding MTU

Practical Impact: - 3-4x battery life improvement for small payloads - 90+ bytes available for application data (vs 54 without compression) - Enables IPv6 on Class 1 constrained devices - Foundation for Thread, Zigbee IP, and Matter smart home standards

659.5 What’s Next?

Continue to Application Layer Protocols to learn about CoAP and MQTT - the two dominant application protocols for IoT communication.