IPv6 and the Internet of Things

For a while now we’ve been told that IPv4 addresses (you know, the network addresses that look like 192.168.1.1) are running out. and, approximately three decades from now, there aren’t going to be enough of them left to go around. While we have reached the point of IPv4 being fully allocated at a high level, it's still easy to buy or lease IP addresses in any region, and ISPs are not turning down new customers because they cannot allocate them an address. Some ISPs have had to go the route of only assigning IPv6 addresses, using a variety of tricks to allow you to still access the IPv4 internet; however, that being said, the complete allocation of usable addresses will come at some point. Nobody knows when because nobody knows precisely how many addresses are actually in use. Therefore, to future proof any device we build they should support IPv6 and use IPv6 services, right?

IPv6 was developed as a replacement for IPv4, but only received formal ratification in 2017, almost 20 years after the draft standard was published. Often, Internet-of-Things (IoT) devices are mentioned in articles about IPv4 exhaustion, saying that Things/devices like your fridge, washing machine, robot vacuum or TV are contributing to the issue by needing to be connected. This is somewhat incorrect, as these all connect to your home/office network and don’t get a public address (ie: your internet’s public IPv4 address is shared among all devices connected on your network).

While the media pick on IoT devices in your home, Things out in the wild can be using/requiring an internet address of their own. Cellular (or even DSL/Fibre) connected environmental monitoring stations, cellular asset trackers, or other remote monitoring/tracking solutions might have their own IPv4 address. I say might, as quite a few Machine to Machine (M2M) SIM card providers use Network Address Translation to share a public IP address amongst multiple clients on their networks - similar to the TV or Fridge in your home behind your internet router. This is fine if you’re just pushing data up to a service, but it isn’t very helpful if you need to run a server (web or ftp for example) on your device. Take for instance a large, remote diesel generator - having it report back to a service is great for keeping track of maintenance hours, electrical loads, fuel consumption and such - but what about remote start/stop or live tuning of parameters? This likely needs a web interface running on the generator, and to get to that web interface you would need to be directly connected to the internet in most cases. I’m ignoring for the moment M2M SIMs that create a VPN tunnel directly into your office/server rack in a data center, as many low budget/simple M2M options don’t have this capability from the provider, and a very simple microcontroller might not have the capability (memory/processor time/flash space) to implement such a measure directly.

As designers of connected electronics, we should be looking to use IPv6 so we aren’t ‘part of the problem’, as news articles like to make us out to be - but is that really possible?

The ISP I use for my business was an early adopter of IPv6, all of their web, email, infrastructure servers support IPv6, and every internet customer gets a whole /64 of IPv6 addresses to use (which is pretty common, and that's twice as many address as all of IPv4!) They also offer M2M SIM cards which have a static IPv4 address, but they don’t have the capability to offer IPv6 addresses on a cellular connection, despite the fact that a 4G connection uses IPv6! Infrastructure and software/technical decisions made in the past can be a major contributor as to why services haven’t moved to IPv6 yet.

Take something as simple as email. Mail servers are all capable of working over IPv6, but generally they don’t because it’s just too easy to change your IPv6 address when your ISP gives you twice as many IPs as the whole IPv4 space. Why does that even matter? Well, most spam monitoring systems attribute a reputation to a specific IP address to determine if they are spammers or not - a viable solution because there are relatively few IP addresses available - many services will simply reject anything coming over IPv6 because of this. If we want our internet connected Thing to send email directly without using a web based service as a proxy, it’s probably going to need IPv4 to get through to a major mail provider like Google or Microsoft’s inbox offerings.

I wanted to see just how viable it would be to use IPv6 exclusively on an internet connected Thing - assuming you could get an IPv6 address in the first place. I attempted to set my office computer to use only IPv6 during the test, but the brand new (and fairly low budget) name brand switch I recently purchased doesn’t switch IPv6 packets properly. So despite having an IPv6 address with loads of IPs to play with… there wasn’t much I could test from the office (didn’t I just mention infrastructure issues?). To do some testing I setup an Ubuntu virtual machine on a server in a datacenter. There’s nothing much between a server in a rack and ‘the internet’, so it rules out any infrastructure failure modes.

Before we look at accessing IoT related services over IPv6, how accessible is the internet in general? Looking at the top 500 websites according to Alexa, only about 23% of them support IPv6 (http://www.delong.com/ipv6_alexa500.html) so already things are not looking so good, are they?

I set the virtual machine’s IPv4 to disabled (despite the fact it didn’t have an address assigned), just to be really sure we’re only using IPv6.

Once I manually configured the IPv6 address (as it’s a virtual machine with no DHCP/SLAAC) and set the DNS servers to use CloudFlare’s IPv6 DNS servers (https://1.1.1.1/dns/), I was able to do a quick check at http://ipv6-test.com to confirm all was set.

Perhaps we can quickly check Digi-Key and Mouser for the latest IoT offerings! Uh oh… server not found. I had no luck visiting RS Components, Element14, Farnell, Arrow, Chip1 Exchange, TEM, Quest Electronics, or Rutronik with just IPv6. There was just a single component distributor I could visit - Future Electronics works nominally, give them a gold star. Out of all the major electronics distributors, that was the only website I was able to visit. These companies are supplying the parts we use to design build the latest and greatest tech, yet still don’t have IPv6.

Perhaps they don’t feel that there are enough potential customers visiting their websites from IPv6 to take the time to implement it? According to data from World IPV6 Launch, this might not be too far from the truth. Things are changing, and fairly rapidly if you look at the graphs for providers to see adoption rates. Five years ago, it was a bit of a chicken and egg situation — companies didn’t offer IPv6 web services because customers didn’t have IPv6, and customers didn’t have IPv6 because there were no IPv6 web services to use. Now however, some major North American and European providers have over 70% adoption rates.

Now back to IoT devices, what if we want to make a little bot that will tell social media when a door is opened (like at a makerspace) or provide daily weather extremes? Facebook and Twitter are popular platforms with good APIs for letting your fans know. Facebook works for this, however Twitter does not. Google Plus works too, incidentally.

What about sending a message to yourself to let you know that something has turned on, overflowed, or is running out of battery? We’ve already ruled out SMTP as an option because many spam filters will reject the email without an IPv4 address in the header. To get our message out via SMS or Email, we’ll need to use a web service that will do the work for us. I’m trying top Google search results (from google.nl), assuming that larger providers have better page rank.

I was going to make a nice results table, however, below are the only two SMS providers that I was able to visit out of the first 2 page results - all the major players  (talked about in the community/media) were on the first page.

• GatewayAPI (https://GatewayAPI.com)

• Textbelt (https://Textbelt.com)

I haven’t used these services, so I can’t say anything about their offerings except that their website and API are accessible via IPv6.

For sending email, only SparkPost (https://www.sparkpost.com/) and the GMail API were responsive - out of the first 2 page results.

Amusingly (for me at least), Google’s ad services didn’t work over IPv6 so I wasn’t able to click on the ad links to check the providers which were paying to advertise their services.

The results are really quite similar on IoT data logging services. Only Xively (https://xively.com/) worked for me out of the first 4 pages of results (I went a little further, as there were numerous blog articles in the results). Xively wasn’t in the search results, but they were mentioned in a blog post that worked, so I’ll count them in.

If you’re looking to create your own services, Microsoft Azure has good support for IPv6 and their website actually works over IPv6. Everything Google offer seems to support IPv6, and the Google Cloud service is no exception. Amazon has lots of search results for supporting IPv6 and how to add IPv6 to instances of their services, but sadly none of these documentation pages could be loaded. You could also look at a small Virtual Private Server (VPS) or dedicated server where you’d have complete control over the IPv6 implementation (assuming your ISP gives you IPv6 addresses!).

Despite all the talk of IPv6 being the future and the IPv4 address pool being exhausted, there’s very little we can do as engineers using the services currently available to help the situation. With IoT being a big buzzword in high tech industry, I had hoped IPv6 would have been more widely adopted in order to future-proof products we are developing today. Hopefully, we can encourage service providers to offer IPv6 support, as microcontrollers are not always capable of an IPv6->IPv4 tunnel which would be a solution on a desktop computer. IPv4 is here to stay for the foreseeable future, and it’s what we’ll need to base our designs on. It’s hard to future-proof a product when the world isn’t ready for it yet.