Why move to an all-IP IoT

Connectivity standards and the move to all-IP

As IoT has evolved, many different connectivity standards have arisen and are in use today. Z-Wave, Zigbee and Bluetooth all started as ways to efficiently communicate using a specific wireless spectrum with additional protocols for pairing and messaging.

Unlike Wi-Fi, these technologies were not IP-based, but they as they have matured, each have added IP capabilities. This move was made for several reasons:

• Interoperability with other networks and applications. Initially, smart home tech relied on peer-to-peer or peer-to-hub communication. Direct communication with other IP-connected applications, particularly in the cloud, became more of a necessity.
• Ease of development. IP technologies are heavily standardized and have a large community of open source support, which gives developers a wider range of tools to build and deploy solutions faster.
• Native support for web technologies, voice and video. IP technologies have developed over time to handle many kinds of application traffic, especially those suited to the smart home and IoT.

IPv4 presents challenges for IoT architectures

IPv4 and its supporting higher layer protocols, TCP and User Datagram Protocol have been the backbone of the internet for decades. However, the IPv4 address space has been exhausted since 2015, with only a few addresses being eked out here and there. Today's IPv4-based home networks rely on private address space held together with network address translation (NAT), which lets a single public address handle hosts "behind" it in a private address space.

This presents some challenges for many IoT architectures. With products based on different physical layer technologies, the smart home will have many networks within it -- not just a single private LAN --which means using multiple private address spaces and preventing simple peer-to-peer communication. While possible, workarounds such as Session Traversal Utilities for NAT or reliance on "always-on" communication channels are complex and can be difficult for sleepy devices or sensors that are only polled for information once in a while.

What about IPv6?

Though IPv6 has been around for two decades, IPv4's staying power, mostly fueled through NAT technology, has made many hesitant to adopt it wholesale into their network plans. However, IPv6 presents distinct advantages for IoT, having been designed for the future of many billions of network connections traversing thousands of heterogeneous networks.

The sheer magnitude of address space alone is an advantage of IPv6 for IoT. A full IPv6 deployment eliminates the need for private address space altogether, allowing easy bidirectional communication between devices and applications. Since the exhaustion of the IPv4 address space, operators have deployed various transition mechanisms -- such as 6rd, mapping of address and port using translation, and mapping of address and port using encapsulation -- to run IPv4 over IPv6 backbones.

Additionally, IPv6 greatly reduces the network overhead of bootstrapping and address assignment. Stateless address autoconfiguration lets nodes negotiate their own network addresses without the need for central management and assignment. This is a great boon for any deployment with hundreds of devices on one network and devices that frequently come in and out of service.

What can you do to have more reliable IPv6 support in your products?

As said above, IPv6 is well supported by the standards and open source communities. However, rigorous and comprehensive testing of IoT and smart home products that use IPv6 is absolutely essential to getting to it to just work for the end user. Here are some important elements to check when considering IPv6 for your IoT products:

• Connectivity to cloud services. Can your product connect to the cloud services it needs to operate and stay updated? Does your IPv6 connectivity work both before and after a firmware update?
• Bootstrapping. Will your device need to be able to operate with both IPv4 and IPv6 network connectivity? Can it boot, receive addresses and connect to services after restart or sleep modes?
• User control. How do end users access the GUI of your product, if any? Do local interfaces or first-use applications work over IPv6?
• Fundamental service interoperability. Do the core protocols your products need, such as DNS or Network Time Protocol, work over IPv6?

Checking these features is achieved best with rigorous automated testing. Testing the above for each build and new firmware is important to make sure there were no regressions in basic IP protocol functionality. Additionally, there are many things that can cause a device to end up in a bad state, even if the underlying protocol stack -- often implemented from open source code -- works for basic connections. Repeating these connectivity tests frequently over long periods of time can isolate memory leaks or fragmentation that will cause a device to lock up or fail to connect without user intervention.

Ultimately, the Wild West of IoT's connectivity landscape will probably be around for some time. As we move toward a world where smart products become the norm and even a part of critical infrastructure, considering the move to IP and IPv6 can help organizations navigate the waters of this brave new world.

About the author
Jason Walls is director of technical marketing at QA Cafe, developers of quality test and analysis solutions for networks and networking products. A protocol geek at heart, he's been involved with computer networking technologies for over 20 years and helps drive industry standards and open source projects for broadband, enterprise and consumer networks.