Whenever Ars runs an article about the increasing global scarcity of IPv4 addresses or an IPv6- related topic, we inevitably hear from some readers that they would like to see Ars available over IPv6. We thought we’d explain why we haven’t made that move yet.

Why should you care?

First though, we want to help your organization or business decide if it should be pursuing the goal of making your websites or applications available on IPv6. There are so many kinds of businesses and applications out there that it's hard to generalize, but the first question you should ask yourself is whether making this transition even makes sense right now.

If your company is an ISP , datacenter, network provider, or similar, this article is probably not for you. You've likely dealt with all your IPv6 issues long ago or are working through a transition right now. The level at which this article becomes more worthwhile is for SaaS providers (think 37signals' products, Amazon's AWS platform, Heroku, Google Docs, and so forth), and content-heavy organizations (like Ars Technica, The New York Times, Government portals, University Websites, your company's website, or an online store like Amazon.com).

First, identify your goals for making your site available over IPv6. Are you losing customers and money being IPv4-only? This could start happening very soon in Asian nations where customers will be handed IPv6 addresses when the current pools run dry (although the impact is debatable, as their ISP will likely tunnel them to IPv4 sites for a long time). Do you have philosophical ambitions and want to set a good example? Do you want geek cred with your community, or do you want to make sure you and your company are ready when that fateful day comes?

Most are not going to take action until they can show some kind of financial benefit. As we'll show, auditing and transitioning even a small operation will take a good chunk of time, research, and implementation. This all costs money in labor, but it could also cost money in hardware upgrades, support time, and software licenses. In addition, it could lead to downtime, which could result in lost profits. All of these will have to be accounted for and weighed against the potential financial benefit. Will your signups increase 5% by being available over IPv6? Can you leverage the transition as positive press for your product and bring in new customers on geek cred alone? Can you establish yourself amongst your peers as an expert on IPv6 transitions, which could lead to more contracts and projects in the future?

In most cases, the financial benefit will be near $0 at this point—most likely you will lose money—so you'll probably be searching for a promotional or preventative angle. In those cases, or in cases where you can identify a financial benefit, you'll need to start exploring and detailing the process. We've tried to lay out some concrete steps and guidelines below to get you started. Beyond that, we'll detail exactly how we've managed this process for Ars Technica and how we'll approach IPv6 in the future.

The eight circles of IPv6 transition agony

You'll need to start at the bottom and work your way up. You host your software somewhere, and that somewhere is generally a hosting provider. That hosting provider may manage its own network or live on top of a different network provider. Next up the stack will be your organization's networking equipment. These live between your hosting company's network and your servers. Then you have the operating systems themselves, then the Web servers, your home-grown applications, your third-party applications, glue code, and at the very end, the place where you store IP addresses for later analysis (like a database or logging system).

Your network provider

This is either where your servers are colocated or hosted. (If you've got your own datacenter, you would've probably figured this IPv6 transition out by now.) If you're colocating or leasing equipment in someone else's datacenter, they've probably already worked out the logistics of providing IPv6 connectivity to their customers (you). You can generally find out what level they support by poking around on their website. If not, a quick email to your support contact or opening a ticket should suffice. If you're hosting your applications on a non-dedicated or VPS hosting provider, it's less likely they've personally done the legwork on IPv6. They may be rehosting service from a bigger provider, or they could be a budget provider of shared-hosting products.

The good news is that even budget hosting providers like Dreamhost are getting on board with IPv6 these days. So it's likely that you're covered.

Your networking equipment

Depending on your setup, you may have your own dedicated networking equipment that lives between your servers and your network provider. All of this equipment will need to be checked out to make sure it can support IPv6. Anything purchased in the past few years probably has the capability built in—it'll be ready to go with a little configuration. It's also possible that you may need to update the firmware to get support. Also not a huge deal, but you may have to account for the downtime. Then there is cheap and old equipment. Cheap stuff like switches may not have support at all. Similarly, equipment bought long enough ago may have no upgrade path. In either case, this hardware will need to be replaced with modern equivalents.

Operating systems

Your next task will be to confirm that your server operating systems actually have IPv6 support and that support is enabled. OS X has been IPv6 ready since at least 10.4.8, with various applications and services gaining IPv6 support in 10.5; Apple ships Macs with IPv6 installed and enabled. Windows XP has had support since SP2, but it is not installed and enabled by default. Windows Vista and 7 have IPv6 support installed and active right out of the box. Windows 2000 has experimental IPv6 support, but there doesn't seem to be a consensus on whether you should be using it or not. Windows Server 2003 and 2008 both come with IPv6 support. Linux, BSD, and UNIX have long supported IPv6, so you're most likely okay there. Even Haiku (née BeOS) received IPv6 support recently.

In all likelihood, your OS has long had IPv6 support. The exceptions will probably be those servers that have been plodding away in a server closet since the '90s—the ones that no one thinks about anymore. Hopefully you're not in that situation. If you are, the best of luck to you!

Software networking applications

More and more these days, businesses opt to run software-based networking servers like proxies and load-balancers. Old versions may or may not fully support IPv6, but luckily these are extremely easy to update. Moving from very old versions to new editions that support IPv6 may cause issues if other backwards-incompatible changes have wormed their way into the code since then. You'll need to make sure all your configuration settings and tweaks still work the way you thought they did before rolling the update out to production.

Web servers

Next up the stack are your Web servers and application code. Most modern Web servers have had IPv6 support for quite a while. Apache since 2.0.14 (but with IPv6 virtual hosts broken until 2.0.28), IIS since 6.0 (but only without certain functionality like bandwidth throttling enabled, and with IP address restrictions until 7.0), lighttpd has always had it, and nginx has had it since 0.7.36. You can find a huge list of IPv6 compatible applications on Wikipedia.

Application Code

Once you've verified that your Web server can handle it, you'll need to step up into your application code. This is probably the meat and potatoes of your business. This step is going to be highly unique to what your company does, and it will be hard for us to recommend any specific course of action, but we can give you some ideas of places to look for problems.