IPv6 – Failure is an Option?
Here’s a presentation I stumbled upon yesterday.
Aside from the usual presentation (or nagging) on how IPv6 adoption hasn’t taken off as it was planned 10 years ago (the usual diagrams). This presentation discussed something a little different.
What if IPv6 really fails to take off?
Such a hypothesis isn’t necessarily unreasonable as the IPv4 address pool *may* run out by the end of next year – a plausible, though pretty aggressive estimate if there turns out to be a stockpiling frenzy of IPv4 address space. This leaves us with about 300+ days to upgrade the entire Internet to support IPv6 (not including the phasing-out of IPv4).
With so many organizations (not to mention individuals) who have been taught to believe that NAT is a necessary component of any network, it becomes a slightly daunting task to think about how these networks will grasp the notion of globally routable addressing on end-user systems.
Now, what happens then if we manage to deplete the IPv4 address pool before IPv6 can be adopted on a large enough scale?
He mentions the possibility of NAT at the carrier level, which is something that has been mentioned before. With “carrier-grade NAT”, each customer is then limited to a set of port numbers rather than a globally routable IPv4 address. Will this work? Possibly. After all, many technologies today were developed in an era of non-existent end to end connectivity (think of SSL-VPNs, HTTP tunneling, Web 2.0 applications, etc). So it is likely that the “Internet” will continue to work for most people.
*But*, what happens if we adopt such a solution in the long run?
I haven’t been around long enough to have experienced the transition from globally routable host addressing to NAT (yes, I grew up in the era of NAT).
But having grown to appreciate the idea of end-to-end connectivity, I shudder to think about the possible outcomes that will result from the adoption of NAT at the carrier level. If you thought that port-forwarding on your Linksys/Dlink/<insert SOHO router vendor name> router was troublesome enough, think about what would happen when it is your ISP that controls your ability to port-forward.
Yes. The cold, hard, truth is that the short-term marginal benefit of IPv6 does not exceed the cost of upgrading a network to run IPv6. It’s true it would be far easier for an ISP to implement carrier-grade NAT. In fact, that’s what a number of mobile operators are doing to provide IP services over their cellular infrastructure.
But think about it. The long term implications of permanent non-existent end-to-end connectivity are pretty dire. From a home user’s perspective, think about no longer being able to run your favorite file-sharing applications. From an institutional perspective, think about the possibility of being unable to deploy new services without the intervention of your service provider. The list just goes on and on. And it gets scary.
As always, what lies ahead is unknown to us. We can only hope then, that the Internet continues to thrive. Hopefully, there will be a day when we can take end-to-end connectivity over IPv6 for granted, and look back at the past, thinking about how silly it was for us to even think of NAT as a long term solution.
Related posts:
November 27th, 2008 at 9:08 am
Yes, very well said.
December 1st, 2008 at 2:27 pm
[...] IPv6 – Failure is an Option? – By bangky The cold, hard, truth is that the short-term marginal benefit of IPv6 does not exceed the cost of upgrading a network to run IPv6. It’s true it would be far easier for an ISP to implement carrier-grade NAT. In fact, that’s what a number … [...]
June 13th, 2009 at 3:53 pm
The whole concept of ipv6 is flawed. There should be a solution which simply extends v4 address space, similar to what was used to handle IDE drives over 137 GB size (48-bit LBA addressing).
June 13th, 2009 at 8:22 pm
The increase in available address space is probably one of the biggest “selling points” of IPv6. However, it should also be noted that there are other improvements in IPv6, such as the restructuring of the protocol headers to remove (now) redundant fields, provision for the possibility of header extensions, removal of fragmentation requirements for intermediate routers, etc.
Understandably, these improvements have not been as hyped up as the increase in address space; but this doesn’t mean that we ought to overlook them or brush them aside.