Cannot connect to IPv6-only nodes

[CFSworks]

What happened:
Connecting to a node (by name), when that node has an IPv6 address in advertise_ip, and that node's name isn't a valid DNS name, results in an error like:
error: failed connecting to node NODENAME. error: dial tcp: lookup NODENAME on [2001:4860:4860::8844]:53: no such host

Connecting to a node by IPv6 address (with or without brackets - but SSH expects without) yields this parse error:

$ tsh ssh root@2001:db8::1
error: failed to parse 'tcp://[2001:db8::1]:0@default@main':parse tcp://[2001:db8::1]:0@default@main: net/url: invalid userinfo

What you expected to happen:
Teleport shall connect as expected (and as it did in 2.4.x).

How to reproduce it (as minimally and precisely as possible):

• Install Teleport on an auth+proxy server and a node
• Configure an IPv6 address for the node's advertise_ip
• Attempt to connect to that node

Environment:

• Teleport version (use teleport version): Teleport v2.7.0 git:v2.7.0-0-g5745b4fc
• Tsh version (use tsh version): Teleport v2.7.0 git:v2.7.0-0-g5745b4fc
• OS (e.g. from /etc/os-release): Any Linux; bug report made from Debian

[CFSworks]

@klizhentas Was this removed from the 3.1 milestone on purpose? I've been counting down the days to the release of 3.1 so I could remove OpenSSH from my IPv6-only hosts once more. I'm a little sad to see a fix for a breaking regression (as this did work correctly in the 2.4.x series) removed from the next scheduled release.

Since I opened this issue (i.e. since the release of 3.0) the problem has actually gotten worse, as now the presence of an IPv6 address in the advertise_ip field will prevent Teleport from starting up at all.

Please let me know if there are no plans to fix this issue so I can move forward with a workaround instead.

[klizhentas]

@CFSworks did not realize this is such a blocker for you, let me chat to the team and see what we can do

[russjones]

Let's punt on supporting IPv6 for the 3.1 release. While working on it several issues came up that drastically increased the scope of work.

The main issue is that internally Teleport uses a utils.NetAddr everywhere which can hold an host, host:port, HTTP(S) URL, or Unix socket. In addition throughout Teleport something similar to the following is done everywhere fmt.Sprintf("%v:%v", host, port). Bare IPv6 address looks like the following: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 but an IPv6 address with a port looks like the following: [2001:0db8:85a3:0000:0000:8a2e:0370:7334]:8080. The only parsing that is done is url.Parse().

To support IPv6 the following changes need to be made.

1. Drop the utils.NetAddr abstraction throughout Teleport. Instead use a net.Addr and net.IP everywhere.
2. Always force the creation of a net.TCPAddr that contains a valid host, port, and zone when reading file configuration.
3. Never do manual joining or splitting of a host:port string. Always use net.SplitHostPort and net.JoinHostPort to ensure that addresses are in the correct format. (2) will ensure that these functions can always be called.
4. Make sure the IPv6 address is packed into the host certificate.

[klizhentas]

I disagree about dropping utils.NetAddr that encapsulates address handling logic, instead it should support IPV6

[cove]

Since I happened to be looking at that code recently, my 2c is that util.NetAddr does look very similar to go's net pkg in terms of functionality, and net.IP and net.Addr support IPv6 last I checked.

[klizhentas]

@kontsevoy removing this from the milestone for now

[zerodayyy]

Is this issue expected to be resolved in nearest future? Teleport's inability to work in IPv6 environments is quite a large problem, as these are becoming more widespread.

[kontsevoy]

@klizhentas thoughts on including this in 4.1?

[klizhentas]

I'm a bit worried about the expansion of 4.1 scope, so let's make this one almost last one, but otherwise, I'd give it a try in the context of 4.1, yes.

[klizhentas]

This should work for UI as well, right now when you enter user@[::1]:3023 in the UI box, you get UI parsing error.

[alex-kovoy]

It's been fixed on web UI side by 0821e05