Adoption of IPv6
Enterprises generally hold large pools of IP addresses which are pooled dynamically (using DHCP servers) based on demands of devices wanting to join the network. In some organizations, IPs is statically assigned when there are sufficient IPs reserved. Static IP reservation is anyway rare today in enterprises, but even for dynamic assignment, there do not seem to be sufficient number of IPv4 based addresses available to allocate from. IPv6 provides nearly an infinite supply of addresses besides improving routing efficiency and other benefits. Interestingly, the apparently infinite supply of IP addresses introduces the possibility of assigning a defined IP per device which in turn introduces the risk of identified surveillance (because the IP address then becomes an identity - when attached to mobile devices ( smartphones etc). There are however methods of anonymizing addresses to disassociate collected data from specific IP addresses)
The challenge today among enterprises and service providers is to determine a smooth IPv6 transition strategy that is least disruptive. The need is to maintain backward compatibility during the phase of transitioning to IPv6 enablement. There are substantial costs and risks involved in the transitioning (and hence are best postponed in areas like internal networks of enterprises which use private addressing and may not have issues related to address shortage). The state of complete IPv6 adoption is still a long way away today - and hence it is best to adopt in phases (islands of IPv6 adoption) to ensure operations are not affected during the transitioning.
Migration to IPv6 involves the network, operating systems and applications. Even when applications and services claim to be IPv6 compliant, there are feature and performance differences between IPv4 and IPv6 which need to be analyzed. For example, it is believed that adopting IPv6 will result in consumption of more network bandwidth (because of increased packet size).
One of the many migration/transitioning mechanisms is to use the dual-stack strategy (there are other strategies like tunneling etc) where all devices in a communication path have support for dual IP stack available which enables both IPv4 and IPv6 protocols. (A number of operating systems already support this mechanism in the kernel.) This mechanism supports applications that may use IPv4 or IPv6 as their communication protocol in the underlying network. Applications expected to be transitioned to IPv6 should use protocol independent APIs in the code snippets involving TCP/IP communication. For instance, in C/C++, IPv4/v6 portability is assured by using getaddrinfo() instead of gethostbyname() etc. The task of incorporating portable IPv4/v6 support in native code could be along the same lines adopted over the years in cross-platform porting where portable APIs were used to the extent possible (with OS specific code separated using pre-compiler directive flags). Java and .NET libraries already have IPv6 support built in for many years - such that a single code base ensures IPv4 and IPv6 readiness.
It is important to check if there is indeed a business case for a customer to move to IPv6 when the cost of transition exceeds the benefits. Even in a world slowly adoption IPv6, most highly desired content is still in the IPv4 world and hence there may be time yet. Interestingly, China had shown the urgency and built a strong IPv6 based infrastructure well in time for the Beijing Olympics in 2008 - and seemed to have benefitted economically as a result. London for the 2012 Olympics has shown no such interest with a London Olympics spokesperson recently announcing that - "Such is the scale of technology required for Olympic Games, it tends to be tried and tested. We work closely with our technology partners to ensure that we have operational certainty across the project. As such we will be using IPv4 for London 2012." This has indeed left the pro-IPv6 adoption group disappointed - and typically reflects the paranoia surrounding the current state of IPv6 adoption.