Built-in Roaming is limited due to a design fault adding STUN and TURN support would be good and make wire-guard connections more durable.

[Jason A. Donenfeld]

On Sun, Jan 15, 2017 at 9:39 AM, Dan Lüdtke <mail at danrl.com> wrote:
> Although I see the problem and ran into it myself, I would like to see a solution outside the
> wireguard code. Like the one Jason proposed or even a new approach. I am afraid that
> network layers problems (legacy IP and especially NAT) are about to uglify yet another
> beautiful protocol.

Yea -- worry not. I'm not going to add big cludges into core
WireGuard. I would like to provide some useful facilities for people
to do interesting composable solutions to disgusting networking
problems. But I think this solution space is more in the realm of
"API" than "protocol".

I could also imagine people making "wireguard UDP proxy daemons" --
little programs that listen on 127.0.0.1:xxxxx and then forward
packets to some dynamically learned MySQL-connected ASN1-parsed IP
while doing things like "if multiple packets that start with a 0x1 and
are 148 bytes long are sent in a row, the server has probably changed
IPs and we should get STUNed again".

Or, maybe this kind of proxy is objectionable and people would prefer
to use netlink notification for connectivity events instead.

Either way, there's plenty of room for building terrible things _on
top of_, rather than inside of, wireguard.

> My concerns expressed and all that said, I would love to see some code or PoC. Code and pcaps are king :)

:) As the Reverend Doctor Pastor says, PoC||GTFO.

> Wireguards roaming feature tool care of the sites where even the ipv6 prefix changes from time to time.

Or when your laptop or cellphone is moving around between IP addresses
frequently.