TL;DR: IPv6 and IPv6 DNS often stops working on residential home routers. This can manifest in strange outages especially when your browser or computer continues to try using IPv6. Spot when this happens and fix it quickly by monitoring your IPv6 connectivity.
Our Internet runs primarily on two versions of the Internet Protocol; IPv4 and IPv6. IPv4 is running out of addresses, but IPv6 is still abundant and will be for a very long time. ISP (Internet Service Providers) and mobile ISPs are increasingly giving out IPv6 addresses only and then use mechanisms like CGNAT (Carrier Grade Network Address Translation) to ration and share IPv4 pools amongst us. Not all web and Internet assets are available via IPv4 and IPv6, though many are available on both.
You ask your computer for assets and web pages using words, however it’s the DNS (Domain Name System) that tells your computer which IP addresses those assets are served by. DNS servers (caches/resolvers) answer your computer over whichever protocol is active and based upon the type of query they are asked.
Yes, and you may have IPv4 or IPv6 DNS servers configured, or you may have both. In the following sections we will show you how to manually resolve IPv6 addresses and fully test your IPv6 connectivity.
Most configuration processes happen automagically including aspects of your IPv4, IPv6 and DNS settings being supplied by your local router (which is configured by your ISP or organization’s IT team). Your web browser and operating system then request DNS lookups which additionally leverage mechanisms like Happy Eyeballs to decide which of the IPv4 or IPv6 supplied records to use. IPv6 is enabled by default in most modern operating systems but you need to check with your ISP whether they provide (and support) IPv6.
As mentioned above, a really important question is, does your ISP support IPv6 and should you be getting IPv6 connectivity with your chosen plan or account type. Additionally, you need to ensure that your ISP supplied home router or associated equipment fully supports IPv6.
There are many ways to test your IPv6 settings and connectivity. You can do so manually by looking at your operating system settings, running command line tools, or visiting remote sites to check how you appear publicly on the IPv4 and IPv6 Internets.
From the outside in, you should be represented by a public IPv4 and/or IPv6 address. You can manually check this by visiting IPv6-Test or the simpler Test IPv6 however this will only show you a specific point in time (tested over HTTPs) and will not show whether you have had any intermittent or historical issues.
You really need to be testing continuously. This includes making DNS requests and sending IPv6 probes to both your default gateway and also out on to the Internet to be 100% sure you are connected end-to-end and that assets are reachable outside of your ISP. Pinging your default gateway via ICMPv6 (Internet Control Message Protocol for IPv6) is one local test, but checking you can reach and query IPv6 DNS servers and other assets on the IPv6 Internet is another undertaking, so let’s initially look at how you might perform these tests manually.
First, let’s differentiate between IPv6 DNS requests for IPv6 records and requests that actually use IPv6 for transport i.e. requests that are sent using the IPv6 protocol.
Without going too deep in to the DNS, you can ask a DNS server for IPv4 or IPv6 records. IPv4 address records are called “A” records and IPv6 address records are called “AAAA” records. You can ask for either type of Resource Record (RR) from either type of server 😎.
It’s up to whomever owns the assets or pages you’ve requested as to whether they are a) accessible across the IPv4 or IPv6 Internet and b) whether they have the correct types of DNS RRs set to let us know “who” to ask!
If your IPv6 DNS is not working, how would you even know? Well, quite often you don’t. If your fundamental IPv6 connectivity goes down you may experience connectivity problems, be unable to reach IPv6 resources, and/or be unable to connect to your configured IPv6 DNS servers.
We need to check you are represented by a globally routable IPv6 unicast address (rather than just a non-routable IPv6 link local address).
fe80::/10
are link-local addresses and ff00::/8
are multicast addresses. Your IPv6 default gateway will likely be an fe80::/10
address but alternatively may be a global address.
You can rapidly check IPv6 from the outside -> in by visiting IPv6-Test as mentioned previously, or you could simply send some ICMPv6 packets to Google’s Public Primary DNS server ping -6 2001:4860:4860::8888
. If either of those steps fail you then need to troubleshoot (partition your failure domain) and go step by step to find out what’s wrong…
We can look for the presence of IPv6 addresses on your host’s specific interface but let’s kill two birds with one stone and see if you have a default route in your local IPv6 route table (macOS/Linux) but let’s also see if there’s a VPN running with a better match prefix 😎 :
netstat -rn -f inet6 | egrep -i "default|2000::/3"
The above should return at least one route (as per below) via a known interface such as “en0 " on a Mac. We’re also assuming you don’t have any fancy tunnels or VPNs set up for now!
💡 That’s why we also check for 2000::/3
as it’s an overriding route for the public IPv6 address space used by VPNs to trump the default
entry.
Destination Gateway Flags Netif Expire default fe80::5a23:8cff:fe1a:5f21%en0 UGcg en0 default fe80::%utun0 UGcIg utun0 default fe80::%utun1 UGcIg utun1 default fe80::%utun2 UGcIg utun2 ::1 ::1 UHL lo0
Depending upon your flavour of Linux you might see “wlan0 " as the interface or you can also use the following command:
ip -6 route | egrep -i “default|2000::/3”
⬅ Click for explanation!
default via 2a03:b0c0:2:d0::1 dev eth0 proto static metric 1024 pref medium
Next you might check if you can send data to the relevant IPv6 default gateway above fe80::5a23:8cff:fe1a:5f21%en0
(using IPv6 of course which also requires the interface appended!).
ping6 fe80::5a23:8cff:fe1a:5f21%en0
Note: As mentioned, the IPv6 default gateway also specifies the interface “en0 " too (which is different from IPv4 default gateways). If you manage to get responses, let’s see if we can then talk to your configured IPv6 DNS servers.
Note: You could just ask for the record immediately from the IPv6 DNS server and then go from there, but let’s verify our settings first by learning and partitioning the problem space.
You can also see which DNS servers are configured via cat /etc/resolv.conf
or also scutil --dns
on macOS.
Additionally, you can see if DHCPv4 or DHCPv6 have assigned IPv6 DNS servers as per the following where “en0 " is the interface name in question:
ipconfig getpacket en0
... domain_name_server (ip_mult): {192.168.0.1, 192.168.0.2} end (none): ...
So, in the above we are not getting IPv6 DNS servers from the DHCPv4 reply but…
ipconfig getv6packet en0
DHCPv6 REPLY (7) Transaction ID 0x80940b Length 76 Options[4] = { CLIENTID (1) Length 14: DUID LLT HW 1 Time 668691856 Addr 50:ed:3c:2f:46:04 DNS_SERVERS (23) Length 32: 2606:4700:4700::1111, 2001:4860:4860::8844 DOMAIN_LIST (24) Length 0: Invalid SERVERID (2) Length 10: DUID LL HW 1 Addr 58:23:8c:1a:5f:21 }
We are indeed getting IPv6 DNS servers from the DHCPv6 reply. Next we will check if we can send ICMPv6 requests to your IPv6 DNS server addresses, and then then try to ask your IPv6 configured DNS server for a record.
ping6 2606:4700:4700::1111
Once we’ve confirmed a positive response from the above we can use a common tool called dig
to make test DNS requests. We can specify which IP protocol and query we would like to make.
Note: dig
is available on Linux via bind-utils
and/or dns-utils
.
Making a test IPv6 query with dig
might mean asking an IPv4 server for an IPv6 resource dig @1.1.1.1 AAAA pansift.com
but what we really want here is to use the IPv6 protocol for the message transport i.e. ask an IPv6 server, using IPv6, for an IPv6 or IPv4 resource record:
dig -6 @2606:4700:4700::1111 AAAA pansift.com
⬅ Click for explanation!
You can try some different permutations for yourself but you should get a positive response in the answer section much like the following:
... ;; ANSWER SECTION: pansift.com. 300 IN AAAA 2606:4700:3033::6815:6023 pansift.com. 300 IN AAAA 2606:4700:3032::ac43:ac41 ...
Healthy responses are generally returned in less than 20ms. Good enough responses are often between 20-150ms but anything consistently higher means it might be time to configure and use another DNS server. See the section towards the end on differnet public IPv6 DNS servers.
At this point you should be confident you’re fully connected on the IPv6 Internet and can check your address via IPv6-Test , or surf to a known IPv6 enabled website using a Chrome Extension like IPFoo. You can also check on the command line with cURL
to explicitly see the HTTP status code which should be 200
(via the IPv6 switch -6
). Try a few websites yourself to see if they have an IPv6 presence.
curl -6 -s -L -o /dev/null -w “%{http_code}\n” pansift.com
⬅ Click for explanation!
…should result in…
200
The above is all essentially toil i.e. undifferentiated heavy lifting. It requires you to manually get a command line on the problematic host (or try to get the user to find the terminal and type commands!). It doesn’t help you spot intermittent issues or historical problems!
It’s important to keep an eye on whether or not remote workers are dual stack (IPv4 and IPv6) from the outset including what ISPs they are connecting to (as they work from different locations). PanSift solves for all of these issues mentioned but let’s keep rolling with the manual approach so you can understand what’s going on under the hood…
As noted previously, ensure you know whether or not you are supposed to have IPv6 as part of your service before changing or updating anything. Always take a backup of any configuration before making changes.
Also, check if one of your issues might be that perhaps you are on CGNAT(Carrier Grade NAT) where you have native IPv6 connectivity but shared/pooled IPv4 addresses performing NAT64 for you in the carrier or ISP cloud. In this case, sometimes when their IPV4 pool or translations have issues, no IPv4 traffic passes but IPv6 does. What entails is that much of the sites or endpoints on the World Wide Web or parent Internet do not have IPv6 reachable interfaces. In this case, sites with IPv6 presence and AAAA DNS RRs will load (think Google, Cloudflare, Cisco) but sites that are only IPv4 enabled will not. This can also affect other protocols riding atop IP such as email SMTP/POP/IMAP, SSH, RDP, etc.
Recommendations |
---|
1. By disabling and re-enabling a Wi-Fi interface or by disconnecting and reconnecting an ethernet cable, it forces your computer to re-ask for settings from the local router including DHCP (or to re-initialize addresses via SLAAC). The previous getpacket commands can be used for DHCP only. |
2. Log in to the local router and check that it is getting an IPv6 WAN/Internet address. Check it is configured to hand out DNS settings via DHCP on the LAN (which should include IPv6 DNS server settings) though the router may offer its own address as a DNS cache/relay. You could also configure the public ones listed below. |
3. Reboot your local router/modem and check it has no warnings or errors in its logs. |
4. Contact the nominated ISP support service to perform deeper health checks on your service, WAN connection, and account. |
This is an extreme option and it is not recommended unless there is no other choice or solution found. You can disable IPv6 via the command line or via the GUI in macOS or Linux.
networksetup -setv6off Ethernet
networksetup -setv6off Wi-Fi
networksetup -setv6automatic Wi-Fi
networksetup -setv6automatic Ethernet
Check your specific flavour but most are alike for “linux flavours”.
This is definitely not recommended as it may be the only type of connectivity you are provided with (especially in modern times as IPv4 address space runs out). This action would require knowing that you are not solely on an IPv6 connection and that the ISP provides full connectivity via IPv4. You are likely to cut yourself off from the Internet fully but you can still experiment as long as you know how to revert your settings!
2001:4860:4860::8888
2001:4860:4860::8844
2606:4700:4700::1111
2606:4700:4700::1001
2620:fe::fe
2620:fe::9
More Quad9 info as some addresses offer “secured” and “insecure” services…
The other option is to just run an instant troubleshooting tool which continuously monitors a range of IPv6 metrics, settings, and even Wi-Fi performance like PanSift!
Digital work requires reliable connectivity. Whether for low latency or regular data streams, Wi-Fi, DNS, and network issues cause teams to lose time and productivity. Even worse is when support teams waste time trying to recreate and isolate issues! See how PanSift saves time, money, and frustration on all sides with instant remote troubleshooting 🏠🏝🛰.
2 x free macOS agents
No registration, immediate live demo!