How To Avoid The Nine Fatal Traps Of IPv6 Migration


Every organization must sooner or later adapt to an increasingly IPv6 global environment. The transition can take a number of forms:

  • Hasty and costly early adoption, without sufficient planning, prioritizing and pre-testing
  • Reluctant rearguard action as business is lost to competitors more visible to a growing IPv6 market and audience
  • Forced adoption under pressure from government mandates and market/consumer drivers
  • A careful, step-by-step migration that spreads the cost, prioritizes for optimal business benefit, allows time to evolve to the new environment and avoids expensive mistakes.

Not surprisingly, this article argues for the latter course. Having worked with a large number of engineers and IT professionals who have already deployed IPv6 from across the globe, I have distilled five key steps from that work to achieve that smooth migration. I have also identified nine key traps to be avoided along the way of migrating from IPv4 to managing the co-existence of IPv4 and IPv6 in the network and applications.

Most agree that organizations should begin with running IPv4 and IPv6 in parallel, starting at the perimeter of the network (the Internet facing side), then the internal core and only then the end-nodes. As deployments begin to impact internal networks, more attention must be given to vulnerabilities with existing protocols and adoption plans by enterprise equipment.

In particular, the people I’ve worked with already, agreed that the sheer management of the IPv6 address space will become a major challenge. The expansion to 128 bit addressing, including complex address annotations and an explosive number of IP addresses will overwhelm home grown IP address management databases and be impossible to manage by spreadsheets alone. The only reliable solution requires some form of automation of key management functions such as DNS, DHCP and IP Address Management.

There is no avoiding the inevitable

The pool of unallocated IPv4 addresses have run out, and the Regional Internet Registries (RIRs) will exhaust their local pools by early 2012. For now, all new Internet services will continue to use IPv4 addresses to access the IPv4 part of the Internet, but the registries cannot continue to supply IPv4 addresses freely as supplies will not last for long. By 2015, 17 percent of the Internet is predicted to use IPv6, with 28% of new Internet users running the new IPv6 protocol.

Gartner predicted growth of mobile devices like smartphones and tablets from less than $20million in 2010 to more than $900million by 2016, mobile will outnumber the PC by 4 to 1. As a result they see that the mobile operating systems will overtake the pc operating systems in 2016.

Simultaneously a 19% growth rate is predicted for Cloud Computing and they predict that by 2016 half of all IT providers will be cloud server brokerages.

These trends increase the need for Internet accessible IP’s, dynamic IP assignment/management and automation of network configuration changes exponentially. Also it will stress core network service like DNS and DHCP.

Turning on an iPhone alone already triggers over 30 DNS requests. Top this up with the fact that mobile devices will need multiple IPv6 addresses to function and you quickly understand that automatic IPv6 assigment and management will be a prerequisite for any future proof network.

Several approaches have been tried to extend the life of IP addresses. The two most popular are 1) the recovery of unused public addresses and 2) the use of public Network Address Translation (NAT).

Early Internet pioneers, such as the government, IBM, AT&T and MIT, were granted large blocks of IP address that remain largely unused and there’s been a call to move those addresses back into the public domain. This will extend the availability of IPv4 addresses, but cannot satisfy the need for over a billion new IPv4 addresses over the next five years. You could also argue, people are then still investing in a legacy network. They need to invest in the next generation IPv6 network!

A longer-term possibility is to extend the use of NAT into carrier networks. NAT or Network Address Translation, allows thousands of users to share one public IP address (public Internet Address). Cascading NAT or multiple translation points would extend the life of IPv4, but it introduces greater complexity that could degrade or brake peer-to-peer applications and other basic functionality, especially in the area of tele-presence and unified communication.

Traditional NAT 4 to 4 devices (using one public IPv4 address to service multiple other hidden IPv4 addresses/users behind the NAT device) must also retain state information on each session, and the more sessions multiply, the more resources are required, which is a problem.

If a single public IPv4 address is shared among 2,000 customers using NAT, it allows only about 30 Internet sessions per user. A session is where your PC, tablet or smartphone needs to exchange one-to-one information with an application on the Internet.

Yet modern applications need numerous sessions in parallel to work– a Yahoo page may create 20 sessions, a Google image search 30 to 60 sessions and a YouTube video uses 90 sessions. On average, users require 500 sessions, significantly limiting the ability for NAT to support a massive population of users.

Head in the sand won’t work when the sand runs out

If already running a private IPv4 addressing scheme, can’t one forget about IPv6 for now? It is not that simple, because it is not just the technology but also long-term operational and business issues that must be considered. The following factors will compel many organizations to adopt IPv6 sooner than expected.

  • Immediate need. A growing number of national governments, as well as the European Union, are applying mandates for IPv6 readiness. For equipment and service providers addressing the public sector this makes IPv6 readiness an immediate need.
  • Application requirements. Many new applications and services are being designed for a new generation of devices such as sensors, appliance-based controls, power management (smart grid), 4G wireless / LTE that only just beginning to migrate to the Internet and amounting to a surging demand for extra addresses – necessarily IPv6 because of the sheer numbers. It’s a tipping point that will further accelerate IPv6 adoption, and if you are not prepared, this population will be beyond the reach of your organization.
  • Loss of critical Web statistics and visitor information. Even if IPv6 devices can reach your website via NAT, you will miss key customer information as it gets lost in translation. Marketing data such as identification of visitor information, country, and organization, are based on Web server logs which will require native IPv6.
  • Operational risks. What plan have you to migrate your public facing Web sites and applications to IPv6? The reduction in available IPv4 address will increasingly become a significant risk to the organization. Could future corporate governance legislation require disclosure of IPv4 exhaustion as a business continuity risk?
  • Innovation. Staying ahead of the competition & laying the right foundation to grow a business in the digital era where the internet and online communication are business critical

Five safe steps to IPv6

From our experience of IPv6 migration problems suffered by customers – some of it bitter – we have distilled these five key steps for a smooth and cost-effective transition.

Step 1: Implement IPv6 on your external facing Internet presence

A flood of new mobile devices will mean a new population of IPv6-only users that will be invisible to organizations that do not support IPv6 on external facing Web sites, mail servers and other applications.

Relying on IPv4 to IPv6 translation means all traffic passes through a protocol translation device creating a potential bottleneck, losing end user information and a need for redundancy and other high availability and performance features in the translator to ensure 24/7 availability.

A better solution is “dual stack” architecture, where the Internet facing infrastructure understands both IPv4 and IPv6 protocols – with no single point of failure or performance bottleneck threats. There are, of course, dual routing domains that need to be monitored and managed appropriately.

Step 2: Migrate the internal core network and WAN to dual stack

Deploying IPv6 internally on switches and routers is recommended by the end of 2012 for parity with industry direction. This means a dual stack deployment of all internal switching and routing this year, leaving time for testing and analysis for IPv6 end point deployment in 2012. This means more than just evaluating the WAN routing infrastructure. – services must be IPv6 compatible or an IPv6 migration plan is needed from the carrier to ensure this. WAN optimization equipment, firewalls, and the infrastructure and security components impacting the WAN must also be IPv6 compatible.

Step 3: Migrate the Intranet to IPv6

With the routing and switching infrastructure in place, you should enable local IPv6 access to the Intranet. Although this could be done by translation, dual stack is better as explained above.

Step 4: Implement IPv6 Internet access

IPv6 enabled sites are becoming more prevalent. In 2008, about three percent of Autonomous Systems (AS) announced IPv6 routes, reaching nearly eight percent by 2010. Content on the IPv6 network is also starting to grow: YouTube will be IPv6 compatible, Netflix has already demonstrated IPv6 access, eBay and Facebook plan to deploy IPv6 enabled sites. Most content will be IPv4 compatible for the foreseeable future; however, some services are better suited for IPv6 access, such as connectivity to native IPv6 smart phones and devices.

Step 5: Enable native IPv6 access to the end client

With the core IPv6 infrastructure in place organizations should then push native IPv6 access to the edge of their networks. This inflection point requires significant changes in how IPv6 addresses are assigned and managed, manual systems will not be able to keep pace with the complexity. This is discussed at the beginning of the next section.

General considerations: if we assume that one amortizes the cost of equipment for three to five years, all new equipment purchased today by organizations must be IPv6 compatible. Regardless of how one evaluates the exact cut-over to IPv6, for most organizations, all the projections anticipate a an accelerating shift to IPv6 in the next three years.

Nine traps to avoid – and how

Some general principles are well understood: a thorough audit is needed of all equipment and software; staff education is necessary and networking policies must be reassessed or established. However, joint experience has highlighted eight key issues:

1. Configuring and tracking IP addresses

The most fundamental impact of IPv6 is on IP address assignment and management with the shift from 32-bit IPv4 to 128-bit IPv6 addressing. Manual tools, such as spreadsheets, become impossible to use with IPv6. Organizations should move to automated IP Address Management (IPAM) tools that are fully IPv6 compatible, including DHCPv6 for controlled IPv6 address assignment.

2. Reviewing the DNS/DHCP architecture

Planning for IPv6 on internal networks, involves assessing IPv6 readiness of the core network services, including DNS and DHCP. If you use DHCP for address assignment, your DHCP server must be IPv6 compliant. Supporting an IPv6 end point requires configuring IPv6 DNS domain support, DNS server addresses, network time server addresses and more, all of which is preferably controlled by the DHCP server. So it is essential to have a modern DNS infrastructure equipped to deliver both IPv4 (A Records) and IPv6 (AAAA Records), and that both DNS and DHCP must be interoperability tested to ensure inter-compatibility.

3. Reconsidering security and maintenance policies

The vulnerabilities of the IPv4 stack are well known, but IPv6 is relatively unknown territory and thorough threat assessment is needed. Organizations must review their security posture as they deploy the new protocols as IPv6 provides new attack vectors that are not always understood.

4. Know your current network infrastructure

IPv6 migration requires knowing what’s actually deployed in the current network. Conduct a thorough analysis of the infrastructure and traffic routing – as you implement IPv6 in each subnet you need to make sure the path to the backbone is fully IPv6 enabled to avoid a broken link. Automated IPv6 network discovery and analysis tools will be crucial.

5. Application compatibility

Applications may not function as expected on an IPv6 network, and should be tested. The changes in the IPv6 stack imply that new TCP layer 4 protocols (TCP6 and UDP6) will be deployed and that could impact some applications. For example, the popular Asterisk PBX only became compatible with IPv6 in late 2010.

6. Updating backend tools

Managing and troubleshooting an IPv6 network requires new, or at least revised, tools. For example, the sheer length of IPv6 addresses, poses problems for some databases. IT managers who failed to check discovered that analyzers and other monitoring tools tend not be IPv6 compatible.

7. Network performance impact

IPv6 header size is doubled over IPv4, increasing to 40 bytes. This affects applications that rely on small packet size. SIP, for example, uses packets around 1000 bytes in length, adding about 2 percent on to the packet size –enough to impact extreme cases.

8. Impact on IPv6 equipment

While most system vendors have an IPv6 implementation strategy, watch out for the performance. The IPv6 protocol is generally supported in firmware, but it is not yet optimized in silicon. Significant deployments of IPv6 will require a hardware upgrade to maintain the level of performance customers and employees expect today.

9. Impact on SPAM tools

SPAM blocking relies on the use of DNS blacklists or blocklists, known as DNSBLs that will not work effectively in IPv6. The limited supply of IPv4 addresses meant listing and blocking a few hundred addresses was simple. With IPv6 hackers can allocate thousands of addresses to a server and jump from address to address for each new SPAM.m Listing IPv6 ranges, isn’t feasible as they are so vast that the caches and DNS servers will overload.

DNS caches prefer to keep the most recent answers, so the flood of DNSBL data will force all other DNS information out of the cache, increasing the load on every other DNS server, re-fetching answers that were flushed out of the cache. Even if the DNSBL servers use a single DNS wildcard record to cover a large range of DNSBL entries, that doesn’t help, because DNS caches can’t tell that a response was created from a wildcard, and so it keeps separate entries for each response. Make sure your SPAM protection vendor has addressed these issues.

What you will need

To avoid the first trap above, you will need robust automation solutions for DNS, IP Assignment (DHCP) and IP Address Management (IPAM), and network change and configuration management in place before you implement and operate IPv6 networks.

IPv6 complicates the traditional tactics of managing the routers, switches and other core devices, and so naming conventions to predict where devices are located and how connected, begin to fail. Solutions are needed to automate the discovery, analysis and management of the network infrastructure as you migrate from IPv4 to IPv6. Also, once decided on your IPv6 migration plan, you need to tools to validate that all router configurations are in line with you plan.

New generation IP Address Management (IPAM) products should provide a dual stack (Pv4 and IPv6) infrastructure for DNS/DHCP service delivery and visual IP Address Management tools for both IPv4 and IPv6 address space allocation and management. Assigning an IPv4 and IPv6 address to a device in the IP number plan should automatically update the DNS and DHCP services accordingly.

Choose the best IPv6-ready solutions and get advice from leading specialists in this field and in five well-planned steps you will avoid the nine fatal traps of IPv6 migration.

Jan Ursi, Technical Director EMEA, is responsible for Presales, Systems Engineering and Professional Services for Infoblox in EMEA. Jan is a well-spoken thought leader in the area of Network Change Management and Network Automation (involving DNS, DHCP, IP Address Management). Throughout his career, Jan has contributed to the growth of new technologies in emerging markets and evangelising the need for Network Automation Management. Before joining Infoblox, Jan was responsible for Systems Engineering at NetScreen Technologies in the BeNeLux. When NetScreen was aquired by Juniper, Jan stayed on to run Presales and Systems Engineering for Juniper in Northern Europe. Jan started his career at Alcatel as Presales Engineer and Solutions Marketing Manager for the broadband access (ADSL) and data backbone technologies (ATM/IP/MPLS). Jan holds a master’s degree in Business Commerce (MBA, Marseille), a PhD in Commercial Science (Uni Brussels) and a technical degree in Industrial Sciences.