12  IPv6 for IoT

12.1 Start With Enough Addresses for the Estate

IPv6 looks large because it is built for networks where every sensor, gateway, and service can have a stable place without squeezing through scarce IPv4 space. The design question is not just length; it is how identity, routing, discovery, and operations change when address scarcity stops being the main constraint.

Use this chapter to follow an IoT device from local link addressing to routed prefixes and cloud reachability. The goal is to see when IPv6 simplifies the path and when it introduces new evidence you must collect.

Overview: IPv6 Removes the Address Bottleneck, Not the Design Work

IPv6 gives IoT systems a much larger address space than IPv4, but the useful design question is still practical: which addresses are visible outside the site, which are local only, how does a device learn its prefix, and what evidence proves that routing and neighbor discovery work after deployment?

The main shift is that scarcity stops being the design center. A team can give every routed IoT segment a clear prefix without squeezing cameras, gateways, controllers, and maintenance tools into tiny pools. That does not make the network automatically safe. Address scope still decides where traffic can be routed, and security policy still decides which device, service, or management plane should be reachable.

Beginner Rule

Use IPv6 to make addressing and routing explicit. Do not treat the large address space as a reason to skip prefix planning, local-scope rules, or troubleshooting evidence.

The IPv6 base header carries large source and destination addresses while moving optional features into extension headers.

For IoT, IPv6 is especially important when devices use IP-based mesh or constrained-network technologies such as Thread and 6LoWPAN. It supports end-to-end addressing without IPv4-style NAT as the default assumption, but firewalls, routing policy, access control, and device identity still matter. A globally routable address does not mean a device should be reachable by everyone.

A practical IPv6 inventory distinguishes global unicast addresses, unique local addresses, link-local addresses, multicast groups, and any temporary privacy addresses that devices may form. That distinction keeps exposure review concrete: a cloud-facing gateway, an internal building controller, and a same-link commissioning tool can all speak IPv6, but they should not have the same routing scope or firewall intent.

IPv6 addresses are 128 bits long. The usual human notation writes those bits as eight 16-bit groups, or hextets, separated by colons. Leading zeroes inside a hextet may be omitted, and one consecutive run of all-zero hextets may be written with ::. Use compressed notation to keep logs readable, but keep enough original context to prove that two abbreviated addresses are the same endpoint.

Global Unicast

Use for devices or services that need routed reachability through the organization and beyond controlled boundaries.

Unique Local

Use for private site addressing where the network should be routable internally but not advertised publicly.

Link-Local

Use on every interface for local neighbor discovery, router discovery, and same-link operations.

Multicast

Use for group communication such as discovery and controlled one-to-many network operations.

Some IPv6 prefixes have special meanings that should appear in the review record when they are used. ::/128 is the unspecified address used before an interface has a usable address, ::1/128 is loopback, ::ffff:0:0/96 represents IPv4-mapped addresses, fc00::/7 is unique-local space, fe80::/10 is link-local space, and 2000::/3 is the current global-unicast range. These labels are scope evidence, not just notation trivia.

Practitioner: Build the Prefix and Autoconfiguration Record

The practical IPv6 plan starts with readable prefixes and standard subnet boundaries. Use site, building, floor, zone, or device-class fields where they help operations teams understand a route. Keep individual LAN-style device networks as standard IPv6 subnets so stateless autoconfiguration and neighbor discovery behave predictably.

Address notation should be short enough to read and consistent enough to troubleshoot.

Address Planning Rule

Spend prefix bits on operational meaning, not on address conservation. The plan should make it easy to tell which site, device class, or network segment owns an address.

A common device startup path is: form a link-local address, verify uniqueness on the link, discover routers, receive a prefix in a router advertisement, and form one or more usable addresses. DHCPv6 may still be used where the network needs managed configuration, but many IoT networks rely on SLAAC plus clear routing and firewall policy.

Record the autoconfiguration contract at the same level as the prefix plan. For each segment, capture the expected prefix length, router-advertisement source, valid and preferred lifetimes, default-router behavior, DNS advertisement method, DHCPv6 managed or other-configuration flags, and whether devices use stable interface identifiers or rotating temporary identifiers. Standard SLAAC behavior expects a normal LAN-style prefix, commonly a /64, so a nonstandard prefix choice must be tested against the actual device stack before rollout.

The host portion also needs an evidence rule. Older examples often show a modified EUI-64 interface identifier derived from a 48-bit MAC address by inserting ff:fe in the middle and flipping the universal/local bit. That mechanism is useful to understand, but many modern devices use stable private or temporary random identifiers instead. A rollout record should say which identifier method is expected and whether privacy, inventory, or troubleshooting requirements depend on it.

6LoWPAN keeps IPv6 usable on constrained links by compressing predictable header fields.

Prefix Source

Record whether the prefix comes from an ISP, enterprise allocation, lab block, site router, or border router.

Subnet Meaning

Map prefixes to site, floor, device class, link type, trust zone, or operational owner.

Device Formation

State whether devices use SLAAC, DHCPv6, stable private identifiers, temporary identifiers, or gateway-managed addressing.

Evidence

Keep router advertisements, neighbor discovery traces, route tables, firewall rules, and address inventory samples.

Commissioning should prove both address formation and path control. A useful record includes the link-local address, the selected global or unique-local address, duplicate-address detection result, observed router advertisement, default route, first-hop neighbor entry, firewall decision for expected services, and a negative test showing that unintended management access is blocked. For low-power IPv6 networks, also record the border-router prefix, mesh route status, and whether header compression or fragmentation changes the packet path.

Under the Hood: Neighbor Discovery, Routing, and Transition Boundaries

Under the hood, IPv6 success depends on local discovery and routed policy working together. Neighbor Discovery replaces the IPv4 ARP habit, router advertisements shape autoconfiguration, and multicast is part of basic local operation. If these local behaviors are filtered, spoofed, misconfigured, or unobserved, the addressing plan can look correct while devices still fail in the field.

Neighbor Discovery uses ICMPv6 messages rather than broadcast ARP. Router solicitations and router advertisements establish default-router and prefix information. Neighbor solicitations and neighbor advertisements resolve link-layer reachability and support duplicate-address detection. Solicited-node multicast limits discovery traffic to a relevant group, but switches, firewalls, and low-power border routers still need to pass the required ICMPv6 and multicast behavior for the link.

The fixed IPv6 base header is 40 bytes: Version, Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit, Source Address, and Destination Address. Optional extension headers, such as Hop-by-Hop Options, Routing, Fragment, Destination Options, Authentication Header, and Encapsulating Security Payload, are chained through the Next Header field. In IoT networks, extension-header support should be verified on the actual path because constrained stacks, firewalls, and gateways may handle optional headers differently from ordinary Ethernet servers.

Hierarchical prefixes help route aggregation and incident triage when IoT deployments grow.

Operational Evidence

• Neighbor evidence: neighbor cache entries, duplicate-address checks, router discovery, and link-local reachability.
• Routing evidence: prefix ownership, route aggregation, default route behavior, and border-router failover.
• Security evidence: firewall rules, exposure review, device identity, management-plane access, and rogue-router controls.
• Constrained-link evidence: 6LoWPAN compression behavior, fragmentation risk, MTU assumptions, and retransmission symptoms.
• Transition evidence: dual-stack, translation, or tunneling boundaries when IPv4-only systems remain in the path.

Transition design should be explicit. Dual-stack devices need both IPv4 and IPv6 monitoring. Translation boundaries need clear ownership because failures can look like DNS, address, firewall, or application faults. Tunnels can solve reachability but add another operating dependency. The safest plan names which path is native IPv6, which path is translated, and what test proves each path after a network or firmware change.

IPv6 also changes some failure clues. There is no IPv4-style header checksum, routers do not fragment packets in transit, and path MTU discovery depends on ICMPv6 Packet Too Big messages returning to the sender. A firewall that blocks all ICMPv6 can therefore break healthy-looking traffic. On constrained links, 6LoWPAN compression saves bytes but does not remove the need to inspect fragment loss, neighbor-cache churn, route repair, and retransmission pressure.

Recheck the Plan

Reopen the IPv6 design when a new device class appears, a link becomes low-power or lossy, a site gains a new border router, cloud endpoints stay IPv4-only, prefixes are renumbered, or neighbor-discovery evidence no longer matches field behavior.

12.2 Summary

IPv6 for IoT is not only a bigger address space. It is a routing, discovery, scope, and operations design. Plan which device groups use global, unique-local, link-local, and multicast addressing; define how devices form addresses; keep standard subnet behavior where autoconfiguration expects it; and collect evidence for neighbor discovery, routing, security policy, constrained links, and IPv4 coexistence.

12.3 Key Takeaway

Use IPv6 to make IoT addressing explicit and maintainable: plan prefixes by operational meaning, verify autoconfiguration and neighbor discovery, and document transition boundaries where IPv4 remains.

12.4 See Also

• IPv4 Addressing Fundamentals - compare IPv4 address limits and subnet notation with IPv6 planning.
• Subnetting and CIDR for IoT Networks - review prefix sizing and route summaries.
• Port Numbers and NAT for IoT - understand the IPv4 NAT behaviors IPv6 can avoid or still coexist with.
• DHCP and Address Resolution - connect IPv6 autoconfiguration and neighbor discovery to address operations.