25  IPv6 for IoT

Key Concepts

• IPv6: Internet Protocol version 6; uses 128-bit addresses providing 2^128 unique addresses (~3.4 × 10^38)
• Colon-Hex Notation: The human-readable representation of IPv6 addresses as eight groups of four hex digits (e.g., 2001:db8::1)
• Address Compression Rules: Two rules for shortening IPv6 addresses: omit leading zeros in each group, and replace one run of consecutive all-zero groups with ::
• Link-Local Address: Automatically configured address (fe80::/10) valid only on the local link; every IPv6 interface has one
• Global Unicast Address (GUA): A globally routable IPv6 address (2000::/3); the equivalent of a public IPv4 address
• Unique Local Address (ULA): A private IPv6 address (fc00::/7); equivalent to RFC 1918 private IPv4 ranges, not routed on the internet
• ICMPv6 NDP (Neighbor Discovery Protocol): Replaces ARP in IPv6; handles address resolution, router discovery, and stateless address autoconfiguration

25.1 In 60 Seconds

IPv6 provides 2^128 addresses – enough for every IoT device on Earth to have a globally unique address without NAT. For IoT protocols like Thread, Matter, and 6LoWPAN, IPv6 is mandatory, enabling direct end-to-end device connectivity and eliminating the NAT traversal problems that plague IPv4 IoT deployments.

25.2 Learning Objectives

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

• Explain IPv6 benefits: Analyze why the 2^128 address space eliminates NAT requirements for large-scale IoT deployments
• Interpret IPv6 addresses: Decompress and reconstruct 128-bit hexadecimal addresses using compression rules
• Apply 6LoWPAN compression: Calculate header compression ratios and evaluate payload capacity gains for constrained 802.15.4 devices
• Select addressing strategies: Differentiate between global unicast, unique-local, and link-local addresses and justify selection for specific IoT scenarios
• Design transition strategies: Construct dual-stack, tunneling, and NAT64 coexistence plans for IPv4/IPv6 network migration
• Configure SLAAC: Demonstrate stateless address autoconfiguration for IPv6-enabled IoT devices

MVU: Minimum Viable Understanding

Core concept: IPv6 provides 340 undecillion addresses (2^128), enough for every IoT device to have a globally unique address without NAT.

Why it matters: IPv6 eliminates NAT traversal problems and enables direct end-to-end device connectivity.

Key takeaway: For Thread/Matter and 6LoWPAN protocols, IPv6 is mandatory - not optional.

25.3 Prerequisites

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

• IPv4 Addressing Fundamentals: Understanding of 32-bit addressing
• Ports and NAT: Why NAT creates problems for IoT

For Beginners: Why IPv6?

The problem: IPv4 has only 4.3 billion addresses (2^32), but there are already 15+ billion IoT devices worldwide - and growing rapidly.

The solution: IPv6 has 340 undecillion addresses (2^128). That’s 340 followed by 36 zeros. Enough for every grain of sand on Earth to have billions of addresses.

What this means for IoT:

• Every device can have a unique, globally routable address
• No NAT needed - devices can connect directly
• Protocols like Thread and Matter are built on IPv6

IPv6 addresses look different: 2001:db8:85a3::8a2e:370:7334 - Eight groups of 4 hex digits separated by colons - Can compress consecutive zeros with ::

Sensor Squad: Address Space for Everyone!

“We are running out of IPv4 addresses!” Sammy the Sensor panicked. “There are only 4.3 billion of them, and there are already 15 billion IoT devices!” Max the Microcontroller calmed him down. “That is exactly why IPv6 exists. It has 340 undecillion addresses – that is 340 followed by 36 zeros!”

“How big is that?” asked Lila the LED. Max grinned. “Imagine giving every single grain of sand on every beach on Earth its own billion addresses. You would STILL have addresses left over. We will never run out.”

“And the best part for us IoT devices,” said Bella the Battery, “is that we do not need NAT anymore! With IPv4, we all have to hide behind one public address and use a translator. With IPv6, every single sensor gets its own globally unique address. I can talk directly to any device anywhere in the world – no middleman needed.”

“Protocols like Thread and Matter are built entirely on IPv6,” added Max. “And 6LoWPAN compresses those long IPv6 headers so even tiny sensors with limited memory can use them. IPv6 is not just the future of IoT – it is already here!”

---

IPv6 Header Structure

Figure 25.1: IPv6’s simplified header design eliminates fragmentation and checksum fields from the base header, improving router processing efficiency. Extension headers provide optional features when needed.

25.4 Why IPv6 Matters for IoT

IPv4 Exhaustion Problem:

• IPv4: 2^32 = ~4.3 billion addresses
• Global population: ~8 billion people
• IoT devices: 15+ billion (and growing)
• Result: Not enough IPv4 addresses for every device

IPv6 Solution:

• IPv6: 2^128 = 340 undecillion addresses
• Enough for every device to have a globally unique address
• No NAT required (every device can be directly addressable)

Putting Numbers to It

IPv6’s 128-bit address space provides an incomprehensibly large number:

\[2^{128} = 340{,}282{,}366{,}920{,}938{,}463{,}463{,}374{,}607{,}431{,}768{,}211{,}456\]

That’s 340 undecillion addresses. To put this in perspective: \[\frac{2^{128}}{7.5 \times 10^{18} \text{ (grains of sand on Earth)}} \approx 4.5 \times 10^{19} \text{ addresses per grain}\]

For the 15 billion IoT devices currently deployed: \[\frac{2^{128}}{15 \times 10^9} \approx 2.3 \times 10^{28} \text{ addresses per device}\]

Even allocating a /64 subnet per household (18 quintillion addresses each) for 10 billion households only uses: \[\frac{10^{10}}{2^{64}} = \frac{10^{10}}{1.8 \times 10^{19}} \approx 0.00000005\% \text{ of IPv6 space}\]

This abundance eliminates address conservation concerns entirely — why IoT can use stateless autoconfiguration freely.

Tradeoff: IPv4 vs IPv6 for IoT

Decision context: When designing IP addressing for a new IoT deployment, you must choose between IPv4 (with NAT) or IPv6 addressing.

Factor	IPv4	IPv6
Address Space	Limited (4.3 billion, exhausted)	Virtually unlimited (340 undecillion)
NAT Required	Yes (for internet access)	No (end-to-end connectivity)
Header Size	20-60 bytes	40 bytes (fixed)
Device Support	Universal (all devices)	Growing (most modern devices)
Configuration	Manual or DHCP	Auto-configuration (SLAAC)
Gateway Complexity	Higher (NAT translation)	Lower (direct routing)
Legacy Compatibility	Full	Requires dual-stack or tunneling

Choose IPv4 when:

• Deploying in brownfield environments with existing IPv4 infrastructure
• Using legacy devices that lack IPv6 support
• Network equipment or cloud services only support IPv4
• Simplicity is paramount and NAT overhead is acceptable

Choose IPv6 when:

• Deploying large-scale IoT (thousands of devices needing unique addresses)
• End-to-end connectivity is required (no NAT traversal issues)
• Using 6LoWPAN/Thread/Matter protocols (IPv6 native)
• Future-proofing the network for growth

Default recommendation: Use IPv6 for new greenfield IoT deployments, especially with 6LoWPAN-based protocols. Fall back to IPv4 only when legacy infrastructure or device compatibility requires it.

25.5 IPv6 Address Structure

An IPv6 address is 128 bits written as eight groups of four hexadecimal digits:

Full format: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Compressed format: 2001:db8:85a3::8a2e:370:7334

Compression rules:

1. Leading zeros in each group can be omitted: 0db8 → db8
2. Consecutive groups of zeros can be replaced with :: (once only): 0000:0000 → ::

Figure 25.2: IPv6 address compression: full format to shortened notation using :: and leading zero removal

25.6 IPv6 Address Types for IoT

Type	Format	Scope	IoT Use Case
Global Unicast	2000::/3	Internet-routable	Cloud-connected sensors with unique IPs
Link-Local	fe80::/10	Single network segment	Local device discovery, neighbor communication
Unique Local	fc00::/7	Private networks	Internal IoT networks (like RFC 1918 for IPv4)
Multicast	ff00::/8	Group communication	Firmware updates to device groups
Loopback	::1	Local device	Testing (equivalent to 127.0.0.1)

Example IoT addressing scheme:

• Global unicast: 2001:db8:1234:5678::sensor:100 (internet-facing gateway)
• Unique local: fd12:3456:789a:1::sensor:100 (private sensor network)
• Link-local: fe80::a2e:370:7334 (auto-configured on every interface)

25.7 IPv6 Benefits for IoT

1. End-to-end connectivity: No NAT, direct device addressing
2. Simplified network design: No private/public address translation
3. Auto-configuration: Devices can self-assign addresses (SLAAC)
4. Better security: IPsec support is built into the IPv6 specification (RFC 6434)
5. Efficient routing: Hierarchical addressing, better aggregation
6. Multicast support: Efficient firmware distribution to device groups

---

25.8 6LoWPAN: IPv6 for Constrained Devices

Problem: Standard IPv6 packet with headers = 40 bytes (IPv6) + 8 bytes (UDP) = 48 bytes. IEEE 802.15.4 max payload = 127 bytes. Headers consume 38% of frame!

Solution: 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks)

Figure 25.3: 6LoWPAN header compression reducing 48-byte IPv6 header to 2-8 bytes

6LoWPAN Compression Techniques:

1. Header Compression (HC1/LOWPAN_IPHC)
   • Omit IPv6 fields that can be inferred (version, traffic class, hop limit)
   • Compress well-known UDP ports (61616 → 2 bits)
   • Result: 40+8 bytes → 2-8 bytes (83-95% reduction)
2. Fragmentation and Reassembly
   • Split large IPv6 packets across multiple 802.15.4 frames
   • Add fragmentation header (4-5 bytes)
3. Mesh Routing
   • Multi-hop routing under IPv6 layer
   • Allows sensor networks to extend range

Example: Temperature sensor sending data: - IPv6 destination: 2001:db8::gateway:1 - Source: 2001:db8::sensor:42 - 6LoWPAN compresses to: 4 bytes (both addresses share prefix 2001:db8::) - Savings: 32 bytes (addresses alone) → 4 bytes = 87.5% reduction

---

25.9 Transition Strategies: IPv4 and IPv6 Coexistence

Dual Stack: Devices run both IPv4 and IPv6 simultaneously - Pro: Full compatibility with legacy and modern systems - Con: Requires more memory, processing

Tunneling: Encapsulate IPv6 packets in IPv4 (or vice versa) - 6to4, 6rd, Teredo tunnels - Used when one protocol must traverse network supporting only the other

Translation (NAT64/DNS64): Translate between IPv4 and IPv6 - IoT sensors use IPv6, cloud uses IPv4 - Gateway translates between protocols

---

25.10 Deep Dive: IPv6 Address Planning for Large-Scale IoT

Planning IPv6 addressing for large-scale IoT deployments requires a fundamentally different mindset than IPv4. With virtually unlimited addresses, the focus shifts from conservation to organization, aggregation, and operational simplicity.

25.10.1 Hierarchical Address Structure

A well-designed IPv6 addressing plan uses the 128-bit address space hierarchically:

Global Prefix (48 bits)     Site/Building (16 bits)     Subnet (16 bits)     Interface ID (64 bits)
2001:db8:abcd               :0001                       :0100                :sensor-mac-derived
|__________________|        |___|                       |___|                |__________________|
     From ISP/RIR           Site ID                     Device Type          SLAAC or EUI-64

Real-World Example: Smart City with 1 Million Sensors

Figure 25.4: IPv6 hierarchical address planning for smart city with 1 million sensors

25.10.2 Subnet Sizing Recommendations

Deployment Type	Recommended Prefix	Subnets Available	Devices per Subnet
Single floor/zone	/64	1	18 quintillion (unlimited)
Building	/56	256	Each /64 unlimited
Campus	/52	4,096	Each /64 unlimited
City district	/48	65,536	Each /64 unlimited
Enterprise	/44	1 million+	Each /64 unlimited

Key insight: Always use /64 for individual subnets. This is mandated by SLAAC and simplifies neighbor discovery. Never use longer prefixes (/65 or smaller) for device networks.

25.10.3 Interface Identifier Strategies

Option 1: Modified EUI-64 (Traditional)

MAC: AA:BB:CC:DD:EE:FF
Step 1: Insert FFFE → AA:BB:CC:FF:FE:DD:EE:FF
Step 2: Flip 7th bit → A8:BB:CC:FF:FE:DD:EE:FF
Interface ID: A8BB:CCFF:FEDD:EEFF
Full address: 2001:db8:1234:0001:a8bb:ccff:fedd:eeff

Option 2: Stable Semantically Opaque (RFC 7217) - Recommended

• Generates stable but unpredictable interface IDs
• Prevents address scanning attacks
• Same address on same network, different on different networks
• Linux: enabled by net.ipv6.conf.all.addr_gen_mode=3

Option 3: Temporary Addresses (RFC 8981)

• Privacy extensions for mobile devices
• Rotating addresses prevent tracking
• Not suitable for servers or sensors (address changes)

---

25.11 Worked Example: Planning IPv6 Addressing for a University Campus IoT Network

Scenario: A university is deploying 12,000 IoT devices across 8 buildings (classrooms, labs, dormitories). The ISP has assigned the prefix 2001:db8:42::/48. The network team needs to allocate subnets for environmental sensors (Thread/6LoWPAN), security cameras (Wi-Fi), and smart lighting (Zigbee with 6LoWPAN border routers).

Given:

• ISP prefix: 2001:db8:42::/48 (gives 16 bits for subnetting = 65,536 possible /64 subnets)
• 8 buildings, each with 3-5 floors
• 1,500 sensors per building average
• Thread sensors use 6LoWPAN (need /64 subnets for SLAAC)
• Security cameras use standard IPv6 on Wi-Fi

Step 1: Design the subnet hierarchy

Use the 16 subnet bits (bits 49-64) as: 4 bits building ID + 4 bits floor + 8 bits device class.

2001:db8:0042 : BFCC : [interface ID - 64 bits]
               ||||
               |||+-- CC: Device class (00=sensors, 01=cameras, 02=lighting, 03=HVAC)
               ||+--- F: Floor (0-F = up to 16 floors)
               |+---- B: Building (0-7 = 8 buildings)

Step 2: Assign subnets

Location	Subnet	Prefix	Devices
Building 1, Floor 1, Sensors	2001:db8:42:1100::/64	B=1, F=1, C=00	~100 Thread sensors
Building 1, Floor 1, Cameras	2001:db8:42:1101::/64	B=1, F=1, C=01	~15 Wi-Fi cameras
Building 1, Floor 2, Sensors	2001:db8:42:1200::/64	B=1, F=2, C=00	~100 Thread sensors
Building 3, Floor 4, Lighting	2001:db8:42:3402::/64	B=3, F=4, C=02	~60 smart lights

Step 3: Calculate capacity

• Subnets used: 8 buildings x 5 floors x 4 device classes = 160 subnets
• Subnets available: 65,536 (from /48)
• Utilization: 160 / 65,536 = 0.24% – plenty of room for growth
• Devices per /64 subnet: up to 2^64 (18 quintillion) – effectively unlimited

Step 4: 6LoWPAN header compression impact

Thread sensors share a common /64 prefix within each subnet. 6LoWPAN compresses: - Full IPv6 header: 40 bytes - Compressed header (shared prefix, link-local source): 2 bytes - Savings: 38 bytes per packet = 95% compression

For an 802.15.4 frame (127-byte max): 127 - 2 (compressed header) - 8 (UDP) = 117 bytes available for sensor data, versus 127 - 40 - 8 = 79 bytes without compression. That is 48% more payload capacity.

Key insight: IPv6 subnet planning for IoT is fundamentally different from IPv4. You never need to worry about “wasting” addresses – a /64 subnet gives each floor more addresses than all of IPv4 combined. The goal is a logical, readable hierarchy that makes troubleshooting easy: if you see prefix 2001:db8:42:3402, you immediately know it is Building 3, Floor 4, Lighting.

---

25.12 Exercise: IPv6 Address Compression

Challenge: Compress the following IPv6 addresses using proper notation rules:

1. 2001:0db8:0000:0000:0000:0000:0000:0001
2. fe80:0000:0000:0000:a2e0:0370:7334:0000
3. 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Solutions:

1. 2001:db8::1
   • Remove leading zeros: 0db8 → db8
   • Replace consecutive zeros with ::: 0000:0000:0000:0000:0000:0000 → ::
   • Trailing :0001 → :1
2. fe80::a2e0:370:7334:0
   • fe80:0000:0000:0000 → fe80::
   • a2e0:0370:7334:0000 → a2e0:370:7334:0
3. 2001:db8:85a3::8a2e:370:7334
   • Remove leading zeros
   • 0000:0000 → ::

Key Rule: You can only use :: once in an address (otherwise ambiguity exists).

Try It: IPv6 Address Compression Explorer

viewof selectedAddress = Inputs.select(
  [
    "2001:0db8:0000:0000:0000:0000:0000:0001",
    "fe80:0000:0000:0000:a2e0:0370:7334:0000",
    "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
    "0000:0000:0000:0000:0000:0000:0000:0001",
    "2001:0db8:0000:0001:0000:0000:0000:0001",
    "fd12:3456:789a:0001:0000:0000:0000:0042"
  ],
  { label: "Select an IPv6 address to compress" }
)

{
  // Parse address into 8 groups
  const groups = selectedAddress.split(":").map(g => g.toLowerCase());

  // Step 1: Remove leading zeros from each group
  const noLeadZeros = groups.map(g => parseInt(g, 16).toString(16));

  // Step 2: Find the longest run of consecutive "0" groups for :: substitution
  let bestStart = -1, bestLen = 0, curStart = -1, curLen = 0;
  for (let i = 0; i <= noLeadZeros.length; i++) {
    if (i < noLeadZeros.length && noLeadZeros[i] === "0") {
      if (curStart === -1) { curStart = i; curLen = 0; }
      curLen++;
    } else {
      if (curLen > bestLen) { bestLen = curLen; bestStart = curStart; }
      curStart = -1; curLen = 0;
    }
  }

  // Build compressed form
  let compressed;
  if (bestLen >= 2) {
    const before = noLeadZeros.slice(0, bestStart).join(":");
    const after = noLeadZeros.slice(bestStart + bestLen).join(":");
    if (before === "" && after === "") compressed = "::";
    else if (before === "") compressed = "::" + after;
    else if (after === "") compressed = before + "::";
    else compressed = before + "::" + after;
  } else {
    compressed = noLeadZeros.join(":");
  }

  // Calculate compression ratio
  const origLen = selectedAddress.length;
  const compLen = compressed.length;
  const savings = origLen - compLen;
  const pct = Math.round((savings / origLen) * 100);

  // Identify address type
  const firstGroup = parseInt(groups[0], 16);
  let addrType = "Unknown";
  if (groups[0] === "fe80" || groups[0].startsWith("fe8") || groups[0].startsWith("fe9") || groups[0].startsWith("fea") || groups[0].startsWith("feb")) addrType = "Link-Local (fe80::/10)";
  else if (groups[0] === "fd12" || groups[0].startsWith("fc") || groups[0].startsWith("fd")) addrType = "Unique Local (fc00::/7)";
  else if (selectedAddress === "0000:0000:0000:0000:0000:0000:0000:0001") addrType = "Loopback (::1)";
  else if (firstGroup >= 0x2000 && firstGroup <= 0x3fff) addrType = "Global Unicast (2000::/3)";

  return html`<div style="font-family: monospace; background: #f8f9fa; border-radius: 6px; padding: 16px; border-left: 4px solid #16A085;">
    <div style="margin-bottom: 12px;">
      <strong style="color: #2C3E50;">Original (full):</strong><br>
      <span style="color: #E67E22; font-size: 1.05em;">${selectedAddress}</span>
      <span style="color: #7F8C8D; font-size: 0.85em;"> (${origLen} chars)</span>
    </div>
    <div style="margin-bottom: 12px;">
      <strong style="color: #2C3E50;">Step 1 - Remove leading zeros:</strong><br>
      <span style="color: #3498DB;">${noLeadZeros.join(":")}</span>
    </div>
    ${bestLen >= 2 ? html`<div style="margin-bottom: 12px;">
      <strong style="color: #2C3E50;">Step 2 - Replace ${bestLen} consecutive zero group${bestLen > 1 ? "s" : ""} with ::</strong><br>
      <span style="color: #7F8C8D;">Groups ${bestStart}–${bestStart + bestLen - 1} (all zero) → ::</span>
    </div>` : html`<div style="margin-bottom: 12px; color: #7F8C8D;"><em>Step 2: No consecutive zero groups to compress with ::</em></div>`}
    <div style="margin-bottom: 12px; padding: 8px; background: #e8f8f5; border-radius: 4px;">
      <strong style="color: #16A085;">Compressed result:</strong><br>
      <span style="color: #16A085; font-size: 1.15em; font-weight: bold;">${compressed}</span>
      <span style="color: #7F8C8D; font-size: 0.85em;"> (${compLen} chars, ${pct}% shorter)</span>
    </div>
    <div style="color: #7F8C8D; font-size: 0.9em;">
      <strong>Address type:</strong> ${addrType}
    </div>
  </div>`;
}

Try It: 6LoWPAN Payload Capacity Calculator

viewof headerMode = Inputs.select(
  ["Uncompressed IPv6+UDP (48 bytes)", "6LoWPAN compressed (2 bytes)", "6LoWPAN compressed (8 bytes)"],
  { label: "Header mode", value: "6LoWPAN compressed (2 bytes)" }
)

viewof frameSize = Inputs.range([50, 127], { value: 127, step: 1, label: "802.15.4 frame size (bytes)" })

{
  const headerBytes = headerMode.startsWith("Uncompressed") ? 48
    : headerMode.includes("(2 bytes)") ? 2 : 8;

  const payload = Math.max(0, frameSize - headerBytes);
  const headerPct = Math.round((headerBytes / frameSize) * 100);
  const payloadPct = 100 - headerPct;

  const uncompPayload = Math.max(0, frameSize - 48);
  const improvement = headerMode.startsWith("Uncompressed") ? null
    : uncompPayload > 0 ? Math.round(((payload - uncompPayload) / uncompPayload) * 100) : null;

  const barWidth = 300;
  const headerW = Math.round((headerBytes / frameSize) * barWidth);
  const payloadW = barWidth - headerW;

  return html`<div style="font-family: sans-serif; background: #f8f9fa; border-radius: 6px; padding: 16px; border-left: 4px solid #3498DB;">
    <div style="margin-bottom: 12px;">
      <strong style="color: #2C3E50;">Frame breakdown (${frameSize} bytes total):</strong>
    </div>
    <div style="display: flex; align-items: center; margin-bottom: 12px; border-radius: 4px; overflow: hidden;">
      <div style="width: ${headerW}px; background: #E74C3C; color: white; text-align: center; font-size: 0.8em; padding: 8px 2px; min-width: 20px;">
        Header<br>${headerBytes}B
      </div>
      <div style="width: ${payloadW}px; background: #16A085; color: white; text-align: center; font-size: 0.85em; padding: 8px 4px; min-width: 30px;">
        Payload: ${payload} bytes
      </div>
    </div>
    <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 8px; margin-bottom: 8px;">
      <div style="background: #fdecea; border-radius: 4px; padding: 8px; text-align: center;">
        <div style="font-size: 1.4em; font-weight: bold; color: #E74C3C;">${headerBytes}B</div>
        <div style="font-size: 0.8em; color: #7F8C8D;">Header (${headerPct}%)</div>
      </div>
      <div style="background: #e8f8f5; border-radius: 4px; padding: 8px; text-align: center;">
        <div style="font-size: 1.4em; font-weight: bold; color: #16A085;">${payload}B</div>
        <div style="font-size: 0.8em; color: #7F8C8D;">Payload (${payloadPct}%)</div>
      </div>
    </div>
    ${improvement !== null ? html`<div style="color: #16A085; font-size: 0.9em; font-weight: bold;">
      6LoWPAN gives ${improvement}% more payload capacity vs. uncompressed headers.
    </div>` : ""}
  </div>`;
}

---

Common Pitfalls

1. Applying IPv4 Subnetting Habits to IPv6

IPv6 /128 is a single host; /64 is a standard subnet (not a /24 equivalent). Assigning /120 to a LAN wastes no addresses but complicates management. Fix: use /64 for all IPv6 LAN subnets — the standard subnet size — and /128 for loopback and point-to-point links.

2. Not Using “::” Compression Consistently

Writing 2001:0db8:0000:0000:0000:0000:0000:0001 instead of 2001:db8::1 in configurations introduces transcription errors. Fix: always use the compressed form in documentation and configuration files.

3. Forgetting That IPv6 Link-Local Addresses Require Interface Identifiers

fe80::1 is ambiguous when a device has multiple interfaces. The correct notation is fe80::1%eth0 (with zone ID). Fix: always include the interface zone ID when referencing link-local addresses in commands or configurations.

🏷️ Label the Diagram

Code Challenge

25.13 Summary

• IPv6 provides 2^128 addresses - enough for every IoT device to have a globally unique address
• No NAT required with IPv6, enabling direct end-to-end device connectivity
• IPv6 addresses are 128 bits written as eight groups of four hex digits, compressible using :: for consecutive zeros
• Address types include global unicast (internet-routable), link-local (single segment), unique-local (private), and multicast
• 6LoWPAN compression reduces IPv6+UDP headers from 48 bytes to 2-8 bytes for constrained 802.15.4 devices
• Thread and Matter protocols are IPv6-native - IPv4 would require protocol translation
• SLAAC enables automatic address configuration without DHCP
• Transition strategies (dual-stack, tunneling, NAT64) enable IPv4/IPv6 coexistence

25.14 What’s Next

Now that you can analyze IPv6 addressing and apply 6LoWPAN compression, continue building your networking knowledge with these related chapters:

Topic	Chapter	Description
DHCP and Address Resolution	DHCP and Address Resolution	Apply DHCP, ARP, and IPv6 Neighbor Discovery to automate address assignment in IoT networks
IPv4 Addressing Fundamentals	IPv4 Addressing Fundamentals	Compare IPv4 subnetting and CIDR notation with the IPv6 addressing hierarchy covered in this chapter
Ports and NAT	Ports and NAT	Analyze the NAT traversal problems that IPv6 eliminates, and evaluate when NAT64 translation is still required
6LoWPAN Deep Dive	6LoWPAN Overview	Construct 6LoWPAN mesh topologies and configure header compression for IEEE 802.15.4 sensor networks
Networking Addressing Overview	Networking Addressing and Subnetting	Review the full addressing module and select the right addressing strategy for your IoT deployment
Thread and Matter Protocols	Thread Protocol Overview	Implement Thread mesh networking which mandates IPv6 and 6LoWPAN as covered in this chapter