By now, even the non-technical folks out there are aware of IPv4 address exhaustion (The IPocalype), thanks to the problem finally coming into the consciousness of the mainstream media. As organizations plan how to deal with this exhaustion, those who do the right thing and choose to deploy IPv6 (instead of trying to teach the IPv4 elephant how to dance using NAT) at some point are likely to choose and deploy one or more transition techniques. These are mechanisms that are supposed to smoothen the migration from IPv4 to IPv6… or will they? They certainly have the potential to do so (smoothen the transition), but network architects must make sure that these transition techniques don’t end up as the seeds of a new problem by becoming ends in themselves rather than a means to an end (full native IPv6).

Failure in transition techniques do and will result in a backlash from users that give the end-game (IPv6) a bad reputation (when you hear comments like “IPv6 is not yet operational”, “It doesn’t work” in various forums, look close by and you’ll find a bad IPv6 experience lurking not far away).

My focus on this post is to caution us that the general human tendency to focus on the short term, look for quick-fix solutions, combined with the reluctance to change could turn these well-meaning transition techniques into obstacles to full blown native IPv6 deployment. There is a precedent for this kind of thing happening – Network Address Translation (NAT) and it’s sibling Network Address and Port Translation (NAPT). In response to the impending issue of IPv4 shortage in the early 1990s, Egevang and Francis proposed NAT as a solution (see RFC 1631). The authors of NAT were well aware of the dangers I am highlighting here, hence their warning:

“NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution.” – K. Egevang and P. Francis – RFC 1631

Looking at where we stand today, network engineers ignored that warning and today NAT is so ingrained in the thought processes of network engineers that it (in its various forms) is being pitched as an alternative to implementing IPv6 despite various documentation that the NAT-path isn’t the way to sustainable Internet growth and innovation.

The problem in this scenario was (and still is) “IPv4 Depletion”, and the two solutions are IPv6 (the fundamental solution – addresses the root cause) and NAT (the symptomatic solution – addresses the symptoms only). The symptomatic solution was supposed to be used temporarily to buy us time while we implemented the fundamental one. But we now know that the success of NAT is the a key reason that IPv4 lived longer than it was supposed to, which in turn kept IPv6 stagnant for about 20 years after being standardized.

This pattern of events fits perfectly the “Shifting the Burden” archetype in Systems Thinking which is described thus in the “The 5th Discipline” by Peter Senge

“A short term solution is used to correct a problem, with seemingly positive immediate results. As this correction is used more and more, more fundamental long term corrective measures are used less and less. Over time, the capabilities of the fundamental solution may atrophy or become disabled, leading to even greater reliance on the symptomatic solution“

An early warning symptom that you are dealing with this pattern of events can be spotted in statements like:

“Look here, this solution has worked so far, what do you mean there is trouble down the road?”

Here is a diagram of the “Shifting the Burden” model adapted to the IPv4, IPv6 context.

Does this pattern of events look/sound familiar? … that’s because it is. As we have relied on NAPT more and more, fewer organisations have thought about implementing IPv6, some of the inertia simply based on the huge investments (financial, emotional and intellectual) that have been made in IPv4 and NAPT. When folks complain of the lack of feature parity of IPv4 with IPv6, they often fail to see that the said lack of feature parity is a direct consequence of the fact that they have not deployed and tested IPv6 to build operational competence with it. IPv4 did not mature overnight, it was through progressive use, improvements, feedback and re-use that it got it’s rich feature set. The end game of falling into this kind of thinking is that we will at some point end up with a system that is stuck at a mediocre level of performance (think sub-par IPv6 and all the problems that result when NAPT is over-used).

I make the case that all the current transition techniques we currently have are different variations of that sub-par system that we might end up in. Of course, some clueful folks will tell me there are no performance issues with some transition techniques, but I think there’s a reason we call them ‘transition’ techniques – they are a move towards an end-game, not the end-game itself.

The vicious cycle is perpetuated further by another occurrence: as the transition technique starts to work ‘better’ than broken implementations of native IPv6, organizations invest more resources in it to optimize it better, all of this investment happens at the expense of native IPv6 deployment which further makes the later less attractive while increasing the financial and emotional investments in the transition technique. This is a classic “Success to the successful” archetype in Systems Thinking which is illustrated below.

So what can we do? (apart from building a time machine, going back to 1994, nipping NAT in the bud and directing all efforts into IPv6!). Here are a few ideas:

1. All IPv6 deployment plans should have as their objective native IPv6, any transition techniques deployed should be milestones to that end game. So project managers and CIOs, look out for that and demand it from suppliers, vendors and contractors and from your network engineers.
2. Leverage normal equipment and software refresh cycles to ensure that network and application elements support native IPv6. This builds end-game capability in existing systems, thus making sure that transition mechanisms will progressively not be needed.
3. Educators and trainers must continue to inform the world of the sub-optimal solution that non-native IPv6 is.

More importantly, I will like to know your suggestions and strategies for making sure this doesn’t happen or even if you think it’s a problem t beware of.