14 IPv6 for IoT

14.3 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.

Before using the large address space as a design argument, inspect Figure 14.1 to see what every IPv6 packet actually carries. The header fields expose the routing, lifetime, traffic, and next-protocol evidence that operations must be able to capture.

Read Figure 14.1 from version, traffic class, and flow label through payload length, next header, and hop limit, then finish with the 128-bit source and destination addresses. The fixed sequence separates per-packet forwarding information from optional extension headers. That distinction connects explicit prefix planning to packet-trace evidence when reachability, policy, or path lifetime fails.

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.

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.

14.4 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.

Pause at Figure 14.2 before carrying practitioner: build the prefix and autoconfiguration record forward. Its visual vocabulary joins IPv6 notation: compress for to reading, expand for checking, which frames address notation should be short enough to read and consistent enough to troubleshoot.

Compare IPv6 notation: compress for with reading, expand for checking inside the visual at Figure 14.2. Next find FULL FORM, which completes the scope of address notation should be short enough to read and consistent enough to troubleshoot. The decision in practitioner: build the prefix and autoconfiguration record must preserve that labelled boundary.

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.

Use Figure 14.3 to prepare the decision in practitioner: build the prefix and autoconfiguration record. The diagram names 6LoWPAN Header Compression and IPv6 header, the two anchors needed to assess 6lowpan keeps ipv6 usable on constrained links by compressing predictable header fields.

Use IPv6 header to test 6LoWPAN Header Compression in the diagram at Figure 14.3. Then inspect 40 bytes as the final qualifier on 6lowpan keeps ipv6 usable on constrained links by compressing predictable header fields. That sequence keeps practitioner: build the prefix and autoconfiguration record tied to what is visibly labelled.

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.

14.5 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.

Before assigning individual IPv6 addresses, inspect Figure 14.4 to see how a larger deployment can encode operational boundaries in its prefixes. The diagram matters because aggregation and incident scope depend on the hierarchy, not on the size of the address space alone.

Read Figure 14.4 from the parent allocation into district branches, then compare the sensor, lighting, parking, industrial, and reserved subnets beneath them. Each branch gives routing and operations a summarizable boundary while leaving room for growth. The hierarchy connects prefix planning to neighbor, route, firewall, and ownership evidence: when a branch fails, responders can narrow both the affected estate and the responsible control plane.

The constrained-link evidence line above has a specific shape on an IEEE 802.15.4 mesh. A 6LoWPAN node can identify itself two ways: a 64-bit extended address that behaves like the modified-EUI-64 identifier described above, or a shorter 16-bit address that a PAN coordinator assigns after the node associates. Because 802.15.4 frames are small and do not support IPv6 multicast directly, a leading dispatch pattern in the compressed frame tells the receiver what follows: an ordinary compressed IPv6 header, a mesh-addressing header carrying the originator and final 6LoWPAN addresses plus a hop-count field for multi-hop forwarding, or a fragmentation header carrying a datagram tag and offset when a packet does not fit in one frame. Border-router and mesh-route evidence should record which of these header types a segment actually uses, since a stack that only expects plain compressed headers will not reassemble a fragmented one.

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.

Use the address-bootstrap failure preset below when the symptom is only “no application connection.” It stops at the first failed prerequisite and leaves later DNS and service checks explicitly untested. Then select the DAD-conflict case to compare a missing address response with an IPv6 address that forms but never becomes usable.

Carry the first failed stage, authoritative trace link, and untested higher layers into the incident record. This prevents an application timeout from becoming evidence against every layer at once.