Status Update
No update yet.
Comments
hu...@google.com
Information redacted by Android Beta Feedback.
ji...@gmail.com
hu...@google.com
hu...@google.com
Thank you for reporting this issue. We have a fix rolling out in an upcoming release.
hu...@google.com
ji...@google.com
Thanks for the additional information.
It concerns support for connecting to literal IPv4 addresses such as 8.8.8.8 and 23.153.8.71
This is supposed to work on CrOS now -- if you type an IPv4 literal in the address bar of Chrome, the IPv6 synthesis logic will be invoked since it can detect that NAT64 is available (by resolving ipv4only.arpa). See
If you see any issue for reaching 8.8.8.8 in Chrome when NAT64 is available (via ipv4only.arpa), could you capture a trace following the steps in #4? Thanks!
For components other than Chrome, IPv4 literals should be supported by the CLAT daemon on CrOS, as Hugo mentioned in #2.
when the host cannot resolve any AAAA records for ipv4only.arpa, but can still discover the NAT64 prefix via PREF64
Currently, both the CLAT on CrOS and the IPv4 synthesis in Chrome won't use the PREF64 information, so it's expected that this does not work if "host cannot resolve any AAAA records for ipv4only.arpa".
hu...@google.com
hu...@google.com
Some quick update: as a temporary workaround m134 will now use the Google IPv6 DNS64 servers when setting the DNS option to "Google name servers" in Settings -> Internet -> WiFi -> $ssid -> Network foldable and the network is IPv6 only. The UI might still show 8.8.8.8, 8.8.4.4, but thsi will be fixed in a later update.
That should allows you to have IPv4 destination connectivity when RFC8925 is used but the network itself does not advertise DNS64 servers.
We are also working on enabling clat for Chrome on such networks, no timeline estimate for now.
hu...@google.com
Pref64 support will also be part of the m134 release.
Supports for routing Chrome's IPv4 traffic over CLAT will not be added before m135 (depending on complexity it could be a later release too)
Description
Potentially related to the following Android issue?:
ChromeOS version: 131.0.6778.241 (current stable version)
When connecting to a dual-stack (IPv4 and IPv6) network whose DHCPv4 server advertises DHCP option 108 ("if you support 464XLAT, please use it, i.e. exclusively use IPv6 and set up a CLAT for IPv4 connectivity"), as specified in RFC 8925 (entitled "IPv6-Only Preferred Option for DHCPv4"), ChromeOS successfully self-assigns routable IPv6 addresses (GUAs and ULAs) and can use them to connect to other IPv6 addresses, including over the public internet (e.g.https://ip6only.me/ ), but it does not successfully set up a CLAT, and thus has absolutely no IPv4 connectivity, as evidenced by the inability to connect to IPv4-only sites (e.g. Reddit, GitHub, https://ip4.me/ ). This is also evidenced by reports such as that provided by https://ip6.biz/ .
We can't advertise DHCP option 108 on our networks because of this, because this unexpectedly breaks access to services on the internet on ChromeOS devices. The only current workarounds that would allow us to work further towards IPv6-mostly/-only networking are:
(a) relegating all ChromeOS devices to their own network / VLAN whose DHCP server doesn't advertise DHCP option 108; or
(b) mandating that ChromeOS devices not be used on our premises.
As it stands, this is a major blocker for businesses that want to implement IPv6-mostly networking, because either:
(a) the presence of even just a single ChromeOS device on the network unfortunately ruins the fun for all devices, not just themselves, because it means we have to completely disable DHCP option 108 on networks where at least one ChromeOS device is present; or
(b) ChromeOS devices have to go without IPv4 connectivity on such networks due to this buggy behaviour, when they very well could just solicit an IPv4 address from the DHCPv4 server as normal, just like any other device that doesn't support RFC 8925.
If the cause of the issue is that ChromeOS has a CLAT but just doesn't configure it correctly, then the fix is either to fix the CLAT behaviour (so that 464XLAT is achieved) or to simply ignore DHCP option 108 until such fix is applied (so that ChromeOS solicits an IPv4 address from the DHCPv4 server as usual).
If the cause is that ChromeOS lacks a CLAT entirely, then it should simply ignore DHCP option 108 (so that it solicits an IPv4 address as usual).