Getting ready for an IPv6-enabled Internet of Things

Michael E. Anderson, The PTR Group, Inc.

May 04, 2014

Michael E. Anderson, The PTR Group, Inc.May 04, 2014

Well, it’s finally happened. We’ve exhausted the IPv4 address space. There are no more /8 IP addresses to be given out and the regional internet registries (RIRs) are scrounging for unused address space to reclaim. So what does this mean for the embedded developer? That’s what we’ll talk about in this paper.

The Internet Engineering Task Force (IETF) foresaw over a decade ago that we would eventually run out of IPv4 addresses to allocate. There were several estimates over the years as to exactly when the regional internet registries (RIRs) would run out of address blocks. Fortunately, the use of such things as network address translation (NAT), the dynamic host configuration protocol (DHCP) and classless inter-domain routing (CIDR) managed to hold off the inevitable for almost 6 years beyond the original estimates. However, the exhaustion of the IPv4 address space was as unavoidable as death and taxes. The so-called “X- day” occurred in mid April of 2011 as shown in Figure 1.

Figure 1. The IPv4 Exhaustion Counter

But, what does “running out of addresses” actually mean to the Internet at large? Essentially, it means that any new requests for large blocks of address space cannot be met. No more ISPs with blocks of address space can be created. Now, IPv4 address space becomes a commodity that can be bargained, traded and potentially sold. And yet, the Internet continued to work.

In fact, in spite of exhausting the address space, nothing of any significance has happened… yet. As long as the major carriers keep their users at bay, the internet will continue to work just fine. However, there is a major block of addresses that, although allocated, hasn’t started to show up much – namely Africa. As more users from that block start to come online, the congestion in the core routers will continue to grow.

As more streaming services like Netflix, Hulu, iTunes and YouTube continue to gain popularity, the latency of traversing the so-called “middle boxes” like firewalls, NAT devices and the like will also continue to grow. This will also be exacerbated by streaming TV services to smartphones and tablets that are now being offered to mobile subscribers. With the number of mobile, Internet-aware devices continuing to increase, and the bandwidth to those devices expanding with the introduction of the long-term evolution (LTE) 4G phone service, we will start to reach a tipping point within the next few years where IPv4 will become a set of handcuffs that will hold the world’s insatiable desire for data hostage. Likely within the next 5 years, we’ll start talking about the tyranny of IPv4 and why it’s holding back progress.

OK, so that’s something to be concerned about for the future of IPv4 in the global Internet, but what about your embedded devices on private network segments? Well, as long as NAT continues to work or the devices have no need to access the Internet, then they’ll continue to work just fine. So, unless your O/S vendor completely drops IPv4 support, not likely in the next decade or so, you’ll be able to continue running for the foreseeable future. There is no compelling reason to incorporate IPv6 into your existing designs in these cases other than the desire to be “current” or if your customer requires it.

Here may lay the key feature that forces the issue. The U.S. Government has mandated the use of IPv6 by the end of 2012 and all federal agencies have had to demonstrate IPv6 capability and publish a statement that shows their compliance. In addition, the major carriers, largely prompted because the federal government is one of their largest customers, are also requiring that any device attached to their networks also be IPv6 capable. So again, existing sensor networks and embedded devices used by the federal government are “grandfathered”, but new devices will need to show IPv6 compliance. This means that we have the luxury of a transition period that may be on the order of a few years.

What if I'm a Middle-box Vendor?
On the other hand, if you’re a vendor of the middleware hardware and software boxes, then your future is lays on a somewhat different path. As stated previously, the federal government is mandating IPv6 support in all new equipment. Additionally, the major carriers are mandating it as well. This means that if you want to continue to sell your devices, you’ll have to bite the IPv6 bullet sooner or later.

For a large number of O/S platforms, this transition to IPv6 support is a fait acompli. Linux, Android, Windows, OS/X, and the xBSD platforms already support IPv6. In most, the support simply needs to be enabled. This can take the form of loading a driver or it may already be built in.

Once enabled, the network interfaces will show two separate addresses. One set for IPv4 and one for IPv6. These operating systems will also have a preference value that can be set to prefer using one or the other addresses. An example of the address duality can be seen in Figure 2.

Figure 2. Ethernet Interface wl IPv4 & IPv6 Active

Having both protocols active is referred to as having a “dual-stack” capability. The two protocol stacks run in parallel. If you have both stacks active and are only using IPv4 addresses, then the primary overhead is simply the memory used by the IPv6 stack. The matching done on the version field of the IP header will then direct packets to one stack or the other.

Yet, the desktop O/Ses are not the only ones to have IPv6 support. Many of the major RTOS vendors also have IPv6 support. For some, it’s built in like the desktop O/S variants. In other cases, it’s an extra-cost option. For example, Wind River’s VxWorks, Enea’s OSE, RIM’s QNX all have IPv6 support. For Express Logic’s ThreadX, the stack itself is an extra-cost option, but IPv6 is available. However, operating systems like Micrium’s µC/OS-III only support IPv4 at the time of this writing. If IPv6 support for your embedded device is in your future, make sure to pick an O/S that supports it.

There is another benefit for embedded devices by switching to IPv6. The IPv4 protocol is notoriously complex requiring a fair amount of processing power to handle simple routing chores (Figure 3). The size of the IPv4 header can vary from 20 to as many as 60 octets depending on the enabled options. This can require a substantial amount of processing power to handle layer-3 switching.

Figure 3. IPv4 Protocol Header

On the other hand, an IPv6 header is always a fixed 40 octets and is considerably simpler (Figure 4). Much of the complexity of IPv4 is pushed off to subsequent protocol headers that need not be interrogated by layer-3 switches. This allows for many more packets-per-second through the same hardware with IPv6 when compared to IPv4.

Figure 4. IPv6 Protocol Header

How difficult is it to port to IPv6?
Let’s say that you’re committed to supporting IPv6, but you’ve got a lot of legacy IPv4 code. How hard is it to port to IPv6? Fortunately, it’s not that difficult.

First, realize that most of your old favorite commands like ping, traceroute, etc. have IPv6 versions with a “6” in their names. Therefore, ping becomes ping6, traceroute becomes traceroute6 and so on. Additionally, tools like tshark, WireShark, tcpdump, etc. are already IPv6 aware.

As for the programming APIs, only minor tweaks are typically needed to the code. The address family for IPv6 is AF_INET6 and the sockaddr_in structure is replaced by sockaddr_in6. As you might guess, most of the required changes to the code are in the area of setting up the addresses. The following is an example of an IPv4 server program that was converted to IPv6:

#include <sysƒtypes.h>
#include <sysƒsocket.h>
#include <netinetƒin.h>
#include <stdio.h>
#include <netdb.h>
main(argc, argv) /* server side */
int argc;
char *argv[];
int f;

/*                                             */
/* OLD code: struct sockaddr_in from;          */
/* OLD code: struct sockaddr_in sin;           */
/*                                             */
/* Change structure to sockaddr_in6 from sockaddr_in. */
/*                                             */
struct sockaddr_in6 from;
struct sockaddr_in6 sin;
struct servent *sp;

sp = getservbyname("login", "tcp");
if (sp == NULL) {
      "rlogind: tcpƒlogin: unknown service\n");
#ifndef DEBUU
/* Disassociate server from controlling terminal. */

memset((char *)&sin, 0, sizeof(sin));

/*                                                */
/* OLD code: Not applicable.                      */
/*                                                */
/* If the len member was not in the original IPv4 code */
/* add it now and make sure it is sin6_len for IPv6.   */
/*                                                     */
sin.sin6_len = sizeof(sin);

/*                                                     */
/* OLD code: sin.sin_port = sp->s_port;                */
/*                                                     */

/* Make sure you are using sockaddr_in6 members.       */
/*                                                     */
sin.sin6_port = sp->s_port; /* Restricted port */

/*                                                     */
/* OLD code: sin.sin_addr.s_addr = INADDR_ANY;         */
/*                                                     */
/* Make the modifications for assigning in6addr_any to */
/* sin6_addr.                                          */
/* */
sin.sin6_addr = in6addr_any;

/* */
/* OLD code: f = socket(AF_INET, SOCK_STREAM, 0); */ /* */
/* Use the correct address family for IPv6. */ /* */
f = socket(AF_INET6, SOCK_STREAM, 0);
if (bind(f, (struct sockaddr *)&sin, sizeof(sin)) < 0) {
listen(f, 5);
for (;;) {
   int g, len = sizeof(from);

   g = accept(f, (struct sockaddr *) &from, &len);
   if (g < 0) {
      if (errno != EINTR)
         syslog(LOU_ERR, "rlogind: accept: %m"); continue;
   if (fork() == 0) {
      doit(g, &from);

With the exception of the occasional “6” and the difference in handling the addresses, this looks pretty much the same as the IPv4 version. But, this raises the question of those pesky 128-bit IPv6 addresses.

< Previous
Page 1 of 2
Next >

Loading comments...

Parts Search