A common phrase I heard these days was: „IPv6 is definitively needed when the Internet of Things / Internet of Everything takes place“. On first sight it totally makes sense: gazillion of things need to communicate and there is a need of an address space which is capable of assigning an address to each of these communicating devices. Of course this can easily be done with the IPv6 space if you only look at the end-host numbers. But is it that easy? Is this THE driver of IPv6 adoption? To understand the addressing needs I had to dig deeper into communication behavior and techniques which can be used in an IPv6 sensor installation. I tried to look at the sensor example because sensors can have very limited power, processing and storage capacity. In contrary to e.g. production machines which can easily have a full blown server with an all-you-can-wish stack as part of their interior system. So, to think of a changed environment basically a sensor network can look like this:
First I thought of a Sensor Layer which includes all kinds of very tiny or large sensors. These devices can simply transmit their data or can trigger other sensors (aka: M2M) and of course receive control information. The next step will be the Collector Layer. The items placed here do a pre-verify of sensor data and keep track of the sensors. In this example it is the first connection to the Internet. Due to the communication needs of the collector layer we can add the Transport Layer to send data to a central intelligence, the Middleware Layer.
To comment that approach: yes, there are a lot of variations possible. You can think of analyzing and storing data on premise, then there is no need of a Transportation Layer. If you have sensors combined with Arduino Yùn or Raspberry PI, then you can easily overcome the Collector Layer and just send your data e.g. to CKAN Servers. An example of a prototype super sonic distance sensor which is able to send tweets of the measured distance may be illustrated by this picture (only the serial output was taken, but this Arduino Yùn comes with a full blown IP stack):
So, to start from top to bottom, the Middleware Layer is in my opinion one of the easiest ones. Think of a CKAN Server, which collects data and e.g. can reside in a virtual environment, it is only dependent on the hosting servers IP capabilities. Most of the operating systems do support Dual-Stack and therefore communication to the Transport Layer is given.
Next layer would be the Transport Layer. Basically I also see no restrictions if you stick to proven techniques. You can easily communicate over an IPv4 or IPv6 enabled infrastructure. This is possible with native IPv6 or with tunnel techniques. By adding additional confidentiality and having a mixed IPv4 or IPv6 environment, DMVPN can be your choice. Working proof here. So nothing special at this layer either.
But now let’s start with interesting things: the Collection Layer. These devices have to do some kind of translation and should add security to their communication habits, because this is the layer which connects the data to the public Internet. Right now, I only take connectivity in consideration otherwise it would go far behind this small article. These devices must be dual-stack enabled, because native IPv6 lines from Internet providers are not granted everywhere. They have to support tunnel techniques to transport or receive their data to/from the Middleware Layer and they should support most of the physical connectivity options to interact with the Transport Layer. But there is another side: communication with the Sensor Layer. If I simply follow the assumption that every sensor has a legacy wired/wireless IPv6 stack, sensor is sending data on a regular basis and has enough power to stay always on and get the maximum transmission capacity, then this new world would be easy. But this perfect environment is not always granted. Devices in the Collection Layer have to have some kind of protocol translation capabilities. They must connect to the various communication options which are provided by the Sensor Layer. It leads us directly to communication habits of sensors. All of these tiny little devices should be IP enabled, but they can have different characteristics. Some are „always-on“, some have very low power requirements and are only online and do communicate once an event is triggered. And of course their ability to connect over long distances is also very limited. All of these can be reflected e.g.: ZigBee as a connection protocol, which is part of the IETF 802.15.4 standard. But what if the devices are not able to contact directly their collection devices? The following picture will illustrate that approach:
To implement routing in such an environment the ROLL working group from IETF has been established and their timeline looks promising:
Do we have to take only routing into consideration? The legacy IPv6 protocol stack must also be modified, because the connection here is lossy, communication must be aware of different online behavior, bandwidth is limited, etc … One approach to overcome these limitations is 6LoWPAN:
To come to a conclusion:
I think Internet of Things / Internet of Everything movement will be a huge opportunity to bring IPv6 forward and drive new evolutions. Additional protocol extensions are needed for this completely different environment. But anyhow: these add-ons are only included when useful and the legacy IPv6 world will understand the base protocol. It’s much easier to go for it than to implement „old“ translation technologies … So finally: It will be definitively one of the main drivers, starting from sensors (things) to their collectors via transport to the application, IPv6 will be everywhere. We have to embrace the new protocol!! Go for it!!