Apologies if this exact question has been posted and answered on the forum already. I did a quick search, but never found anything with a concrete solution.
I have FTTP and have recently bought/installed the Nest WiFi soloution by Google. As I have FTTP I already have an Openreach Modem installed and have connected my Nest router directly to that. I had no issues getting the Internet up and running using this method, but am unable to enable IPv6 on the Nest router. I've found a number of articles on the internet regards a number of 1st Gen Google Wifi users having this issue after a software update back in 2018, but as Nest WiFi is the second gen it shouldn't be affected (confirmed by Google Support).
I raised a case with Google support who have checked/tried numerous things to get IPv6 up and running, but to no avail. The Google Support Tech seems to think the Openeach modem being put into Bridge mode could help, but as the modem is essentially a piece of Openreach infrastructure used by all ISP's, I doubt this is a valid route and in either case, not something the customer (me) has admin access to support.
I've also tested hooking the Nest Router into the BT Smarthub, but although this works for IPv4 Internet access it still doesn't seem to support IPv6 connectivity.
I can see that the BT SmartHub is allocated a /56 prefix on the WAN interface (/64 to clients), so would expect the same for the Nest router. But I'm curious if anyone knows how this /56 prefix is allocated and/or if BT have somehow restricted it for use with their SmartHubs only?
Anyone on hear found similar issues and did you ever get a proper resolution?
Its /56PD and should work with any router. There seem to be a number of third party devices that don't support BT's implementation and only support /64PD.
The modem (ONT) will be in bridge mode in any case.
Thanks for the reply licqourice.
That's good info regards the modem - rules out one factor anyway. 😊
Support suggests the nest wifi router will support a prefix list of /64 or less. In fact it recommends a lower prefix so that it can provision IPv6 on any guest networks that are setup as well.
Out of interest, do you know if the BT provide the IPv6 allocation by DHCPv6, or does it expect the router to use SLAAC?
I think it is actually DHCPv6 PD. As you say, Google Wifi should support this, but it doesn't. I raised a case with Google but got nowhere.
Thanks for all replies and advice. I've also opened a case with Google as I initially blamed the nest, but now I'm not so sure.
I connected my laptop directly to the openreach modem and established a pppoe connection, but still got no ipv6 address allocated.
I plan on doing this again over the weekend whilst capturing traffic on my ethernet interface, so will update the post if I get anywhere.
They asked me to try this as well. Had a go and no IPv6. This looks like it is because the DHCP behaviour of a Window ls DHCP client is not the same as in a router. A router will send a DHCP request using prefix delegation. A client will not
DHCPv6 Prefix Delegation is intended for network elements that behave as a router. The terminology used in RFC 3633 [“IPv6 Prefix Options for DHCPv6“] indicates this: the client requesting an IPv6 prefix is called the “requesting router”, and the server which leases the IPv6 prefix is termed the “delegating router”. Since the host running Windows Vista doesn’t behave as a router by default, the DHCPv6 client doesn’t request an IPv6 prefix by default from the server.
this references Windows vista but I believe it still applied l applies to 10.
A quick update for anyone that's interested...
I've not had any further correspondence with Google support or BT in relation to this ipv6 issue, but for some unknown reason my nest router managed to pick up an ipv6 allocation on its own accord yesterday. Nothing was changed on my part, but it did seem to coincide with a brief disconnection/reconnection of my internet connection. It doesn't appear that the nest firmware has updated either, so I suspect that the ipv6 allocation could disappear the next time there is a similar reconnection event, but I'll monitor for that. If that does happen then it may raise more questions about the ipv6 support generally and root cause of the issue.
Interestingly I am now able to turn on IPv6 in the app. It doesn't work though, says it is enabled but your ISP doesn't support it...