IPv6 has characteristics lacking in IPv4 that make it advantageous for internet of things deployments, such as supporting large IoT networks, helping preserve battery life of IoT devices and reducing administrative and maintenance burden. Could IoT be helping to drive IPv6 adoption in enterprise networks?
IPv6 has plenty of addresses
One glaring problem with IPv4 is that it supports only 4.2 billion possible addresses while, by some estimates, the number of internet-connected devices is expected to grow to 28.5 billion by 2022. That’s an enormous shortfall that means when deploying IoT networks, most of these devices could not be connected to the internet without an intervening layer of technology – network address translation (NAT) – that lets one or more public IP addresses service many locally significant or private IP addresses.
IPv6, on the other hand, supports about 340 undecillion addresses or 340 trillion trillion trillion, which is enough to give universally unique IP addresses to each IoT device. And it could do so without requiring further investment in NAT.
IPv6 and IoT battery life
IPv4 also has shortcomings when it comes to preserving IoT battery life. Because many connected devices are battery-powered, and because IoT networks, such as factory sensor systems, can consist of hundreds or thousands of devices, making the batteries last as long as possible is a huge advantage. Just imagine the cost in time and effort required to replace batteries in many widely scattered IoT devices.
With IPv4, routine broadcast messaging unnecessarily saps battery life. For instance, broadcast messages are used for processes like Address Resolution Protocol (ARP) , which is used for binding MAC addresses to IPv4 addresses. The way it works, an ARP message is sent to every device in the network, and each device must process this packet, and therefore use up some battery power, regardless of whether it was necessary for that device to participate in the exchange.
This inefficiency can also disrupt the network as a whole. The problems related to broadcast storms, when broadcasts are used frequently in a short period of time, are well known, and this type of event would be detrimental to an IoT network.
With IPv6, there is no broadcast function. Instead, efficient multicast communications are used for these one-to-many communications. Rather than broadcast, IPv6’s Neighbor Discovery Protocol (NDP) uses efficient multicast with solicited-node multicast addresses for building and maintaining a neighbor cache. The Neighbor Solicitation (NS) packet is sent to only a minute subset of the LAN’s /64 prefix and the Neighbor Advertisement packet is sent back using unicast.
The IPv6 All-Nodes link-local multicasts group address (FF02::1) is as close as IPv6 comes to a broadcast, and IoT devices attempt to use unicast messages whenever possible to further conserve battery power.
Specifics: How IPv6 can reduce draws on IoT batteries
IPv6 offers a variety of methods for dynamically assigning addresses to IoT devices. IPv6 nodes have multiple addresses, unlike IPv4 nodes which only have a single unicast address. IPv6 nodes have a link-local address (FE80::/10) and one or more IPv6 unicast addresses per interface. The link-local address is used to “bootstrap” obtaining the unicast addresses as a source address of a Router Solicitation (RS) message to discover the local router.
The first-hop router sends back a Router Advertisement (RA) message to the all-nodes multicast group (FF02::1) indicating the local IPv6 /64 prefix and the method to obtain its unicast address. Based on certain flags and other options in the RA message, a node is told to use either Stateless Address AutoConfiguration (SLAAC) (RFC 4862), Stateful DHCPv6 (RFC 8415) or Recursive DNS Server (RDNSS) (RFC 8106). Which to use is a question that comes up frequently in enterprise networks.
For sensors that lack the robust computing power needed to run DHCPv6 and only need to operate on a flat network, SLAAC is an obvious choice. For corporate desktops and servers, DHCPv6 has been the recommendation, but the decision has become a little murky. Now that more OSs support RDNSS, including Android, RDNSS is becoming a popular choice.
Thanks to Scott Hogg (see source)