[RFC] Handling multiple endpoints for a single peer
dave.taht at gmail.com
Mon Jan 9 08:00:55 CET 2017
As I mentioned on an earlier thread, a daydream of mine is to use up extra
ipv6 /64s to improve "fair queued" latency and eliminate head of line
blocking for individual flows.
So being able to dedicate an entire /64 as an endpoint
would lead to a major advance over conventional vpn technologies.
On Sun, Jan 8, 2017 at 2:49 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Thanks for the proposal. Obviously the easiest solution is a userspace
> decoupled one, but this might not necessarily be the most desirable.
> However, it's possible the upcoming userspace event notification fd
> support (epoll on an fd to learn when handshakes happen) and userspace
> peer-message support (send an encrypted out of band non-IP packet
> directly to a peer, for things like autoconfig) could play a nice role
> in this.
> But if it is in the kernel, the decision logic boils down essentially
> to: there's a list of endpoints in a given order. Based on differing
> metrics of success at differing points in time, the list gets
> reordered, and packets are always sent to the top of the list. For
> example, the list could be rotated or permutated on every handshake
> retry. Or the various other RTT or routing metrics you mentioned
> However, this doesn't shine any light on the hardest problem: how to
> update the list of addresses in a memory-bounded fashion. Right now,
> if you receive an encrypted packet, the endpoint of that peer is
> updated to the src address of that packet. With multi-endpoint, which
> endpoint is updated? Is it simply appended to an ever-growing list of
> recent endpoints? How to keep this clean and manageable?
> WireGuard mailing list
> WireGuard at lists.zx2c4.com
Let's go make home routers and wifi faster! With better software!
More information about the WireGuard