F5 Friday: IPv6 Day Redux

We had a successful #IPv6 day – but not everyone was so fortunate. But that’s why you test, isn’t it?

Application delivery controllers, i.e. load balancers, were an integral component in getting ready for World IPv6 Day. As we, as in the Internets, continue to plan a path toward full IPv6 support, they will continue to be a key piece of the migration puzzle regardless of the strategy (dual-stack, translation, tunnels) ultimately chosen.

At F5 we chose to eat our own dogfood and implement what is essentially a “dual-stack” strategy as a means to support IPv6 and thus participate in the testing. Our IT department leveraged BIG-IP LTM and GTM (for DNS) capabilities to ultimately get our IPv6 presence up and running. The details can be found in a case study, published on IPv6 day:

Customers can take advantage of BIG-IP devices’ dual stack capabilities and use their own DNS server to resolve IPv6 requests directly. The IT group used this method for its proof of concept. It configured the BIG-IP 3900 devices for IPv6, assigning them IPv6 virtual addresses that point to www.f5.com web servers—the same physical servers that already host www.f5.com on the IPv4 Internet.

No changes were made to the servers themselves. “We simply added new IPv6 addresses for most of our web properties to our DNS server in BIG-IP GTM and made those addresses publicly available on the IPv6 Internet,” says [Casey] Scott [Network Engineer in the IT group at F5]. Connected to both IPv4 and IPv6 networks, BIG-IP GTM now has valid A records (IPv4) and AAAA records (IPv6) for all F5 web properties, so it can answer DNS queries in either direction—client to server or server to client. For example, when BIG-IP GTM receives an A record request, it hands back an IPv4 address to the client; when it receives a quad-A (AAAA) record request, it hands back an IPv6 address to the client.

“We tested this method using several different IPv6 clients,” says Scott, “and it worked beautifully.” With the exception of links to third-party content available only on the IPv4 network, in all cases, F5 web properties worked as expected using IPv6- only client devices.

-- F5 Enables IPv6 Network Support in Record Time Using Existing F5 Tools, Technologies

Live testing went well, from our perspective – without any of the hiccups. We processed a fair amount of IPv6 traffic to our enabled site, which showed good participation from others as well as clients helping out by poking around. There also seems to be a fair amount of IPv6 activity in general, as our IPv6-enabled presence has not been “quiet” since it first went live – several weeks before IPv6 day was scheduled to occur.

A steady stream of IPv6 traffic is a good sign.

But while F5 experienced a relatively seamless transition to support IPv6 for this live test, many others did not. The NANOG mailing list was full of sites and issues arising from the day, including those arising from – you guessed it – load balancing issues.

Was participating until we hit a rather nasty Load balancer bug that took out the entire unit if clients with a short MTU connected and it needed to fragment packets (Citrix Netscaler running latest code). No fix is available for it yet, so we had to shut it down. Ran for about 9 hours before the "magic" client that blew it up connected.

-- IPv6 Day Non-Participants, NANOG

These bumps in the road to IPv6 were exactly the reason the Internet community at large needed a “live” test, and it’s the reason we’ll need another one. The migration from IPv4 to IPv6 will not happen over night, although it does need to happen more quickly than we may have once assumed given the record time in which depletion of IPv4 occurred. As we – and organizations – begin the move we’ll need more “live testing” days to flush out the bugs and bumps that can only be discovered by processing real traffic coming from real clients interacting with real applications. Lab testing simply isn’t good enough to assure ourselves and you that interoperability and a dual-version environment can be supported.

Just as odd application behavior can sometimes only appear under heavy load, so too is this true for protocols and networking components. Sometimes it’s only under high-load or in response to a request that isn’t specification perfect that we see issues arise that need to be addressed.

We’ll need more of these days in the future, though they will perhaps be less well publicized. Much in the same way NASA shuttle launches have become “old hat”, of real interest only to those keenly following such efforts, one would hope IPv6 “test” days would also become “old hat” over time, until one day we’re all running IPv6 exclusively.

For some astoundingly deep and #geek data regarding the day and performance, take some time to peruse RIPE NCC who is currently compiling data and presenting it in myriad ways as a means to help understand the impact of IPv6 on all aspects of performance.

Published Jun 10, 2011

Version 1.0

availability

design

dynamic infrastructure