On Tue, Dec 20, 2016 at 7:40 PM, Toke Høiland-Jørgensen <[email protected]> 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. _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
