Can the Internet of Things drive the deployment of IPv6?

IPv6 has features that IPv4 lacks, which makes it advantageous in IoT deployment, such as supporting large IoT networks, helping to extend the battery life of IoT devices, and reducing their management and maintenance burden. So can IoT help promote IPv6 applications in enterprise networks?

[[257160]]

IPv6 has many addresses

One of the outstanding issues with IPv4 is that it may only support 4.2 billion addresses. It is estimated that the number of networked devices will grow to 28.5 billion by 2022. This is a huge gap, which means that when deploying the Internet of Things, most devices cannot connect to the Internet without the intervention of a technology layer called network address translation (NAT).

On the other hand, IPv6 supports approximately 340 trillion addresses, which is more than enough to provide a universal unique IP address for every IoT device. It can do this without 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 an IoT network (such as a factory sensor system) can contain hundreds or thousands of devices, it is a huge advantage to make the batteries last as long as possible. Imagine the time and effort required to replace batteries in many widely dispersed IoT devices.

With IPv4, regular broadcast messages consume battery life unnecessarily. For example, broadcast messages are used for processes such as the Address Resolution Protocol (ARP), which is used to bind MAC addresses to IPv4 addresses. The way it works is that the ARP message is sent to every device in the network, and each device must process this packet, therefore consuming some battery power, regardless of whether the device needs to participate in the exchange.

This inefficiency can also disrupt the entire network. Problems associated with broadcast storms, where broadcasts are used frequently in a short period of time, are well known, and such events are detrimental to IoT networks.

With IPv6, there is no broadcast capability. Instead, efficient multicast communications are used for these one-to-many communications. Instead of broadcasting, IPv6's Neighbor Discovery Protocol (NDP) uses efficient multicast with a solicited-node multicast address to build and maintain a neighbor cache. Neighbor (NS) packets are sent only to a small subset of the LAN's /64 prefix, while neighbor packets are sent back using unicast.

The IPv6 all-node link-local multicast group address (FF02::1) is very close to IPv6 broadcast, and IoT devices use unicast messages whenever possible to further save battery power.

Details: How IPv6 can reduce battery use in the IoT

IPv6 provides multiple methods to dynamically assign addresses to IoT devices. IPv6 nodes have multiple addresses, unlike IPv4 nodes which have only one 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" the acquisition of a unicast address as the source address of a Router Solicitation (RS) message to discover local routers.

The first-hop router sends a Router Advertisement (RA) message back to the all-nodes multicast group (FF02::1), indicating the local IPv6/64 prefix and the method used to obtain its unicast address. Based on certain flags and other options in the RA message, the node is told to use Stateless Address Autoconfiguration (SLAAC) (RFC 4862), Stateful DHCPv6 (RFC 8415), or Recursive DNS Servers (RDNSS) (RFC 8106). Which to use is a question that often arises in enterprise networks.

For sensors that lack the powerful computing power required to run DHCPv6 and only need to run on a flat network, SLAAC is an obvious choice. For enterprise desktops and servers, DHCPv6 has always been recommended, but the decision has been a bit fuzzy. Now that more operating systems support RDNSS, including Android, RDNSS is becoming a popular choice.

RA packets are typically transmitted by the local router every 200 seconds to let all nodes know about changes. New nodes joining the network are impatient and send an RS packet to the all-router link-local multicast group (FF02::2) to learn about the network they have joined. The local router responds to the RS immediately by sending a RA to all nodes. As you can imagine, this can consume some measurable battery life in an IoT application, so the option to control RAs was created.

One option is to use a longer RA interval for IoT. IoT devices may only need to receive RA messages once a day, or even longer. However, every time a new IoT device joins the network, it sends an RA, triggering a full-node RA multicast sent by the local router.

To further restrict the multicast packets to all nodes, the RA can be changed to a unicast packet from the single node sending the RS. This will prevent any other established nodes 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 Releases 15.4(2)T, 15.4(2)S, 15.2(1)SY1, and later, and is configured using the Layer 3 interface command "ipv6 nd ra solicited unicast".

Innovative IPv6 IoT Protocol

IPv6 has fostered innovation, and there has been a significant amount of development of IoT protocols that support IPv6. Here are a few examples of how IoT networks are using IPv6.

6LoWPAN (IPv6 over Low Power Wireless Personal Area Networks) is a low-speed wireless personal area network standard based on IPv6 that allows IPv6 packets to be compressed, encapsulated, and divided into multiple smaller frames and sent over IEEE 802.15.4 wireless networks (RFC 4944 and RFC 6282). Therefore, 6LoWPAN requires a gateway device (edge ​​router) to connect the local IPv6 network to the IoT device network. The goal is to further limit the use of IPv6 multicast to maximize battery life (RFC 6775). These methods are used by the Zigbee protocol suite.

The IETF is working on IPv6 through low-power wide area networks like LoRaWAN and Lightweight Implementation Guidelines (LWIG) for small embedded devices using IPv6. The IETF is also creating routing protocols for these low-power and lossy networks (LLNs). The IETF created "RPL: IPv6 Routing Protocol for Low Power Networks" (RFC 6550) and Multicast Protocol for Low Power Networks (MPL) (RFC 7731). RPL uses IPv6 to discover all RPL nodes using the IPv6 group FF02::1A.

The IETF has developed a standard for IoT devices to communicate over IPv6 using the Web and RESTful interfaces (CoRE). The Constrained Application Protocol (CoAP) (RFC 7252) defines how these IoT devices use public 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 transitions 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 orchestration of high-speed motion. PTP uses IPv6 multicast groups FF02::6B and FF0X::181. As enterprises continue to deploy any type of IoT application, they should explore how to make that system use IPv6.