Is IPv6 Too Big for an IoT Tiny Home?

Read about wireless IoT protocols, and one feature will stick out above the rest. 6LoWPAN is a typical client addressing protocol. But what is it? The “6” gives us an immediate hint, and if you’re asking if it has anything to do with IPv6, you’re on the right track. 6LoWPAN stands for IPv6 over Low Power Wireless Personal Networks. It’s an IETF standard defined in RFCs 4944, 6282, and 6775. The problems with standard IPv6 comes down to scale and focus when applied to IoT device networks. The minimum MTU specified by IPv6 is 1280 octets. The minimum MTU size for 802.15.4 networks is 127 octets. That’s a 10x difference for those counting! Additionally, IPv6 relies on each link being a single broadcast domain, but most IoT wireless networks operate on some form of mesh network with many devices sharing a broadcast domain. Further, IPv6 focuses on speed and robustness, while 802.15.4 focuses on low power, long-distance over unreliable links, and low costs. These differing focuses force the edge routers and gateways to bridge the gap and all clients to adapt. Finally, after considering 802.15.4 MAC headers, we’re left with an 81-byte payload. Then, a standard IPv6 header requires 40 bytes. Houston, we have a problem: we’ve nearly exhausted the payload, and we haven’t added data. So, how do we resolve these problems? The first significant adaptation of 6LoWPAN is header compression. With header compression, we recognize common data flows contain common header values. We can also assume a common network prefix is used by the entire 802.15.4 network attached to a border router, which allows us to address all devices with the host only portion of the address. Further, on a single hop, the receiver can assume the source address is the transmitter’s MAC address. For this reason, header compression varies based on the destination of the packet in question. Host-to-host traffic within the same network is compressed to 2 bytes. Once we leave the 802.15.4 network, our header increases to 12 bytes if we already know the network prefix or 20 bytes if we don’t. This compression leaves us behind many more bits to encode our data payload. The second adaptation is frame fragmentation. Frame fragmentation is deserving of its own discussion, as many factors will affect how the packet is fragmented and reassembled, including the type of mesh networking in use and the power budget and buffer size for the devices participating in the mesh network. Ultimately, it’s vital to know we fragment the 802.15.4 frames, and each is tagged with:

• Datagram size is the total size of the unfragmented datagram, not the size of the fragment
• Fragment tag identifies which datagram the fragment belongs to
• Datagram offset is where in the unfragmented datagram the fragment resides

The third and final major adaptation for 6LoWPAN is how the devices are addressed and registered with a border router. Neighbor Discovery Protocol (NDP) is more complex and contains unneeded features for IoT networks. All 802.15.4 clients use their local physical (MAC) address by default, so their first packet is a Neighbor Solicitation (NS) packet destined for their own link-local address. If the device receives no response within a time window, it can assume the address is unique. Next, the device sends a Router Solicitation (RS) message to register with the border router and receive the network prefix. This simplified addressing scheme allows a device to quickly and efficiently connect to the network. There are other protocol level considerations for IoT networks, but none are as important as an understanding of basic addressing, and the limitations presented by the PHY and MAC layers of the technology. While IPv6 initially seems overly complicated and resource intensive for IoT devices, a clear understanding of 6LoWPAN demonstrates that with adaption, IPv6 works well and quickly provides every IoT device with a globally unique IP address.