It's possible that they are using some other protocol for IPv6 other than DHCPv6.
If you can find that out, maybe the only thing needed will be to ask them to activate it, without renting the Eero from them.
I'd try this first, to see what your ISP is actually offering by way of IPv6 routers. (You may need to do opkg update ; opkg install tcpdump first.)
You can listen on your WAN interface (mine is eth0, yours may be different, do ip a and you'll see it). This should dump all of the router advertisements being sent by your ISP, be patient, could be a minute or two between packets, I'd wait no longer that 10 minutes before giving up.
As an example, here's my ISP's (Cox) upstream Cisco router telling me it's alive and ready to server:
Here's another thing I've just been playing with. Try to ping the "all routers" multicast address, and see if you get any response.
The count -c2 has to be greater than 1 for ping to collect all the responses from the first send. The fe80:... is the LLA (Link Local Address) of your WAN interface, again do ip a and there should be exactly one address with that prefix on the interface. As above eth0 is the name of your WAN interface. ff02::2 is the multicast address meaning "All Routers" (https://www.rfc-editor.org/rfc/rfc4291.html#section-2.7.1).
Note in example below that we get a response from "ourselves", i.e., we see that first and last address duplicate the LLA of the OpenWrt router from which I'm sending the ping. Note also that the address ending in 8419 is that same Cox Cisco box that sent the RA in my previous post.
# Change 'fe80::...' and 'eth0' to match values from your router.
$ ping6 -c2 -I fe80::20d:b9ff:fe5a:4d8c%eth0 ff02::2
PING ff02::2 (ff02::2) from fe80::20e:b9ff:fe5a:4d8c%2: 56 data bytes
64 bytes from fe80::20e:b9ff:fe5a:4d8c: seq=0 ttl=64 time=0.657 ms
64 bytes from fe80::227:90ff:fe0d:8419: seq=0 ttl=64 time=7.829 ms (DUP!)
64 bytes from fe80::20e:b9ff:fe5a:4d8c: seq=1 ttl=64 time=0.560 ms
--- ff02::2 ping statistics ---
2 packets transmitted, 2 packets received, 1 duplicates, 0% packet loss
round-trip min/avg/max = 0.560/3.015/7.829 ms
It could be the rep was confusing IPv6 with WiFi 6.
There are tunnel methods for an ISP to offer IPv6 without IPv6 packets appearing natively on the cable, as their internal network remains IPv4 only. The customer's router would need to run a tunnel client (OpenWrt supports this). This is not very common any more though.
*For Most Ethernet customers serviced by Non-GPON Symmetrical services.
Not sure what that means. GPON (the most common type of home fiber Internet) is not included?
The default configuration of OpenWrt should pick up a SLAAC address on wan (which will be shown in IPv6 Upstream on the main status page), but if it is only a single /64 you'll need to set up relay mode for the rest of your network.
from my debugging a similar issue, I used tcpdump (via wireshark), and could see that slaac was failing, i.e. the computer would send a router solicitation packet, but the router advertisement packet was never returned.
So it seems it's for astounds home internet, ipv6 is not supported at their end.
my service is asymmetric (not symmetric), and cable (not fiber)
Same problem here; I just noticed it. I could have sworn I used to get assigned an ipv6 address, even some of my lan devices are getting an ipv6 address.
I was trying to follow this post, but don't where in the config I should put noacceptreconfig '1'.