Last month I was helping a friend troubleshoot remote access to their home NAS, and we hit a detail that's easy to miss: the broadband connection had clearly been assigned an IPv6 address, but the device still refused to connect from outside the network.
Here's the thing — having an IPv6 address doesn't mean you have working IPv6 connectivity. Address assignment, routing, and actual reachability are three separate stages. If you only check whether an address shows up, you'll walk right past the real problem.
If you're not comfortable digging through network settings, running an online check first and working through the results step by step is usually more productive than jumping straight into the router config.

IPv4 uses 32-bit addresses, which caps out at a limited number of them. With phones, computers, smart home gear, and every other connected device piling up, the IPv4 pool simply can't keep up with long-term global demand. IPv6 uses 128-bit addresses, giving the internet vastly more room.
If you run a NAS, a home server, or anything else you want to reach remotely, and your broadband, router, and devices all support IPv6 with routing and firewall rules set up correctly, you can get true end-to-end connectivity over IPv6 instead of relying on IPv4 address translation.
That said, turning on IPv6 doesn't magically expose every device to the outside world. Your router's inbound rules, each device's firewall, and your ISP's own network configuration all affect whether a connection actually goes through.
Running an IPv6 check every so often tells you where your network stands on protocol support — and gives you a baseline to work from when something breaks later.
The most obvious difference is the format and length of the addresses.
| Aspect | IPv4 | IPv6 |
|---|---|---|
| Address length | 32-bit | 128-bit |
| Typical format | 192.168.1.10 | 240e:1234:5678::1 |
| Notation | Decimal numbers separated by dots | Hexadecimal numbers separated by colons |
| Address space | Relatively limited | Extremely large |
| How traffic flows | Home networks typically rely on address translation | Supports end-to-end routing without depending on traditional NAT |
| What to check | Address, routing, DNS, and connectivity | Address, routing, DNS, and connectivity |
These days a lot of home broadband runs dual-stack, meaning IPv4 and IPv6 are live at the same time.
One thing to keep in mind: not every IPv6 address is reachable from the public internet. Addresses starting with fe80:: are link-local — they only work for communication on the same link. ::1 is the loopback address.
The 2400::/12 range is part of the global unicast space, and addresses handed out by some Chinese ISPs may start with 2408, 2409, or 240e.
To know whether an address can actually reach the outside world, you need to look at routing, the address scope, and a real connection test together — don't judge it from the first few characters alone.
If all you want is a quick yes/no on IPv6 support, an online checker like ToDetect is usually the easiest route. If you want to confirm what the device itself is configured with, the commands built into your OS will get you further.
Open Command Prompt and run ipconfig, then look for an IPv6 address under the network adapter you're actually using. Seeing an address that starts with fe80:: means the device has a link-local IPv6 address — on its own, it doesn't prove your ISP has assigned you a public IPv6 address.
In a terminal, run ip addr — on Linux this lists the addresses on your network interfaces. macOS doesn't ship an equivalent ip addr command by default, so use ifconfig instead.
Check the inet6 entries for the relevant interface. These commands tell you which addresses the device picked up. Whether IPv6 can actually reach the internet is a separate question, and that's the next test.
Try loading a site you know supports IPv6, or test the connection from the command line.
On a system with curl, for example: curl -6 --connect-timeout 5 https://ifconfig.co
If it returns content, your environment managed to complete an HTTPS request over IPv6, at least this once. If the connection fails, take the error message and keep digging.
You can also try ping -6 2400:3200::1. If the online check, the website test, and the command-line test disagree with each other, work through the following list.
| What you see | Likely cause | Where to look |
|---|---|---|
| Only an IPv4 address | IPv6 isn't enabled on the network, or no global unicast address was assigned | System settings, router, and ISP configuration |
| IPv6 address present, but external sites won't load | No valid route, upstream network issue, or firewall restrictions | Check the default route and test against several IPv6 targets |
| Domains fail, but some IPv6 addresses connect fine | DNS resolution problem or misconfigured domain records | Check AAAA records and DNS query results |
| Some pages load, larger content fails | Possibly path MTU issues or ICMPv6 filtering | Look at the connection errors and path MTU |
| The computer has an address, the phone doesn't | Differences in device settings, adapter state, or protocol support | Check each device and its network interface separately |
If your setup uses a bridged optical modem with the router handling dial-up, you'll also want to confirm that the IPv6 prefix is being delegated correctly and that the router is passing that prefix on to devices on the LAN.
Don't rush to change DNS or MTU the moment something fails. Figure out which stage is broken first, and you'll avoid a lot of unnecessary configuration churn.
A page showing an IPv6 address means the test environment obtained or recognized an address. It doesn't confirm the whole network path is healthy.
If the tool offers an actual IPv6 connectivity test, check whether it passed — and weigh that against real website loads. Displaying an address is not the same as verifying connectivity.
A domain's AAAA record is what supplies its IPv6 address. If DNS results look wrong, investigate the domain's configuration, the DNS server, and the resolution process rather than blaming the IPv6 address itself.
If IPv6 tests fine but one particular site still won't open, consider the site's own service status, its certificate, application configuration, and the network path involved.
When you run an IP check with ToDetect, start with the addresses and network details the page actually reports, then cross-check against whatever DNS, IPv6, or other tests are available. Different tools offer different checks, so go by what the results page actually shows.
Because address assignment is only one part of network communication. The default route, DNS resolution, the upstream network, the target site's configuration, and firewalls can all get in the way. Test against a site you know supports IPv6, then work through the error messages one by one.
It could be your ISP reassigning the prefix, privacy extension addresses on the device, or the network interface reinitializing. Whether that's normal depends on the address type and your network setup. If you need long-term remote access, work out how often the address changes and pick a dynamic DNS approach that fits.
It can be. System settings, network drivers, protocol support, and configuration vary between devices. Check whether IPv6 is enabled on the computer's adapter, then confirm the router is delegating a prefix properly and that the device has no conflicting network configuration.
Start by telling the address types and interfaces apart. Addresses beginning with fe80:: are usually link-local, ::1 is loopback, and global unicast addresses need to be judged by their scope and routing state. Having multiple IPv6 addresses on one device isn't unusual.
What an IPv6 check should really tell you isn't just whether a string of characters appears on the page. It's whether the device got a usable address, whether routing works, and whether access actually succeeds.
Re-run the check after switching broadband providers, replacing a router, changing network settings, or upgrading your OS — and run it right away if websites start failing or remote connections drop.
When something won't connect, confirm your current network state with an online tool first, then narrow it down with system commands, DNS lookups, and real access tests. That order tends to get you to the answer a lot faster.