It's a tp-link Archer, and since it supports Wi-Fi 6 it must have been from 2019 or later.
Hmm, I just went deep into the settings and there's an IPv6 toggle (disabled by default, and requires playing with menus to make it actually work) now. I don't remember seeing that (and I explicitly checked) when we switched the ISP-side last April. But the firmware is dated after that, so I choose to trust my memory.
Actually trying to connect to ipv6 stuff besides the router itself (in fd00::/8, that's good) just gives "Destination unreachable: Beyond scope of source address" though (probably because I only have an fe80 link-local address though?). If I play with the settings some more I get a ::/64 address, but that just gives me a black hole ... wait, is that even a legitimate address? Do I need to fill in the prefix manually or something?
I'll play with this some more in the morning I guess. But I certainly wouldn't expect a normal user to get IPv6 working under these circumstances if I haven't figured it out yet ...
That's a leftover from back when IPv6 was very new (yes these utilities are that old), and the networking utilities (ping, traceroute, etc) understood only IPv4. It's no longer necessary, all relevant networking utilities have since been upgraded to work with both IPv4 and IPv6; you can use just "ping" with a IPv6 address and it should work.
> You can use just "ping" with a IPv6 address and it should work
Not on BSD-derived operating systems (macOS included). You must use ping6 to ping an IPv6 address (including a hostname that only publishes AAAA records.)
From `man ping6` on macOS Sonoma:
> There have been many discussions on why we separate ping6 and ping(8). Some people argued that it would be more convenient to uniform the ping command for both IPv4 and IPv6.
> The following are an answer to the request:
> From a developer's point of view: since the underling raw sockets API is totally different between IPv4 and IPv6, we would end up having two types of code base. There would actually be less benefit to uniform the two commands into a single command from the developer's standpoint.
> From an operator's point of view: unlike ordinary network applications like remote login tools, we are usually aware of address family when using network management tools. We do not just want to know the reachability to the host, but want to know the reachability to the host via a particular network protocol such as IPv6. Thus, even if we had a unified ping(8) command for both IPv4 and IPv6, we would usually type a -6 or -4 option (or something like those) to specify the particular address family. This essentially means that we have two different commands.
I often use ping to check if a machine is alive or is reachable at large. Then it might be more informative if ping tried all addresses the name resolves to. You wouldn't need to specify the protocol version.
ping6 and ping4 are symlinks to ping on my system, and are equivalent to passing -4 or -6 to force a specific version. The default behavior negotiates either fine.
I'm testing with `ping ipv6.google.com` as well as the router IPs. Between each change, I disconnect from wifi.
The router itself has a ping tool and can ping ipv6.google.com just fine. So I assume the upstream options are correct.
For the LAN, I have 4 options:
* ND Proxy gives me an fd/8 address. I can ping the router via its fd/8 or fe80 address, google blackholes.
* DHCPv6 gives me an ::/64 address. I can ping the router via its fd/8 or ::/64 addresses, google blackholes
* SLAAC + Stateless DHCP does not give me any address (I still have the default fe80 address). I can ping the router via its fd/8 or ::/64 addresses, google gives Destination unreachable: Beyond scope of source address
* SLAAC + RDNSS does not give me any address (I still have the default fe80 address). I can ping the router via its fd/8 or ::/64 addresses, google gives Destination unreachable: Beyond scope of source address
In all cases, the IPv6 addresses the router says are its DNS servers blackhole. I do have working DNS returning IPv6 address for google though; presumably because the ipv4 DNS server it advertises (which is the router itself) still works.
If I bypass the wifi router, the ISP router gives me both an address in both fd/8 (in the same /64 as the wifi router gets assigned, which makes sense) and in 2607/16, besides the usual fe80. The ISP router is really bad, all it has is an "it's connected" indicator and a bunch of phone numbers and URLs for support.
Still bypassing, pinging `ip6-allnodes` gives me 3 responses, all with fe80::/64 addresses: my computer, an unknown, and the wifi router; I can ping those addresses, as well as the wifi router's fd/8 address.
Maybe I should play with the router's upstream settings ... "Get IPv6 address" has auto, slaac, dhcpv6, non-address ... since I can ping it from outside that has to be right. If I disable "Prefix delegation" the ::/64 box is editable but it complains about literally anything entered. And I don't have anything meaningful to manually enter a DNS address.
Hm, I just noticed that the last bit of the router's address varies between some of its addresses ...
fd::/8 addresses (really fc00::/7) are ULA addresses [0], defined as non-routable local addresses, so it’s expected that you can’t get out to the internet through just that address.
Do you have any smart home devices? Protocols like Thread and HomeKit establish their own randomly-generated ULA prefixes and advertise them through RA’s (router advertisements) and correctly-configured devices in your LAN will observe the RA for that network and generate a local address for it (including your router.) So just seeing a fd/8 address doesn’t mean your actual router gave you it, it just means that something on your network is using a ULA prefix.
Basically, it’s possible the real problem is that you’re not actually seeing an RA from a “real” (routable) IPv6 subnet when behind your router.
> If I bypass the wifi router, the ISP router gives me both an address in both fd/8 (in the same /64 as the wifi router gets assigned, which makes sense) and in 2607/16, besides the usual fe80
When you do this, can you ping out? (`ping6 2607:f8b0:4004:c17::65` or something to rule out DNS issues.)
> Maybe I should play with the router's upstream settings ... "Get IPv6 address" has auto, slaac, dhcpv6, non-address ... since I can ping it from outside that has to be right. If I disable "Prefix delegation" the ::/64 box is editable but it complains about literally anything entered. And I don't have anything meaningful to manually enter a DNS address
What you want here is dhcpv6 and prefix delegation. This will make your router ask the ISP for a real IPv6 network to use, and upon receiving this from your ISP, will send RA’s out to your local network for a “real” (2607/16 or whatever) network. A prefix length of 64 should do it, unless you need multiple subnets inside your router. (People say dhcpv6 is obsolete by SLAAC, but prefix delegation is a different thing… if you want to have your own router obtain a network prefix from an ISP, DHCPv6+PD is the only way to do this.)
Hmm, I just went deep into the settings and there's an IPv6 toggle (disabled by default, and requires playing with menus to make it actually work) now. I don't remember seeing that (and I explicitly checked) when we switched the ISP-side last April. But the firmware is dated after that, so I choose to trust my memory.
Actually trying to connect to ipv6 stuff besides the router itself (in fd00::/8, that's good) just gives "Destination unreachable: Beyond scope of source address" though (probably because I only have an fe80 link-local address though?). If I play with the settings some more I get a ::/64 address, but that just gives me a black hole ... wait, is that even a legitimate address? Do I need to fill in the prefix manually or something?
I'll play with this some more in the morning I guess. But I certainly wouldn't expect a normal user to get IPv6 working under these circumstances if I haven't figured it out yet ...