I wrote about upgrading
to IPv6 in the past, but I have more to say.
The wrong way: I've heard a number of people say they are
going to try to convert all of their desktops to IPv6. I think
they are picking the wrong project. While this is a tempting
project, I think it is a mistake (well-intentioned, but not a good
starter project). Don't try to convert all your desktops and servers
to IPv6 as your first experiment. There's rarely any immediate
value to it (annoys management), it is potentially biting off more
than you can chew (annoys you), and mistakes affect people that you
have to see in the cafeteria every day (annoys coworkers).
Instead copy the success stories I've detailed below. Some use a
"outside -> in" plan, others pick a "strategic value".
Story 1: Work from the outside -> in
The goal here is to get the path from your ISP to your load balancer
to use IPv6; let the load balancer translate to IPv4 for you. The
web servers themselves don't need to be upgraded; leave that for
It is a small, bite-sized project that is achievable. It has a
real tangible value that you can explain to management without being
too technical: "the coming wave of IPv6-only users will have faster
access to our web site. Without this, those users will have slower
access to our site due to the IPv4/v6 translaters that ISPs are
setting up as a bandaid.". That is an explanation that a non-technical
executive will understand.
It also requires only modest changes: a few routers, some DNS
records, and so on. It is also a safe place to make changes because
your external web presence has a good dev -> qa -> production
infrastructure that you can leverage to test things properly (it
Technically this is what is happening:
At many companies web services are behind a load balancer or reverse proxy.
ISP -> load balancer -> web farm
If your load balancer can accept IPv6 connections but send out IPv4
connections to the web farm, you can offer IPv6 service to external
users just by enabling IPv6 the first few hops into your network;
the path to your load balancer. As each web server becomes IPv6-ready,
the load balancer no longer needs to translate for that host.
Eventually you're entire web farm is native IPv6. Doing this gives
you a throttle to control the pace of change. You can make small
changes; one at a time; testing along the way.
The value of doing it this way is that it gives customers IPv6
service early, and requires minimal changes on your site. We are
about 280 days away from running out of IPv4 addresses.
Around that time ISPs will start to offer home ISP service where
IPv6 is "normal" and attempts to use IPv4 will result in packets
at the carrier level.
Customers in this situation will get worse performance for sites
that aren't offering their services over IPv6. Speed is very
important on the web. More specifically,
latency is important.
[Note: Depending on where the SSL cert lives, that load balancer might need to do IPv6 all the way to the frontends. Consult your load balancer support folks.]
Sites that are offering their services over IPv6 will be faster for
new customers. Most CEOs can understand simple, non-technical,
value statements like, "new people coming onto the internet will
have better access to our site" or "the web site will be faster for
the new wave of IPv6-only users."
Of course, once you've completed that and shown that the world
didn't end, developers will be more willing to test their code under
IPv6. You might need to enable IPv6 to the path to the QA lab or
other place. That's another bite-sized project. Another path will
be requested. Then another. Then the desktop LAN that the developer
use. Then it makes sense to do it everywhere. Small incremental
During Google's IPv6 efforts we learned that this strategy works
really well. Most importantly we've learned that it turned out to
easy and not expensive.
Is IPv6 code in routers stable? Well, we're now sending YouTube
traffic over IPv6. If you know of a better load test for the IPv6
code on a router, please let me know! (Footnote:
IPv6 is easy, not expensive Engineers say upgrading to next-gen
Internet is inexpensive, requires small team")
Story 2: Strategic Upgrades
In this story we are more "strategic".
Some people run into their boss's office and say, "OMG we have to
convert everything to IPv6". They want to convert the routers, the
DNS system, the DHCP system, the applications, the clients, the
desktops, the servers.
These people sound like crazy people. They sound like Chicken
Little claiming that the sky is falling.
These people are thrown out of their boss's office.
Other people (we'll call these people "the successful ones") go to
their boss and say, "There's one specific thing I want to do with
IPv6. Here's why it will help the company."
These people sound focused and determined. They usually get funding.
Little does the boss realize that this "one specific thing" requires
touching many dependencies. That includes the routers, the DNS
system, the DHCP system, and so on. Yes, the same list of things
that the "crazy" person was spouting off about.
The difference is that these people got permission to do it.
According to a presentation I saw them give in 2008, Comcast found their 'one thing" to be: Settop box management.
Every settop box needs an IP address so they can manage it. That's
more IP addresses than they could reasonably get from ARIN. So, they
used IPv6. If you get internet service from Comcast, the settop box
on your TV set is IPv6 even though the cable modem sitting next to it
providing you internet service is IPv4. They had to get IPv6 working
for anything that touches the management of their network:
provisioning, testing, monitoring, billing. Wait, billing? Well, if
you are touching the billing system, you are basically touching a lot
of things. Ooh, shiny dependencies.
(There used to be a paper about this at http://www.6journal.org/archive/00000265/01/alain-durand.pdf but the link isn't working. I found this interview with the author but not the original paper.)
Nokia found their "one thing" to be: power consumption. Power
consumption, you say? Their phones waste battery power by sending
out pings to "keep the NAT session alive". By switching to IPv6
they didn't need to send out pings. No NAT, no need to keep the
NAT session alive. Their phones can turn off their antenna until
they have data to send. That saves power. In an industry where battery life is
everything, any CxO or VP can see the value. A video from Google's IPv6 summit
details Nokia's success in upgrading to IPv6.
Speaking of phones, T-Mobile's next generation handset will be IPv6-only. Verizon's LTE handsets are required to do IPv6. If you have customers that access your services from their phone, you have a business case to start upgrading to IPv6 now.
In the long term we should be concerned with converting all our networks and equipment to IPv6. However
the pattern we see is that successful projects have picked "one
specific thing to convert", and let all the dependencies come along for
In summary, IPv6 is real and real important. We are about a year away from running out of IPv4 addresses at which point ISPs will start offering IPv6 service with translation for access to IPv4-only web sites. Successful IPv6 deployment projects seem to be revealing two successful patterns and one unsuccessful pattern. The unsuccessful pattern is to scream that the sky is falling and ask for permission to upgrade "everything". The sucessful patterns tend to be one of:
- Find one high-value (to your CEO) reason to use IPv6: There are no simple solutions but there are simple explanations. Convert just that one thing and keep repeating the value statement that got the project approved. There will be plenty of dependencies and you will end up touching many components of your network. This will lead the way to other projects.
- Work 'from the outside -> in": A load balancer that does IPv6<->IPv4 translation will let you offer IPv6 to external customers now, gives you a "fast win" that will bolster future projects, and gives you a throttle to control the speed at which services get native support.
I'd love to hear from readers about their experiences with convincing management to approve IPv6 projects. Please post to the comments section!
P.S. Material from the last Google IPv6 conference is here: