Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Kalin KOZHUHAROV <me.kalin@gmail.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Roaming between IPv4 and IPv6?
Date: Wed, 07 Mar 2018 09:56:43 +0100	[thread overview]
Message-ID: <87po4gl0vo.fsf@toke.dk> (raw)
In-Reply-To: <CAKXLc7diB1tx9oHJ9JRio84wrrbEqPu7nLi7WAY83h9nqT0g4w@mail.gmail.com>

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

  reply	other threads:[~2018-03-07  8:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-06 21:53 Toke Høiland-Jørgensen
2018-03-06 21:57 ` Jason A. Donenfeld
2018-03-06 22:08   ` Toke Høiland-Jørgensen
2018-03-06 22:14     ` Jason A. Donenfeld
2018-03-07  0:31       ` Kalin KOZHUHAROV
2018-03-07  8:56         ` Toke Høiland-Jørgensen [this message]
2018-03-06 22:59     ` Matthias Urlichs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87po4gl0vo.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=Jason@zx2c4.com \
    --cc=me.kalin@gmail.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).