IPv6 has been a hotly contested technology for as long as I can remember. It has always been “a few years out”, or something “no one is asking for”, depending on who is asked. In reality, and like most things, the truth lies somewhere in the middle. IPv6 has been slow to appear for certain demographics of networking, but a long standing pillar in others. It just so happens that IPv6 is not being asked for because when deployed correctly most users just don’t notice that it is there – and that’s by design. To really understand how IPv6 deployments work, one needs to know a bit of history and have a dash of understanding of deployment models.

In the “old days”, running multiple protocols on the same routed medium was common.

In the “old days”, running multiple protocols on the same routed medium was common. It was not a surprise to see AppleTalk, IPX/SPX, and IP all on the same LAN. Sometime around 2002 the multiple protocols stopped being as common, and IP just took over. It was, after all, the protocol that ran the internet which was quickly becoming more like a utility and less like a novelty. Around this time, IPv6 started to bubble up here and there and the 6bone deployment was peaking. IPv6 became “important” to a whole new cohort, but alas, the stack was not really ready for prime time support and vendor support – and by extension hardware capabilities – were novelty at best and non-existent at worst.

Fast forward a decade. IPv6 support is reasonable and it has started to bubble up in backbones and even on dual stacked networks. Remember the multiple protocols running on the same network? This the time where that becomes relevant again, and probably the time that most engineers should have started paying attention to IPv6 and getting familiar. It started showing up in mobile networks, sensor networks, compute clusters, and more importantly it was getting mainstream OS support. This becomes important because there is also an initiative by vendors to support and in some cases even enable tunnels such as teredo by default. What did this mean? It means that even those engineers staunchly against IPv6 were almost certainly running it without even knowing. What was the right answer to the concern? There were two:

• Disable IPv6 by policy on every device in a given administrative domain
• Enable native IPv6 everywhere

Both were daunting tasks, so most just happily ignored v6 as a novelty problem for “future me“. Well, the future has steamrolled over many folks. There are now initiatives to implement IPv6-only. That’s not dual stack. That means no IPv4 for large parts of a given networks. Fret not, friends! This isn’t as extreme as it sounds. There are significant resources for learning and mastering IPv6, and the truth is that for most organizations, IPv4 behind some middle box doing masquerading isn’t going anywhere, but there will almost certainly be a need for some IPv6 transit. And while there is still a lot of work to be done, we are closer than we have ever been.

Fret not, friends! This isn’t as extreme as it sounds.

For those interested in learning a bit more about IPv6-only, there are some resources I have been involved with that are a reasonable start.

I was asked to talk about some of the more recent efforts in deploying IPv6-only on a recent IPv6 Buzz podcast, take a listen.