> This is quite surprising! Is there any explanation for this observed behavior? Are there saturated v4 paths that have a less congested v6 alternative? Are CG-

> This is quite surprising! Is there any explanation for this observed behavior? Are there saturated v4 paths that have a less congested v6 alternative? Are CG-NATs adding that much latency? I can give a few theories. Some CGNAT setups do add a lot of latency (e.g. T-Mobile hand v6 traffic off locally where possible but v4 has to be hauled to one of their CGNAT installations, which might be a long way away). Some CGNATs are outright overloaded. v6 doesn't have a checksum, so routers don't need to update the checksum when they fiddle the TTL header. NAT must add some latency too. A "page load" involves lots of round-trips, so even a very small difference in round-trip time can add up to make a bigger difference in page load time. (This does suggest that improvements to HTTP and rate control algorithms to reduce the number of round-trips would narrow the difference.) > I think you're thinking about the eyeball ISP side here I was thinking about "company internal" networks, both their own internal networks but also the internal parts of their hosting setups. In hosting, it's generally true that you need to handle v4-only clients... but that can be handled entirely at the edge by your load balancers or by NAT46, it doesn't force you to use v4 inside at all. You can use v6 inside, and it'll be easier and cheaper than v4 for the reasons I mentioned. > we might well be stuck with a long tail of IPv4-only properties for the next decade or more NAT64 can handle the long tail of v4-only websites for v6-only clients, so this is actually okay. It's not blocking deployment of v6 or undeployment of v4. The only real problem it causes is that people use it as an excuse to not do v6...