Top Five Considerations for Enabling IPv6 Support on Your Application Delivery Controller
As we approach the much talked about World IPv6 Launch on June 6th, 2012 it is important to help as many as possible do what is needed to prepare their own Internet Edge to not only participate in the launch but also to ensure business continuity regardless of which IP version is used. Start now so you don’t have to rush your deployment at the end.
There are important first steps to take before you ever type the first command or click the first check box on a product. Important stuff like a gap analysis on what you can and cannot support as well as what your provider supports IPv6-wise, what your address plan will look like and other considerations. Luckily Cisco has either written a document or a blog on many of these topics. Recent blogs include:
- “Integrating IPv6 Into Your Network: Five Steps for Building Your IPv6 Address Plan” – by Jim Bailey
- “Taking Advantage of World IPv6 Launch: Practical ways to add more IPv6 to your network” – by Phillip Remaker
- “Deploying IPv6 in the Internet Edge” – by yours truly, Shannon McFarland
Given that we are just shy of a month away from World IPv6 Launch, I wanted to blog on the top considerations for enabling IPv6 support on one of the most important components of any Internet Edge design, the Application Delivery Controller (ADC) or more commonly known as a Server Load Balancer (SLB).
If you are serving web content of most varieties, you are using an ADC/SLB to front-end those web servers. We use ADC/SLB products to serve important functions that include but are not limited to:
- Traffic load distribution
- TCP Normalization
- Server/Application Health Monitoring
- Reverse Proxy
Guess, what? We need all of these and more (stuff I did not list) in both IPv4 and IPv6. In the most pure form of SLB, most products on the market, including the Cisco ACE 4710 Appliance and ACE 30 Module, support the servicing of IPv4 (called SLB44) and IPv6 (SLB66). Basically, the incoming version of IP is matched with the back-end (server-facing) version of IP (i.e. Incoming packet from Internet client is IPv6 and back-end connection from ADC to web server is IPv6).
For the most part, the design considerations for ADC/SLB products are the same between IPv4 and IPv6 but there are times when you have a unique deployment requirement that may actually dictate the translation or mapping between both IP versions. We call this SLB64, where incoming connections on the Internet are IPv6 but we have to map or reverse proxy these connections to a back-end IPv4-only resource. Thankfully, the Cisco ACE can support all of these functions (SLB44, SLB66, SLB64).
Top Five Considerations
If you are deploying your ADC/SLB for IPv6 service, be sure to:
- Use SLB66 whenever possible – Your number one goal should be to have a top-to-bottom dual stack deployment in your Internet Edge to gain maximum performance, high availability and native protocol visibility (for security and logging)
- Treat your load-balancing and SSL-offload policies much the same between IPv4 and IPv6 – For the most part your Layer 4 and Layer 7 policies will look much the same between versions but study and implement any special security policies that may apply specifically to IPv6
- Don’t forget the importance of logging – Many people will deploy IPv6 and forget the most basic functions they have enabled for IPv4 such as X-Forwarded-For (XFF) header insertion and logging
- If using SLB64 do so only for a short period of time – Translation/Reverse-Proxy use is like a drug: easy to do, you are instantly hooked and it is hard to get away from and SLB64, Stateful NAT64, Apache Reverse-Proxy all fall into this category and can inject latency, reduce availability and obstruct native protocol visibility
- Don’t shortcut your deployment – If you cannot build an IPv6-enabled Internet Edge that supports near-IPv4 performance, availability and security then don’t even start as in most cases when a client has IPv4 and IPv6 access and name resolution, IPv6 wins and you don’t want the user to suffer from your bad IPv6 implementation
This list is by no means exhaustive but over the last year of dual stack deployments on the Cisco ACE, these seem to be the most common things people are either wildly successful at or forget completely about until they go live and the client user experience suffers.
How to get it done
The technical details on how to deploy your Cisco ACE to support full dual stack (SLB44/SLB66) or, for a short time, support a reverse-proxy approach (SLB64) are included in my Cisco Validated Design (CVD) “Deploying IPv6 in the Internet Edge“. In the CVD, you will find details on configuring the Cisco ACE to support SLB66 and SLB64 and address the top considerations listed above.
In the coming weeks there will be several blogs from Cisco that will provide you with practical guidance on preparing for World IPv6 Launch. Stay tuned to blog posts on http://blogs.cisco.com/ and the Cisco Support Community page dedicated to IPv6 Integration and Transition.
Start now so you don’t have to rush your deployment at the end. Remember, user experience and business continuity are your goals for IPv6 deployment in the Internet Edge. If you plan and deploy poorly then the user will suffer and that may mean a direct impact to your business.