Kalin KOZHUHAROV <me.ka...@gmail.com> writes:
> On Tue, Mar 6, 2018 at 11:14 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote:
>> On Tue, Mar 6, 2018 at 11:08 PM, Toke Høiland-Jørgensen <t...@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 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
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
WireGuard mailing list