Re: Multicast over a wireguard link?

["Toke Høiland-Jørgensen" <toke@toke.dk>]

On 20 December 2016 19:43:15 CET, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote:
>On Tue, Dec 20, 2016 at 7:40 PM, Toke Høiland-Jørgensen <toke@toke.dk>
>wrote:
>> Right, but that means that even if multicast is added, a routing
>> protocol won't be terribly useful, since it can't tell wireguard
>which
>> subnets lives behind which peers. What I would need is to be able to
>> assign /32s (or IPv6 lladdrs) to the interface for each peer, and
>have
>> the kernel routing table determine which subnets should go to each of
>> those. My hope was that wireguard could then figure out where to send
>> the packet from the /32s (which would be in the wireguard config,
>> presumably).
>
>Ahh, I see. In this case, the routing protocol needs to update
>WireGuard, not the kernel's routing table. This forces you to
>re-envision your routing protocol in terms of "which public key should
>get which routes?" which strikes me as an authenticity improvement.

Hmm, longer term carrying public keys in the routing protocol might be viable, but getting to there is not trivial. 

However a netlink interface that says, essentially, "add traffic going to subnet A to the same peer that has address X". That would turn wireguard into a normal routing table (conceptually, at least). If the same netlink interface could be used, it wouldn't even be necessary to modify the routing daemon...