<p dir="auto">by <strong><a href="mailto:google@barrera.io">google@barrera.io</a></strong>:</p>
<pre class="notranslate">$ go version
go version go1.2.2 linux/amd64
$ cat test.go 
package main

import "net"
import "fmt"

func main() {
        conn, err := net.Dial("tcp", "google.com:80")
        if err != nil {
                fmt.Println(err)
        }
        fmt.Fprintf(conn, "GET / HTTP/1.0\r\n\r\n")
}
$ go run test.go
dial tcp 173.194.42.72:80: network is unreachable

---

This is happening on an IPv6-only host, so there should be no attempt to connect to the
above IPv4, and instead, try the IPv6 (eg: the AAAA record) one instead.</pre>
<pre class="notranslate">Forking this from <a href="https://golang.org/issue/3610" rel="nofollow">issue #3610</a>.

My experiments show that net.Dial has two modes of operation when connecting to a
dual-stack hostname:

1. By default, it prefers IPv4 :(
2. When using a net.Dialer{DualStack: true}, IPv4 and IPv6 SYNs are sent simultaneously,
and the resulting address family is unpredictable.

The latter violates a "MUST" in the Happy Eyeballs RFC:
<a href="http://tools.ietf.org/html/rfc6555#section-4.1" rel="nofollow">http://tools.ietf.org/html/rfc6555#section-4.1</a>

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.</pre>