Kalin KOZHUHAROV <[email protected]> writes: > On Tue, Mar 6, 2018 at 11:14 PM, Jason A. Donenfeld <[email protected]> wrote: >> On Tue, Mar 6, 2018 at 11:08 PM, Toke Høiland-Jørgensen <[email protected]> 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 _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
