IPv6 deployment has long been hampered by a ‘chicken or the egg’ problem – next-generation networks deployment is very slow without compelling new applications, and applications aren’t built without networks. Is porting applications so difficult? Jim Bound, CTO of the IPv6 Forum states that:

“Porting applications to support IPv6 is not a complex programming task, industry finding the business case to redirect engineering resources for the investment is the challenge, and we continue to face this chicken-or-the-egg paradigm for wider deployment of IPv6 applications” 

For companies that have found the business case, such as vendors to DoD, it’s still difficult to find developers with experience, exact requirements, and hard to even define what exactly is an “IPv6-ready” application. The US Federal government and DoD have been moving ahead with IPv6 IT infrastructure procurement, but they haven’t defined what they want for IPv6 applications to the vendor community. At Command Information, as part of our Command Ready service and R&D, we have been creating IPv6 applications for our industry clients. We have also been holding a training class on IPv6 for application developers so our developers can help spread IPv6 programming knowledge around the US tech base and stimulate IPv6 uptake. I’m going to try and distill a few lessons learned from that experience here and over a few posts.

First – Here is how we define an IPv6 application:

IPv6-Capable software should able to accurately transmit, receive, process, and function correctly using the Internet Protocol Version 6 (IPv6). Specifically:

1) All user functions (data plane) of the application which utilize an IP network service comply with the IETF guidelines for data exchange over Internet Protocol Version 6 (IPv6) Standard (RFC 2460)

2) Unless sold as an “IPv6-Only” product, this IPv6-capable software is “fully dual stacked” to maintain interoperability with IPv4. Specifically, the software is able to operate on/coexist on a network supporting IPv4 only, IPv6 only, or a network supporting both IPv4 and IPv6. 

3) Each software item delivered is supported by the vendor/developer’s IPv6 technical support. 

This statement covers functions of the application, any supporting applications, control plane network services the application calls such as RPC or DNS, and any remote management or software update functions used by the vendor/developer’s software. If some functions work in IPv6 while other require IPv4, then the application is considered “partially dual stacked” with IPv4 dependencies.  

Second – what is missing in many software packages? I asked Yanick Pouffary, a fellow IPv6 Forum Fellow, and in her opinion,

“All applications are not made equal. For most applications porting to IPv6 is straight forward, replacing IPv4 calls [such as “sockaddr_in”] by expanded IPv6 calls [such as gethostbyaddr()] , and for others it is a little more involving especially if the application deals with network protocols. Please note that many vendors provide tools to locate where the necessary code changes need to occur. It is also strongly recommended that while an application is being updated to support IPv6 to make this application transport agnostic to future-proof that application.”

I agree with Yanick that “All applications are not made equal.” It has been very straightforward for us to IPv6-enable many simple software packages we’ve worked on where the network simply provides transport. However, we’ve created network management and security software that was very complex to transition because of its very specific interaction with IP. Another issue is implementation quality - In my experience a lot of software claiming to be “IPv6 complaint” still has shortcomings such as:

·         Incomplete implementations that leave IPv4 dependencies

·         Lack of good user interfaces/GUIs for IPv6

·         Partial functionality in IPv6 - often application implement only one interface or function in IPv6, others still in IPv4-only

·         Poor documentation and support for IPv6 features

·         Fail to function in an “IPv6-dominant” environment because of IPv4 dependencies 

In closing this New Year’s Eve post I’d like to say that in the last year we have been able to find good IPv6 –ready application in virtually every category of common enterprise applications such as VOIP, VTC, workgroup collaboration, supply chain management, asset tracking, building automation & sensors, online storage, IPTV & VOD, surveillance cameras, etc…  

In the next post, next year, we’ll explore a bit more detail on how to create, test, and prove IPv6 applications, what are the subtle and difficult parts, and how we engineer IPv6-Optimized applications.

A few-hours-early Happy New Year! … It’s been a great year for IPv6:
Some root servers got IPv6 addresses (+AAAA records)
Google held a little tech conference, great videos!
IPv6 Growth Increases 300 Percent in Two Years
Sensor vendors (Such as ArchRock) coming into their own
Industry finally starting to push IPv6 deployment / adoption
Google starts some public IPv6 testing, more info here
The OMB522 Mandate, of course
The 2008 Olympics was an IPv6 milestone
NAT-PT gets demoted to “historic”
… but NAT makes a comeback @ IETF73 (and elsewhere)
IPv6 turned ten!
Jeff Doyle has some similar thoughts, great excerpt:

“Another, more subtle, milestone is the change in the way IPv6 is presented in public networking forums. We have left behind what might be called the “marketing phase” of IPv6; most everyone in the IP networking world now understands that IPv6 is inevitable. Network operators (starting in the latter half of last year) are now focused on how to best implement IPv6; large portions of the agendas at NANOG, RIPE, and APRICOT have been devoted to strategy sharing. “

And, looking forward, there are lots of interesting goings-on:
Google’s IPv6 Implementers’ Conference
IETF74 promises lots of IPv6-relevant action

… and, for a gratuitous plug, if you decide you need to start getting up to speed - or advancing your knowledge of IPv6 - I know who you should ask: Command Information’s IPv6 Training Calendar (Also reachable via a shorter URL)

(Oh, and I still HIGHLY recommend everyone read Geoff Huston’s latest article!)

So, what are your thoughts for 2008, IPv6 and life in general?

Just a quick tip o’ the hat to Geoff Huston, author of:

… and lots of other fantastic works of art, like the IPv6 Rocket Train, therein!
I highly recommend reading it, and welcome any thoughts or comments!

/TJ ((crossposted))

In the last discussion, we talked about service providers using a single IPv4 address shared between subscribers.  Carriers may well do this not as an alternative to IPv6 deployment – which pretty much everyone (finally) agrees is the “real” solution – but as a stopgap measure to allow them more time to complete their IPv6 deployments.  Many providers have done a poor job of preparing their businesses for the “post ready availability of IPv4 routable addresses world”.  Additionally, and as an aside, not all in-home platforms are IPv6 ready and on-by-default (Windows XP, for example, have IPv6 but it is not on by default.  So, there are a number of reasons why providers need to be able to provision IPv4 to existing and new subscribers for another few years.

In the “shared IPv4 address” schemes, rather than have “one IPv4 address per subscriber” there would be a new practice – “one IPv4 address per multiple subscribers”.  There are several implementation schemes under discussion for how the provider would actually do this.  One schemes call for “double NAT”, where the subscriber (with a NAT router at the edge) uses RFC1918 internally, does NAT at the edge, and then the provider does NAT *again*.  Another scheme simply moves the NAT function from the subscriber edge router into the provider cloud, leaving it still “single NAT”, but no longer in the subscriber device.  More about these another time.

The issue left on the table last time was “what do we do about inbound services”?  Suppose a subscriber wants to run a webserver, for example.   Suppose another subscriber sharing that routable IPv4 address also wants to run a webserver?  Clearly, both cannot receive traffic inbound destined for “IPv4_Addr:80” – the standard HTTP TCP service port.  What do we do in this situation?

I think the answer is the simple one – “don’t do that”.

The most likely implementation will be for the “standard” subscriber service offered to home users (“consumer class”) to indeed be a “shared IPv4 address” scheme.   These addresses are probably most often, for almost all carriers, assigned via DHCPv4 anyway, and are dynamic.  Someone using the standard service would not be expected to run services requiring specific inbound ports.  These subscribers would only be expected to run “NAT-friendly” applications – as most subscribers do today.

For subscribers hosting services, or using more advanced applications, however, the provider will offer a “premium service” – a dedicated IPv4 address.  That will be the solution.  A “normal” subscriber gets a shared IPv4 address.  A “premium” subscriber pays a little extra, gets a dedicated IPv4 address (and probably a static IPv4 address, which some carriers offer today as a premium service), and is not subject to NAT within the carrier cloud.  If the subscriber does NAT locally, within their home edge device, that is up to them. 

In some ways, this is a simple solution.  It only appears simple from the subscriber view.  They pay a little extra.  For the provider – not simple.  Remember that solutions only work for providers that are scalable.  Think about the impact on the provisioning and billing systems or the provider.  Think about the network impacts of implementing the “shared IPv4 address” scheme.  Lots of challenges, lots of work to do, and – look around – in a pretty challenging business environment.

I always say it is not easy being a provider.  This is another example.  But what choice do the providers have?  They need to keep signing up new customers, and not all subscribers are ready for IPv6 today (nor will they be in 2009, when the IPv4 address shortage really will begin to constrain their business).

Ahead, we’ll talk about applications that will not work (or as well) in a double-NAT environment, and also about some of the more popular “shared address” schemes.

The following all take place at our Herndon Training Facility
13655 Dulles Technology Drive
Suite 190
Herndon, VA 20171

Q1 2009 Open Enrollment Classes
2/23 - 2/27 Building IPv6 Networks
3/16 - 3/18 Securing, Hacking and Defending IPv6

Q2 2009 Open Enrollment Classes
4/6 - 4/10 Building IPv6 Networks
4/13 - 4/15 Securing, Hacking and Defending IPv6
5/4 - 5/7 IPv6 for Application Developers

(And naturally, we can provide our training at your site as well …)

A new study by MI2G Global Risk Specialists points out highly integrated the world economy has become with the Internet. This underlies highlights the importance of the IPv6 Internet upgrades we have been working on  are to ensure operational continuity of the Internet after IPv4 address exhaustion. Internet addressing, scaling, and operations directly impacts the global economy and will cause a major economic problem if we begin to lose the ability to communicate effectively.  This study estimates that: 

“Over 1% damage to GDP of a developed country such as Switzerland for every one week of Internet blackout is a reflection of how reliant modern business and society have become on Internet technologies. It is very interesting for us to observe that ETH has independently arrived at a similar approach to ourselves in developing economic damage models for large scale Internet attacks,” said, DK Matai, Executive Chairman, MI2G. “We are pleased to announce our intention to collaborate with Swiss Federal Institute of Technology Zürich (ETH) to develop more refined economic damage models for Internet attacks and their lingering commercial fallout in the years ahead.” 

Looking at this data and US GDP data we can see that the US produces 1.9%  of GDP per week so a 1% loss would be over 1/2 of production that week – about 250 Billion a week in lost productivity. Our economy is increasing tied to eCommerce, unified communications, and netcentric business systems - making Internet continuity a business continuity issue. That’s why total global value of eCommerce is one of the trends I track on “IPv6 Trends and Adoption Timelines“

In a commercial sample scenario presented by ETH, when an Internet Service Provider with an annual revenue of CHF 2.81 billion is hit by 24 hours of Internet outage, the total economic loss is projected to be CHF 32.99 million or 1.2% of annual revenue. The breakdown is as follows:

1. Downtime Loss = Degraded Productivity + Loss of Revenue = CHF 292,000
2. Disaster Recovery = CHF 5.2 million
3. Liability = CHF 15 million
4. Customer Loss = CHF 12.5 million

The top Internet leadership has been warning us that  IPv6 Transition is an  Issue of Business Continuity: 

“The technical stuff for IPv6 is done. IPv6 is ready. This is a business issue in the internet service industry. The ISP community round the world needs to pay attention… They are persisting in the ‘nobody is asking for this’ mentality.  They are not valuing business continuity as they should.  When they finally wake up, there is going to be a mad scramble for IPv6 and they won’t implement it properly”.   - Vinton Cerf, September 30, 2008 interview with “The Times Online”. 

In case you don’t know who Vinton “Vint” Cerf is, or if he is a reliable source, he’s the American computer scientist who is the “person most often called the father of the Internet.” His contributions have been recognized repeatedly, with honorary degrees and awards that include the National Medal of Technology, the Turing Award, and the Presidential Medal of Freedom. Vint is considered the leading candidate for the new Federal CTO position under the Obama administration. 

What are other top leaders in the Internet community saying?

• “In order to sustain the impressive speed of Internet innovation and ensure a healthy Internet economy for the future, we recommend that content providers make their services available over IPv6,” - Axel Pawlik, Managing Director RIPE NCC. 
• “.. With only 19% of IPv4 address space remaining, ARIN is now compelled to advise the Internet community that migration to IPv6 is necessary for any applications that require ongoing availability of contiguous IP number resources.” –ARIN Board 2007
• “If deployment <of IPv6> is delayed, the future growth and global connectivity of the Internet will be negatively impacted.” –Internet Society (ISOC) FAQ on IPv4/v6

Now, if a failure to migrate to IPv6 in time creates a major operational problem for the Internet that will impact the nation’s economic future, is IPv6 transition, as John Curran, ARIN Chairman and COO of ServerVault has warned the US Defense and Intel community, a “national security issue”?   If so, we better have a timeline and a plan together for transition…

Google has taken the advice of the Internet Engineering Task Force (IETF) engineers, American Registry for Internet Numbering (ARIN) (John Curran and company), Google’s own famous “Internet Evangelist” Vint Cerf,  and others that getting external facing servers working on IPv6 is a business continuity issue. There have been numerous warnings from the top experts in the Internet community about the consequences of Internet growth and the need to switch to IPv6:

• “In order to sustain the impressive speed of Internet innovation and ensure a healthy Internet economy for the future, we recommend that content providers make their services available over IPv6,” - Axel Pawlik, Managing Director RIPE NCC. 
• “.. With only 19% of IPv4 address space remaining, ARIN is now compelled to advise the Internet community that migration to IPv6 is necessary for any applications that require ongoing availability of contiguous IP number resources.” –ARIN Board 2007
• “If deployment <of IPv6> is delayed, the future growth and global connectivity of the Internet will be negatively impacted.” –Internet Society (ISOC) FAQ on IPv4/v6
• “.. in 2011, IPv6 must be in use by public-facing servers” –John Curran, ARIN Chairman, COO ServerVault  
•  “.. the Internet has been evolving, and IPv6 is the next major revolution that has to happen soon. ” –Vint Cerf, Internet Pioneer

John Curran, ARIN Chairman and COO of ServerVault, at a meeting of US Defense and Intel Internet engineers, went further to suggest that IPv6 transition is beyond an eBusiness continuity issue:

“<IPv6 transition> is a national economic policy issue and will be a national security policy issue within two years” 

As you can see in this picture, Google has been running their IPv6 service as a separate part of the Google space, and we connect across native IPv6 connections from the desktops in our Command Information network. (2610:F8::/32 is our address)  

However, more interesting than their IPv6-access site, is that they have installed an “invisible widget” on regular IPv4 Google to test IPv6 connectivity readiness of a portion of their users trying to connect to their production Google search portal. The widget directs a background process to exchange data with ipv4.ipv6-exp.l.google.com or dualstack.ipv6-exp.l.google.com to gather data on IPv6 connectivity. Lorenzo Colitti of Google revealed the experiment and the statistics they have been gathering at the European Internet Protocol Registry (RIPE) meeting at the end of October. Our enineers Joe Klein, TJ Evans, and others have analyzed their data and found a few interesting facts:

•  Less that 1% of Google users today have useful IPv6 connectivity (and prefer IPv6)
• 0.09% of IPv6 users have broken connectivity - most likely they don’t have both IPv6 connections and a AAAA capable DNS server serving IPv6 records. We can fix that with proper DNS implementations and IPv6 connection engineering
• All users with MS Vista, Apple Mac OSX Leopard, Windows Mobile smartphones, and modern Unix/Linux OSs have native IPv6-capable systems with IPv6 turned on - unless they have purposely disabled it. What’s holding them back is the lack of ‘last mile’ support infrastructure, and with IPv6 tunneling in these OS’s thats mostly a lack of IPv6 DNS implementation.
•  At least a million distinct IPv6 hosts out there have accessed Google during the test period
• The country with the most IPv6-ready users is Russia is the most IPv6-connected country -  the U.S. is #5 behind France, Ukraine, and Norway
• The most common connection type is 6to4 tunnels - which implies that sucessful IPv6 users are not behind NAT gateways and have native IPv4 connections that can run 6to4
• Apple has the most IPv6 connected computers - Joe commented that that’s probably the combination of Apple PCs with Apple Airport Extreme home network gateways - which support IPv6

The full report is available here: www.ripe.net/ripe/meetings/ripe-56/presentations/Colitti-IPv6_at_Google.pdf

The takeaway from all of this? Google has taken the plunge and is well positioned for the 2012 number crunch pain by already having external IPv6 connectivity on their WWW and DNS servers. Organizations sucessfully running external IPv6 servers are the IETF, ARIN, RIPE, IPv6 Forum, ICANN, Command Information. and many more. It seems that the major IPv6 transition advocates are heeding their own advice and sucessfully “eating their own dogfood” to show that IPv6 transition is not as difficult as many believe.

In closing, here are a few interesting snapshots of the Google data: