IPv6 for Embedded Developers used to IPv4

### Overview In this presentation, Thiago Macieira from Intel's Open Source Technology Center discusses the critical necessity of transitioning embedded and Internet of Things (IoT) systems from IPv4 to IPv6. Driven by the depletion of IPv4 addresses—IANA ran out of top-level blocks in 2011, with regional internet registries subsequently exhausting theirs (Asia in 2011, Europe in 2013, Latin America in 2014, North America in 2015, and Africa expected by 2019)—the explosion of billions of connected IoT devices makes IPv4 unsustainable. Macieira outlines foundational IPv6 architecture, addressing mechanisms, common programming pitfalls, and modern socket programming practices tailored for embedded developers.

### Key Topics - **IPv4 Exhaustion vs. IoT Growth**: The projected surge of IoT devices (up to 50 billion by 2020) far exceeds the capabilities of standard IPv4, where residential routers typically allocate pools of only 50 to 100 DHCP addresses. - **Protocol Architecture Improvements**: IPv6 mandates multicasting (replacing broadcast entirely), increases the minimum MTU to ensure kilobyte-scale packets transit without intermediate router fragmentation, and introduces native privacy extensions (IPsec was originally designed for IPv6). - **Stateless Address Autoconfiguration (SLAAC)**: Allows local communication between devices without DHCP servers or routers using link-local addresses derived from interface hardware identifiers (e.g., modified EUI-64 MAC addresses). When a router is present, prefix announcements provide globally routable addresses. - **Privacy and Stability Mechanisms**: Addresses privacy concerns by offering RFC-defined temporary random addresses (generating 63 bits of randomness rotating periodically, such as every 12 hours) and stable opaque addresses generated using network identifiers (like SSIDs or router addresses) and local secrets. - **Prefix Delegation and Allocation**: Explains how routers acquire subnet prefixes (typically /64 per network, with standard allocations of /48 or /56 from ISPs via DHCPv6 prefix delegation) and perform Duplicate Address Detection (DAD).

### Technical Details & Programming Practices - **Address Handling Mistakes**: Developers must stop assuming an IP address fits into a 32-bit integer (`uint32_t`) or that an interface holds only a single stable IP. Multiple addresses exist simultaneously (link-local, unique local, globally routable, temporary random), which can expire or become obsolete. - **Modern Socket APIs**: Replace legacy functions like `gethostbyname` and commands like `ifconfig` with `getaddrinfo`, `getnameinfo`, `struct sockaddr_storage`, and the `ip` tool from `iproute2`. `getaddrinfo` automates protocol selection, port resolution, and address sorting based on system reachability. - **Dual-Stack Servers**: Embedded developers are urged to write servers in IPv6. By clearing the `IPV6_V6ONLY` socket option, an IPv6 socket can accept connections from both IPv6 clients and IPv4 clients via IPv4-mapped IPv6 addresses (though developers must ensure firewalls and ACLs account for mapped syntax). - **Low-Power Networks (6LoWPAN)**: Adapting IPv6 for constrained networks, such as IEEE 802.15.4 and BLE via 6LoWPAN, allows 16-bit radio addresses to map directly into link-local IPv6 addresses, providing aggressive header compression without extra lower-layer translation. - **Address Lifecycle & Kernel Notification**: On Linux, developers can listen to `AF_NETLINK` sockets to receive kernel updates regarding IP changes, expirations, and deprecations, while active TCP connections retain existing socket bindings.

### Takeaways Embedded and IoT software can no longer rely on IPv4 assumptions, NAT workarounds, or single-address paradigms. Developers must build protocol stacks using protocol-agnostic system APIs like `getaddrinfo`, design applications capable of handling dynamically rotating addresses, leverage SLAAC and unique local addresses for robust local mesh networking, and configure proper IPv6 packet filtering (`ip6tables`/`nftables`).