A well written paper by the folks at DREN, the Defence Research and Engineering Network under the Defence Department’s High Performance Computing Modernization Program, can be found here: DREN Success Story. 

DREN, an early Hexago customer, is credited with having the first operating IPv6 network in the US government and this paper describes their real world experience in getting it operating and what they have identified as their six key factors of success.

DREN is leaps and bounds ahead of the US government OMB mandate which, among other things, dictated that by June 30, 2008:

“All agency infrastructures (network backbones) must be using IPv6 and agency networks must interface with this infrastructure. Agencies will include progress reports on meeting this target date as part of their EA transition strategy.”

Now, many US government departments and agencies interpreted this to mean flowing IPv6 packets between two core routers conveniently forgetting about the “interface with this infrastructure” part but not DREN.  They went above and beyond and ahead of schedule in their implementation and, in their words, “It is now time for federal stakeholders to travel the trail blazed by the DREN” or in my words “it is high time to get this party started”.

Bruce Sinclair

The IPv6 killer application has finally been found, making sure Internet continues to run. The general consensus at Google’s IPv6 implementors conference was that the reason to deploy IPv6 is to ensure business continuity for your Internet services. The survival of the Internet is the killer app of IPv6 as one of the participants put it. The approach to achieve this is different from case to case. For ISPs the shortage of IPv4 addresses is the main decider in how the deployment of IPv6 will be done. Doing dual stack is not an option as it won’t save addresses, instead many operators are looking at different ways to rid themselves of IPv4 at same time as maintaining their IPv4 service to the end user. For content providers IPv6 deployment is way of keeping up with IPv6 rollout to ensure that users don’t run into problems by having to go through multiple NATs.

Now the question is when the Internet needs saving. There seems to be a common understanding that IPv6 will not be deployed in time to take care of the IPv4 shortage by its own existence. Instead it has to be used as a tool to extend the life of IPv4 services. This will become a reality within a next year or two when the ISPs will start to feel the pain of adding IPv4 customers in a traditional manner. At that point IPv6 will become an important part of the Internet even though a lot of users will continue to run IPv4 on their old Windows XP machines or PS3s.

Having IPv6 become a tool to keep the Internet running isn’t a bad thing, it is what IPv6 was created to do. The only thing that has changed is the way it is being done.

I want to address a few interesting comments made on my last blog.  I agree with Dan’s sentiment – there needs to be more than simple supply and demand capitalism to solve the migration problem as we define it because ideally, supply should precede demand but the question is: who’s going to foot the bill?

Within service provider organizations there are at least two groups who are personally rewarded for a winning IPv6 strategy – those who are charged with implementing it and those who are charged with paying for it.  The implementers we meet with are in sync with Dan’s view.  They know it is going to take 12 – 18 months to get it right after all, it is a huge network undertaking that involves all equipment/OSs/services/apps from the core all the way into the home/handset.  The payers however are not willing to spend one $/yen/won that will not return 1.2 $s/yens/wons until the last possible moment but the question is: when is the last possible moment?  Theoretically it equals: depletion date (is that ICANN or RIR depletion?) minus 12 to 18 months.  Unfortunately, as many have discussed before, it is an under constrained problem.  No one knows the depletion date for sure so until someone discovers it or it becomes blatantly obvious, no significant $s/yens/wons are going to flow into IPv6.

So, what does all this mean?  Well I think it means one of two things: either there will be some sort of external force to accelerate operators on their path, as demonstrated by various governments around the world, or the transition to IPv6 will be different than we originally envisioned.

If no form of external intervention is applied the transition to IPv6 will not be orderly, it will not be pretty and it will all be done at the last minute.  An important question is: how will it be done?  As Geoff points out there are numerous distasteful possible outcomes.  You know what they say about “The best laid schemes o’ mice an’ men”…  The IETF had the best laid scheme, years ago.  It was simple; from now until the depletion date, convert your networks to dual stack using tunneling as a tool to get you there.  Once you have two parallel operating networks, turn the v4 one off and you’re done.  Oh, and if you have to, perhaps you will need to use translation somewhere along the way but we’re not going to standardize that.  But because of the proverbial outstretched hat, no (few) network operators followed this advice.  The result is the IETF is now revising things because both technical solutions in their scheme require IPv4 addresses and if these address run out or are in very short supply (due to the service providers waiting until the last minute) then there will be a need for other technical solutions.  So now they are studying transition solutions that involve translation in one form or another.  Two hot topics right now being discussed in the IPv6 working groups are NAT-PT (welcome back) and Dual-stack Lite – whether or not they will be standardized in time remains to be seen.  In addition to transition/migration the focus also includes interoperability because the reality is that the Internet will soon become a heterogeneous hotchpotch of v4, v6 and yes, dual stack networks.

I believe the transition will be ugly but ultimately beautifully efficient.  Through the heterogeneous worldwide solution set someone is going to get it right – satisfying the implementers (technically sound and scalable), the payers (with a working business model) and governments (in the best national interest) and when this happens the momentum of this Darwinian sharpened solution will lead the way for everyone else to fall in line.

Bruce Sinclair

Head over to Living with IPv6 and read about why IPv6 shouldn’t be seen as a security issue. I completly agree with his point that IPv6 getting a lot of attention related to security when there are things that are much more of concern. Just because people don’t know about it doesn’t mean that they should be affraid of it. In many cases it almost seem to be fear of change and nothing else. Some people seem to think that if things are not done as they are today then the Internet will crumble and fall. This couldn’t be further from the truth. Change is what has kept the Internet allive over the years and IPv6 is just one step on the way.

It’s interesting to note that this week has heard official statements from Vietnam and Malaysia on their plans for migrating to IPv6.  As I said a week ago there are surprises to be found from the ASEAN countries in the race to IPv6.  This week also saw news from Kenya and the week before from Uganda.  What’s up with that?  Why are we seeing these smaller countries, not exactly known for their networking prowess, dedicating real budgets and political capital to the development of the next generation Internet?

Some say Asia has fewer IPv4 addresses available so they see this as a more eminent threat – but that’s just a myth.  Address assignments to the RIRs are equally made.  If APNIC legitimately requires more allocations than RIPE or ARIN then they will get them.  Some say there are smaller stockpiles with the operators in Asia, so this makes them more nervous.  Well they may be nervous but from my experience, this is also a myth.  Operators around the world, whether from Canada, Greece, Brazil or Australia all have approximately the same size stockpiles (as a ratio of customer base) and they are all finding it more difficult to get new addresses.  And ironically the entity that has the most address stockpiled is the U.S. government but they are one of the most aggressive proponents of moving to IPv6 – not out of fear but out of the desire for innovation.

No, it’s not a case of the haves and have nots, it’s a case of history and growth.  When I talk to policy makers in these countries similar themes emerge.  Whether it is with government officials in Vietnam, Malaysia, Thailand or India, all of whom are coming up with own policies to galvanize v6 in their countries, the discussions center around the national importance the Internet has for the economics of their respective countries.  They cite how they were caught by surprise and therefore not initially prepared to develop their infrastructure for the first wave of the Internet.  They don’t what to be left behind on what they see as a second wave.  In their minds IPv6 is a way to level the playing field.  The transportation of bits is as important to their economies as the transportation of atoms.  This preoccupation if further exasperated by the growth they are experiencing in broadband connections and mobile phone market share.  When you are a little behind in the penetration stats you have further to go to reach status quo with the perceived first tier Internet countries.  So in my view the hotter than average IPv6 activity found in ASEAN countries is a result of plain good governance.

Bruce Sinclair

There has been some interesting work done lately in regards to getting a better understanding about the status of the IPv6 deployments. The most famous on is probably Google’s measurement of how many nodes actually could access IPv6 content. This showed that 6to4 is the dominating technology. But looking at the data presented by Kurtis Lindqvist there seems to be a hidden player in the IPv6 world, Teredo. It shows one example where a Swedish operator has significantly more traffic going through their Teredo relay compared to their 6to4 gateway. On top of that some operators have said that they see a thousand times more Teredo traffic than 6to4 traffic. There is actually a logical explanation to this difference in data and that is Vista’s default Teredo behaviour. This will not send any Teredo traffic to an IPv6 enabled web site even if it could. IPv6 will only be used over Teredo if an application forces the use of IPv6. Unfortunately there is no easy way for users to change Teredo’s behaviour to use it for “ordinary” IPv6 communication otherwise we might see a lot more IPv6 traffic showing up at IPv6 enabled web servers. For now Teredo will have to remain the quiet IPv6 champion that provides peer to peer IPv6 connectivity without the users knowing they are using IPv6 or it showing up in the readiness status measurements.

In their effort to prepare for, and move to IPv6 Google has started offering IPv6 connectivity to www.google.com, but there is a catch. In order to get an IPv6 address when querying Google your ISP has to be onboard and promise to help get IPv6 working in case people have problems accessing the Google website. If they agree to work with Google on making sure IPv6 works as well as IPv4 then the queries from that network will return both IPv4 and IPv6 addresses. This is a great step in right direction. I just wish Google would have gone all the way and turned on IPv6 to everybody because I believe all ISPs quickly would fix their network to make sure that their customers can access Google even if they have IPv6 turned on. Perhaps Google would have suffered a tiny loss of users for a short time period but they would have provided a giant leap forward for IPv6. I still applaud them for offering IPv6 in this limited way since it breaks the chicken and egg dilemma where content providers and network operator blame each other for not providing IPv6.

If your ISP isn’t helping you then you can have a look at this article discribing how to tweak your system to do Google in IPv6 anyway.