Getting ready for an IPv6-enabled Internet of Things - Embedded.com

Getting ready for an IPv6-enabled Internet of Things

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
#include < sysƒsocket.h>
#include < netinetƒin.h>
#include < stdio.h>
#include

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) {
   fprintf(stderr,
      “rlogind: tcpƒlogin: unknown servicen”);
   exit(1);
}

#ifndef DEBUU
/* Disassociate server from controlling terminal. */

#endif

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) {
      close(f);
      doit(g, &from);
   }
   close(g);
}
exit(0);
}

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.
IPv6 Addresses
Up to this point, we really haven’t made muchof an issue of what the IPv6 addresses look like or how they’reassigned. Considering that IPv6 addresses are four times the size ofIPv4 addresses, there must be a significant difference in how they’rehandled. This assumption is spot on.

First, forget about keepingIPv6 addresses in your head. With the exception of localhost (::1) andthe IPv6 version of INADDR_ANY (::), you don’t have much of a chance toremember them. First, the address is broken up into blocks of fourhexadecimal digits separated by “:”s. Leading zeros can be omitted andsuccessive blocks of zeros can be abbreviated as “::” although only one“::” sequence is permitted per address.

As an example, the following addresses are all equivalent:

    2008:0db8:0000:0000:0000:0000:1978:57ac
 2008:0db8:0:0:0:0:1978:57ac
  2008:0db8::1978:57ac
 2008:db8::1978:57ac

And, if you’re wondering how you enter a web address using the IPv6 address:

  http://[2008:0db8::1978:57ac]/
 https://[2008:0db8::1978:57ac]:443/

Clearly,these addresses will not be used by the public at large. These cry outfor using the domain name service (DNS). To configure DNS to supportIPv6, the records are not “A” records, but rather “AAAA” records:

$ sudo dig aaaa ipv6.google.com

; <<>> DiG 9.7.1-P2 <<>> aaaa ipv6.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56332
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ipv6.google.com. IN AAAA

;; ANSWER SECTION:
ipv6.google.com. 900    IN   CNAMEipv6.l.google.com.
ipv6.l.google.com. 300  IN   AAAA 2001:4860:8003::93

Withsuch a large address space, how do we go about assigning an IPv6address to our interfaces? As it turns out, there are a number ofapproaches. Some of them are automatic, some require user intervention.

Oneof the goals of IPv6 is to restore end-to-end transparency to network.Essentially, eliminate the need for NAT boxes and allow devices to talkto each other as peers. If this is a goal, then we need to be able touniquely assign an IPv6 address. Therefore, one of the techniques forassigning addresses is to use the “link local” form of the address. Inthis technique, the MAC address of the interface is split in half andused in different portions of the IPv6 address.

Assuming anEthernet MAC of 5c:26:0a:26:76:dc, the link-local IPv6 address would be:fe80::5e26:0aff:fe26:76dc/64. Huh? The 48-bit MAC address is encoded asthe lower-order 64-bits of the IPv6 address. Let’s take a closer lookat the IPv6 address to decode it.

The first two octets of theaddress are “FE80”. This denotes a link-local address, e.g., one encodedfrom the MAC of the interface. The 6 octets of the MAC are then splitinto two equal pieces with “FFFE” sandwiched between. Finally, bit 1 ofthe first octet is set and the address is complete. This then becomes amodified IEEE EUI-64 identifier.

The advantage of this addressingapproach is that the address can now be uniquely traced to a singlemachine assuming that there are no duplicate MAC addresses floatingaround out there. This traceability is either good or bad depending onyour perspective. On the plus side, it helps diagnose connectivityproblems. On the bad side, it gives “evil-doers” more information aboutyour machine, like the manufacturer, than you’d really care to give out.

Ifyou don’t care for this addressing approach, then there are severalothers. One simply requires you to contact your site’s main router andhave the router assign an address using the State-less Automatic AddressConfiguration (SLAAC) protocol. Very similar to IPv4’s DHCP, SLAAC justassigns you the next available address, but doesn’t keep track of theaddresses you device was assigned. This means that each time you getboot, you’ll end up with a different IPv6 address.

In addition,there is an option to generate a more randomized address as per RFC 4941″Privacy Extensions for Stateless Address Autoconfiguration in IPv6″.With this feature enabled, the IPv6 address will be randomized acrossboots making it very difficult to correlate network traffic to aparticular device.

If you’d like more consistency inyour IPv6 addresses, then you have the option of using the statefulDHCPv6 server or manually assigning the address. Realize that the top 64bits of the address are likely assigned by your ISP, so you have tokeep those consistent so the core routers can find your network carrier.The remaining 64-bits are yours to choose including the application offurther subnet masks as assigned by the addressing authority for yoursite.

Security and IPsec
Another aspect of IPv6 that’sfrequently used as justification for its deployment is the use of theIPsec encryption layer. IPv6 has IPsec specified as an integral portionof the protocol. And yet, IPsec is also supported in IPv4 although ithasn’t seen wide-spread deployment in IPv4 networks. The notableexception is Cisco’s use of IPsec for their VPN solution and theLinux-based OpenSWAN/FreeSWAN VPNs.

IPsec is a link-encryptiontechnique. That is, each transaction is uniquely keyed and provides fordata integrity (the message won’t decrypt properly if it has beentampered with), data origin authentication (a unique key is used thatcan’t be forged from another location) and anti-replay facilities(sequence numbers can’t be duplicated). In addition, we can encrypt justthe security header or the header and the data payload as separatesteps depending on the security level desired.

This sounds greatin theory. And, given the layering of the protocols, routers need not gobeyond the top-layer IPv6 header into the encryption headers. Thisreduces the processing requirements for the middle boxes.

Unfortunately,in practice, the encryption key management is a bit on the complex sideand does not traverse NAT devices. Additionally, the process ofencrypting the traffic can place a significant overhead on datatransmission unless the device has hardware-based encryption engines.Therefore, although all IPv6 implementations will have support forIPsec, in practice there isn’t a lot of IPsec traffic traversing theInternet currently.

Are You Ready for IPv6?
June 6th,2012 was “World IPv6 Launch Day” (Figure 5 ). On that day, many of themajor ISPs and websites like Google, Yahoo!, Facebook, Akamai and otherspermanently enabled their IPv6 sites. Since then, the number ofIPv6-enabled websites has increased by roughly 2500%.

Figure 5. World IPv6 Launch Day

VariousIPv6 readiness tests are available on the Internet including going tohttp://test-ipv6.com. This site will test your IPv6 connectivity andprovide a report as seen in Figure 6 .



Click on image to enlarge.

Figure 6. IPv6 Connectivity Test

Ifyou happen to be serviced by one of the network service providers thatdo not already support IPv6 natively, all is not lost. There are anumber of ways for IPv4/IPv6 coexistence. In particular, there areseveral IPv6 tunneling techniques such as 6to4, Teredo, 6in4 and otherswith tunnel brokers that provide an endpoint as apoint-to-point of IPv6 ingress/egress for testing purposes. An exampleof a Teredo tunnel is shown in Figure 7 .

Figure 7. A Teredo IPv6 Tunnel Example

Aquick visit to your favorite search engine will show several otherwebsites that provide information and testing techniques to verify yourdevice’s ability to handle the future of IPv6 networks.

Summary
Unfortunately,we’ve merely scratched the surface on the issues associated with IPv6.But, hopefully you now have a better idea of what IPv6 is all about. Theissue ahead of you is if/how you’ll support IPv6 in your embeddedprojects?

Remember, if your devices are an isolated sensornetwork or similar application wherein all traffic is on the localnetwork, then you can likely ignore IPv6 for at least a few more years.However, if you are a mobile application or touch the Internet is someway, IPv6 is definitely in your future. As is the case for mostdevelopment, it’s a matter of time and money (and customer demand) as tohow soon you’ll be supporting IPv6.

If you get a few minutes,it’s likely in your best interest to go out to the various IPv6 testsites to see how your ISP and your equipment do in some of the simpletests. This will at least give you an idea of how much work lays aheadof you.

Michael Anderson is currently CTO and Chief Scientistfor The PTR Group, Inc. With over 35 years in the embedded and real-timecomputing industry, he works with a number of RTOS offerings. However,his focus over the past decade is primarily embedded Linux and Androidon a number of CPU architectures. This paper is based on content hepresented as part of a class at the Embedded SystemsConference on “Transitioning from IPv4 to IPv6 (ESC-423).”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.