Roaming between IPv4 and IPv6?

Roaming between IPv4 and IPv6?

[Toke Høiland-Jørgensen]

Hi

Is wireguard supposed to be able to handle roaming between IPv4 and
IPv6? If I setup a tunnel to a dual-stack machine and establish the
tunnel using IPv6, then switch to a different interface (from WiFi to
cellular in this case) that doesn't have IPv6, the tunnel stops having
connectivity. Whereas if I go in the other direction (first establish
the tunnel over IPv4), I can seamlessly roam between different
connections.

Is this expected behaviour, or should v4/v6 roaming work?

-Toke

Re: Roaming between IPv4 and IPv6?

[Jason A. Donenfeld]

Hey Toke,

For incoming packets, this would be strange behavior, since it's
listening on v4 and v6. For outgoing packets, if wireguard thinks it
should be sending to a v6 address, then that's what it will do. One
way to fix this would be to re-resolve DNS from userspace, which is a
bit ugly. Another way would be to simply store the last v4 address,
and fall back to that if it can't establish a route for the v6
address. And yet another way -- if simplicity is desired -- would be
to do nothing (the status quo), and not build legacy semantics into
something new. Any opinions on this?

Jason

Re: Roaming between IPv4 and IPv6?

[Toke Høiland-Jørgensen]

"Jason A. Donenfeld" <Jason@zx2c4.com> writes:

> Hey Toke,
>
> For incoming packets, this would be strange behavior, since it's
> listening on v4 and v6.

Yeah, I think the incoming side is fine (it works over both v4 and v6 as
long as I have connectivity on the other end).

> For outgoing packets, if wireguard thinks it should be sending to a v6
> address, then that's what it will do.

Right, so it's not just me, this doesn't actually work currently. Cool ;)

> One way to fix this would be to re-resolve DNS from userspace, which
> is a bit ugly. Another way would be to simply store the last v4
> address, and fall back to that if it can't establish a route for the
> v6 address. And yet another way -- if simplicity is desired -- would
> be to do nothing (the status quo), and not build legacy semantics into
> something new. Any opinions on this?

While I can appreciate the simplicity of doing nothing, I think seamless
roaming even across v4/v6 is a pretty killer feature to have. It turns
wireguard into a "universal connectivity" tool that you can just enable
and forget about, without having to worry about calls dropping when
roaming, etc.

I think the idea of configuring both v4 and v6 on startup and caching
them is a reasonable idea. Maybe even configure all available addresses
when doing the initial DNS lookup? Or is that awkward to do?

-Toke

Re: Roaming between IPv4 and IPv6?

[Jason A. Donenfeld]

On Tue, Mar 6, 2018 at 11:08 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@tok=
e.dk> wrote:
> I think the idea of configuring both v4 and v6 on startup and caching
> them is a reasonable idea. Maybe even configure all available addresses
> when doing the initial DNS lookup? Or is that awkward to do?

You mean taking one v4 and one v6? That's probably possible. Since
getaddrinfo has complicated ordering logic, this probably be best
expressed as something like "endpoint" and "secondary endpoint" when
told by userspace, with them then being swapped when the FIB complains
about trying to route to one of them.

Re: Roaming between IPv4 and IPv6?

[Matthias Urlichs]

On 06.03.2018 23:08, Toke Høiland-Jørgensen wrote:
> I think the idea of configuring both v4 and v6 on startup and caching
> them is a reasonable idea. Maybe even configure all available addresses
> when doing the initial DNS lookup? Or is that awkward to do?

Frankly, IMHO that's a userspace problem. I don't want to see the kernel
driver burdened with complicated timeout logic, multiple address caching
and timeouts, and whatnot. Discovering which address is still reachable
when a link fails, re-checking DNS (you really should not use a resolved
address beyond its DNS timeout, esp. not when it fails to work), and all
those sundry tasks do not belong in the kernel.

-- 
-- Matthias Urlichs

Re: Roaming between IPv4 and IPv6?

[Kalin KOZHUHAROV]

On Tue, Mar 6, 2018 at 11:14 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote=
:
> On Tue, Mar 6, 2018 at 11:08 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@t=
oke.dk> wrote:
>> I think the idea of configuring both v4 and v6 on startup and caching
>> them is a reasonable idea. Maybe even configure all available addresses
>> when doing the initial DNS lookup? Or is that awkward to do?
>
> You mean taking one v4 and one v6? That's probably possible. Since
> getaddrinfo has complicated ordering logic, this probably be best
> expressed as something like "endpoint" and "secondary endpoint" when
> told by userspace, with them then being swapped when the FIB complains
> about trying to route to one of them.
>
A slight simplification/generalization will be to define a peer in
terms of and ordered C-list of IP addresses (whether v4 or v6), 0 or
more (currently 0 or 1 IP+port).
Then sending will try the first and move to the next, possibly adding
a "bad score", until one of the endpoint is reachable; then keep using
it until it fails again.
Those IP addresses may come from say A records of a certain host (this
is not WG land anyway), slapping a default port at the back.
Add a fat warning that the more unreachable IP addresses you add, the
more delays will be introduced.
(of course, to make things simple, a peer is defined as knowing the
secret key; changing IPs, and ports and allowed_ips does not matter)

Another GSoC idea, LoL.

Cheers,
Kalin.

Re: Roaming between IPv4 and IPv6?

[Toke Høiland-Jørgensen]

Kalin KOZHUHAROV <me.kalin@gmail.com> writes:

> On Tue, Mar 6, 2018 at 11:14 PM, Jason A. Donenfeld <Jason@zx2c4.com> wro=
te:
>> On Tue, Mar 6, 2018 at 11:08 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@=
toke.dk> wrote:
>>> I think the idea of configuring both v4 and v6 on startup and caching
>>> them is a reasonable idea. Maybe even configure all available addresses
>>> when doing the initial DNS lookup? Or is that awkward to do?
>>
>> You mean taking one v4 and one v6? That's probably possible. Since
>> getaddrinfo has complicated ordering logic, this probably be best
>> expressed as something like "endpoint" and "secondary endpoint" when
>> told by userspace, with them then being swapped when the FIB complains
>> about trying to route to one of them.
>>
> A slight simplification/generalization will be to define a peer in
> terms of and ordered C-list of IP addresses (whether v4 or v6), 0 or
> more (currently 0 or 1 IP+port).

Yeah, this is basically what I meant: Resolve *all* A and AAAA records
of the configured hostname (for bonus points: get the port number from
SRV records), and stuff them all into the kernel, which will then use
all of them as possible candidates for connecting and use whichever
works (or do happy eyeballs, or something).

However, yeah, this is maybe a bit overkill, but could be a cool idea
for GSOC.

For a simple v4/v6 roaming fix, having one v4 and one v6 configured and
switching between them when the FIB state changes would probably
suffice. I think I would add a v6 preference, though; otherwise it'll
never roam back to v6 once it's on v4 unless the client connects to a
v6-only network.

So something like: If v6 FIB becomes routable, try the v6 address and
switch to that if it works; if v6 FIB becomes unroutable, switch to v4
address...

-Toke