Comment 1:

http://tools.ietf.org/html/rfc6555

Comment 2:

Yes, we discussed this briefly on golang-dev in 5486078 as part of issue #240.  The
DialAttempt SoftTimeout.  We went with a considerably milder CL for Go 1 because the
deadline was coming too quickly to do the whole DialPlan thing comfortably.

Comment 3:

Brad, do you still have the DialPlan sketch? Can you drop it in here?

Comment 4:

Labels changed: added go1.1.

Comment 5:

DialPlan sketch (reconstructed from a poor photo and memory):
https://golang.org/cl/5486078/

Comment 6:

Related, a user is discussing how DialTimeout is insufficient for them because they need
to set the DialTCP local address along with a timeout, and we have no API that can do
both.
Now that issue #2631 is being fixed by https://golang.org/cl/6815049, we can at
least properly set the dial timeout.
Adding DialTCPTimeout and DialUnixTimeout and DialIPTimeout (and everything Timeout)
would be unfortunate.  Using DialPlan (or something like it) would be preferred.

Comment 7:

Well, I just wanted, still want to have a simple and improved Dial that runs 
both IPv4 and IPv6 racers under the hood. ;) I'm fine with DialPlan or whatever.
A question: Do you guys suppose that DialPlan would be a sort of connection 
pooling? (expect: no)

Comment 8:

Looks like requirements for DialPlan would be:
R1. It must take various dial targets
a) DNS names
b) IP addresses
c) Combo of (a) and (b)
R2. It must run Happy Eyeballs dialing if the given target is a DNS name
R3. It must take various dial strategies (optional?)
a) Round-robin
b) Run through
R4. It must take various dial deadlines
a) Deadline for each dial
b) Deadline for entire dial list
Thoughts?

Comment 9:

No connection pooling.

Comment 10:

Labels changed: added size-l.

Comment 11 by paul@vanbrouwershaven.com:

Are there any plans to continue the development of this DialPlan function?
While the issue in DialTimeout is closed by https://golang.org/cl/6815049 it
has no option to specify a local address to bind to. This DialPlan function would make
it all much more flexible.

Comment 12:

See also issue #4842 (TCP Fast Open)

Comment 13:

This issue was updated by revision 752fec2.

Update issue #4842
R=golang-dev, r, dave, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7365049

Comment 15:

How is it blocked on 4056? The situation with thread creation may be better with the new
scheduler.

Comment 16:

Ah, I misunderstood that happy eyeballs will require one more DNS lookup, not true.
Anyway, very happy to see new scheduler, yay!

Comment 17:

Seems like there's still a lot left on this. I'm inclined to postpone it to Go 1.2
unless someone can argue that it's important and also that it's simple and can be done
quickly.
Thoughts?

Comment 18:

Later.
Most Go usage is on servers where IPv6 connectivity is relatively reliable.  It's
clients (at home, behind crappy NAT boxes and crappy ISPs) who need Happy Eyeballs the
most, so this is somewhat low priority, even though it'd be fun.
It's also likely that in a year's time, IPv6 will be much better deployed in the wild. 
If it gets done before Go 1.2, great, but it shouldn't block Go 1.1.

Labels changed: removed go1.1.

Comment 19:

Owner changed to ---.

Comment 20:

Labels changed: added go1.2maybe.

Comment 21:

Labels changed: added feature.

Comment 22:

This issue was updated by revision f0291a8.

Update issue #5267
Update issue #5707
R=golang-dev, bradfitz, dave, fvbommel
CC=golang-dev
https://golang.org/cl/11958043

Comment 23:

Status changed to Started.

Comment 24:

This issue was updated by revision 3c6558a.

Update issue #5267
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13368044

Comment 25:

This issue was updated by revision 20692c2.

Update issue #5267
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13241046

Comment 26:

This issue was updated by revision 7c59c8b.

Update issue #5267
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13374043

Comment 27:

This issue was updated by revision c576bcb.

Update issue #5267
Update issue #5707
R=golang-dev, bradfitz, dave
CC=golang-dev
https://golang.org/cl/13465043

Comment 28:

What is missing from this?

Comment 29:

The review of the last CL in progress.
https://golang.org/cl/12416043/

Comment 30:

This issue was closed by revision 89b2676.

Status changed to Fixed.

Comment 31:

This Happy Eyeballs implementation does not comply with
http://tools.ietf.org/html/rfc6555#section-4.1
"""
   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.
"""
Note that "MUST" is stronger than "SHOULD" in RFC-speak.
I wrote a test client, and repeated invocations show that IPv4 and IPv6
addresses are reported at random.  This behavior is considered harmful,
for the reasons laid out in section 4.1
Here's the test client I'm using:
package main
import (
        "net"
        "fmt"
)
func main() {
        dialer := net.Dialer{DualStack: true}
        conn, err := dialer.Dial("tcp", "ds.test-ipv6.com:80")
        if err != nil {
                panic("Dial")
        }
        fmt.Fprintf(conn, "GET /ip/ HTTP/1.0\r\n\r\n")
        buf := make([]byte, 4096)
        conn.Read(buf)
        println(string(buf))
}

Comment 32:

Yup, as described in the CL description, the current implementation is not compliant for
RFC 6555. It runs two TCP syn racers simultenaously without dealing with address family
preferences as described in Geoff Huston's slides. Please open new issue if you think we
should make it compliant to RFC 6555.

Comment 33:

Filed issue #8453.