Welcome to the world of Infosys Engineering! It is a half a billion plus organization that takes pride in shaping our engineering aspirations and dreams and bringing them to fruition. We provide engineering services and solutions across the lifecycle of our clients’ offerings, ranging from product ideation to realization and sustenance, that caters to a cross-section of industries - aerospace, automotive, medical devices, retail, telecommunications, hi tech, financial services, energy and utilities just to name a few major ones.

« August 2011 | Main | October 2011 »

September 29, 2011

Adoption of IPv6

In recent times, there seems to have been a renewed interest in IPv6 adoption - with the impending state of exhaustion of IPv4 closer than ever before. The internet explosition and the proliferation of internet enabled devices (ever-connected and online) have resulted in a much quicker-than-expected exhaustion of IPv4 addresses. Strangely, over the years, there have been various publicly advised debates around the accessibility and growth of the internet -but somewhere there, the urgency to think about a state where existing IP addresses would exhaust - seemed lacking. We are at that very point now where transitioning to IPv6 has seemingly become very important.  Apparently, the last blocks of IPv4 internet addresses will soon be assigned to regional internet registries.

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.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter

Recent Posts