Before you begin: Please be aware IPv6 testing is only supported on F-series and G-series sensors. Sensors manufactured before 2019 will not support IPv6. These unsupported sensors have serial numbers with format ZAxxKH4xx or contain Superhero surnames (e.g. Wayne1234).

You can now use your UXI sensors to test IPv4 and IPv6. You can measure and compare the performance of the network and applications, identify and pinpoint issues in either IP stack and ensure your network is ready for dual-stack or IPv6-only.

The IP Stack is configured at the network level in the UXI dashboard. This allows you to test IPv4 and IPv6 independently. In dual-stack environments, you can use the network alias feature and label the IPv4 network differently than the IPv6 network.

To get started, go to Settings and select either Wireless or Wired.

Create a new network and specify the authentication details. If a network configuration by the same name already exists, type in an alias.

In the advanced options, select the IP Stack. By default, the setting is IPv4. To test IPv6, change this setting to IPv6.

Some tests might have destination URLs or domains that do not have IPv6 addresses (ie AAAA DNS records). These tests cannot be completed on IPv6 networks. DNS64 and NAT64 solve this problem by converting/translating/embedding the IPv4 address into an IPv6 address. A DNS server that does DNS64 does this transparently to the client. The translated IPv6 addresses usually start with 64: Only enable this setting if your network supports DNS64 and you want to test IPv4 addresses.

All the proxy settings, authentication methods, and test limitations are the same as IPv4 testing. However, you must specify an IPv6 address or hostname that corresponds to an IPv6 address for the proxy server. You cannot use an IPv4 proxy on an IPv6 network. For WPAD, the PAC URL would also need to be available over IPv6 and the contents of the PAC file should use IPv6 addresses or domain names that are resolvable to IPv6 addresses.

The sensor can get an IP address using SLAAC, SLAAC + stateless DHCPv6 or stateful DHCPv6. The method used depends on the IPv6 router advertisement flags according to RFC 4861 - Neighbor Discovery in IPv6.

In the About section of the sensor status page for the IPv6 network, you will see the IPv6 link-local IP address, the global unicast address, the method used to get the global unicast address, the gateway address, and primary and secondary DNS servers.

If the sensor uses SLAAC, you will see a new icon on the main page of your dashboard for SLAAC. On the SLAAC status page, the SLAAC IP Generation Time is the total time taken to obtain an IP address via SLAAC.

If the sensor uses SLAAC + Stateless DHCPv6 for IP allocation, then in addition to the SLAAC IP Generation Time graph on the SLAAC status page, the Stateless DHCPv6 Response Time graph will show the total time taken to get the other settings (eg DNS nameservers) from the DHCPv6 server in stateless mode.

If the sensor uses stateful DHCPv6, these measurements are provided on the DHCP status page under DHCPv6 response time. The DHCP Response Time is the total time taken to obtain an IP address.

Once the sensor has an IP address, the sensor will test the gateway, connectivity past the gateway, the DNS servers, and a captive portal if necessary.

Please follow these steps to select groups and networks when you want to configure tests for your IPv6 network. The following test templates are supported, but the results depend on the test targets also supporting IPv6.

The following test templates may not support IPv6

Many of the pre-defined tests are similar to web server tests. Many of these work on IPv6, however, some do not have AAAA DNS records. The following predefined tests do not have IPv6 addresses (at the time of releasing this feature) and these tests are skipped if they are configured on IPv6 networks unless the Use DNS64 setting is enabled on the dashboard:

The following pre-defined tests have IPv4 literals as their target (and no known IPv6 equivalent) are:

These tests will always be skipped in IPv6 networks. If they are configured on IPv6 networks, they will always be grey on the dashboard. The Use DNS64 setting will not help in this case.

Other pre-defined tests such as Netflix (Fast.com), Dropbox, YouTube work on IPv6.

Here are some of the most common IPv6 issues and what the root cause of the issue often is.

This usually indicates the router did not return a router advertisement to the sensor. Therefore the sensor is unable to get an IP address. The network is likely not enabled for IPv6.

This usually indicates your sensor has an IP address and can reach the gateway, but the test of external connectivity to http://cdn.capenetworks.io/auth is failing. This web page is available over IPv6 and should be reachable by the sensor to determine if there is internet access.

This can sometimes indicate the test target did not have any AAAA DNS records. View the triage output for more detail.

If the test is one of the predefined tests (eg slack, github, jira, etc) and there is no AAAA DNS record, then you might have enabled the Use DNS64 option on the dashboard without having the DNS64 + NAT64 setup on their network. If you are sure you have the DNS64+NAT64 on the network, this failure is pointing to something wrong with that setup. However, if you do not have DNS64+NAT64 setup on the network, then the dashboard setting Use DNS64 should be disabled.

Usually, this indicates some underlying network issue exists and therefore the sensor is not attempting to test over IPv6. For example, if there is an error "No connectivity past gateway", external tests are not attempted because there is no internet access.

Another possibility is the test is one of the pre-defined tests that we know does not have AAAA DNS records and the configured network has not enabled Use DNS64. In this case, the test is skipped and it is guaranteed that it will grey out on the dashboard.