You can't ignore IPv6 any longer (in seven steps)
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.
More information
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.
Fact#2 See Fact#1
Fact#3 Mobile operatores recycle RFC 1918, with just more routers. As they done since 2001.
Fact#4 NAT is ok, and double NAT will reduce P2P, that's a good thing for a lot of industry players.
Fact#5 See Fact#1
Fact#6 On consumer market, only price is important.
Fact#7 Typical IPv6 dream. Time to wakeup after 15+ years.
=-X
Let's wait a few years and see 8-)
As for the web site, I would need to clone the existing VM that hosts a number of other things into ioshints-hints-specific one and enable IPv6 on it. At least I know there are no showstoppers and all the preparatory work has already been done (we have PI prefix, it's multihomed, IPv6 is running in our DMZ ...).
;)
I like Your logic and viewpoint in this post.
However, I disagree on the premice. We manage a couple of networks in higher education and my 'customers' are 100% between 18-28. The last count of iphones during the last 7 days in our network showed a total of 7,5%, so i guess our 'customers' are indeed part of the major audiance t-mobile, etc. are aiming for.
Speaking from our experiances: the internet is not down when Youtube or facebook are unreachable (though they make quite an amount of total traffic), but when Google is unreachable!
I hence do not believe a comercial telco provider would get anywhere without delivering a consistent ability to not only reach Google, Youtube, Facebook and a couple of other sites, but also every link a Google Search, bit.ly, Twitter, etc. shows up.
Even though I find the "my customers will go elsewhere"-view intruiging, my experiance with end users and our data do not support the sense of urgency this view implies.
Having to balance my visions of a connected future with pure cost/benefit considerations, regarding the implementation of IPv6 I see a lot of initiative penalty on the side of T-Mobile & Co. and no urgency to follow up with them so quickly for the rest of the world.
I am not completely agree with that. Do you remember how long did it take to make popular apps run through NAT44? 3-5 years ago I do remember that some IMs could not run through NAT. Now most of the applications are ok, even if we use NAT444 (you can refer to draft-donley-nat444-impacts-01).
My idea is that it will take a lot of time to make NAT64 mature. And in the moment it is MUCH worse comparing to NAT44 (and even to NAT444). There are some NAT64 trials, there is draft-tan-v6ops-nat64-experiences-00 describing some impressions of NAT64, but I am not sure about any large-scale deployments.
Anyways, I will be happy to know I am wrong 8-)
There's even a standard way to build NAT-traversing applications (STUN) and NAT64 was developed by the same working group and should work well with STUN. Any well-written application should thus work as easily over NAT64 as it does over NAT44 ... which brings us to another problem: many applications (anything browsers-based obviously excluded) simply haven't realized (yet) that there's a new address family you have to take in account.
I don't have any first-hand information about large-scale NAT64 trials. Juniper does have stateful NAT64 working on one of their edge routers (http://www.juniper.net/techpubs/en_US/junos10.4/information-products/topic-collections/nce/nat64-ipv6-ipv4-depletion/configuring-nat64-ipv6-ipv4-depletion.pdf)