This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.
Remember when you were a kid and you got so tired of your parents nagging you to clean your room, you finally just stopped listening?
It's kind of that way with IPv6.
IT departments are weary of hearing how they urgently need to move to IPv6 because IPv4 addresses aren't available anymore. The truth is, many U.S. companies still have enough IPv4 addresses to last them several years, so no problem, right?
Wrong. Here's the catch: Three-quarters of the world is already embracing IPv6 because IPv4 is not an option for them. That means if your company doesn't support IPv6, inevitably your public-facing, IPv4-based Web properties and content will be unreachable by a significant portion of your customers, suppliers, partners, vendors and contractors.
IN THE NEWS: Europe's supply of IPv4 addresses nearing depletion
Now, that is a problem -- especially if your company expects to provide a consistent level of B2B service and continue growing globally. I don't know any IT pro who wants to answer to shareholders for lost revenue because the company didn't take IPv6 seriously.
Still, when it's questionable whether an IPv6 initiative will significantly increase your bottom line in the near term -- say the next two to four quarters -- it's tough to justify bumping it to P1 status.
The good news is, you don't have to. With careful planning, most enterprises can gradually integrate IPv6 without spending a lot of money, consuming a lot of IT resources, or disrupting day-to-day operations.
Of course you'll need to lay the initial groundwork -- obtain your IPv6 address range, arrange to get IPv6 circuits from your ISP, determine how you want to allocate addresses, and so on. If you haven't taken these steps yet, you're already behind the curve. Do it now. This part of the process can take a lot longer than you think. When you're ready to draw up your implementation plan, consider taking the following phased approach.
Phase I: Put your focus where it matters: on customers and the general public.
As your global customers, vendors, partners and suppliers move to IPv6, your initial goal is to enable clients -- whether individuals or businesses -- to connect to your website. These people must be able to reach you to continue doing business with you. Today, 90% of them might operate on IPv4, but it's only a matter of time before you need to work with a supplier or manufacturer in India or China that can only operate on IPv6.
If you use dual-stacked application delivery controllers (ADCs) to manage traffic to your Web servers, you can accomplish this step making few if any changes to the servers themselves. ADCs that understand both IPv4 and IPv6 can be used as gateway devices to proxy IPv6 traffic to IPv4. Assign your ADCs the new virtual IPv6 addresses and have them point to your existing IPv4-based Web servers. Then, add those new IPv6 addresses to your DNS server and make them publicly available on IPv6 to establish your presence on the IPv6 Internet. Your ADC devices will continue handling requests from IPv4 clients as usual, but they will also be able to serve requests from IPv6-only clients, directing them to your existing IPv4-based Web servers.
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.
After that, go clean your room.
Read more about lan and wan in Network World's LAN & WAN section.