If getaddrinfo will no longer be the default resolver in Go 1.5, then this feature needs to be a release blocker. Address selection is a central feature of getaddrinfo which cannot simply be discarded.

Without getaddrinfo, the IPv4/IPv6 address selection is currently race-based. This will cause Go clients to behave unpredictably when connecting to dual-stack names.

/cc @mikioh @mdempsky

It would help to understand why/how this is release blocking. E.g., is simply implementing the RFC 6724 default sorting functionality sufficient? Or do we need to support glibc /etc/gai.conf (and equivalents on other OSes) too?

Hard-coding the RFC 6724 rules would solve 99% of the problem, and I would not personally object to leaving the full gai.conf parser for post-1.5.

Pragmatically, the parts that really matter for Internet connectivity are:

• Avoid unusable destinations.
• If IPv6 would use a 6to4/Teredo/ULA source address, then prefer IPv4.
• Otherwise prefer IPv6.

The standard approach is to probe each address using UDP connect and getsockname, to obtain reachability and source address information from the kernel.

The current resolver picks IPv4/IPv6 at random. Even if both are available, this is undesirable for network and service operators because it makes IPv6 less effective as a NAT offloading tool, and logging/debugging gets annoying when the client can't make up its mind.

On an IPv4-only or IPv6-only machine, preferring the wrong family causes dialSerial to spin through a few ENETUNREACHes before finding an address that works. This is quite fast on Linux, but I've observed that Windows consistently takes 1 second for connect to fail, which is noticeable but not catastrophic.

6to4/Teredo have proven to be unreliable on the Internet, so not de-preffing those means that a small fraction of users will have a really bad time.

I'd like to postpone handling this sort of, dual IP stack, issues to Go 1.6. The upcoming Go 1.5 contains @pmarks-net's Happy Eyeballs implementation and it could provide fairly better TCP connection setup than released versions on various environments such as IPv4-only, IPv6-only, dual IP stack w/o translation techniques or with XLAT, MAP-T or DS-lite, MAP-E-like translation techniques. Performance and connectivity improvements are desirable. But before doing that, I think we need to address issues in the real world carefully.

Random thoughts:

• We don't need to consider 6to4 any more. See https://tools.ietf.org/html/rfc7520 https://tools.ietf.org/html/rfc7526
• Both http://www.ietf.org/mail-archive/web/v6ops/current/msg22275.html and http://www.ietf.org/mail-archive/web/v6ops/current/msg22290.html threads are pretty interesting

@mikioh I don't understand what point you're trying to convey. Are you suggesting that we leave things as-is, and give users a resolver with random address preference in 1.5?

Real world networks are designed under the assumption that endpoints will attempt to follow the RFCs; that's why the RFCs exist.

I reiterate that random address preference is a Really Bad Idea; Happy Eyeballs would do a reasonable job of hiding the ensuing brokenness, but that isn't enabled by default (and probably shouldn't be, until dialTCP supports cancellation.)

RFC 7050 relates to NAT64, which is unrelated to 6to4. As for why 6to4 source addresses must be de-preferred, this site has relevant data: http://www.fud.no/ipv6/

Back before the first World IPv6 Day, lots of users had broken 6to4 connectivity and preferred IPv6, which resulted in long timeouts when connecting to dual-stack hostnames. The problem largely disappeared in 2011, when the last of the major browsers fixed their address selection rules.

Since the data is browser-based, we no longer know how bad the problem would be if those fixes were dropped. It might be better, might be worse, but nobody is looking anymore.

Ouch, I meant https://tools.ietf.org/html/rfc7526.

@pmarks-net,

I'm not convinced of implementing non-configurable destination address selection described in RFC 6724 would solve 99% of the problem, because it would probably interfere with user's DNS recursor stuff, and when #11450 would be a solution for it there's no need to use builtin DNS stub resolver, but I may be wrong.

RFC 7526 does not imply that address selectors can delete their 6to4 rules; on the contrary, it means that de-preferring 6to4 is even more important, because wherever 6to4 has been deployed, it is now more likely to provide broken connectivity. Since most other clients follow RFC 3484/6724, this brokenness will predominantly affect clients written in Go.

RFC 7526 explicitly states:

The default address selection rules specified in [RFC6724] are not modified.
...
All hosts using 6to4 MUST support the IPv6-address-selection policy described in [RFC6724].

Could you clarify how RFC 6724 might interfere with DNS recursion?

If I understand correctly RFC 6724 leaves issues on various site-specific implementations to site operators. If a site that implements DNS full service resolver stuff prefers IPv4 rather than IPv6, non-configurable address selection policy might annoy the site operator. For example, what if they use a plain-old DNS round-robin as a last resort? This sort of issue happens not only for an IPv6-to-IPv4 fallback case but for an IPv6-to-IPv6 fallback case; what if a node has multiple prefixes and one of the prefixes is not global routable?

I agree on fixing this issue is necessary, and personally hope it comes with some interface for site operators.

CL https://golang.org/cl/12246 mentions this issue.