net: Happ{y,yish,ier} Eyeballs should give the preferred family a head start

[pmarks-net]

Forked from issue #8453.

The Happy Eyeballs implementation used by net.Dialer{DualStack: true} sends IPv4 and
IPv6 SYNs simultaneously, and the resulting address family is unpredictable.

This is harmful for two reasons:
- It increases server load in the common case, by always sending two SYNs.
- Dual-stack clients cannot reliably use IPv6 to route around NATs.  The primary
incentive for a network operator to deploy IPv6 is to reduce NAT load (and therefore
save money), but this sort of client behavior invalidates that incentive.


http://tools.ietf.org/html/rfc6555#section-4.1 says:

"""
   Thus, to avoid harming IPv4-only hosts, implementations MUST prefer
   the first IP address family returned by the host's address preference
   policy, unless implementing a stateful algorithm described in
   Section 4.2.  This usually means giving preference to IPv6 over IPv4,
   although that preference can be overridden by user configuration or
   by network configuration [ADDR-SELECT].  If the host's policy is
   unknown or not attainable, implementations MUST prefer IPv6 over
   IPv4.
"""


When the DualStack flag is true, clients should follow this algorithm:

  Call getaddrinfo()
  Note the family of address[0], and start a routine which connects to each address of that family, in order.
  After ~300ms, start a second routine which connects to addresses *not* of that family, in order.
  Meanwhile:
  - If the first routine terminates before 300ms, start the second routine immediately.
  - When one routine succeeds, cancel the other.


There's room for flexibility in the details, but the important point is that under
normal network conditions, a client should send exactly one SYN to the first address
reported by getaddrinfo().

[mikioh]

Comment 1:

off topic:
> The primary incentive for a network operator to deploy IPv6 is to reduce NAT load (and
therefore save money)
really? (from APNIC region ;)  but pretty interesting, is that common in ARIN/RIPE
regions recently?

[mikioh]

Comment 2:

Labels changed: added repo-main.

[pmarks-net]

Comment 3:

>> The primary incentive for a network operator to deploy IPv6 is to reduce NAT load
(and therefore save money)
> really? (from APNIC region ;)  but pretty interesting, is that common in ARIN/RIPE
regions recently?
Well, the primary incentive *should* be to preserve the Internet as a platform of
freedom and innovation, but for a hypothetical ISP who only cares about cost, IPv6 makes
more sense if you know that you won't have to keep scaling up your IPv4 NAT
infrastructure forever.
That said, I don't personally know what the operators are thinking.

[mikioh]

Comment 4:

> There's room for flexibility in the details....
For the record: as discussed other issue, current implementation is happi{sh,er}
eyeballs" as described in
http://www.potaroo.net/presentations/2012-04-17-dual-stack-quality.pdf.

[gopherbot]

Comment 5 by google@barrera.io:

By ignoring the address ordering a more important issue arises:
Since they always prefer IPv4 unconditionally, all golang applications fail to establish
any network connections on IPv6-only hosts. I've seen this behavious consistenly across
several golang applications: they can never connect to any host. (And I don't have any
native IPv4 connectivity most of the time).

[mikioh]

@pmarks-net is working on this issue.

[gopherbot]

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