We know the world will eventually run out of IPv4 addresses, but while at least some service providers got the message and already deployed IPv6, it seems like most enterprise IT departments still practice the denial strategy. It’s worrisome to read articles from Jeff Doyle describing the ignorance of his enterprise clients, so I’ll try (yet again) to explain why you should start IPv6 planning NOW.
Fact#1 – most analysts agree the major growth in Internet services will be in mobile space. If you’re an iPhone/Android/iPad user, you’re already there.
Fact#2 – if you’re doing your business on the web, you’re probably interested in those mobile users. After all, they had enough money to buy an expensive gadget, so they just might have some more money to spend on your products/services.
Fact#3 – most mobile operators already use NAT. Many of them historically regarded TCP/IP purely as a convenient transport mechanism within their walled garden, used RFC 1918 address space and failed to grab the public IPv4 address space they would need to support their growing customer base.
Fact#4 – everyone hates NAT (maybe not everyone, for some people it’s a valuable component of the NAT-GRE-PBR duct tape). It makes service providers’ life miserable, more so if they have to keep track of individual NAT translations for legal reasons.
Some mobile service providers regard IPv6 as the way out of the NAT mess (example: T-Mobile, see their presentation from Google IPv6 Implementers Conference). T-mobile decided dual-stack is not worth the effort (not to mention that you need two PDP contexts if you’re using old 3G software or the rumored problems some mobile chipsets might have with two protocols), they plan to go with pure IPv6 internally and NAT64 on the network edge. After all, they already run large-scale NAT (LSN) in NAT44 mode and changing that to NAT64 can’t be much worse.
Oh, and did I mention LTE (once it turns from hype into reality) runs on IPv6?
Fact#5 – large percentage of mobile user traffic comes from Google (YouTube) and Facebook.
For mobile operators, this fact is a huge opportunity. Google and Facebook have already deployed IPv6, meaning that all this traffic could be handled as NAT-free native IPv6. T-mobile projects ~50% of its users’ traffic can be served by native IPv6 by EOY2011 (same source).
Fact#6 – smart service providers invest into the infrastructure that ensures perceived high-quality for majority of their users.
If you have teen kids, you know their definition of “Internet is down” – they can’t reach YouTube or Facebook. If they can’t reach your web site, Internet is not down as long as they can complain about that on Facebook. It doesn’t matter if the problem is actually a neglected NAT64 gateway at the edge of the service provider network – if they can reach Facebook (which they will over native IPv6), Internet works and your web site is broken.
It’s hard to predict what might happen, but I would not be surprised to see diminishing investments in SP NAT equipment and operations once majority of the traffic shifts to native IPv6.
Fact#7 – There are plenty of alternatives on the Internet
Two years ago, I was comfortably sitting in the “why should I care about IPv6” camp until a smart guy running the web site of our national TV opened my eyes during one of the Slovenian IPv6 summits. He said “my users don’t care whether my site supports their browser or not. If it doesn’t they’ll go to my competitor: I have to make sure I support all major browsers.”
You’ll see the same effect in the IPv4/IPv6 world. If a mobile user won’t be able to reach your web site, he’ll just return to Google and select to the next search result. Can you afford that after all the money you’ve invested in redundant highly-available infrastructure, web design and application development, and SEO optimization or placed ads?
The same T-Mobile presentation tries to put a polite spin on this fact
Customers will not tolerate broken content, they will move on to content that works. Best for the content owner to control the IPv6 experience by providing native IPv6 services, and not depend on CGN / LSN.
I hope you got the real message.
Last but definitely not least, in the immortal words of Martin Levy: “You can either do a planned, careful migration, or you can do it in a panic. And you should know full well that panicking is more expensive.”
The choice is yours.
The first steps you have to make when considering IPv6 deployment in your enterprise network are described in my Enterprise IPv6 – the first steps webinar.