Page 2 of 2
IN DEPTH: IPv6: Dual-stack strategy starts at the perimeter
Remember, your goal in this phase is simply to enable your customers and the general public to stay connected to you. If your DNS servers can return an IPv6 record to an IPv6 client, then you’ve accomplished that goal — without making any infrastructure or application changes.
Phase II: Consider the core network, protecting your Web applications and network resources.
Passing traffic through a gateway means you lose the ability to see the source IP addresses of client devices, so you need to take into account the capabilities of your security tools. To guard against DoS, DDoS, SQL injection, cross-site scripting and myriad other security threats, you already use a variety of security tools such as firewalls, proxies, IDS/IPS, authentication services and antivirus software. Ideally, those same tools should be IPv6-aware so you can use them to see the unique client information of IPv6 devices, whether they’re connecting from outside of your organization or from within your network. [Also see: “Hackers target IPv6”]
Thankfully, some security vendors’ products already support IPv6; others are moving in that direction. Solutions that support both protocols are preferred because they eliminate the need to add more point solutions in your environment. If your current solutions don’t support IPv6, you can either wait for them to catch up or find new tools that enable you to provide the same level of protection on IPv6 that you’re currently providing on IPv4.
In any case, leveraging your ADCs to help you proxy IPv6 traffic is still a valid solution that enables you to accomplish your goal while avoiding architectural changes to your infrastructure and applications.
Phase III: Connect employees to corporate resources.
No doubt your organization provides remote access solutions (such as SSL VPN) so employees can easily access IPv4-based corporate resources from outside the company. These solutions are especially important for mobile workers who provide direct support to your current IPv4-based customers.
As more of your customers move to IPv6, however, your remote access solutions must also support IPv6 so that employees can continue providing the best possible customer service. The ideal solution would let you assign new virtual IPv6 addresses to the hosting servers and then simply make the clients aware of them. This would enable employees to reach any internal resource they need, regardless of where they are located, the type of network access that’s available, or the type of device they’re using.
What’s important to note here is that your security requirements don’t change, so you want a solution that enables you to apply the same access policies to IPv6 that you currently use for IPv4. Again, the idea is to provide remote access for IPv6 with minimal administrative overhead. If your existing solution can get you there, that’s always preferred to adding new point solutions.
Phase IV: Enable optimized site-to-site communication on IPv6.
While SSL VPN is great for providing secure client access, it’s not the appropriate solution for connecting physically separate sites, teams or business units. Instead, a site-to-site communication solution gives remote teams a secure, high-speed tunnel through which they can connect and share resources directly without relying on a PC or workstation to have network access.
Today, few ISPs provide direct site-to-site circuits on IPv6, but the list is growing. If your current solution supports both IPv4 and IPv6, so much the better as that will likely save you time and administrative overhead. Your objective is to enable your employees to work on IPv6 the same way they do on IPv4 today. Preferably, the solution would enable you to replicate data, back up and recover systems, mirror virtualized applications — all the same types of activities you use site-to-site communication for today on IPv4.
Phase V: Tackle legacy applications and backend systems.
The final, pesky challenge many organizations worry about is how to deal with their legacy applications — those backend behemoths that will never support IPv6 directly. In fact, these systems should be the least of your worries. It will be nearly a decade before IPv6 takes full center stage from IPv4. By then, you might have replaced these systems. If not, you will have done everything necessary to make your infrastructure hum along beautifully on IPv6. For the few remaining IPv4 stragglers, proxying traffic will still be a legitimate solution, so get ready to circle back to Phase I.