net: make Dial(listener.Addr().String()) always work, even if machine's IPv6 config is not ideal

[bradfitz]

I just hit a problem in grpc-go (grpc/grpc-go#1058) where their tests were assuming they could write code like this:

        lis, err := net.Listen("tcp", ":0")
        if err != nil {
                t.Fatalf("Failed to listen: %v", err)
        }
        conn, err := net.Dial("tcp", lis.Addr().String())

The code looks reasonable, and often works (on both Go 1.7 and Go 1.8, on Linux and Darwin).

But not always.

lis.Addr().String() returns [::]:NNNNN, which looks like an IPv6 address literal for all zeros (like 0.0.0.0), regardless of whether the machine has IPv6.

And if a machine doesn't have an IPv6 address on the loopback interface, then net.Dial("tcp", "[::]:12345") fails.

But it passes otherwise.

The net.Dial documentation (https://beta.golang.org/pkg/net/#Dial) is kinda fuzzy on whether dialing the all zero address works. It does document and implement this behavior this, though:

If the host is empty, as in ":80", the local system is assumed.

Thus, the solution for gRPC's tests and anybody else is apparently adding something hacky like:

// dialAddr returns a valid net.Dial address to dial using network "tcp".
func dialAddr(ln net.Listener) string {
	addr := ln.Addr().String()
	addr = strings.TrimPrefix(addr, "[::]")
	addr = strings.TrimPrefix(addr, "0.0.0.0")
	return addr
}

But that's kinda lame and tedious.

Maybe we should just treat a net.Dial of [::] or 0.0.0.0 the same as an empty string for the host part?

/cc @mikioh @rsc @ianlancetaylor @MakMukhi

[ghost]

I vaguely remember some problem with a Go code when I was using a linux kernel with IPv6 disabled.

[rsc]

Maybe we should just treat a net.Dial of [::] or 0.0.0.0 the same as an empty string for the host part?

@bradfitz I'm pretty sure that's how it worked originally.

[bradfitz]

@rsc, I'll try older Go versions to see when/if it changed.

[pmarks-net]

That's precisely why you shouldn't remove ::1 from your loopback interface. It creates an asymmetry between the bind and connect socket APIs: a server can bind to [::]:port, but clients can't connect to it unless ::1 is available.

We've been trying to stomp out this configuration across Google machines because it's a pain to work around.

[pmarks-net]

But in terms of a practical workaround, Go could probably interpret dialing "[::]:80" or ":80" as:

"[::]:80, with sequential fallback to 0.0.0.0:80"

Replacing it with localhost:80 also works in most cases, unless your server socket is actually IPv6-only, and localhost is 127.0.0.1-only.

[bradfitz]

Paul, I didn't manually do anything to this machine. It started life as a default GCE VM and has remained untouched networking wise.

[pmarks-net]

Does ping6 ::1 work? What's the Linux distro and version?

[bradfitz]

$ ping6 ::1 
connect: Network is unreachable

$ lsb_release  -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.6 (jessie)
Release:        8.6
Codename:       jessie

$ ip route
default via 10.240.0.1 dev eth0 
10.240.0.1 dev eth0  scope link 
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 42:01:0a:f0:00:0c brd ff:ff:ff:ff:ff:ff
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default 
    link/ether 02:42:4c:05:d8:a5 brd ff:ff:ff:ff:ff:ff

$ cat /proc/net/tcp6 
  sl  local_address                         remote_address                        st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode
   0: 00000000000000000000000000000000:0016 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 665 1 ffff8800ba94c800 100 0 0 10 0
   1: 00000000000000000000000000000000:1F41 00000000000000000000000000000000:0000 0A 00000000:00000000 00:00000000 00000000  1000        0 12321728 1 ffff8800ba94c040 100 0 0 10 0

Again, this was just a GCE instance I created for development about a year ago and occasionally turn off and turn back on.

[pmarks-net]

about a year ago

http://b/18777177 was fixed in April 2016, so your GCE image likely predates it.

This was the relevant config change: andsens/bootstrap-vz@15c7d1c

[bradfitz]

@pmarks-net, regardless, this bug is about whether Go guarantees my posted program at top is always valid.

I don't want those guarantees to depend on your sysctl knobs being set a certain way.

But for the record,

# /sbin/sysctl  -a | grep ipv6 | grep able
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.docker0.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.neigh.default.base_reachable_time_ms = 30000
net.ipv6.neigh.docker0.base_reachable_time_ms = 30000
net.ipv6.neigh.eth0.base_reachable_time_ms = 30000
net.ipv6.neigh.lo.base_reachable_time_ms = 30000

I only have that one line in:

$ cat /etc/sysctl.d/70-disable-ipv6.conf 
net.ipv6.conf.all.disable_ipv6 = 1

But looks sane, and like something somebody might write.

I see no reason Go shouldn't be consistent even on such a machine.

[gopherbot]

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

[bradfitz]

@ianlancetaylor and I looked into this. What @pmarks-net said in #18806 (comment) looks doable. I'll send a change.

[gopherbot]

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

[gopherbot]

Change https://golang.org/cl/47554 mentions this issue: net: don't return IPv4 unspecified addr for Resolve*Addr of [::] or [::]:n