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.

« January 2012 | Main | March 2012 »

February 27, 2012

IPv6 - The missed opportunity and more

A common dilemma that software engineering teams across geographies face is the dilemma of building for the future. Under strict timelines, considerations for the future are often compromised under the excuse of taking that up at a later point of time, once the current emergency is handled. There is the conflict of whether there is an accuracy of thought as regards the future requirement - and whether it is worth investing time and effort for a future requirement that might not arise. Vincent G. Cerf (one of the Fathers of the Internet along with Bob Kahn and program manager on the DARPA project to develop and realize TCP/IP technology) was confronted with the same problem back in 1977 when designing the Internet- "How much address space is needed for the Internet?"

As per his story of the early days of the internet, the debate (among stakeholders then working on the Internet) to answer that question, ran for a year without a definite conclusion. The debate was around whether a 32-bit address space, 128 bit address space or a variable-length address space would be apt - each argument having been strongly debated among engineers and scientists working on the project.  At the moment of time, when the decision needed to be made, there were very few networks available and hence 128-bit addresses was not deemed necessary. The variable length address was rejected by programmers who felt that determining the length of the IP address from within a TCP/IP packet - to determine the source and destination - would be an overhead. With the need to proceed with live testing and final design of TCP/IP, the 32-bit address size was agreed upon for experiments to prove the concept.  That decision was never revisited, until the IETF (Internet Engineering Task Force) realized in the early 90's that with the rapid growth of the Internet, the address space would eventually be exhausted - and hence decided to consider a new extended address format - which we now know as IPv6.The repercussions of the apparently harmless consensus of going ahead with a 32-bit format, is apparent even today.

Implementing IPv6 is going to be a significant change to the Internet architecture - probably the first major shift since its inception.  The change will potentially touch a lot of things eventually - gateways and routers, Domain Name Systems, DHCP, applications, client and server machines. Organizations all over the world have hence been slow in responding to calls to move their networks entirely to IPv6 because of the volume of changes and uncertainty post that change.  Some organizations (particularly in the US) still own plenty of unallocated IPv4 addresses to last some more time, and hence do not feel the urgent need to transition. The world's network is still primarily IPv4 based.

Many organizations have converted their client facing web-site to be IPv6 friendly during the World IPv6 Day. However, considering the scale of investments in network architecture changes required for total IPv6 adoption, it is possible organizations made changes only to the client facing web-sites for that day to enable IPv6 access. Potentially, the network load balancers that intercepted requests to the client facing website supported IPv6 in the front facing side and internally with the IPv4 only web servers in the network - implementing NAT64 here . Such a change would not be entirely disruptive as far as the organization's internal network topology is concerned. Though, this is one mechanism using which organizations can avoid being cut-off from IPv6 users, there is obviously the overhead of conversion by a mediator which might have performance implications if the numbers of user's are high.  There are similar mechanisms in which mobile carriers set up server farms on their network to enable IPv6 to IPv4 conversions for the next generation LTE phones and devices that are eventually going to be IPv6 only. There are mechanisms like dual-stack, tunneling etc. that will enable a migration path from IPv4 to IPv6 as covered briefly here.

There are however IPv4 die-hards who feel that the life of 32-bit addressing schemes can be prolonged using techniques like Network Address Translation (NAT) but the truth is that with the spiraling proliferation of devices, IPv6 will eventually have to be adopted. Thomas A. Limoncelli, in the same article talks about the 2008 Google IPv6 symposium, where Nokia apparently demonstrated that having their devices behind a NAT was a disadvantage because of the need to send frequent pings to keep the NAT session alive thus resulting in unproductive wastage of battery power. By moving to IPv6, the antennae can be switched on only when there is a need to send data because the phone will now own an IP address. This will be a good move considering that watt/$ is an important metric in gauging efficiency of mobile devices.

IPv6 adoption is growing with many organizations in Asia and Europe adopting simply because they cannot get any more IPv4 addresses. ISPs are also under pressure as they are not able to provide IPv4 addresses to their customers. Besides, they are also going to have a number of new IPv6 customers who expect the same services as that on the IPv4 network. ISPs will have to implement strategies (like tunneling for example) which will enable IPv6 customers to use the IPv4 internet - and will then have to eventually plan to migrate their subscriber network to IPv6. But, that seems some time away as the world is looking around to check if they can hold on to IPv4 a little while longer - simply to postpone potentials risks of downtime and painful recovery in case of adoption issues.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter