As the leader in Application Delivery Networking, F5 has long anticipated the shift to Internet Protocol version 6 (IPv6). In preparation, the F5 IT group recently conducted a proof of concept to demonstrate that the F5 public-facing websites are IPv6 compatible using F5 BIG-IP devices. Another goal of the project was to identify unforeseen challenges that F5 customers might encounter with their own IPv6 efforts.
Although advanced testing continues, initial testing was successful and revealed positive outcomes. For F5 customers, the most significant revelation is that they already have the tools they need to begin making the IPv6 transition—and it doesn’t have to be as painful as industry analysts and IT pundits have led people to believe.
As IPv4 addresses begin to diminish and IPv6 becomes more pervasive worldwide, organizations with a presence on the Internet need to consider how they are going to integrate IPv6 support into their environments.
In many parts of the world, such as Japan, Southeast Asia, Europe, India, and South America, IPv4 addresses are difficult for new enterprises and service providers to obtain. Consequently, organizations in these regions are operating solely on the IPv6 Internet. Similarly, many of the newest smartphones being introduced in the market are IPv6-only devices.
Among the biggest challenges that IPv6 poses is that it is completely incompatible with IPv4—the two protocols cannot “talk” to each other. That means IPv4 and IPv6 networks are entirely separate, and traffic can’t travel from one network to the other without some intervening technology.
As a result, enterprises that have tenaciously held to the notion of “IPv4 only” will ultimately need to support IPv6 or be faced with the potential loss of new customers as their websites and content become inaccessible to these users.
“We provide solutions to help our customers easily integrate IPv6 into their environments, but the IT group at F5 is also an F5 customer,” says Casey Scott, Network Engineer in the IT group at F5. “We need to support IPv6 for the same reasons our customers do—to continue providing consistent services to both IPv4 and IPv6 users.”
The F5 IT group is responsible for www.f5.com as well as web properties for the company’s knowledge base, technical community portal, and employee training and download sites, partner resource center, and more.
“We don’t want to cut off those users from the services that we’ve always provided to IPv4 users. For that reason, we think of our support for IPv6 as an expansion rather than a migration,” says Scott. “Eventually, we will make all of our web properties available on the IPv6 network, but we aren’t abandoning IPv4. It will still be around for some time, and we will continue to support it.”
Like its customers, the F5 IT group has long been addressing the questions of “When?” “Where?” and “How?” to extend support to IPv6 with the least amount of disruption, downtime, and additional infrastructure costs.
The “When?” question proved to be significant because of all the preparation that was required. “Whether you implement IPv6 in a test or production environment, you first need to find a provider for the IPv6 circuit, and your current provider might not be equipped to do that,” says Jon Caples, manager of IT Network Engineering and the IT Dog Food Program at F5.
“Our current carrier in Spokane already supported IPv6 and supplied the cables we needed,” Caples continues, “But it took six months or more for us to find a carrier in Seattle. After you have the circuit, you need to request, obtain, and then allocate your IPv6 addresses, and the paperwork alone can take many months.”
To answer “Where?” to begin the transition, the IT group chose to conduct a proof of concept rather than configure F5 production servers for IPv6. The IT group set up redundant pairs of BIG-IP 3900 devices running BIG-IP Local Traffic Manager (LTM) and BIG-IP Global Traffic Manager (GTM) in its Seattle and Spokane data centers.
The reasons for not using the production network were the unquantifiable risks to existing IPv4 services and bandwidth issues. In Spokane, F5 was able to acquire a 50 megabits per second (Mbps) IPv6 circuit, but in Seattle it is using a 1.5 Mbps T1 testing circuit. “Since we were looking primarily for capability rather than performance, 1.5 Mbps was enough bandwidth for us in the test environment,” says Caples.
“How?” was the easiest question for the IT group to answer? In the data center, a BIG-IP device sits between clients and servers. BIG-IP LTM intelligently manages network traffic between users and applications; BIG-IP GTM provides Domain Name System (DNS) services and enables traffic to be managed across multiple sites.
Because a BIG-IP device is a full proxy device, it can view all interactions between client and server. And because it is dual-stacked, it can understand and handle both IPv4 and IPv6 requests, or it can act as a gateway, translating IPv4 addresses to IPv6 and vice versa. “Many F5 customers aren’t aware that the BIG-IP devices they already own have these capabilities,” says Caples. “That’s especially significant for organizations like F5 that may need to accommodate website visits from IPv6-only devices.”
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 Scott.
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.
“Because we don’t have control over third- party web content, we can’t guarantee that it will work as expected. But this isn’t an F5 problem; it’s a universal problem,” Scott explains. “That’s why it’s so critical for enterprises to understand that until they make their websites and content available on IPv6, neither will be reachable by IPv6 users, either directly or as a referenced URL.”
He continues, “This could have significantly negative financial effects on vendors of business partner and software-as-a-service (SaaS) applications as customers begin to drop their IPv4 only solutions in favor of those that operate on IPv6.”
Although advanced testing will continue, the IT department’s IPv6 proof of concept was a success and has already identified clear benefits that F5 customers can quickly realize in their own environments.
IPv6 is creating a whole new set of customers. A vast new market is emerging worldwide that enterprises can’t afford to ignore. For F5 customers, the good news is that they can quickly establish a presence on the IPv6 network to address this new market using the same F5 technology, tools, and methods that they are using today.
“By making BIG-IP devices addressable on the IPv6 network, F5 is enabling its customers to reach out to this new market immediately,” says Scott. “The beauty is that they don’t need to make any changes to their production servers or networks to establish that IPv6 network presence.”
Once the initial planning is complete and IPv6 addresses are allocated, deployment of BIG-IP devices on the IPv6 network is very quick. “The process of setting up the BIG-IP devices and establishing a presence on the IPv6 network took only a few hours, and it required no additional training for the IT staff, which would have been necessary with a third-party solution,” says Scott.
In addition, when all testing is completed, the IT group will repurpose the BIG-IP 3900 hardware it used in each data center, so Spokane data centers, we will begin moving our production servers to IPv6 in this way,” says Scott.
For huge enterprises such as content providers, financial institutions, and web monsters, the process of supporting IPv6 will understandably be more complex. The differences of scale alone will magnify the third-party content challenges.
That’s because large organizations are often highly dependent on third-party applications and services such as payroll processing, subscriber billing, content delivery, and CRM, SaaS, and application service provider vendors. These applications can be very particular about how and when other elements and processes such as firewalls, TCP and WAN optimization services, caching, and compression are configured and implemented.
The business logic required to orchestrate all the moving parts will present more complex challenges for these organizations.
For F5 customers, however, small and large, the news is good. “The BIG-IP devices are actually the easiest part of the ‘IPv6 equation’ to solve,” says Scott. “It’s really no more complicated than adding a new van to the infrastructure.” F5 TMOS, the foundation for all BIG-IP products, is what makes this possible.
BIG-IP devices can handle both IPv4 and IPv6 whether on the client side or the server side.
“That’s the beauty of BIG-IP being a full proxy server that already operates internally on IPv6. Ultimately, providing IPv6 support will be a two to three year roadmap for most vendors. F5 is ahead of the game because we’re building on a solid foundation that’s already native IPv6.”