Monitoring IPv6 Networks

Posted by on May 31, 2017

IPv6 has been around for two decades, and yet it is only now making up a meaningful portion of Internet traffic. Reports today find that there are between 10-15 billion Internet-connected devices (each requiring an IP address), yet only 2.8 billion routed IPv4 addresses. The conclusion? Most connected devices do not have unique, public IPv4 addresses and instead utilize network address translation (NAT) to communicate with the Internet.

The adoption of IPv6 is being driven by large-scale cloud provider and ISP networks. This is happening as a result of IPv4 address exhaustion and the complexities of managing NAT in these large-scale networks. In some cases, these providers are paying big bucks to acquire unused IPv4 address space. But increasingly, they are turning to IPv6 for both internal network connectivity as well as consumer-facing connectivity. For example, Facebook found that page load times can decrease by 10% with IPv6 as opposed to IPv4, because fewer middleboxes have to be traversed in access and content provider networks.

Among major cloud, content and access networks, IPv6 traffic in the U.S. is reported as:

As you can see, customer-facing applications are beginning to tip toward IPv6 as the dominant connection type in the U.S. In addition, with recent announcements by Amazon to support IPv6 for S3 and EC2 and by Microsoft for Azure VMs, along with Google Compute hot on their heels, we expect this trend to accelerate with IaaS-facing services as well.

Monitoring IPv6

With IPv6 becoming more prevalent in cloud provider and consumer access networks, you may already be on the path to IPv6 deployment with your network and applications.

Want to understand IPv6 in your environment? Here are three things you should be monitoring:

  • IPv6 DNS resolution
  • IPv6 traffic paths
  • IPv6 BGP prefixes and routes

IPv6 DNS Resolution

In order to resolve a hostname to IPv6, you’ll of course need an IPv6 address record (AAAA record). You can easily monitor your A and AAAA records and their resolved IP addresses with a DNS Server or DNS Trace test. And you can easily alert on whether a AAAA record is available in various regions of the world.

Figure 1
Figure 1: IPv6 AAAA record mappings for

IPv6 Traffic Paths

Since IPv6 resolves to IP addresses distinct from IPv4, IPv6 connections are often served from different data centers and network providers. You’ll want to make sure that you have monitoring set up for IPv6 as well as IPv4 if you have it enabled in your environment.

Figure 2 shows the comparison of IPv4 and IPv6 traffic from the same data center in San Francisco to LinkedIn. IPv4 connectivity traverses Tinet and Telia to San Jose, with ECMP links visible at the top. IPv6 connectivity traverses Zayo and Level 3 to Los Angeles, at the bottom. Target data centers and intermediate networks vary considerably between the two.

Figure 2
Figure 2: From the same source data center to target service, IPv4 connectivity (top)
traverses different networks from IPv6 connectivity (bottom).
Figure 3
Figure 3: IPv6 traffic from Cloud Agents in Europe (left) to LinkedIn data centers (right).

IPv6 Routes

To best understand IPv6 traffic paths, you’ll want to also monitor the routes to your IPv6 prefixes. You can visualize routes using our BGP Route Visualization, which will show the AS Paths for each of your IPv4 and IPv6 prefixes. When you monitor a service from an IPv6-compatible agent, we’ll automatically resolve the DNS and collect routes for all of the corresponding prefixes. Figure 4 shows an IPv6 prefix for LinkedIn, with upstream ISPs that correspond to the Path Visualization in Figure 3.

Figure 4
Figure 4: BGP route topology for LinkedIn’s 2620:109:c00c::/48 IPv6 prefix. Upstream ISPs are Level 3 (AS3356),
Hurricane Electric (AS6939), Telia (AS1299) and NTT America (AS2914).

Expanded Support for IPv6

We’ve expanded our support for IPv6 in order to support its growing adoption. Today you can utilize IPv6 across all of our test types (web, network, voice, routing) and all of our agent types (cloud, enterprise, endpoint).

Our recently expanded support includes new IPv6 Cloud Agent locations around the Internet, now totaling 34 globally (an increase of 15 over the past 5 months). We now cover locations in Australia, Colombia, Costa Rica, India, Mexico, South Africa, Spain and Sweden.

In addition to Cloud Agents, we’ve also made it easier to use IPv6 with Enterprise Agents. Enterprise Agents, which are placed in your own network environment, are now dual-stack (IPv4 and IPv6). With this capability, you can run IPv4 and IPv6 tests from the same Enterprise Agent. To do so, you can select one of three options: IPv4 only, Prefer IPv6 or Force IPv6.

Figure 5
Figure 5: Dual-stack Enterprise Agent options for IPv4 only, Prefer IPv6 and Force IPv6.

Stay tuned over the coming months as we continue our expansion of IPv6 Cloud Agents to support even more parts of the globe. If you’d like to try IPv6 monitoring for DNS, traffic paths and routing, you can do all three in a free trial of ThousandEyes.