Use this page to collect tips on how to troubleshoot IPv6 issues. For instance, adding an AAAA record for a service to your DNS may result in a small percentage of end-users losing connectivity and others experiencing unusually high latency. The root cause for connectivity loss is usually that the end user is on another network with IPv6 on their PC but no form of IPv6 connectivity. In fact, their company may be blocking Teredo and 6to4 traffic. The root cause for high latency is usually that the end user is using some form of tunnel (ISATAP, tunnel broker, 6to4, Teredo) that causes their traffic to trombone out to a distant tunnel endpoint and then come back again, or perhaps the tunnel endpoint is on a network that has poor IPv6 connectivity.
As you deploy IPv6 and as other networks deploy IPv6, your helpdesk will see new and different problems. Also, problems that seem familiar will turn out to have different root causes from before. You will need to deal with this issue even if you are delaying implementation of IPv6 in your own network.
In order to debug connectivity issues, you can easily traceroute from various places to your network by setting up an IPv4-only host and setting up various kinds of transition technologies on it (6to4, Teredo, gogo6 and SixXS tunnels, etc.)
Verifying the IPv6 Experience
It may not be initially obvious, but your IPv6 throughput may not be the same as your IPv4 throughput.
- Service providers may have IPv6 transit or peering, but those connections may not be dual-stacked and so IPv6 operates over a separate physical interface than the IPv4 traffic.
- The IPv6 path is more circuitous than IPv4 because of sub-optimized routes to get to the target node. Because there are so (comparatively) few IPv6 links, the physical path to the target mode may be indirect.
- The service provider may have less-optimized transit or peering links than IPv4, and so while they may have IPv4 peering with Company A and B, they may not have IPv6 peering with Company B.
- An intermediate router(s) may not be able to route IPv6 in hardware but only in software, and relatively low levels of traffic may bring the router to a very high level of CPU utilization resulting in lower IPv6 throughput.
- The service provider may be using tunneling for IPv6.
In addition to their service provider's topology, an end-users' local IPv6 environment may result in poor IPv6 throughput.
- The end-user's PC could be using Teredo and all the traffic is being tunneled through a remote host positioned sub-optimally in the path to the target node.
- The end-user's router tunnels to a remote host that is also not in the path to the target node.
- The end-user's router is performing IPv6to4 and the network stack is not well-optimized.
Identify your IPv6 address
Test your IPv6-based browsing connectivity
Test your e-mail server connectivity
- E-mail reflector helps email users identify whether or not they're sending over IPv6 and also clues them in to what their DNS looks like from the outside world. It will reply to the email showing the Received headers as well as dig -t mx output for the domain.
- This is a tool for testing if your mail setup is capable of sending IPv6 emails. To use this tool simply send an email to firstname.lastname@example.org and if your mail is IPv6 enabled, you should receive an instant reply. If you do not receive a reply, that means that your mail system is probably not IPv6 enabled. You can leave subject field and body of the message empty, or you can put something in the subject field that will help you identify reply email. The body of the message can be empty and will be replaced in the reply with some helpful information (the date the message was received and the path of the message). Please note that the bouncer is only reachable over IPv6, however, the reply message may be mailed to you over IPv4. Check message headers of the reply message. Missing the reply message? Check your spam folder.
- Anyone can send an e-mail to email@example.com and get a dual stack reply - if the sending e-mail system is IPv6 ready the response will return over IPv6. if not, it will come back over IPv4. The reply contains the message headers (as the message body) of the message that was sent (the message body is discarded). More here.
- Free webmail service that's accessible over IPv6 (and IPv4). Open account here (note: site is in German)
Test FTP access
Test NTP access
Test Telnet access
- ipv4.test-ipv6.com 79 for IPv4 only
- ipv6.test-ipv6.com 79 for IPv6 only
- ds.test-ipv6.com 79 for either
The only way to know the actual 'goodput' of your IPv6 link is to measure that with an IPv6-based test. Here are some IPv6 "speed test" sites:
Here are some large files accessible over IPv6:
- Tele2: 10 GbE connection to their core, capable of at least 5Gbps
Here are some IPv6-capable throughput software tools:
Test Network Connectivity
Thorough diagnostic tests of network links (both require Java)
Without Java - http://test-ipv6.se/ and http://test-ipv6.com/
Test support of Extension Headers
- The path6 tool of SI6 Networks' IPv6 Toolkit is an IPv6-enabled traceroute-like tool with full support for IPv6 Extension Headers.
If you host a website and want to test your end users' IPv6 access:
Test IPv6 readiness of a domain
Test for open ports
Here are some web sites that use an NMAP scan over IPv6 to test for open ports on the visitor's address