Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages
Filter by Categories
a) Access Network
All Course Calendar
b) Core Network
Basic Courses for Professionals
Business Analytics & Management
c) Certified Technicians
Carrier Ethernet Program
Cloud-Enabling Technologies
Fiber Optics Communication Technologies Courses
Internet of Things (IoT)
IP / Traffic Engeering / Signaling
LTE / 4G / 5G Technologies
Network Operations & Business Support
Network QoS & Optimization
Security Courses
Telefocal Certification Programmes
Training Course Calendar
Training Courses
Transmission Technologies

IPv4 to IPv6 Migration Strategies and Challenges

There are around 25 billion devices connected to the Internet and the number is increasing as you are reading this article (Source: Chief Technologist, Internet Business Solutions, Cisco Systems)

IPv6, the addressing scheme used by today’s Internet, is fast approaching its saturation point in allocating available addresses. It has fuelled an increasing attention and awareness towards deploying alternative solution found in utilising the IPv6 protocol – a 15 year old Internet addressing protocol.

IPv4 offers 2^32 addresses managed by the Internet Assigned Number Authority (IANA) and by the Regional Internet Register (RIR). In contrast, IPv6 offers 2^128 addresses. Whilst the latter is seen as a solution towards overcoming IPv4 address allocation limitation, its rate of adoption has been slow and the main reasons can be attributed to its lack of interoperability with IPv4 and vendor support.

The transition from IPv4 to IPv6 is not meant to be a radical one, since functions that work on IPv4 can be maintained in IPv6 but those that don’t can be discarded.

As an alternative to incurring high Capital Expenditure (CAPEX) and Operating Expenditure (OPEX) for IPv6 adoption and implementations, efforts were made in recent years to implement low-cost solutions base on IPv4 network infrastructure so as to slow down the process towards reaching IPv4 address saturation, for instance, making use of technologies such as Classless Inter-Domain Routingz` (CIDR) and Network Address Translation (NAT).

Despite such solutions, IANA’s primary address saturation point is estimated to be reached by early February 2011. As of 30 November 2010, only seven of the 224/8 allocation blocks remain available. This is translated to less than 3% of the total available IPv4 address space. (

Asia-Pacific Network Information Centre (APNIC), the RIR which allocates IPv4 addresses in the Asia-Pacific region, is expected to reach the address saturation point between June 2011 and December 2011. (


Coupled with worldwide Internet growth and increased mobility of people round the world, it appears now to be more imperative than ever to deploy IPv6 so as to overcome the address limitations imposed by, as well as lack of user mobility of IPv4.

However, suffice it to say that such transition will not be gradual. It is foreseen that IPv4 and IPv6 would co-exist for at least twenty years before IPv4 gets obsoleted.

There are many methods and strategies for IPv4 to IPv6 transition with each having its merits and demerits.

Benefits of deploying IPv6:

  1. IPv6 address space is now 2^128
    1. Provides addresses which simplify direct peer-to-peer applications and networking
    2. Do away the need for address translation technologies
    3. Introduces simplified header which reduces the processing cost of packet handling
    4. Caters to hierarchical addressing
    5. Provides auto-configuration (stateful and stateless)
  2. Offers scalability of Multicast Routing due to a larger pool of addresses
  3. Provides built-in Security
  4. Provides Quality of Service capabilities based on traffic flow
  5. Offers improved support for Options
  6. Offers authentication and privacy capabilities

Transition process from IPv4 to IPv6 is comparable to any other technology upgrades or migration processes but since in this case the global Internet community is involved, any constraints imposed by IPv6 implementation would be amplified.

Challenges of deploying IPv6:

  1. Incompatibility of IPv6 with IPv4. IPv6 has been designed as an alternative to IPv4, and not as its extension. This limits the feasibility of a straight forward transition plan.
  2. Incoherence in not creating a transition plan from IPv4 to IPv6.
  3. Distraction in not enabling IPv6 addressees to “communicate” with IPv4 addressees. The entire Internet infrastructure cannot switch overnight from IPv4 to IPv6.
  4. Stepwise transition due the fact that the transition will take years and it is quite impossible to synchronise the processes at different sites. IPv4 and IPv6 network equipment will be required to coexist and offer interoperability.
  5. No feasible mapping scheme to map IPv4 to IPv6 addresses (IPv6 hosts can have more than one IPv6 address)
  6. IPv6 is still an evolving standard.

Some of the transition techniquesavailable, which have different associated costs and involve different levels of complexity and functional capabilities, are illustrated below:

  1. Dual-stack (IPv4 and IPv6)

In this method Pv6 is deployed within the network infrastructure. Each node will have both IPv4 and IPv6 protocol stacks, and used independently to communicate with other IPv4 or IPv6 nodes. Since IPv6 and IPv4 are different protocols they can be run concurrently using their own protocol stack.


This method focuses on users, core infrastructure, enterprises applications, and back-end systems.

Depending on its scale, it can be very expensive and time consuming to deploy since it involves new hardware, considerable planning and skilled operations.


  • IPv6 to IPv4 Tunnelling


This involves a mechanism that encapsulates IPv6 packets in to IPv4 packets. A dual stack host can send IPv6 packets through an IPv4 core using a tunnel to a IPv6 remote host without requiring any IPv6 infrastructure.

The only requirement is that at the endpoints of the tunnel, there has to be a IPv6/IPv4 header translation router or an IPv6/IPv4 node.

Tunnels are typically manually or automatically configured. Manually configured tunnels are mainly used as stable links for regular communications, and are easy to deploy over existing IPv4 infrastructures.

These tunnels however give rise to large management overheads and troubleshooting challenges. Tunnel’s endpoints are still relying on a dual-stack solution.

There are different kinds of tunnelling techniquesthat can be used:

  1. Configured Tunnelling. In router-to-router and host-to-router tunnelling method, the IPv6 packet is tunnelled to a router. The tunnel endpoint is an intermediary router. The intermediary router at the end of the tunnel de-encapsulates the IPv6 packet, and forwards it to the final destination. The IPv6 packet does not provide any information about the tunnel endpoint IPv4 address. The node creating the tunnel provides configuration information that determines the tunnel endpoint IPv4 address.



  • Automatic Tunnelling. In the host-to-host and router-to-host tunnelling methods, the IPv6 packet is tunnelled until its final destination. The tunnel endpoint is the IPv6 packet’s final destination, the IPv6 packet’s destination determines the tunnel endpoint. There is no need to configure the tunnel endpoint address.





  • ISATAP Tunnels. Intra-site Automatic Tunnel Addressing Protocol is another method of tunnelling where the tunnels are automatically defined and not statically defined. These tunnels are primarily used between hosts and routers, manually configured tunnels are used between routers. It is automatic in the sense that is it created only when it is needed.




As a transition strategy it is ideal for campus and branch sites because ISATAP activates to activate IPv6 connectivity on the existing IPv4-only network while the infrastructure is gradually migrated to integrate native IPv6 capabilities.

The benefit is given by the need of only one ISATAP router. The drawback is the lack of IPv6 multicast support.


  • 6 to 4 Tunnelling. It is defined by IETF, and it is similar to a manual tunnelling, except that the tunnel is set up automatically. IPv6 addresses are a concatenation of a special IPv6 prefix with the 32 bit IPv4 address of the router where the tunnel terminates.
  • IPv6 Translation

It is a different kind of solution which allows IPv6 devices to communicate with IPv4 devices without requiring being dual-stack. There are some forms of packet header translation between IPv6 and IPv4 addresses:

  1. Stateless IP/ICMP translation (SIIT) translates IP header fields, NAT Protocol Translation (NAT-PT) maps IPv6 to IPV4 addresses. The Request For Comment (RFC) however does not specify how to perform address assignment nor routing to and from IPv6 hosts when communicating with IPv4 hosts.


  • Application Level Gateway (ALG) intercepts traffic and converts between IPv6 and IPv4 protocols. It is an IP device running dual-stack and can have native access to both IPv6 and IPv4 services. ALGs are used as proxies to perform protocol translation with one proxy server per application (HTTP, FTP, SMTP.). The advantage is to have only IPv4 addresses for these proxy servers. Where firewalls and proxies are already utilised (many LAN implementations) this will not imply a high price to be paid. Unfortunately ALGs are not able to handle all services, in particular those with end-to-end requirements.
  • Bump-In-the-Stack (BIS) and Bump-In-the-API (BIA) are NAT-PT implementations within a host. It is used where organisations cannot upgrade their applications running on hosts and servers to use IPv6. BIS/BIA intercept system calls to IPv4 functions and dynamically respond with IPv6 information. BIS enable the communication of IPv4 applications on an IPv4 host to communicate with an IPv6 host. It is not designed for the initial stage in the transition from IPv4 to IPv6, but it will be most probably used for the interoperability of legacy IPv4 applications with IPv6 applications. It uses three extra layers in the IPv4 protocol stack between the application and the network layers. It doesn’t support multicast communication. BIA mechanism inserts an API translator between the API module and TCP/IP module in the dual-stack host.

Each transition mechanism has a unique role to play, but the best choice would depend on specific needs and thus differ from case to case. There are few questions that one needs to consider when selecting the transition mechanism. These invariably relate to why IPv6 is considered, why IPv6 is being deployed, if the hardware and infrastructure support IPv6, CAPEX and OPEX budget allocated, time-frame available for the migration process, and last but not least, if it is it a temporary or a permanent solution.

I hope you enjoy this article. Feel free to email at should you have further questions.

Telefocal Asia Pte Ltd © All rights reserved. Website Terms & Conditions

Setup Menus in Admin Panel