Chrome and IPv6 adoption

[Eric Orth]

Anybody know if Chrome has any experts around on the global state of IPv6 adoption or UX implications thereof?

Context: crbug.com/1157070

User on an IPv4-only connection and tries to connect to an IPv6-only domain.  For various legacy compatibility reasons, Chrome's DNS code only attempts A queries on IPv4-only networks and thus doesn't know whether or not the domain has IPv6 addresses, only that no IPv4 addresses are found.  End result is that the user gets a generic error message about the website being unavailable/unreachable.

This is leading into multiple questions, pretty far into bigger-picture territory than just DNS handling:

• Should Chrome prioritize doing more to attempt to determine if an unreachable website might be an IPv6-only site (and thus be able to provide more accurate error messaging)?
• When on IPv4-only connections, should Chrome make some attempt to communicate that to users that their ISP or network may be providing only a partial internet experience?
• Even if not communicating in general regarding IPv4-only, should error pages for issues that may (but unconfirmed) be related communicate to users the potential IPv4-only cause?

Answering these questions and prioritizing solutions seems to require more background knowledge than I have regarding IPv6 adoption and user agency/willingness to deal with error messages on the subject.

[Matt Menke]

We could try running probes on networks where we discover lack of IPv6 support:

When we're on such a network, do IPv4 and IPv6 lookups of a known host, and time+histogram each.  Do the same for IPv4 and IPv6 connections to a known IP address (could condition this on the IPv6 lookup succeeding).

Could optionally also do this on networks where IPv6 is supported, to get a baseline.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcGhvH5ZjdS0wQgkqj%2B4iLtvs8bd6OoVnXddDWi7-UnwVw%40mail.gmail.com.

[Eric Orth]

On Mon, Dec 14, 2020 at 12:04 PM Matt Menke <mme...@chromium.org> wrote:

We could try running probes on networks where we discover lack of IPv6 support:

When we're on such a network, do IPv4 and IPv6 lookups of a known host, and time+histogram each.  Do the same for IPv4 and IPv6 connections to a known IP address (could condition this on the IPv6 lookup succeeding).

So the idea is to test if AAAA query performance might be reasonable on that network and use that knowledge to potentially reenable the AAAA queries so Chrome can actually know if a domain is IPv6-only? There's a bit of risk that even an isolated probe IPv6 query might cause issues with bad routers and cause bad performance for the normal non-probe A queries, but there's probably a good argument that the risk is minimal in 2020 now that IPv6 has been a thing for quite a while.

[Matt Menke]

Actually, I was thinking we could use the probes to get Finch data on whether we need to probe IPv6 at all, or can just get rid of the logic entirely, but it also seems reasonable to use the probes to determine if we should restrict ourselves to IPv4.

[Eric Orth]

Ah.  So if we can get such probes turned on without things going bad, that's evidence that isolated AAAA queries are safe enough.  We could then use the data from the probes experiment to determine if we could just always query A and AAAA (which would also make everyone in crbug.com/530482 happy) or if it would be better to maintain the probe to only conditionally allow AAAA queries.  Either way, if we can make AAAA queries more, that makes Chrome more likely to know if a site is IPv6-only and potentially improve error messaging.

[Matt Menke]

That plan sounds good to me, at least.

[Eric Orth]

Opened crbug.com/1158538 for that idea.  Still keeping this thread and its context bug (1157070) open for dealing with the bigger picture issues regarding error messages for IPv4-only connections, whether we do or don't get a better signal of whether or not a requested domain is IPv6-only.

[David Benjamin]

It's unclear to me if the later discussion in the bug is talking about trying to better diagnose IPv6-only sites on a IPv4-only network, or if it's about the browser proactively warning users about a v4-only network, even independent of any actual errors. Proactively warning seems a non-starter, given how many warnings that would show.

Providing better errors when a site has failed to load due to v6 connectivity seems plausible. I guess it's not immediately actionable by the user, since it's only fixable by action on either the site or the ISP. But it might give a pointer to who to talk to or let us give a better explanation. +Edward Jung may have thoughts on the UX side of that.

On the technical side, whether we can detect this case seems a question of whether we can query AAAA records more reliably now. (Is this something where Happy Eyeballs v2 would help?) If we can, it sounds like that would improve a lot of things, including allowing for better errors. If we can't, we'll probably have a hard time detecting this failure case.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH5F-zgKJuhkZo-DsvaNMLvCUU4K0uchhW8bVK6JnXxEQ%40mail.gmail.com.

[Eric Orth]

On Mon, Dec 14, 2020 at 4:36 PM David Benjamin <davi...@chromium.org> wrote:

It's unclear to me if the later discussion in the bug is talking about trying to better diagnose IPv6-only sites on a IPv4-only network, or if it's about the browser proactively warning users about a v4-only network, even independent of any actual errors. Proactively warning seems a non-starter, given how many warnings that would show. 

Providing better errors when a site has failed to load due to v6 connectivity seems plausible. I guess it's not immediately actionable by the user, since it's only fixable by action on either the site or the ISP. But it might give a pointer to who to talk to or let us give a better explanation. +Edward Jung may have thoughts on the UX side of that.

There's plenty of middleground.  We have lots of circumstances here where there is some error and we believe it's an IPv4-only network, but we don't know whether or not the requested site would have worked with IPv6 or if that really had anything to do with the error.  Would it be reasonable or helpful to warn users in such circumstances that they are on an IPv4-only network?

 

On the technical side, whether we can detect this case seems a question of whether we can query AAAA records more reliably now. (Is this something where Happy Eyeballs v2 would help?) If we can, it sounds like that would improve a lot of things, including allowing for better errors. If we can't, we'll probably have a hard time detecting this failure case.

Two semi-related issues with querying AAAA:

(1) Would it kick bad routers into a bad situation where they start performing poorly for A queries too?

(2) Would AAAA queries perform poorly compared to A queries and thus slow down our overall resolve times if we keep blocking on the AAAA results?

Happy Eyeballs v2 absolutely would help with (2), but would still be dangerous if (1) is an actual issue.  Note that (1) is a similar fear to the multiple simultaneous DNS queries that Chrome is historically hesitant to do but that there are some currently-active experiments around.  So if those experiments go well, it may be a good sign that truly horrible routers and issue (1) are no longer significant issues.

[Eric Orth]

Offlist, a Google IPv6 expert pointed me to this dashboard and the backing data behind it to show levels of IPv6 adoption.  33% adoption globally, with some really big regional differences.  Overall, good to see that IPv6 is slowly gaining traction, but I think that confirms my suspicions from crbug.com/1157070 that IPv6 adoption still isn't at a level where it would it would be super reasonable to assume possible IPv6 problems are at fault when we have errors that are not confirmed to be with an IPv6-only site.  I think we'd just be unreasonably annoying users with unreasonable assumptions.

So unless somebody really wants to argue that Chrome should still be more proactive about trying to communicate about IPv4-only connections, I think that leads back into the strategy of trying to better determine when a domain is IPv6-only to better communicate those specifically-determined errors.

[Matt Menke]

I think it's worth pointing out that just because someone doesn't have IPv6 access doesn't mean IPv6 DNS requests / connection attempts would necessarily cause things to fail in problematic ways.

[Eric Orth]

Absolutely correct, but no IPv6 access does have a correlation with potential issues from AAAA queries (because the router blocking IPv6 access is often the same device that would be handling DNS queries), and the situation even more so limits the potential benefits of making AAAA queries (you likely can't connect to the results, so you don't get much out of it other than better error messaging in this one case or better handling for edge cases where we've misdiagnosed IPv6 connectivity).

[Eric Orth]

Another potential solution I just thought of (assuming we decide that the only risk of making AAAA queries is potentially blocking A queries without Happy Eyeballs v2): We leave the main request logic as-is, only doing A queries when Chrome believes the connection to be IPv4-only.  But we improve the DNS diagnostic probes (that run after DNS issues to help determine the error messaging to users) to always allow AAAA queries (I think they currently only ever query A) and use those results to determine if we're in this problem situation.