IoT Requires New Internet Protocol

It is no secret that the 4 billion-plus Internet Protocol Version 4 (IPv4) addresses are just about used up. According, the American Registry for Internet Numbers (ARIN), “phase 4” of its IPv4 countdown plan kicked in last June. There are now fewer than 17 million IPv4 addresses remaining, which for all practical purposes means the pool is depleted.

That should hasten the move to IPv6, but so far it hasn’t. In fact, according to CloudFlare CEO Matthew Prince, requests forIPv6 addresses are only 1.5% of all IP address requests. “If we keep growing at this rate, then it will take until May 10 of 2048 before we can finally retire IPv4.”

There are several reasons for this. One is that IPv4 is a 32-bit addressing scheme, and there are still tons of 32-bit applications out there. While 64-bit systems can run 32-bit apps, the reality is that apps always run better in their native environment. In fact, most of the UNIX 64-bit servers run 32-bit versions of the OS for backward compatibility.

A second reason is that IPv4 is mature, well understood, and there is a deep well of experience with it. It isn’t leading-edge technology anymore.

Third, interoperability is proven with IPv4. “Among the many challenges that IoT devices will face when it comes to IPv6 implementation, what we’ll find at the top of the list is interoperability and standardization,” says Santiago Pontiroli, security researcher at Kaspersky Lab. “Vendors are rushing to get their latest gadget to the market, and that sometimes means compatibility with other devices and newer protocols hasn’t been sufficiently tested.” That means as long as IPv4 addresses can be obtained, vendors would rather use them up than worry about new issues with IPv6.

Amit Gattani, senior director of embedded solutions for Micron points out that “the big thing about the IoT, from deployment perspective, is that it is all about making data-driven, real-time decisions. It is a hybrid of all the things that will exist on the IoT.” All of this points to a pressing need to expand the addresses of the IoT. “We are seeing an explosion of devices, traffic,, real-time computing, etc. that drive IoT economics” notes Gattani.

So how is it that we keep muddling along with IPv4? Essentially, it comes down to technological black magic. IPv6 packets will be wrapped in IPv4 packets as long as necessary. There is also a small segment of reuse of addresses, but that doesn’t account for much.

To be able to route IPv6 packets around, they are encapsulated within an IPv4 header (IP protocol 41). This is generally done using 6-to-4 and Teredo dynamic tunneling techniques, which allow systems to gain access to the IPv6 Internet. Such techniques “tunnel” IPv6 packets within IPv4 packets. Tunneling encapsulates IPv6 packets in IPv4 packets and uses the IPv4 network as a link-layer mechanism.

The 6-to-4 method places the IPv6 packets within IPv4 protocol 41 packets. The Teredo method uses a UDP 3544 header and places IPv6 packets within IPv4 packets. One simply sends IPv6 packets, wrapped inside these IPv4 packets, to one of their servers where they are dumped onto the Internet.

Overlay tunnels reduce the maximum transmission unit (MTU) of an interface by 20 octets (assuming the basic IPv4 packet header does not contain optional fields). The use of overlay tunnels, for now, is a transition technique toward a network that supports both the IPv4 and IPv6 protocol stacks, and eventually the IPv6 protocol stack. (There is an excellent white paper by Cisco that discusses this methodology.)

One thing that is fairly common knowledge is the difference, in bits, between the two addresses. IPv4 is a 128-bit address. It is said one could assign an IPv6 address to every atom on the surface of the planet and still have enough addresses left to do another 100+ Earths. That is a lot of IP addresses, “340 undecillion,” to be exact, says Pontiroli.

While it’s unlikely we will need that many addresses, the IoT will signifantly up the ante, according to Philip Lewer, marketing director for IoT and smart home at NXP Semiconductors. “With the support of 3.4 x 10^38 addresses, every ‘thing’ can now have its own globally unique address. Many of these devices will be on low-power personal area networks (LoWPAN) using radios such as those specified in IEEE 802.15.4, which is the underlying radio used in ZigBee, for example. These devices tend to be very low power, low bandwidth and support small maximum transmission unit sizes, such as 127 bytes in the case of 802.15.4. To more efficiently use the computing power in these devices, the 6LoWPAN standard, which is supported by NXP and others, uses header compression techniques to reduce the packet size and thus the processing requirements. The good news is that 6LoWPAN has been put in place to handle the processing challenges, but the rollout of IPv6/6LoWPAN will be sporadic, so IoT device manufacturers will need to support multiple protocols for the foreseeable future.”

IPv6 drilldown
IPv6 adds a number of new protocols that are necessary, especially for the IoT, including:

Internet Control Message Protocol version 6 (ICMPv6). This is responsible for providing diagnostics and error reporting and replaces ICMPv4.
Multicast Listener Discovery (MLD). This is a series of three ICMPv6 messages that replace version 2 of the Internet Group Management Protocol (IGMP) for IPv4 to manage subnet multicast membership.

Neighbor Discovery. Responsible for the interaction of neighboring nodes and includes message exchanges for address resolution, duplicate address detection, router discovery, and router redirects. It replaces Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and the ICMPv4 Redirect message.

There are other protocols that will simply need to be updated, such as the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Both must be updated to be able to perform some new checksum calculations or the IPv6 addresses. TCP must now be able to store IPv6 addresses in its internal Transmission Control Block (TCB). The Routing Information Protocol (RIP) must now be able to send and receive IPv6 route prefixes. (Figure 1 shows the IPv6 core protocols.)

Fig. 1 IPv6 protocol stack. Courtesy of Microsoft.

Like IPv4, IPv6’s primary job is to address and route packets between hosts. It consists of the IPv6 header and payload. It consists of any number of IPv6 extension headers, the upper layer protocol data unit, an ICMPv6 message, for example, and a UDP message (see Figure 2).

Fig. 2. IPv6 packet structure. Courtesy of Microsoft

In IPv6, the 128-bit address is delineated by 16-bit boundaries. Each of these 16-bit blocks is converted to a four-digit hexadecimal number, separated by colons. The resulting representation is known as colon-hexadecimal (21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A. As with IPv4, the leading zeros can be removed for simplification to yield 21DA:D3:0:2F3B:2AA:FF:FE28:9C5A). This varies from the IPv4 syntax, which uses 8-bit boundaries that are converted to decimal equivalent (256.256.256.256, for example) and delineated by periods.

Multicast listener discovery
MLD is the IPv6 equivalent of Internet Group Management Protocol version 2 (IGMPv2) for IPv4. MLD is a set of ICMPv6 messages that routers and nodes exchange to enable routers to discover which multicast addresses have listening nodes for each attached interface.

There are three types of MLD messages in IPv6. The first is the Multicast Listener Query. MLQ messages are either general query messages or multicast-address-specific query messages. Each message type is determined by the multicast destination address in the IPv6 header and a multicast address within the Multicast Listener Query message.

The second is the Multicast Listener Report. MLR messages are sent by multicast listeners to either report interest in receiving multicast traffic for a specific multicast address, or to respond to a MLQ message.

The third is called Multicast Listener Done. This message is sent to report that they are no longer interested in receiving multicast traffic for a specific multicast address.

Neighborhood discovery
This new protocol, ND, is a set of ICMPv6 messages and processes that determine relationships between neighboring nodes. This replaces ARP, ICMP Router Discovery, and ICMP Redirect used in IPv4, and provides additional functionality. ND is used by hosts to discover neighborhood routers and address prefixes, addresses, and other configuration parameters.

Routers use ND to inform hosts of a better next-hop address to forward packets for a specific destination and advertise their presence, host configuration parameters, and on-link prefixes.

Finally, nodes use ND to determine whether a neighbor is still reachable, determine when the link-layer address of a neighboring node has changed, and resolve the link-layer address of a neighboring node to which an IPv6 packet is being forwarded.

There are, of course, many more details to all of this, and there is a plethora of technical data available from a myriad of sources such as Cisco and Microsoft.

IPv6 challenges
As necessary as IPv6 is for the rollout of the IoT to continue, the rollout of IPv6 is still a slow process. “IPv6 adoption is currently a challenge for a number of reasons,” says. Pontiroli. “However, IoT devices might actually be the reason for many vendors to think seriously about the migration from IPv4 once and for all.”

Another challenge to adoption is that current network system designs will have to be reworked. “Increasing the number of available addresses means that RFC 1918 (Address Allocation for Private Internets) and RFC 2663 (IP Network Address Translator Terminology and Considerations) might become a thing of the past and IPv6 will bring a new set of network design considerations and security issues to address beforehand,” says Pontiroli.

“Another challenge is going to be in the capability of the gateways,” notes Philip Lewer, marketing director for IoT and smart home at NXP. “These gateways will not only need to be able to bridge between IPv6 and 6LoWPAN, but there will continue to be IPv4 nodes on the network so the gateways will need to support dual stacks as well as IPv4-IPv6 network address translation (NAT),” he explains. “Finally, another challenge will be the development of flexible protocol stacks in things, which will allow the transition from IPv4 to IPv6 in a small memory footprint.”

There are, of course, many additional challenges that will come up as both IPv6 and the IoT evolves. Some will be easy to manage, others will require a lot of interaction among entities – that won’t be so easy to resolve.

IPv6 security issues
Fortunately, security in IPv6 is not that much different than its predecessor. That is also the unfortunate flip side. Because IPv4 is so well entrenched and the security hasn’t been a big issue, turning that ship will take a lot of effort.

Fortunately, security in IPv6 is not that much different than its predecessor. “The problem really doesn’t change dramatically from a semiconductor perspective. But the strategies will change, somewhat. The security of hardware, and the algorithms, what I call security IP,” says Amit Gattani, senior director of embedded solutions for Micron.

The problem really becomes one of numbers since there will be so many more items connected with the IoT. Gattani goes on to say that “the bigger problem is that IPv6 takes the problems of IPv4 and extends it to the number of devices connected to the IoT. That will, probably, be the bigger issue in IoT security.”

Lewer supports that notion. “The security challenge is fundamentally the same, which is how to authenticate devices and securely communicate with them. IPSec doesn’t solve the problem as its use is optional, and also IPv6 doesn’t deal with the issue of key management, which is critical as many IoT things will be in environments where there is the possibility of tampering. As well, the use of asymmetric keys with secure storage has been needed in IoT IPv4 networks and will continue to be needed in IPv6 networks.”

Conclusion
There is no doubt that IPv6 adoption will be accelerated by the growth of the IoT. In fact, without that, the promise of the IoT will likely not be realized.

IPv4 is an effective but dated protocol. IPv6 is the next generation. Says Lewer: “IPv6, is built with scalability and compliance in mind, not only in terms of available address space but also when it comes to handling multicast communications. In addition, having a conforming IPv6 implementation means supporting IPSec by default, which from a security standpoint is something we already had in IPv4 but not everyone was using.”

The new features and technologies of IPv6, are very capable of propelling us to the next level of the Internet of Everything. It also has the ability to secure these communications, via IPsec, which would be a great accomplishment if we see that before we get too far down path.

In any event, IPv6 and the IoT are inextricably interwoven. Without the IoT, IPv6 isn’t a critical need. But without IPv6, the IoT is just a dream.