#nat64

Back in the days (thinking 1997 - 1999) when the media was predicting Y2K doom and gloom, there was a side story which was similarly touting the consequences of address space exhaustion on the Internet once our household appliances go online. This article on cnet pretty much sums up the mainstream thinking back then.

Alas, appliances did not quite go online and the world did not quite end either. Having said that, the adoption of mobile devices and population in the emerging worlds have achieved what one's microwave failed to do - all the IPv4 addresses being exhausted. 

Notable projections made in late 2010 indicate a high probability that address exhaustion at the registry level, in Asia Pacific looming around end of 2011 / early 2012. This is somewhat conservative, as of April 15, 2011, the region is down to its last /8 subnet and has begun aggressively rationing assignment of the remaining addresses. 

As most organizations are ever so connected with their users through online collaboration as well as the emergence of the web, they should consider having a concrete and actionable migration plan to IPv6. In doing so, they need to consider the ramifications of how how the consumer, their ISP and overall carriers are preparing for the transition. The choice of transitory approach (such as NAT64, DS-lite) will impact how their presence is rendered and the overall user experience. 

This transition will be of essence to companies whose user base is more global in nature and whose collaboration extends to mobile devices. The latter being key as large carriers such as T-mobile(USA) have committed to IPv6 only deployments with large NAT farms providing backward accessibility to IPv4 content. 

During the migration, one may wish to consider these points: 

Demonstrate Success Early: Quick wins are always appreciated. Though the internal corporate cobweb of interdependencies may be frightening and rather daunting, an easy approach is to provide an enterprise proxy that NATs incoming IPv6 requests to IPv4 that is currently supported. In reality, most organizations use a load balancer in their current topologies, which can fulfill this role (assuming it is currently under support from the top 5 vendors in this space). That would provide the IT operations personnel some time to familiarize themselves with the new environment while providing a foundation to support further migration. Over time, one can begin converting web servers hosting static content to support a dual stack with the intent to migrate to IPv6 only. Also, it would provide an opportunity to address small though niggling concerns such as IPv4 literals that existing content may have and which need to be fixed.

Migrate by Capability: Establish a list of business or user capabilities that will be converted from IPv4 to IPv6. For instance, one may choose to migrate corporate website which for many has static content. Others such as Comcast, migrated their set-top management interfaces. This provides tangible understanding of scope, while driving the sequencing by which the underlying infrastructure (e.g., routers, applications, operating systems) is converted.

Educate internally on 'Work In Progress' Items: Though most applications currently work well in an IPv6 environment, some of the social media applications such as Skype, some IM clients and gaming platforms don't. Users of such tools need to be grandfathered in with appropriate routing and DNS changes in place to ensure minimal impact during the migration. 

Educate consumers and users on IPv6 Readiness: Being aware that the overall user experience is a function of their devices, and the ISPs / carriers in between is essential when understanding the end user experience. Usability and performance testing has to be adjusted to account for the impact of technologies such as NAT and DNS translations as well as the potential issues of devices operating with a dual [IP] stack. All of these can result in the consumers gaining a marginal experience at best and assuming unavailability due to long response times. In addition, though common operating systems support IPv6, the default settings may impact user experience (e.g., OS X support for DNS). Much as was the case of the Internet in the early days of dial-up and connectivity via AOL, organizations would be served well by adding a FAQ and user education sub-site around best practices for connectivity via IPv6. 

Plan for long-term co-existence: Analogous to the migration from SNA to TCP/IP, some core systems will remain on IPv4 for the foreseeable future. Network design and architecture around IT systems need to account for this and how one plans to support such topologies with a set of operational tools such as log aggregators, SIEM and monitoring platforms in general. Though most tools support dual stack usage, the challenge is typically in the custom scripts, programs and 'hacks' that tend to be leveraged for day to day analysis. The size and scale of such adhoc programs in the enterprise should be determined to provide context around the effort to convert these and perhaps retire those which are no longer needed.

Though the migration that has been postponed for more than decade is now upon us, most organizations should be able to transition in a seamless manner to IPv6. Large software and network vendors have diligently included support for IPv6 in the lower components of the OSI stack, thus providing the foundational tools requsite for such a transition.