I pv6 whitepaper

IPv6: What the Transition Means for Content and Application Delivery

White Paper

Table of Contents

INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

WHAT IS IPV6? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

The IPv6 Timeline 2

Are there viable alternatives to IPv6? 3

IPv6 adoption status 4

HOW DOES IPV6 AFFECT WEB CONTENT AND APPLICATION DELIVERY? . . . . . . . . . . . . . . . . 5

IPv6 is not backward compatible 5

Challenges of delivering content in a hybrid Internet 6

AKAMAI: HELPING OUR CUSTOMERS MAKE THE IPV6 TRANSITION . . . . . . . . . . . . . . . . . . . 8

Under the covers: Key areas of Akamai IPv6 development and innovation 8

Akamai’s IPv6 services: Simplifying the transition 10

CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

IPv6: What the Transition Means for Content and Application Delivery 1

IntroductionOver the next few years, the Internet will undergo a significant architectural change as its core network layer protocol, Internet Protocol version 4, or IPv4, is replaced by Internet Protocol version 6, or IPv6. This protocol upgrade is necessary to support the continued growth of the Internet. The transition period will take years, and the Internet will endure considerable bumps and bruises along the way.

In particular, many of the IPv6 transition technologies that are being deployed, as well as the fragmented state of the current IPv6 Internet, will create problems for Web-enabled businesses as they try to reach their audiences across a hybrid v4/v6 Internet. While it is not difficult to support IPv6 end users nominally, it can be far more challenging to do so with the levels of performance and reliability users and online businesses have come to expect.

This whitepaper aims to help organizations understand how the IPv6 changeover will impact their Web sites, and how Akamai can help them make the transition as simply and successfully as possible. We begin with an overview of IPv6, including the growing impetus for it as well as the lack of viable alternatives. We then look at how the IPv6 transition affects content and application delivery, and examine the challenges Web sites will face in trying to provide high quality experiences to their end users. Finally, we present a phased plan for the support of IPv6 within Akamai’s service portfolio, which aims to enable broader IPv6 adoption by making it easy for companies to overcome these challenges. With Akamai, IPv4 sites will be able to take advantage of high performance, high availability IPv6 delivery without making any changes to their origin infrastructures.

What is IPv6?Internet Protocol (IP) is the core network layer protocol upon which the Internet is built. The current version of the protocol, IPv4, has been in use since the origin of the Internet. IPv6 (formerly known as IPng or IP next generation) is the version designed to succeed IPv4.1

The chief motivation for revising the existing protocol is the anticipated depletion of the IPv4 address space. With its 32-bit addresses, IPv4 allows for 2^32, or approximately 4 billion, unique IP addresses

— a number that seemed sufficiently large when put into place in 1977, but is now clearly no longer big enough.2 Today, there are already an estimated 2 billion Internet users worldwide3, and the num-ber of Internet-accessible devices continues to explode as users connect in growing numbers of ways

— by tablet, mobile phone, set top box, and entertainment console. IP address demand growth will also come from new applications and innovations, including always-on appliances used in utility grids, smart homes, health care monitoring, and intelligent sensor networks — the possibilities are nearly limitless. Industry forecasts estimate there will be as many as 50 billion connected devices in less than ten years.4

IPv6 increases address lengths to 128 bits, allowing for 340 undecillion (or 340 trillion trillion trillion) addresses — supporting an effectively unlimited number of connected devices. To visualize the differ-ence in scale, if the IPv4 address space were the size of a golf ball, the IPv6 address space would then be close to the size of the sun.5 If you allocated 1 trillion IPv6 addresses per second, it would take more than 10 quintillion years to run out, or more than 700 million times the age of the universe.


The IPv6 Timeline

IPv6 has been around for almost two decades. Initial IETF discussions began around 1992, and the first IPv6 specification (RFC 1883) was published in 1995 and updated in 1998 (RFC 2460). The first public allocation of IPv6 addresses occurred the following year. Over the past decade, support for IPv6 has been added to many operating systems and applications, and it has seen deployment in some specialized environments. However, without a pressing reason or clear business case to move to IPv6, adoption on the broader Internet has been negligible—at least until very recently, when the depletion of the IPv4 address space became clearly imminent.

IP address space distribution is managed at a global level by the Internet Assigned Numbers Authority (IANA), which allocates both IPv4 and IPv6 address blocks to the five Regional Internet Registries (RIRs). Each RIR is responsible for distributing IP blocks, based on demonstrated need, among local registries in its own region of the globe. These local registries are generally Internet service providers who then provide addresses and connectivity for their customers.

As of December 2010, approximately 2% of the available IPv4 address space remains unallocated at IANA. Based on the depletion rate over the past decade, this means IANA will run out of addresses by mid-year 2011, if not sooner. The majority of RIRs will then have an estimated store of six months to a year of addresses before facing depletion themselves.7 Thus many predict that most ISPs will run out of IPv4 addresses for new customers some time in 2011 or 2012. Past this point, IPv4 addresses will move from being a nearly free commodity to being a constrained resource that can limit growth, result in additional expenses, or require performance-impacting approaches to conserve.

Figure 1: Remaining (Unallocated) IPv4 Address Space, 2000-20116

05

1015202530354038%

36%34%

32%30%

26%

22%

17%

13%

9%

2%

0%

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011

40

35

30

25

20

15

10

5

0

Year

Rem

ain

ing

IPv4

Ad

dre

ss S

pac

e (%

)


This exigency has brought a flurry of IPv6 activity over the last several years. In September 2010, the U.S. government mandated that all federal agencies make their public facing services IPv6-reachable by 20128, raising the bar on a previous mandate to support IPv6 traffic on their backbone routers by June 2008. Access providers, who face the most immediate repercussions of address space depletion, are also moving forward aggressively. A recent European Commission-funded survey found that nearly a third of ISPs now offer IPv6 services to their business customers, and 60% intend to offer services within a year.9 In the United States, T-Mobile, Comcast, and Verizon FiOS have all launched IPv6 end user trials. Verizon Wireless has mandated IPv6 support for all LTE10 devices — with IPv4 support optional. Meanwhile, NTT Communications in Japan began trialing IPv6 services back in 1996 and began their global launch of commercial services nearly 10 years ago.

Currently, however, the percentage of IPv6 Web traffic is still very low — estimates range between 0.25% and 2%.11 End user adoption is hindered both by lack of awareness and a dearth of available content and services. In addition, it faces hurdles such as the lack of IPv6 support in many home wireless routers — potentially requiring the replacement of millions of these devices. But as access providers, particularly those in fast growing markets such as Asia and the mobile space, run out of IPv4 addresses and begin provisioning IPv6 customers wholesale, adoption patterns could change rapidly. T-Mobile USA, for example, expects that 50% of their traffic will be native IPv6 by the end of 2011.12 And on the desktop, over 90% of the installed base of operating systems is IPv6-capable, while the latest operating systems — Microsoft Vista, Microsoft Windows 7, Apple Mac OS X, and all major Linux distributions — have IPv6 enabled by default.13 This means conditions are ripe for IPv6 adoption to soon reach its tipping point.

Are there viable alternatives to IPv6?

A number of strategies have been adopted by network operators in an effort to delay address depletion and thereby prolong the life of IPv4. Approaches include trying to recover allocated but unused addresses or trying to purchase IP blocks on a limited secondary market. Both of these approaches have associated costs and risks, and ultimately provide only very short term relief as depletion continues at a rate of roughly 16 to 20 million IP addresses per month.14 With global Internet adoption continuing at a rapid pace the roughly four billion addresses available in IPv4 simply are not sufficient.

Perhaps the most popular approach to conserving IPv4 addresses relies on the use of NAT, or Network Address Translation. NAT comes in several flavors and involves mapping one set of IP addresses to another; it is commonly used to enable multiple devices within a single home or small office network to be mapped to a single public IP address provided by an ISP. More recently, broadband and wireless access providers have begun deploying the same technology within their own networks, where it is referred to as Carrier Grade NAT (CGN) or Large Scale NAT (LSN). Here, it can be used to map dozens of different users (thousands of user sessions) to a single public IPv4 address by using 16-bit port numbers to distinguish between them.15

Unfortunately, this many-to-one IP mapping creates numerous complications. Applications that rely on differentiating end-users by IP address may simply stop working effectively, including VPNs, VoIP, peer-to-peer, geo-location, and IP blacklisting/graylisting/whitelisting (used to prevent spam, fraud, and other abuses). These problems are exacerbated when communications span several NATs — such as the end user’s home NAT, the end user’s ISP CGN, and then the destination network’s CGN.


Infrastructure Readiness Metrics

• As of December 2010, only about 7.9% of networks (ASes) advertise IPv6 support. However, this is up significantly from 5.5% reported in early 2010.16

• As of March 2010, 22% of transit networks support IPv6, double of March 2009. This number is projected to reach 80% by 2013.17

• Roughly 25% of the current installed base of operating systems has IPv6 enabled by default, while 90% is IPv6-capable.18

Adoption Metrics

• In roughly 8 months (ending December 14, 2010), the number of Web sites in the global top 500 supporting IPv6 grew 83%, from 2.4% to 4.4%.19

• Several sources note that IPv6 only accounts for about 1% of end user traffic.

CGNs also come with high capital and operational costs. In addition to their computational overhead, CGNs can create significant logging requirements, and they make auditing and trouble-shooting difficult. CGN gateways can also become single points of failure, attractive Denial-of-Service targets, or performance bottlenecks within the network. Because of these many drawbacks, CGNs are not a sustainable solution. They are only considered a stopgap measure — a necessary evil delaying address depletion long enough for the Internet to broadly support IPv6.

Ultimately, although the timing of the transition is still unclear, we have reached the point where IPv6 adoption will become a tangible issue for Web content providers.

IPv6 adoption status

Over the next few years, the IPv6 transition will affect every business that touches the Internet in any way. For wireless carriers and Internet access providers, planning began years ago and the conversion is already well underway, with current metrics reflecting reasonable progress on infrastructure readi-ness (i.e., networks, DNS, operating systems).

On the other hand, end user and content provider adoption is still in relative infancy. Here, there is a chicken-and-egg dynamic: many content providers don’t want to make significant investments until there are more IPv6 end users, while audiences are reluctant to shift until they can enjoy an end user experience that is on par with IPv4, in both quality and quantity.

Still, companies should not be lulled into complacency by the current metrics. Content providers need to be ready, as adoption could quickly snowball with any small shift in marketplace forces. Indeed, now is an ideal time to start planning, testing, and experimenting, while the percentage of end users

— and thus, the risks — are still minimal. Once the IPv6 audience grows, content providers who cannot provide IPv6 delivery will find themselves at a clear competitive disadvantage.


How does IPv6 affect Web content and application delivery?In an ideal world, the IPv6 changeover would be seamless to end users and relatively seamless to content providers, who would simply need to procure IPv6 connectivity from their ISPs and upgrade their server infrastructure to handle the new protocol. Unfortunately, the reality is far more complex.

IPv6 is not backward compatible

Perhaps the biggest challenge in the IPv4-to-IPv6 transition is that the two protocols are not compatible; that is, IPv4-only systems cannot talk directly to IPv6-only systems. This means no one can turn off IPv4 support until every last device they want to reach has acquired IPv6 connectivity. Unfortunately, many existing devices — including PCs running older OSes, as well as older cable and DSL modems, wireless routers, and other business and consumer electronic devices—have either limited or no IPv6 support. In other words, companies will have to support both protocols for years to come, in a long and bumpy transition period. During that time, there will effectively be two Internets, an IPv4 one and an IPv6 one, loosely bound together into a hybrid Internet by various transition technologies.

The key transition technologies include:

• Dual Stacking: Dual stacking simply refers to machines running both the IPv4 and IPv6 protocol stacks. Hosts within a dual stacked network can communicate over IPv4 or IPv6. Dual stacking will be common during the transition and may be deployed by enterprises, content providers, and networks. However, it requires hardware and software support that may not be available on legacy equipment. It also requires that having enough IPv4 address space for all dual stacked devices, so it will be of more limited use for fast-growing networks.

• CGN/NAT64: NAT6420 is a type of Carrier Grade NAT that can be used to provide connectivity between IPv6 hosts and IPv4 hosts by translating between IPv6 and IPv4 packet streams. Like other types of CGN, NAT64 can produce significant functional and operational challenges. It also creates a single point of congestion (or failure) that can affect all the users within the network.

• Tunneling (e.g., 6to4, 6RD, Teredo, etc.): Tunneling typically involves encapsulating IPv6 packets inside of IPv4 packets, in order to allow two IPv6 nodes to communicate over IPv4 infrastructure. Tunneling came about because IPv6 connectivity was very fragmented — and insufficient. Unfortu-nately, these tunnels are often unmanaged and sometimes provisioned dynamically, and can cause significant performance, reliability, and security issues. Preliminary data collected by Akamai shows that, as of December 2010, a majority of clients with existing IPv6 connectivity reach the IPv6 Internet through 6to4 tunnels.

Each transition technology has its limitations and drawbacks — but they are necessary to hold the Internet together until the long IPv6 migration is complete. We now take a closer look at the impact the IPv6 transition will have on delivering content and applications over the Web.


Challenges of delivering content in a hybrid Internet

During the IPv6 transition, content providers will face a number of challenges when trying to deliver fast and reliable Web interactions to their IPv6 audiences. These stem from limitations in the transitional technologies, uneven vendor support of IPv6, and the extremely fragmented state of the current IPv6 Internet.

Challenges of reaching IPv6 users from IPv4 sites

The first question for a content provider to consider is whether (or when) to provide native IPv6 connectivity for their site. In the near term, an IPv4 site will generally be able to reach end users connected via IPv6. These communications will likely be through Carrier Grade NAT64 gateways, run by the end user’s ISP, that translate between the IPv6 last mile network and the IPv4 Internet. Unfortunately, CGN creates a host of problems for content providers, including loss of performance, visibility, and functionality.21 Key challenges include:

• Broken location-aware services, abuse mitigation, and other IP address-reliant functions. Many types of Web applications rely on an end-to-end connection, where each device, household, or entity is associated with a single IP address. CGN breaks this assumption — as it creates a situa-tion where hundreds or thousands of end users — related only by their network provider — share the same IP address, and each user’s IP address may change with every new connection. Thus, CGN cripples functions like geo-location — using the user’s IP address to determine their location, in order to personalize content or to enforce licensing restrictions, for example, and abuse mitiga-tion — IP blacklisting or whitelisting, in order to block spammers, trolls, or other abusive users. Likewise, Web site analytics relying on geo-location data to provide audience demographics also become impaired.

• Broken applications. CGN (especially as it is typically applied in multiple layers) breaks assumptions that many of today’s Web applications rely on. In particular it affects applications, such as peer-to- peer and VoIP, which rely in some way on a unique end user IP address. Troubleshooting the issues is extremely complex and costly, as it can’t be done without the NAT operator’s help.

• Poor performance. In order to reach IPv4 sites, IPv6 end users need to go through a NAT64 gateway. Because there may be only one or two such gateways within a network, communications may be forced through long, indirect paths. In addition, these gateways quickly become congestion points within the network, as well as easily targeted points of failure, further affecting the perfor-mance and reliability of the end user experience.

These significant performance and functionality problems underscore the need for sites to provide native IPv6 delivery capabilities as their IPv6 user base grows. While IPv6 users currently represent less than 2% of the total user base, this number is expected to grow rapidly once access networks run out of IPv4 addresses. Thus, forward-looking sites will want to begin experimenting with IPv6 delivery capabilities in 2011.


Challenges of reaching IPv6 users from IPv6 sites

Technically, a content provider could start delivering content to IPv6 users by simply dual stacking servers, configuring IPv6 DNS records, and procuring IPv6 connectivity. This works — in theory

— but it does not necessarily provide an experience that achieves parity with IPv4. In fact, during the Internet’s IPv6 transition period, Web sites delivering IPv6 natively will face several key challenges, including:

• Uneven performance. Because the IPv6 Internet is still sparsely connected, native IPv6 communications may require longer, less direct routes than their IPv4 counterparts, resulting in slower performance and higher packet loss. This is particularly troublesome for high throughput or low latency applications such as online gaming or streaming media. In addition, a significant portion of the IPv6 Internet currently relies on tunneling traffic over IPv4, creating additional performance degradation. One recent Akamai performance test involving more than 9,000 nameservers worldwide showed that, on average, network latencies over IPv6 were higher than over IPv4. In North America the difference was particularly pronounced, with a median IPv4 latency of 48 ms compared to a median IPv6 latency of 87 ms, roughly 80% slower. For tunneled IPv6 traffic, the difference in latencies was even more significant. While performance is expected to improve as the IPv6 Internet matures, it may be years before parity with IPv4 is reached.

• Reliability issues. The current IPv6 Internet is significantly less reliable, less redundant, and less well-supported that the IPv4 Internet. Indeed, much of it may still be considered experimental, and routes that are broken or incomplete may go undetected for longer periods of time because they are not monitored as closely. Intermittent spikes in IPv6 packet loss are common, undermining the Internet’s ability to provide a robust and high performance platform for Web businesses.

• End user denial-of-service. A small but meaningful percentage22 of IPv6-enabled end users will be unable to reach native IPv6 content, due to a variety of factors ranging from browser and OS bugs to broken home gateways, misbehaving routers, misconfigured firewalls, or unreliable tunnels — all ultimately resulting in situations where the end user’s machine believes it has IPv6 connectivity when it really does not. The user’s machine will ask for an IPv6 DNS resolution (also known as a quad-A or AAAA resource record, in contrast to IPv4’s A records), and the name server will return any IPv6 and IPv4 records that exist. The user’s machine will try the IPv6 addresses first, falling back to the IPv4 addresses if those attempts are unsuccessful. The time-out can take 20 seconds per address attempt on Windows, causing untenable delays before the content is delivered. To the end user, it simply appears that the IPv6 site is broken, since all other sites — namely those that do not have AAAA records — continue to work fine. The end result of this is that many content providers are reluctant to hand out IPv6 addresses via AAAA records, even if they have IPv6-capable origin infrastructures.

Proposed approaches to this issue — such as whitelisting of DNS resolvers based on IPv6 capabilities, or restricting AAAA responses to resolvers making requests over IPv6 — each have their limitations. Whitelists create significant management and scalability challenges, and restricting AAAA responses can prove troublesome as there is no direct correlation between nameserver IPv6 support and end user IPv6 connectivity. In addition, these approaches require significant work by the content provider to address a very small portion of potential end users.

• Lack of IPv6 reporting and analytics. Because IPv6 end user adoption is still in its infancy, the tools for measuring, managing, and understanding IPv6 end user traffic are less mature than the IPv4 equivalents. In order to meet their business requirements, content providers will need logging, reporting, analytics and auditing solutions that can support their IPv6 traffic.


Finally, as content providers plan their IPv6 transition strategy, they need to be aware that current marketplace support of IPv6 is uneven, and vendor claims of IPv6 compatibility can be misleading. In addition, the specifications themselves are still evolving; since RFC 2460, there have been more than two dozen RFCs published relating to the core IPv6 protocols, along with many more relating to addressing, routing, and other IPv6-related topics.23 Another important issue is performance: IPv6 “support” often does not mean performance parity with IPv4. For example, hardware vendors may process IPv4 packets in dedicated hardware while performing the same IPv6 processing in soft-ware, impacting both speed and throughput. The same issue holds true for IPv6 content delivery: it is easy to “support” IPv6 traffic, but doing so with the same reliability and performance as IPv4 traffic is far more difficult.

Akamai: Helping our customers make the IPv6 transitionFor over a decade, Akamai has transformed the unpredictable, best-effort Internet into a robust and reliable platform for transacting e-commerce, distributing rich media, and delivering enterprise applications. Our goal is to enable the best possible end user experience while insulating content providers from the underlying complexities of delivering over a highly dynamic and heterogeneous network of networks. In the case of IPv6, this means minimizing the impact of the IPv6 transition on both content providers and end users. Akamai aims to do this by enabling Web sites to maintain their IPv4 origin sites for as long as they wish — while enabling them to reach both IPv4 and IPv6 audiences quickly and reliably over the hybrid Internet.

As we have seen, providing effective IPv6 support in the context of content and application delivery presents significant challenges. The naïve approach of simply dual stacking servers and procuring IPv6 connectivity works in principle — but fails to address the critical issues of performance and reliability. We now take a look at the work Akamai is doing to help its customers solve these challenges, followed by a phased plan for the rollout of Akamai’s IPv6 services.

Under the covers: Key areas of Akamai IPv6 development and innovation

With tens of thousands of servers distributed across a worldwide network infrastructure, enabling high performance IPv6 support across the Akamai EdgePlatform is no small task. It involves not only obtaining IPv6 connectivity across thousands of locations and dual stacking tens of thousands of servers, but also upgrading Akamai’s mapping, monitoring, routing, logging, communications, and control infrastructures, among others. Here are a few critical pieces to the puzzle:

Native IPv6 Support in the EdgePlatform

Rather than developing an IPv6 proxy or adaptation layer, Akamai is implementing native dual stack IPv6 support within its HTTP EdgePlatform. This means servers will be able to serve both IPv4 and IPv6 requests as appropriate, ensuring that IPv6 support is well-integrated into present and future Akamai capabilities.


Mapping the IPv6 Internet

Leveraging the unique vantage point of its broadly distributed network and performance monitoring infrastructure, Akamai is ideally positioned to map the IPv6 Internet, just as it has done over the last decade with the IPv4 Internet. Akamai has been making significant invest-ments across its mapping system to better understand the topology and connectivity of the IPv6 Internet and relate it to the existing IPv4 Internet.

Understanding the evolving topology of the IPv6 Internet requires significant research, including iterative surveying and mapping efforts. Compared to the existing commercial use of IPv4, IPv6 is not as well monitored or supported, resulting in more “brokenness” and instability than we typically see in IPv4.

Understanding the Performance of the Hybrid Internet

The ability to provide a fast and reliable end user experience will require not only a map of the IPv6 Internet, but an accurate understanding of real-time connectivity and perform-ance conditions across the IPv4 Internet, the IPv6 Internet, and interconnection points be-tween them. Thus, Akamai is augmenting its intelligent, real-time monitoring and mapping infrastructure to encompass the entire hybrid Internet. This capability is critical in order to make the best possible decisions about which server, route, and protocol to use for each end user request.

For example, Akamai’s research indicates comparative end user performance over IPv4 vs IPv6 varies on a user to user basis. In some cases, the IPv6 route performs significantly better. But in many cases, the IPv4 connection may perform better because the IPv6 connec-tion must go through a tunnel, a congested gateway, or an indirect route, for example. In other instances, for certain IPv6-capable users, the data center where the closest Akamai servers are deployed may not currently provide IPv6 connectivity. Those end users may also be better served over IPv4 from the nearby location rather than being served from an IPv6-capable location that is farther away. On the other hand, as the IPv6 Internet matures, IPv6 latencies are expected to drop and begin to outperform IPv4 more regularly. This means a comprehensive and real-time understanding the performance of the hybrid Internet is necessary to deliver the best possible end user experiences.

Making the IPv6 Internet Reliable

The Akamai EdgePlatform was architected from the ground up with principles of recovery-oriented computing at the forefront, enabling the network to operate seamlessly, even in the face of multiple failures at all levels, from machine to data center to network-wide.24 This highly fault-tolerant architecture is necessary in a highly dynamic environment like the Internet — and even more so in the immature IPv6 Internet, where ongoing failures are a fact of life. Akamai is investing significant resources to extend its high-availability architec-ture to work effectively across the hybrid Internet, enabling the EdgePlatform to deliver reliably to every end user, every time.


Akamai’s IPv6 services: Simplifying the transition

By embedding intelligent IPv6 support into its EdgePlatform, Akamai aims to insulate customers from the headaches and challenges of a protracted IPv6 transition period. Akamai will enable customers to reach their end users over the hybrid Internet quickly and reliably during all stages of the transition, without having to make significant changes to their origin networking infrastructure.

We will be rolling out IPv6 support for our HTTP-based services in three phases, designed to give customers a seamless and low-risk approach to undertaking the transition.

Early Adoption Phase

The first phase of Akamai’s IPv6 delivery will enable customers to experiment with IPv6 with less risk and without investing significant time and resources. End users will be able to access the customer’s site over IPv6 through a separate hostname, such as ipv6.example.com. The origin site does not need to provide any IPv6 connectivity, as Akamai will deliver to end users over IPv6 while connecting to the origin over IPv4.

This means content providers can offer native IPv6 support without spending the time or money needed to hire expertise, set up and manage separate IPv6 servers, procure IPv6 connectivity, recon-figure DNS infrastructure, or train technical support staff — all just to address what is currently a very small percentage of the user base. Instead, by simply leveraging Akamai’s experience and economies of scale, sites can deliver IPv6 services without significant additional overhead.

Moreover, the use of a separate IPv6 hostname allows Web sites to begin understanding their IPv6 audience in a controlled manner, without significantly disturbing their existing production site. This means content providers can begin experimenting with and understanding how IPv6 will affect their site, enabling them to find and fix application issues — such as headers, log lines, or authentication mechanisms that rely on IP addresses—without affecting users on their primary site. In addition, they have the opportunity to verify that their site management tools, log analytics, firewalls, and other systems work properly in an IPv6 environment.

www.example.com

IPv4

www.example.com

IPv4 (often via NAT)

ipv6.example.com

IPv6

IPv4Origin IPv4

IPv4

Akamai EdgePlatform

IPv4 client

IPv6 client

Figure 2: In the Early Adoption Phase, content providers can begin to test and understand IPv6 without changing their origin infrastructure and without affecting existing users.

Early Adoption Phase Benefits

• No changes to origin server / origin infrastructure

• Native IPv6 delivery to IPv6 users (avoids problems caused by CGN)

• Performance and reliability benefits of Akamai’s distributed network

• Gain visibility into performance and demographics of IPv6 audience


During this phase, customers will be also able to use beaconing to gain visibility into the IPv6 capabilities of their user base. By embedding an invisible pixel within the HTML of their IPv4 site that makes a request to the IPv6 site, content providers can learn what percentage of their current user base has working IPv6 support, as well as how many may run into IPv6 end user denial-of-service issues.

Akamai’s Early Adoption IPv6 support will be offered as a Tech Preview to select customers in the first quarter of 2011. The Tech Preview will support selected traffic management, object delivery, whole site delivery, and application acceleration functionality for customers of Akamai’s Global Traffic Management (GTM), Dynamic Site Accelerator (DSA), Dynamic Site Delivery (DSD) and Electronic Software Delivery (ESD) services.

End User Transition Phase

In the second phase, Akamai will enable high performance delivery of content and applica-tions from any IPv4 origin site to all of its end users across the hybrid Internet. As with the first phase, the content provider does not need to make significant changes to the origin networking infrastructure; Akamai communicates with the origin over IPv4, while handling each end user request in a seamless and optimized way over the appropriate protocol.

For example, when a dual stacked user makes a request to the customer site, the Akamai mapping system will determine whether that user can best be served over IPv6. If so, the user will receive the IPv6 address of an optimal server as well as the IPv4 address of an opti-mal server. The end user machine will then be able to retrieve content quickly from a nearby Akamai server over the protocol of its choice. If Akamai determines that the end user is best served over IPv4, then only IPv4 addresses will be returned. This allows users to receive their content over direct, high performance routes from optimal servers, regardless of protocol.

Figure 3. In the End User Transition Phase, content providers can leverage Akamai to provide high performance delivery to both IPv4 and IPv6 users without having to make changes to the origin networking infrastructure.

End User Transition Phase Benefits

• Deliver best performance and quality of service to all end users (IPv4 and IPv6)

• Seamlessly weather the IPv6 transition with no changes to origin networking infrastructure

• Avoid CGN, tunnels, indirect routes, and other performance and reliability bottlenecks

• Unified analytics and intelligence across global audience base

www.example.com

IPv4

www.example.com

IPv4 or IPv6 depending on anticipated performance

IPv4Origin IPv4

IPv4

Akamai EdgePlatform

IPv4 client

IPv6 client


Akamai also aims to reduce the risks associated with having a dual stacked origin that uses both IPv4 A and IPv6 AAAA DNS records (i.e., the aforementioned end user denial-of-service problem), by conservatively taking multiple performance metrics into account in order to avoid delivering over IPv6 to users with broken or poorly performing IPv6 connectivity.

Customers will opt-in to this phase, so that IPv6 end users won’t show up in log lines or forward request headers until the customer has validated that their applications and systems are ready. As with the first phase, small changes may be needed in customer applications that utilize IP addresses in headers, log lines, or authentication mechanisms. Beyond this, content providers are able to simply maintain their existing IPv4 sites while enjoying fast, reliable delivery to their audience base, no matter what stage of adoption IPv6 is in.

With today’s slow growth and adoption of IPv6 by end users, the need for content providers to use IPv6 in a commercial production setting will vary based on their particular business needs and demands. Akamai has scheduled its IPv6 readiness roadmap to meet customer needs based on our current projections of adoption. We anticipate having Beta service available in 2H 2011, with Limited Availability in 1H 2012.

Origin Transition Phase

Eventually, after IPv6 matures, content providers will move their origin servers to being either dual stacked, or possibly even IPv6-only. Akamai will enable its customers to make this transition on the customer’s schedule, without suffering significant limitations on their ability to deliver the best possible experience to their end users. Content providers can make the switch when they are fully ready and when they have access to a more mature marketplace of IPv6 solutions from hardware and software vendors. Regardless of when this happens, Akamai will continue delivering their content to their audience base over the best-performing routes.

Figure 4. In the Origin Transition Phase, Akamai will support IPv6 origin infrastructures. By using Akamai, content providers can delay making this shift for as long as needed.

Origin Transition Phase Benefits

• Continued industry-leading performance, reliability, and scalability to all end users (IPv4 and IPv6)

• Provide seamless origin server transition to IPv6—no impact to end users

• Leverage Akamai experience and best practices to streamline transition

www.example.com

IPv4

www.example.com

IPv4 or IPv6 depending on anticipated performance

IPv4 or IPv6

Origin IPv4or IPv6

IPv4 or IPv6

Akamai EdgePlatform

IPv4 client

IPv6 client


ConclusionWith ready availability of IPv4 addresses coming to an end, IPv6 adoption will be critical to the continued growth and success of the Internet. Despite the fact that current end user adoption levels are very low, forward-looking content providers will want to start experimenting with IPv6 and developing their transition strategy.

During the IPv6 transition period, Web-enabled businesses will face significant challenges in providing the same high quality experience for their IPv6 users as they do for their IPv4 users. In addition, they will be understandably hesitant to invest a lot of infrastructure resources to support a very small portion of their current user base. These issues have hindered IPv6 adoption to date.

Akamai’s IPv6 services are aimed at helping to smooth and accelerate the IPv6 transition by making it seamless for Web sites and end users alike. Using its proven EdgePlatform, Akamai will enable sites to deliver exceptional experiences to end users across the hybrid Internet—without requiring disruptive changes to their origin networking infrastructure. This will enable companies to deliver high quality, high performance content and applications to both IPv4 and IPv6 connected users.

As Internet growth continues, IPv6 has a critical role to play to ensure the availably of addresses for new users and applications. Web-enabled businesses will need to ensure their applications are available over IPv6 in order to provide the best possible experience to the Internet’s ever-expanding audience. Through the use of innovative technology and service, Akamai aims to help customers with this critical transition.

For more information about IPv6-enabled content and application delivery services from Akamai, please contact your sales team or use the Contact Us link on www.akamai.com.

The Akamai Difference

Endnotes

Akamai® provides market-leading, cloud-based services for optimizing Web and mobile content and applications, online HD video, and secure e-commerce. Combining highly-distributed, energy-efficient computing with intelligent software, Akamai’s global platform is transforming the cloud into a more viable place to inform, entertain, advertise, transact and collaborate. To learn how the world’s leading enterprises are optimizing their business in the cloud, please visit www.akamai.com and follow @Akamai on Twitter.

1 IPv6 is described in IETF RFC 2460. http://www.ietf.org/rfc/rfc2460.txt

2 Internet founding father Vint Cerf blames himself for making the 32-bit decision, which, at the time, seemed plenty big enough for the Internet — an entity that was then still considered “an experiment”. http://www.networkworld.com/community/blog/why-ipv6-vint-cerf-keeps-blaming-himself

3 There are an estimated 1.97 billion Internet users (and 6.85 billion people) worldwide as of June 2010. http://www.internetworldstats.com/stats.htm

4 http://www.ericsson.com/thecompany/press/releases/2010/04/1403231

5 http://www.nro.net/documents/nro50.html#2

6 Historical data from http://www.circleid.com/posts/20090120_milestone_year_for_ipv6/

7 http://www.potaroo.net/tools/ipv4/index.html

8 http://www.cio.gov/Documents/IPv6MemoFINAL.pdf

9 http://news.cnet.com/8301-30685_3-20016284-264.html

10 LTE or Long Term Evolution is a 4G phone technology which runs voice over IP and thus requires an IP address all the time — to make and receive calls.

11 Robert Kisteleki (RIPE NCC) at the Google IPv6 Implementors Conference, June 2010.

12 Cameron Bryne (T-Mobile USA) at the Google IPv6 Implementors Conference, June 2010. https://sites.google.com/site/ipv6implementors/2010/agenda/13_Byrne_T-Mobile_IPv6GoogleMeeting.pdf

13 http://www.oecd.org/dataoecd/48/51/44953210.pdf

14 Estimate based on depletion rates illustrated in Figure 27 of http://www.potaroo.net/tools/ipv4/, further supported by allocation rate cited at http://www.ipv4depletion.com/?m=201005

15 This type of CGN, which translates between private and public IPv4 addresses is sometimes referred to as NAT44. As we will see later in this paper, CGN can also be used translate between IPv4 and IPv6 addresses—this type of CGN is often referred to as NAT64.

16 http://bgp.he.net/ipv6-progress-report.cgi, http://www.oecd.org/dataoecd/48/51/44953210.pdf

17 http://www.isoc.org/isoc/conferences/ipv6momentum/docs/20100323-IPv6-Momentum-Huston.pdf

18 http://www.oecd.org/dataoecd/48/51/44953210.pdf

19 http://arstechnica.com/tech-policy/news/2010/03/as-much-as-one-percent-of-the-internet-is-now-using-ipv6.ars, https://fit.nokia.com/lars/meter/ipv6.html

20 NAT64 is sometimes also called Stateful AFT (Address Family Translation), and is based on the earlier, deprecated NAT-PT (Protocol Translation).

21 The CGN problems listed here hold true for all types of CGN, including NAT64 (used to translate between IPv4 and IPv6) and the previously-mentioned NAT44 (deployed by carriers to delay IPv4 depletion).

22 Google reports the number of “broken” IPv6 users to be in the range of 1 out of every 1000 to 2000 users. https://sites.google.com/site/ipv6implementors/2010/agenda

23 A list of IPv6-related RFCs is maintained here: http://www.switch.ch/network/services/ipv6/references.html

24 “Experience with some Principles for Building an Internet-Scale Reliable System”, http://www.akamai.com/dl/technical_publications/ExperiencewithsomePrinciplesforBuildinganInternetScaleReliableSystem.pdf

©2010 Akamai Technologies, Inc. All Rights Reserved. Reproduction in whole

or in part in any form or medium without express written permission is prohibited.

Akamai and the Akamai wave logo are registered trademarks. Other trademarks

contained herein are the property of their respective owners. Akamai believes

that the information in this publication is accurate as of its publication date;

such information is subject to change without notice.

International Offices

Unterfoehring, GermanyParis, FranceMilan, ItalyLondon, EnglandMadrid, SpainStockholm, Sweden

Bangalore, IndiaSydney, AustraliaBeijing, ChinaTokyo, JapanSeoul, KoreaSingapore

Akamai Technologies, Inc.

U.S. Headquarters8 Cambridge CenterCambridge, MA 02142Tel 617.444.3000Fax 617.444.3001U.S. toll-free 877.4AKAMAI(877.425.2624)

www.akamai.com