I never watch movie previews because I hate them. They’re always enticing, but I know I’ll never see the promoted movies, because as soon as the main feature starts I’ve forgotten the others.

I kind of feel that way about IPv6, the new Internet Protocol (IP) for identification and location of computers on networks and Internet traffic routing. It's as if I've been watching the preview now for years but nothing ever seems to happen. I don’t have customers that are talking about it. I don’t read a lot about it in the trade press. I hear some vague rumors that Siemens has secret underground lab where they’re doing all sorts of hush-hush IPv6 work, but I can’t imagine what that might be.

ODVA and the Profinet Trade Association are pretty quiet about it as well. It’s reported that ODVA has a plan they’ll rolling out at some point to accommodate IPv6. They’ll probably talk about that at their annual meeting in March on a mountaintop in Arizona — more specifically, the Pointe Hilton Tapatio Cliffs Resort in Phoenix.  (Hint to all trade-event hosts: Have your event near a beach.)

In fact, v6 is installed on my laptop but whenever I’m online, I see a v4 address. Because v6 is on my laptop, it must be a pretty serious standard in the Internet world. What’s more, because automation is so closely tied to IT, v6 is going to become increasingly important to us at some point in time.

So, let’s revisit the v6 movie — review the concept, assess its benefits, and provide some fresh insights into the future of it for us in automation.

No article about v6 can start without dire warnings about the shortages of IPv4 addresses. I think it’s a federal regulation, perhaps buried in the 99,999 pages of the ACA. So let’s all hold hands and shout together, “The last block of v4 addresses has been allocated.”

In fact, that’s true. But when I was in college, experts said that by the year 2000 most of the world’s population would starve because we couldn’t possibly make enough food for everyone on the planet. So, let’s be a bit thoughtful (if not skeptical) about that last block of v4 addresses.

First, only something like 14% of the assigned addresses have been used. Plus an awful lot of v4 addresses are used in local domains — and there is no shortage of v4 addresses in local domains. If there was I would advise you to go long on v4 addresses and wait for them to go up when the shortage hits. But that’s not going to happen. Instead you might want to buy Bitcoins and get them soon before they’re worthless. But I digress.

So, the folks in charge of the Internet — how do I get that job? — built a completely new way of addressing IP devices. And while doing it, they “fixed” a bunch of things that people didn’t like about the old IP addresses.

Here’s what they did:


The length of an IP address in IPv6 is 128 bits. That’s four times the size of the IPv4 address making for a total of 3.4×1038 addresses — about 5x1028 addresses for every single person on the planet. I imagine that in 10 years or so I’ll not only have an address for everything I touch all day long but my toes, fingers and each of my teeth will have their own web page. When we get there 5x1028 may not be enough.

With the larger address space, the notation for IPv6 has to be dfferent. Therefore, an IPv6 address is eight groups of four hexadecimal digits separated by colons — 2001:0dc9:85a3:0043:0000:8a3e:0407:2374, for example. To simplify things, the v6 specification provides myriad methods for abbreviating this notation. For example, the section of this address that is all zeroes can be abbreviated as 0043::8a3e. You can get a really nice description of all the v6 notations at www.ripe.net/ipv6-address-types.


Everybody is talking endlessly about security so it’s natural that the v6 architects built security right into IPv6. They’ve included an Internet Protocol Security framework called IPSec that uses cryptographic security to provide things like network-level data integrity, data confidentiality, authentication, replay protection, origin authentication and more. It provides assistance with denial-of-service attacks, data corruption, data theft, credential theft and the like.

One of the nice things about all this is that ICMPv6 (Internet Control Message Protocol), the implementation of the Internet Control Message Protocol for IPv6, is allowed through corporate firewalls. In contrast, because of their malware risk, IPv4 ICMP packets are often blocked by corporate firewalls.

On the downside, devices all need a way to configure and maintain security policies. So, yes, the security is a huge v6 benefit but it comes at a cost — in that designers must implement and manage it.


IPv4 had a standard way for one device to send a packet that had to be read by all devices on the network. Disinterested hosts — hosts not wanting to read the broadcast message — still had to read any and all broadcast messages. Thankfully, support for that was removed in IPv6.


Instead of broadcast packets, IPv6 supports multicast operation. Multicast allows bandwidth-intensive data flows (like multimedia streams) to be sent to some number of destinations simultaneously. The IPv6 header contains a new field, named Flow Label, just for these sorts of streams so that it can clearly identify packets belonging to the same stream.


A lot of work was put into router efficiency:

• IPv6 drops the IP checksum. No longer does that checksum need to be recalculated on every hop. The checksum was of little value as it is usually part of the link-layer processing.

• IPv6 reduces the size of the routing tables to increase efficiency.

• IPv6 now allows an ISP to aggregate the prefixes of their customers IT networks into a single prefix and announce that one prefix to the world.

• The source device (rather than the router) now handles IPv6 fragmentation.


Tired of individually configuring an IP addresses for every device in your network? Well, it gets a lot easier in IPv6. In v6 a router broadcasts its 64-bit link-local prefix. A Link-local address is an address with a ten-bit prefix of 0xfe80 followed by 54 zero bits. A router never forwards any link-local address out of its domain.  A device (such as a motor drive, for example) that wants to automatically generate an IP address can simply extend its MAC address from 48 to 64 bits and prefixes it with the 64-bit link-local address to create a unique IP address. In IPv6 a router periodically sends out a router advertisement, which among other things advertises its link-local address.

Great huh? Well, not so fast. In an automation environment you’re still going to have to somehow let the PLC know what the IP address of the north rewinder drive is and what the south rewinder drive is. You’ve really just traded one problem for another — though I’m sure control system vendors will find a way to help you get around this problem.


The old NAT (Network Address Translation) tables are eliminated in IPv6. NAT tables map addresses inside a router. NATs map outside global internet addresses to local addresses inside a domain in a number of ways. A company could use, for example, a single global IP Address and map that to one or more than one local addresses.

By eliminating NAT tables, true end-to-end connectivity at the IP layer is restored between your local devices and the global internet. With v4 NAT tables were setup but because of the lack of v4 addresses but a lot of users were using the translations from outside to in as a form of security; a job it was never meant to do.

Now that NAT tables are gone, a lot of internal devices could be accessible from the outside world. The thought of that creates panic in a lot of IT departments.

Besides the idea of direct connectivity between the factory floor and the outside world, the other nasty is the fact that IPv4 and IPv6 are not interoperable. The single greatest failure of IPv6 is its lack of backwards compatibility with v4 but that horse has left the barn. All we can do now is manage the transition.

There are three ways to make these guys peacefully coexist:

1. A dual stack where your network infrastructure runs both IPv4 and IPv6 simultaneously.

2. A “tunnel” where you put packets for one inside the other.

3. A Network Translation device that converts packets of one into the other.

None of these are perfect solutions. In fact, all of them are going to give you headaches but that’s the environment we’re going to have to live in.

When we are going to be forced to address this and deal with this mess is unclear. But some things are clear:

• Various governments (including China and the U.S.) have decided that IPv6 is the IP layer of choice and because of that it’s going to written into a lot of specs. If you are a device vendor, you are going to run into an application where you have to satisfy that checkbox.

• For most device vendors this isn’t going to be much of a problem. You’ll have to get an updated TCP/IP stack that supports IPv6 and change the way the user enters the IP Address. You may go the additional step and implement the automatic address configuration.

• If you integrate devices and build systems this is going to be an additional headache. You’ll need to change how you design and implement systems. It’s very likely that you’ll have some devices that will only be IPv4 and some that will only be IPv6. It’s unclear how much longer you will be able to do everything in v4.

• If you have deployed EtherNet/IP or Profinet IO, you are going to need a stack update to support v6. There is no reason to believe that you can’t have an EtherNet/IP and Profinet IO application layer that supports both protocols.

Moving from v4 to v6 isn’t going to be trivial. You’re going to need a strategy, some tools and a plan to get from an IPv4 environment to a joint IPv4 / IPv6 one followed by a plan for all IPv6 operation.