IssueTracker

but it does not successfully set up a CLAT, and thus has absolutely no IPv4 connectivity

This is not true to assume that not having CLAT prevents connectivity to IPv4 destinations. Applications can be NAT64 aware directly or indirectly (eg Apple IOS SDK handles that at the DNS layer)

It is true that ChromeOS does not have a system-wide CLAT component for all host services and processes.

Instead:

• OS components talking to 1P servers (system updates, crash reports, etc) are expected to work on IPv6-only networks with IPv6 destinations, i.e IPv4 connectivity is not necessary.
• Chrome has its own translation mechanism for reaching IPv4 destinations through a NAT64 gateway and does not assume that CLAT is available.

CLAT in ChromeOS is used in two contexts only:

• Android Apps use the standard Android 464xlat system, this is specific to the Android environment
• tayga is used for setting CLAT with Linux VMs only

As a data point, Google's internal corp network has been mostly IPv6 in all offices for multiple years and ChromeOS is beeing successfully used by employees with RFC 8925 enabled for about a year. We have other customers which have successfully deployed IPv6 environment or are using DHCP option 108.

, as evidenced by the inability to connect to IPv4-only sites (e.g. Reddit, GitHub, https://ip4.me/)

Could we focus on the concrete issues you are facing here. Can you describe in more detail the network environment where you observe this problem in Chrome: how is NAT64 setup, do you have DNS64 available ?

Many thanks for your swift reply.

Could we focus on the concrete issues you are facing here. Can you describe in more detail the network environment where you observe this problem in Chrome: how is NAT64 setup, do you have DNS64 available?

My border routers provide NAT64 using the well-known prefix, 64:ff9b::/96, via Jool in NAT64 mode (no manual BIB table entries, just pool6=64:ff9b::/96, full config below). DNS64 is not in use, but the border routers provide regular DNS, and the IPv6 addresses of these DNS servers are advertised in the RAs (and their IPv4 addresses in DHCPv4 responses) of all routers on the network. These DNS servers do advertise the NAT64 prefix by answering AAAA queries for ipv4only.arpa with 64:ff9b::c000:ab (64:ff9b::192.0.0.170) and 64:ff9b::c000:aa (64:ff9b::192.0.0.171). The RAs also advertise the prefix using the PREF64 option.

Jool config:

{
	"instance": "nat64",
	"framework": "netfilter",
	"global": {
		"pool6": "64:ff9b::/96",
		"maximum-simultaneous-opens": 1024,
		"source-icmpv6-errors-better": true
	}
}

Please don't hesitate to let me know if you need any additional info.

Thanks for the details.

These DNS servers do advertise the NAT64 prefix by answering AAAA queries for ipv4only.arpa with 64:ff9b::c000:ab

From memory, this is how Chrome determines if NAT64 is available. So at this point I would expect Chrome to be able to reach an IPv4-only destination by crafting the IPv4 embedded address with the NAT64 prefix.

I think the next step would be for you to capture a chrome://net-export capture to repro the problem:

• connect to your network with DHCP option 108 enabled
• verify that the Chromebook removes the IPv4 configuration and switch to IPv6-only
• go to chrome://net-export
• start a capture
• repro the connectivity problem with IPv4-only destination
• stop the capture

Thanks

We did some checks on our side (thanks jiejiang@ and jasongustaman@) and I was wrong about #2: it turns out Chrome actually does not generates IPv4 embedded addresses with the nat64 prefix from hostnames alone. Since we don't use CLAT with Chrome, RFC8925 on ChromeOS effectively has an implicit requirement that the network supports DNS64 otherwise IPv4 only destinations are not browsable. My apologies about the misleading and incorrect explanations in #2.

I've read quickly RFC8925 again and there isn't any strong requirements on what the network is supposed to offer or what the client is supposed to support. But options for IPv4 connectivity are:

• RFC8925, + NAT64 on the network, + DNS64 (network-side, or client OS-side, or client-application-side)
• or RFC8925, + NAT64 on the network, + CLAT on client.

On ChromeOS, possible options to support RFC8925 with IPv6-only networks that don't have DNS64 could be:

• using the OS dns-proxy service to play the role of DNS64, but when Chrome is configured with always-on-Secure-DNS Chrome will connect directly with the remote DNS server and not use the OS dns-proxy service
• using CLAT with Chrome

jivan.pal@gmail.com, if you want to keep DHCP option 108 for now and have a small amount of chromebooks to manage you can still disable the RFC8925 feature with chrome://flags#enable-rfc8925

After discussing both options internally, we think that CLAT is the most promising.

We would need to

• implementing PREF64 for better correctness of the NAT64 prefix
• changing the CLAT routing setup to have a special routing rule for sending IPv4 traffic from the chrome UID to the CLAT nat64 interface routing table (priority is TBD)

There is one potential concern with the performance impact of CLAT which is currently implemented with a userspace daemon. Especially in the case when DNS server returns A or AAAA records at the same time, with Chrome's happy eye ball we expect both addresses to be tried in parallel with an advantage to v6.

At the moment we don't have any clear estimate on when this problem could be fixed.

it turns out Chrome actually does not generates IPv4 embedded addresses with the nat64 prefix from hostnames alone. Since we don't use CLAT with Chrome, RFC8925 on ChromeOS effectively has an implicit requirement that the network supports DNS64 otherwise IPv4 only destinations are not browsable.

I've read quickly RFC8925 again and there isn't any strong requirements on what the network is supposed to offer or what the client is supposed to support.

Please refer to sections 1.2, 3.2, and 4 of RFC8925, particularly the definitions of "IPv6-only-capable host", "IPv6-mostly network", and "IPv6-only network". From this, it should be clear that DNS64 is not a hard requirement, only NAT64 or something functionally equivalent is. DNS64 is not functionally equivalent to NAT64. In fact, NAT64 is a dependency of DNS64.

This bug report does not concern the resolution of hostnames to IP addresses. It concerns support for connecting to literal IPv4 addresses such as 8.8.8.8 and 23.153.8.71 (that of the IPv4-only service ip4.me) on an IPv6-only/-mostly network. This is not about resolving domain names such as dns.google and ip4.me to IPv4-mapped IPv6 addresses if such domain names do not have any AAAA records in the public DNS. As you point out, DNS64 alone would solve the latter problem. RFC8925 / DHCP option 108 is intended to allow clients to advertise support for 464XLAT-style networking, and allow DHCPv4 servers to tell such clients that they may switch off IPv4 only if they support such networking and discover sufficient info to use it, such as a NAT64 prefix. The ability to connect to literal IPv4 addresses is still of importance on networks where DNS64 is present, since it affects situations where domain names are not used (such as when connecting to a Discord voice chat / VOIP channel, in which Discord's VOIP coordination server discloses the literal IPv4 address of an available WebRTC relay to the Discord client, without the use of any domain name for it).

As mentioned in the original submission, if ChromeOS does not support converting IPv4 addresses such as 1.1.1.1 to IPv4-mapped IPv6 addresses such as 64:ff9b::101:101 (regardless of how that conversion is done, such as by a CLAT implementation like clatd/Tayga or otherwise) given knowledge of the NAT64 prefix (regardless of how that knowledge is obtained, such as by resolving AAAA records for ipv4only.arpa or reading the PREF64 option of an IPv6 RA), then it ought not advertise support for DHCP option 108 in DISCOVER and REQUEST messages, should ignore option 108 in any OFFER responses, and should still solicit an IPv4 address from the DHCPv4 server and use it. Section 4 of the RFC concedes that "declaring a host (technically, a host interface) IPv6-only capable is [an OS vendor] policy decision", but the fact is that ChromeOS's current behaviour is still undesirable, because even if the client has access to a DNS64 server, it breaks users' ability to use IPv4-only services that do not rely on domain names (such as Discord VOIP), since domain name resolution is irrelevant in such cases.

I am still waiting for an opportunity to get the requested packet captures, if you would still like those. I also intend to test behaviour when the host cannot resolve any AAAA records for ipv4only.arpa, but can still discover the NAT64 prefix via PREF64.

Cheers

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 https://crbug.com/40606537 for more details about this feature in Chrome.

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".

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.

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)