Combat is pleased to have Lori Mac Vittie, Technical Marketing Manager join Combat Networks this week as a guest writer to dicuss IPV6. How are you preparing for IPV6?
Reasearchers have moved the IPV4 end date to 2012, and are urging carriers and public facing organizations to begin supporting IPV6. How does this affect you and your business? and what can you do to ensure compliancy while reducing complexity? Lori answers these and many more in our feature article!
Thanks for taking the time to share your knowledge Lori!
/Combat Networks
Making the switch from IPv4 to IPv6 is not a task anyone with any significant investment in infrastructure wants to undertake. The reliance on IP addresses of infrastructure to control, secure, route, and track everything from simple network housekeeping to complying with complex governmental regulations makes it difficult to simply “flick a switch” and move from the old form of addressing (IPv4) to the new (IPv6). This reliance is spread up and down the network stack, and spans not only infrastructure but the very processes that keep data centers running smoothly. Firewall rules, ACLs, scripts that automate mundane tasks, routing from layer 2 to layer 7, and application architecture are likely to communicate using IPv4 addresses.
IT’S NOT JUST LENGTH THAT MATTERS
The differences between IPv4 and IPv6 in addressing are probably the most visible and oft referenced change, as it is the length of the IPv6 address that dramatically expands the available pool of IP addresses and thus is of the most interest. IPv4 IP addresses are 32-bits long while IPv6 addresses are 128-bits long. But IPv6 addresses can (and do) interoperate with IPv4 addresses, through a variety of methods that allow IPv6 to carry along IPv4 addresses. This is achieved through the use of IPv4 mapped IPV6 addresses and IPv4 compatible IPv6 addresses. This allows IPv4 addresses to be represented in IPv6 addresses.
| Traditional IPv4 Address | IPv4 Compatible IPv6 Address | IPv4 Mapped IPv6 Address |
| 192.168.0.1 | ::192.168.0.1 | ::ffff:192.168.0.1 |
But the real disconnect between IPv4 and IPv6 is in the differences in their headers. It is these differences that cause IPv4 and IPv6 to be incompatible. An IPv4 packet header is a fixed length, 40 bytes long. An IPv6 packet header is variable length, and can be up to 60 bytes long. Traditional IP “options” are carried within the IPv4 header, while in IPv6 these options are appended after the header, allowing for more flexibility in extended options over time. These differences are core to the protocol and therefore core to the packet processing engines that drive most routers and switches. Unless network infrastructure is running what is known as a “dual stack”, i.e. two independent networking stacks that allow the processing and subsequent translation of the two protocols, the infrastructure cannot easily handle both IPv4 and IPv6 at the same time.
INVESTMENT and RISK of MIGRATION too HIGH
This makes the task of migrating a massive effort, one that most organizations have continued to put off even though the dearth of IPv4 addresses grows every year. Experts now estimate that public IPv4 addresses will be depleted by the year 2012, which makes it imperative that service providers, hosting companies, and cloud computing providers migrate sooner rather than later or risk being unable to provide services to customers.
David Meyer of ZDNet recently brought this issue to the fore (again) in “IPv4 addresses: Less than 10pc still available” noting that there is little impetus for organizations to make the switch from IPv4 to IPv6 despite continued depletion of IPv4 addresses:
IPv4 and IPv6 addresses are not compatible. Pawlik [NRO chairma] said it was technically feasible to make the two types of IP address talk to each other, but it would be best for companies and ISPs to switch to IPv6 as soon as possible, to keep networks stable and avoid complexity when IPv4 addresses run out.
…
Pawlik also conceded that many businesses are putting off the switch to IPv6 because, even when all public IPv4 addresses have been allocated, they will continue to be able to allocate private IPv4 addresses internally. However, he stressed that anyone running public-facing websites will have to make their sites visible as IPv6 addresses, as their users will be on IPv6 addresses in the future.
It is the organizational reliance on IP addresses in the network and application infrastructure and how thoroughly permeated throughout configurations and even application logic IP addresses are that make Pawlik’s statement quite true. Because organizations can continue to leverage IPv4 internally – and thus make no changes to its internal architecture, infrastructure, and applications – it is unlikely they will feel pressure to migrate. The effort associated with the changes required to migrate along with the possible requirement to invest in solutions that support IPv6 make it financially difficult for many organizations to justify, especially given that they can technically continue to utilize IPv4 internally with very few ramifications.
But as Pawlik also points out, externally it is important to make that migration as more and more users are migrated off of IPv4 and onto IPv6 by service providers. The ramifications of not migrating public facing services to IPv6 is that eventually those services will be unreachable and unusable by customers, partners, and users who have made the move to IPv6.
HAVE your CAKE and EAT it TOO
There are a variety of ways in which both IPv4 and IPv6 can be made “compatible” from a data center networking point of view. Tunneling IPv6 via IPv4 to allow individual hosts on an IPv4 network to reach the IPv6 network is one way, but requires that routers are able to be configured to support such encapsulation. Hybrid networking stacks on hosts makes the utilization of IPv6 or IPv4 much simpler, but does not necessarily help routing IPv6 through an IPv4 network. Most methods effectively force configuration and potentially
architectural changes to support a dual IP version environment, which for many organizations is exactly what they were trying to avoid in the first place: disruptive, expensive changes in the infrastructure.
There is a way to support IPv6 externally while making relatively no changes to the organizational network architecture. An IPv6 gateway can provide the translation necessary to seamlessly support both IPv6 and IPv4. Employing an IPv6 gateway insulates organizations from making changes to internal networks and applications while supporting IPv6 clients and infrastructure externally. 
The right IPv6-enabled solution can also help with migration internally. For example, an enabled application delivery controller like F5 BIG-IP LTM (Local Traffic Manager) can act as an IPv4 to IPv6 gateway, and vice-versa, by configuring a virtual server using one IP address version and pool members using the other version. This allows organizations to mix and match IP versions within their application infrastructure as they migrate on their own schedule toward a completely IPv6 network architecture, internally and externally.
For more complete data center enablement, deploying a gateway such as F5’s IPv6 Gateway Module can provide the translation necessary to enable the entire organization to communicate with IPv6 regardless of IP version utilized internally. A gateway translates between IP versions rather than leveraging tunneling or other techniques that can cause confusion to IP-version specific infrastructure and applications. Thus if an IPv6 client communicates with the gateway and the internal network is still completely IPv4, the gateway performs a full translation of the requests bidirectionally to ensure seamless interoperation. This allows organizations to continue utilizing their existing investments – including network management software and packaged applications that may be under the control of a third party and are not IPv6 aware yet – but publicly move to supporting IPv6.
THERE’S NO REASON NOT TO SUPPORT IPv6
The urgency with which NRO chariman Pawlik speaks on the subject of IPv6 is real. There is an increasing number of users accessing the Web via mobile devices, and it is in the telco and service provider markets that we see the most momentum toward mass adoption of IPv6.
IDC also reported in its new Marketplace Model and Forecast report that more than a quarter of the world’s population, or 1.6 billion people, used the Internet in 2009 on a PC, mobile phone, video-game console, or other device. By 2013, that number is expected to rise to 2.2 billion.
– InformationWeek, “1 Billion Mobile Internet Devices Seen By 2013”
The rapid increase in mobile devices, each which will eventually require their own IP address, is driving providers to adopt IPv6 as they build out their next generation networks to support a massive subscriber base. Unless organizations adopt a strategy that includes supporting IPv6 at least externally, it is likely that they will begin to experience fewer and fewer visitors and customers as more people worldwide adopt, albeit unknowingly, IPv6.
Supporting IPv6 can be a fairly simple exercise that incurs very little costs when compared to a complete architectural overhaul of the data center. There’s just no good reason to ignore the growing need, and about 2.2 billion good reasons to do something about it sooner rather than later.
