More on the economics of IPv6

A few entries ago, I said that the choice between pushing the life of IPv4 and deploying IPv6 comes down to economics:

Ultimately, I think this is an economic question: In the long-term is it cheaper to (more aggressively) deploy NAT and NAT-enable our apps, or to deploy IPv6 and v6-enable our apps?

I listed several factors that influence the cost of both IPv4 and IPv6. But I forgot one big one: If you deploy IPv6, you have to keep your IPv4 network around. For a long time. I'd like to explore that cost in this entry.

I don't think there are any capital costs involved in maintaining IPv4 support. Any networking equipment we have already supports IPv4, and will continue to do so for the foreseeable future. All network software supports IPv4, and will do so for the foreseeable future. No, I think the costs are labor costs. For example, everytime we deploy a service, we have to configure it twice, on both IPv4 and IPv6. This is called dual-stacking our services. We will have to dual-stack our DNS, Kerberos, directory, mail, and web servers, as well as the firewalls that sit in front of them.

This does have costs. Not in terms of configuration, that's usually trivial. The first cost is mindset -- we have to convince our network and system administrators to think about the word "network" differently. They will have to learn that "network" means "IPv4 and IPv6." Programmers will have to learn this same lesson. It's a habit that takes a while to develop. The second cost is testing, and this will be a big cost. Many systems have no problems with IPv6 and dual-stacking. But a minority of them do. Isolating and fixing those problems is time-consuming. This process is confounded by programming languages that aren't amenable to IP-agnostic development.

For example, there are anecdotal reports that when some sites turn on IPv6, 10% of their web traffic disappears. This doesn't happen for everyone (I've not experienced it in ET), but a few people report it. What's happening to those missing packets? Are they lost in a blackhole route somewhere? Does some client have broken DNS software? It's a laborious process to find out. And it is not always the case that the problem is solved simply by upgrading to the latest software at both ends.

So there's a lot more to deploying IPv6 than turning it on on your routers and firewalls. That's only a very small tip of a very large iceberg. To paraphrase a common line: It's the apps, stupid.

This is a serious cost, but it's one I think IT needs to bear. The good news is that everyone who is deploying IPv6 has to bear it, which helps by distributing the cost over many organizations. And people who have deployed IPv6 are willing to help one another out. Two good places for IPv6 help are the ARIN IPv6 wiki and the ITS Wiki IPv6 space. The latter is not currently accessible to non-Penn State users, but we hope to rectify this in the near future.