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.

« Privacy of Data in the Cloud | Main | Product Strategy: Back to Basics for a Strong Start »

Are you IPv6 ready?

Global supply of publicly routable IP (Internet Protocol) addresses is going down and according to an estimate most of the remaining IPv4 addresses are expected to be allocated by the end of 2011. IPv4 addresses are 32-bit and can only provide around 4 billion (2^32) addresses. Less than 10% of these addresses are left and with the growing number of users and devices (e.g. smart phones) connecting to internet, it will become increasingly difficult to get new IPv4 addresses. With most of the current day businesses depending on internet to conduct their daily transactions, it is imperative that for business continuity, they should migrate to IPv6. Some of the leading web content providers are already offering services on IPv6 (e.g. www.ipv6.google.com, www.ipv6.netflix.com). IPv6 addresses are 128-bit and can provide virtually unlimited number of addresses (2^128). IPv6 protocol is specified by Internet Engineering Task Force (IETF) and is documented in RFC 2460.


In the coming years many of the ISPs (Internet Service Providers) will start provisioning only IPv6 addresses and businesses which do not migrate to IPv6 may loose the customers who cannot access their services over the net. Key to successful IPv6 transition is interoperability with the existing installed base of IPv4 nodes, as most of the installed IPv4 infrastructure will continue to co-exist with IPv6 in the coming years. Top priority would be to migrate the external facing servers (servers on the internet) to IPv6. Internally (intranet) organizations could still operate IPv4 networks.


The first step towards migrating to IPv6 would be to upgrade the existing IPv4 infrastructure on hosts, routers, switches etc. to IPv6. When the IPv6 infrastructure is being deployed, existing IPv4 infrastructure can be used to carry IPv6 traffic. IPv6 transition mechanisms like 6to4, Teredo tunneling and ISATAP provide a way to transfer the IPv6 packets over IPv4 networks. The nodes which are upgraded to IPv6 should be dual-stack enabled, i.e. those nodes should support both IPv4 and IPv6 protocols. Such nodes are configured with both IPv4 and IPv6 addresses. Most of the current operating systems like Windows XP/Vista/7, Linux and MacOS support IPv6. But IPv6 is disabled by default and may have to be enabled to operate in dual-stack mode. Mobile operating systems like iPhone OS 4.0, Android (2.0 onwards) and Symbian OS (v7.0 onwards) also support IPv6.


Apart from migrating the infrastructure to IPv6, applications will have to be modified to handle both IPv4 and IPv6 communication. Assuming that the underlying infrastructure has been migrated to dual-stack mode, applications could be in one of the 4 states:

  • IPv4 application in a dual-stack mode: In this case the node supports both IPv4 and IPv6 protocols, but the application can only manage IPv4 communications. Application has to be migrated to IPv6 to handle both IPv4 and IPv6.
  • IPv4-only application and IPv6-only application in dual-stack mode: In this case there are 2 versions of the same application, one which supports only IPv4 and other which supports only IPv6. For e.g. www.google.com is IPv4-only version of application and www.ipv6.google.com is IPv6-only version of the application. The problem with this approach is that two versions of the same source code have to be maintained for same application. Also users of these applications might have difficulty in choosing the right version of the application.  
  • IPv6-only version of the application should be able to communicate with IPv4 nodes also, by using IPv4-mapped-IPv6 addresses (some dual-stack implementations might have disabled support for IPv4-mapped-IPv6 addresses, due to security concerns). IPv6 addresses of type "::FFFF.w.x.y.z" represent the IPv4 address "w.x.y.z". 
  • Application supporting both IPv4 and IPv6 in dual-stack mode: This is the ideal case. In this case the application can handle both IPv4 and IPv6. Single source code is maintained for handling both IPv4 and IPv6 communication. While communicating with remote nodes, typical version-independent applications prefer IPv6 communication by default. If IPv6 communication fails, then IPv4 is tried.  
  • Application supporting both IPv4 and IPv6 in an IPv4-only node: In this case application has been ported to handle both IPv4 and IPv6, but IPv6 protocol has been disabled in the node. Hence the application can only send and receive IPv4 packets. This scenario should also be handled in the application.

 Following are some of the considerations while porting the applications to IPv6:

  • Handle differences in IPv4 and IPv6 address formats and sizes: IPv4 addresses are 32-bit and are represented as four decimal numbers separated by dots. E.g. "". IPv6 addresses are 128-bit and are represented as 8 fields of up to 4 hexadecimal digits, separated by colon. E.g. 3ffe:ffff:101::230:6eff:fe04:d9ff. The string buffers used to hold the addresses should be changed to be big enough to accommodate IPv6 addresses. Also differences in the formats (dot vs colon, decimal vs hexdecimal) should be handled while storing the addresses.
  • Use of protocol independent data structures and APIs: Use generic data structures which can store any address family. For e.g. protocol independent structure "sockaddr_storage" should be used instead of "stockaddr_in". 
  • Protocol-independent versions of the APIs should be used for communication. Following table lists some of the old and corresponding new APIs which should be used: 

Old APIs

New (Protocol Independent) APIs















  • Address resolution: getaddrinfo() returns a list of all the configured IP addresses for a host and the application should try out each of these returned IP addresses till the communication with the remote host succeeds. 
  • With migration to IPv6, remote hosts could be configured with multiple IP addresses.  Hence programmers should not hardcode the IP addresses of remote hosts in the code. Because it may be possible to reach the destination using different IP addresses.
  • DNS changes: "AAAA" DNS resource records are used for identifying the IPv6 addresses ("A" for IPv4). If you have migrated your application to IPv6, then you should advertise both "AAAA" (for IPv6 address) and "A" (for IPv4 address) records with DNS. This enables both IPv4 and IPv6 clients to connect to your host.


For detailed guidelines on migrating applications to IPv6, refer RFC 4038. Other resources which provide materials for helping you to migrate to IPv6 are:

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter