Can IoT networking drive adoption of IPv6?

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.

RA packets are typically transmitted by the local router every 200 seconds to keep all the nodes informed of any changes.  New nodes that join the network are impatient and send a RS packet to the all-routers link-local multicast group (FF02::2) to learn about the network they have joined.  The local router immediately responds to the RS by sending an RA to all-nodes.  As you can imagine, this can consume some measurable battery life in an IoT application and, therefore, options to control RAs have been created.

One option is to use longer RA intervals for IoT networks.  IoT devices may only need to receive a single RA message once a day or even longer.  However, any time that a new IoT device joined the network, it would send an RA, triggering an all-nodes RA multicast to be sent by the local router.

To further restrict All-nodes multicast packets, the RA could be changed to be a unicast packet to the individual node that send the RS.  This would prevent any other established node from receiving the multicast-RA.  This “Unicast-RA” feature eliminates RAs sent to the All-nodes multicast group.  This has been implemented in Cisco IOS versions 15.4(2)T, 15.4(2)S, 15.2(1)SY1 and later and configured using the layer-3 interface command “ipv6 nd ra solicited unicast”.

Innovative IPv6 IoT Protocols

IPv6 facilitates innovation and there has been substantial development of IPv6-capable IoT protocols.  Following are a few examples of how IoT networks can use IPv6.

IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) allows IPv6 packets to be compressed, encapsulate and split up into multiple smaller frames to be sent over IEEE 802.15.4 wireless nets (RFC 4944 and RFC 6282).  Therefore, 6LoWPAN requires a gateway device (edge router) to connect the native IPv6 network to the IoT-device network. The goal is to further constrain the use of IPv6 multicast to maximize battery life (RFC 6775). These methods are used by the Zigbee suite of protocols.

The IETF is working on IPv6 over Low Power WANs like LoRaWAN and Light-Weight Implementation Guidance (lwig) for small embedded devices that use IPv6. The IETF has also created routing protocols for use on these Low power and Lossy Networks (LLNs) (roll).  The IETF has created “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks” (RFC 6550) and Multicast Protocol for Low-Power and Lossy Networks (MPL) (RFC 7731).  RPL uses IPv6 for discovery of all-RPL-nodes using the IPv6 multicast group FF02::1A.

The IETF has developed standards for how IoT devices communicate over IPv6 using web and RESTful interfaces (CoRE).  The Constrained Application Protocol (CoAP) (RFC 7252) defines the method for these IoT devices to use common web services.  CoAP uses the IPv6 multicast group FF0X::FD (All CoAP Nodes).

The Mobile IPv6 (MIPv6) protocol (RFC 6275) has been specified for many years as a way for unconstrained devices to maintain their communications during transition between Layer 3 networks.

IPv6 is even used in industrial IoT manufacturing and robotics networks.  The Precision Time Protocol (PTP) (IEEE 1588-2008) uses IPv6 multicast to synchronize clocks to sub-microsecond accuracy for precise choreography of high-speed movement.  PTP uses the IPv6 multicast groups FF02::6B and FF0X::181.

As enterprises proceed to deploy any type of IoT application, they should be exploring how to make that system utilize IPv6.  Enterprise network engineers should be actively working to deploy the IPv6 infrastructure in-advance of that IoT network while you have the time.  They will implement a better IPv6 network when they are not rushed by a rapidly-moving IoT project that saves the organization money or provides a valuable function.  One of the first steps for enterprises is to obtain their IPv6 address resources from the RIR, and then follow the well-documented guidance for IPv6 deployment.

(Scott Hogg is a co-founder of HexaBuild.io, an IPv6 consulting and training firm, and has over 25 years of cloud, networking and security experience.)