What is the IPv6 Killer App?
IPv6 has been perpetually just over the horizon because the naysayers claim it's too hard to implement, IPv4 is ‘good enough’, and there are no 'killer apps'. That last one is the one I have the biggest problem with. There's this idea that there's nothing that IPv6 does that you can't do with IPv4 is just so silly to me.
There's a ton of reasons for you to deploy IPv6. It's faster, it has none of the baggage of years of inefficient IPv4 deployments, subnetting is WAY easier, it's backward compatible (with the right transition mechanism), cheap to buy all of the v6 space you'll ever need, and security is at least as good and arguably better. But none of these are 'killer apps'.
So what are these 'killer apps' that can only be done with IPv6 or are made drastically easier with a v6 implementation? Here's a couple that I can think of but these are by no means an exhaustive list.
End-to-end Visibility
So at first glance, this might not sound like a 'killer app' just a nicety, but it's such a boon to your ability to investigate security events that I've listed it first. Just think back and ask yourself if you've ever received a report from outside your organization that they've identified malicious traffic originating from your network. Of course, you've got to go correlate their IP with firewall logs because you're masking everything behind a PAT address (or pool) and hope that those logs still exist. IPv6 at the very least guarantees that you can immediately narrow down which subnet that traffic is originating (if the client is using privacy extensions) from and at best the exact client. If you work at a large enough organization, I can guarantee that your security team is probably receiving these types of reports regularly from other organizations, law enforcement, ISPs, etc.
Go ask your security team if they would like to have end-to-end visibility of network traffic. I’ll wait with bated breath on their answer.
Acquisitions and Integrations
Has your company bought another company, been bought by another company, or integrated with another company via a site-to-site tunnel? OF COURSE IT HAS!
If you answered no to all of those, give it time because it's probably inevitable.
Nearly every company I've come across in my career has one or multiple of these scenarios going on actively at all times. What's the answer to integrating these two organizations most of the time? NAT. Why does this suck? NAT.
NAT is easy to implement but hard to track down issues and limits a parent organization's ability to manage on the other side of the divide. The most baffling aspect of all of this is that these companies are going to turn around and spend weeks or months of engineering time to re-IP the acquired organizations to remove the 'temporary' NAT solution. If you're going to re-IP anyways, why not implement IPv6 instead? End-to-end connectivity with globally unique addresses sidesteps all of these issues.
One company I've worked with in the past would acquire a new company every 3-4 months and their network was a mishmash of little self-contained network bubbles that would be stitched together with NAT and an engineering team that was constantly fighting small fires because of it, which made it harder to slow down and implement proper network design. This company is very large (you've probably heard of them if you're from the US) and had the resources to implement IPv6 but refused to listen to reason because 1-2 people felt it was “too difficult”. Beyond that, this company was at the scale that even IPv4 10.0.0.0/16 space was becoming harder to efficiently subnet and provide the scale that they needed. Sometimes, a lot of our pain is self-inflicted.
These are obviously not the only reasons to deploy IPv6 to your network. I made mention of a few other reasons at the top of the page and there’s no better time than now to start putting together your IPv6 transition plans. Check out my other posts on IPv6 here.
Do you agree with my assessment? Leave your comments below and let me know if you think I’m off base here.
