Mosh: implement roaming between IPv4 and IPv6 addresses

[pavlix]

I was at the FOSDEM conference where I was connected to an IPv6 only network. I upgraded to mosh 1.2.6 and asked for stabilization in Gentoo to get IPv6 support. Now I moved to Configuration Management Camp and connected to an IPv4 only network and the mosh client is unable to reconnect.

I checked the mosh-server and it's only listening on the IPv6 address of the server. One way to go would is to listen on both/all IP addresses and convey them to the client. The client would them attempt to communicate to all of them when reconnecting. Alternatively the client can collect those addresses via DNS during the first connection attempt or any time later.

When there are multiple IPv4 and IPv6 addresses, the following may happen for each of them:

1) No response. In that case we have to assume a connectivity issue.

2) We reached another server (learned from DNS) that doesn't know about us. We should be able to learn that and drop that IP address from the list.

3) We reached the right server and we're connected. Let's either just use the address for all communication until it breaks (first successful target wins), or keep retrying with higher priority IP addresses (like IPv6 preferred over IPv4 and stuff like that).

[andersk]

Note: We need to be careful not to let packets forged by an attacker cause us to drop previously working IPs from the list.

[TimCook1]

Is there a reason Boutier's changes can't be merged to add this support? It's been available for years, it was just never added to the main codeline as far as I can tell.

https://github.com/boutier/mosh

[scruffydan]

What is the status of this?

My cell carrier just switched over to IPv6 and my mosh sessions all lose connection when I use my cell data connection.

[peterjeremy]

I would also like the ability to roam between IPv4-only and IPv6-only networks.

I've had a look at Boutier's fork and see a number of significant significant problems with it:

1. The total sum of the documentation as to how it differs from the main Mosh codeline is "multipath fork" - there's no indication as to what it does (or is intended to do) other than via reading the code (currently about 2000 changed lines).
2. I found a comment that it's intentionally incompatible at the network layer. That goes against the Mosh philosophy of backward compatibility.

It looks like cgull started to investigate merging the changes back in about 3 years ago but that doesn't seem to have gone anywhere (I've found 5 messages in mosh-devel but they just stop).

[thegushi]

I’ve had to hack around this by adding v4-only hostnames for my machines, as many wifi hotspots don’t support v6, so joining a network to save data breaks my connection. Would love to know if this is ultimately fixed.

[andersk]

@thegushi You could have used mosh -4 to force IPv4.

[thegushi]

Blink terminal for iOS doesn’t have the -4 option.

[andersk]

@thegushi Ah, well, Blink is a separate project with different maintainers; maybe you can ask them about it.

[furry13]

+1, it would be nice to make Mesh to survive roaming between v4-only/dual-stack/v6-only networks. (Using -4/creating v4-only name does not help when switching to/from NAT64 network).

IPv6-only networks become a reality (and I guess Mesh users are more likely to encounter such scenario than anyone else ;)

[zenczykowski]

I'm not sure I fully understand the problem... but on Linux the best solution I'm aware of is to:

server side: listen on a dualstack ipv6 socket bound to [::]:port (and not to specific individual ips)
sock = socket(AF_INET6, ...)
setsockopt(sock, SOL_IPV6, IPV6_V6ONLY, &0, sizeof(int))
bind(sock, [::]:port)
(possibly listen if tcp)

client side: use getaddrinfo with hints.ai_family = AF_INET6 and hints.ai_flags = AI_V4MAPPED | AI_ADDRCONFIG
getaddrinfo()
sock = socket(AF_INET6, ...)
for x in ga: connect(sock, ga) until one succeeds

and make sure to redo dns resolution (ie. getaddrinfo) before every reconnect, in case network situations (like a move from v4 to v6only network pulling along dns64 dns servers) have caused the situation to change.

(and if you ever set SOL_IP, IP_TOS and/or SOL_IPV6, IPV6_TCLASS, then always set both to the same value and ignore errors)

[mdavids]

Any updates on this?