A practical approach for IPv4 to IPv6 migration

No one really believes that the Internet is going to collapse overnight when we run out of IPv4 addresses later this year, but the media and some vendors selling IPv6-specific products might have you think as much with all the apocalyptic stories of late.

When IPv4 was created, it allowed for over 4 billion addresses – and that seemed fairly generous in a world of 6 billion people when an IP address equated to a single computer. For years after that, IPAM (IP address management) was no big deal for the smaller enterprise. Even when each desk had its own PC, you could often keep track of the company’s addresses on a simple spreadsheet.

But then came the IP phone, and the laptop, and the PDA, and the smartphone; the number of IP addresses on the corporate network was multiplying year after year. Add to that applications such as burglar alarms, secure entry systems, smoke detectors and other functions that used to run independently but increasingly migrate onto the network, and IPAM is becoming a serious issue for even quite small organisations.

Virtualization adds to the pressure: while a new virtual server may take less than a minute to set up, setting up a new virtual server’s IP address manually could take thirty to forty minutes and the technician callout could take days to arrange, because finding an appropriate IP address and tying it to a specific host requires sifting through Excel spreadsheets and cross-departmental communication to find a valid IP address.

Completing the task can also involve many different groups: the DHCP admin to add a DHCP reservation for the new VM, the DNS admin to add A and PTR records for the new VM, and so on.

Automating the network infrastructure functions – like assigning, tracking and managing IP addresses – is no longer just for global corporations; it is becoming a vital necessity for any medium to large company. IPv6 adds a new level of complexity with its longer IP addresses and the interim need to run both IPv4 and IPv6 in parallel.

IPv6 underscores that the founders of the Internet missed one key element about the future: any time you try to guess how big something will be, you are always off 100-fold at the very least. The Internet won’t stop as a result, it will morph as it always has. If you have the right tools, you will ride the IPv6 wave and see the benefits with little pain.

Embracing change is something we should all get used to as the days of static and dumb networks are numbered. IPv6 underscores just one component of change, and accelerates the need for automation, especially as virtualization and the cloud are quickly adopted in the enterprise.

Why Upgrade to IPv6?

The exhaustion of IPv4 addresses does not spell the death of IPv4, but the beginning of its long, slow decline. For the foreseeable future we’ll be running both IPv4 and IPv6 protocols and using transition technologies to move between the two.

Any organization that relies on the Internet must be prepared to manage the two protocols in parallel, serving their old IPv4 customers and partners, while taking on early IPv6 adopters and new business. This means a whole new level of complexity for managing some core network infrastructure services, including handling two types of addresses, longer IPv6 addresses and the added burdens of dual usage.

In the fast-moving world of information technology, early adopters pay a price for the advantages they reap. Internet usage took off in the West and IPv4 was thoroughly established there. So, if a company’s customer base is predominantly in Europe and the US, there is not much incentive to support IPv6. It is the tiger economies of developing countries where the new protocol is being adopted quickly. Though, interestingly, the Vatican is understood to be the only nation fully IPv6 ready – suggesting some divine insider knowledge, maybe?

So Western organisations that do nothing may have the economic advantage in the short term. But once the requisite infrastructure is in place and certain applications and users of IPv6-only-enabled devices have only limited access to a company’s resources – say an eCommerce presence – all will recognize the advantages of the new technology and will migrate in larger numbers. Eventually, the new technology will be the standard and IPv4 will be seen as a curiosity.

It does not mean that a company running IPv4 won’t be able to install any new devices, because there are workarounds available, including translation techniques like Network Address Translation (NAT). NAT (Network Address Translation) means that IPv4 addresses already in use elsewhere can be used within a network, and translated to a unique IPv6 address outside the network. As a message comes into the network, the NAT server translates that unique IPv6 address into the internal IPv4 address, and vice versa as a message leaves the network.

So it might appear that there is no need ever for any organisation to bother with the new protocol, as long as their provider performs NAT. In practice, however, NAT adds latency, another point of failure and, more importantly, some services simply do not work through NAT. The Internet connection is there, but the service offering will be degraded. In the long run, those who do not take up the IPv6 challenge will suffer a throttled-back service. In the move to cloud computing, that disadvantage will grow very serious.

Peparing for the Transition to IPv6

What does it mean to be IPv6-ready in an organisation? It means spending money, including training network staff to handle IPv6 configuration and troubleshooting, plus modifying applications that use IP addresses. If most of your contacts still have IPv4 addresses or are happy with NAT, this won’t provide immediate return on investment. Ignore the problem, however, and sooner or later you’ll be forced to take action to remain competitive.

After recognizing the return on investment might not be immediate, a plan needs to be developed taking key migration considerations into account:

  • Security policies need to be revised. While IPv4 security issues are well documented, IPv6 remains largely unexplored.
  • Application compatibility needs to be verified. Not all existing applications are IPv6 compliant; upgrades may be required.
  • IPv6 compatibility in networking equipment often comes with added risks. Unlike IPv4, several IPv6 implementations are still to be optimized, and they may not have been used long enough for their reliability to be confirmed.
  • Backend tools are still lacking. Current management and troubleshooting tools and methods may not work with IPv6.
  • Testing IPv6 services for compatibility. There are still not enough implementations to test against.

These considerations are non-trivial. When, for example, revising security policies, the firewalls will need to be updated to recognise both IPv4 and IPv6 – because a firewall that does not recognise IPv6 addresses could simply pass such packets blindly through.

There are also IPv6 tunnels that allow IPv6 packets to be encapsulated inside IPv4 packets – unless protected by deep packet inspection, this could provide another risk. Such IPv6 security issues will need to be addressed, especially when many customers will still be on legacy IPv4 networks while others will have transitioned to IPv6.

Your network management systems (NMS) will need to be upgraded for IPv6, where the address fields are larger, the databases bigger and both IPv4 and IPv6 devices will be shown in the user interface. If your NMS is not ready for IPv6 it will need to be replaced.

The bottom line is this: managing the transition to IPv6 is a complex task, and therefore prone to human error unless supported by automation. The right automated network management system will not only address NMS issues, but also greatly reduce the impact of the other costs by reducing problems, simplifying and making network management more transparent.

Managing the transition

Bearing the above considerations in mind, you need to build a transition map, breaking the project into clear stages. Before initiating fundamental changes it would be advisable to set up some form of IPv6 testbed to familiarise your IT team.

Then you can begin by setting up external facing servers that support IPv6: web, name and mail. Next, you need to configure your core routing infrastructure to route IPv6. Only then are you ready for the full conversion process. This will require first identifying which servers and services can run over a dual stack, deciding which transition technology is most appropriate for ensuring access to the others.

IPv6

The above diagram summarizes the process. Taken step by step and carefully planned, it is not as formidable as it might sound. What’s more, Infoblox has already developed a range of tools to help IT teams manage a seamless transition. These embrace: DNS AAAA records for IPv6 DNS resolution; IPv6 IP address management for simplifying the complex tasks of managing IPv6 subnets and IP address allocation; IPv6 address planning; automation of IPv6 network change; and configuration management to ensure that the IPv6/IPv4 network remains secure and compliant.

Conclusion

It’s a tough call for the network management team. Ignore the IPv6 panic and concentrate on business as usual, and you will for a while save money. Only with time will your business begin to suffer the degradation of poorer Internet access, limited accessibility to your business by users worldwide, and risk being left behind.

At some point before that happens, it is better to ”grasp the nettle” and start planning a transition as suggested above.

Meanwhile – if you are still depending on manual processes like Excel spreadsheets for managing IP addresses and antiquated systems for delivering DNS services – you should grab the opportunity to automate your core network services and ensure the most seamless transition to the future.

Dirk Marichal has more than 15 years of successful sales and marketing management experience in the technology industry in Europe. He joined Infoblox four years ago as the Benelux country manager before moving to the role of regional director for Northern and Southern Europe. Before joining Infoblox, Dirk was a Benelux country manager at Juniper Networks and NetScreen Technologies (acquired by Juniper in 2004). He also built his sales experience as a Sales Director at Mobistar in Belgium. He holds a B.A. degree in Economics and International Business Administration, Antwerp University.