Baptiste Jonglez <[email protected]> writes: > Hi Jason, > > On Fri, Apr 07, 2017 at 04:02:49PM +0200, Jason A. Donenfeld wrote: >> Various networking people have been poking and prodding about >> supporting IPv6 Link Local addresses and about supporting special >> multicast addresses. *I MAY VERY WELL NEVER CHOOSE TO IMPLEMENT THIS* >> but in case I do, I wanted to start spec'ing out what this might look >> like in order to think about it better. There are a lot of odd >> concerns to take into account, so I doubt that the below will wind up >> as a final solution. > > This is good news! I can't wait to see Babel running on a wireguard > interface with several peers, or even what OSPF would look like on such a > network. > > That being said, for the purpose of a routing protocol like Babel, I think > it still makes more sense to use only *point-to-point* wireguard links. > Link-local and multicast communication solves the problem of discovering > remote routing daemon, but the AllowedIPs list is still static, which does > not make sense for a routing protocol. With point-to-point links, you can > bypass this limitation by simply setting AllowedIPs to ::/0. Of course, > once we have dynamic AllowedIPs, this will change :)
Yeah, for the use case I'm envisioning, I would teach the routing daemon to update wireguard's route tables... > There is just the minor issue of subnets that encompass both unicast and > multicast addresses, the simplest one being ::/0. Such subnets could be > automatically split by wireguard, or just have the "moving" semantic of > unicast subnets. With this last option, a user would have to explicitly > add a subnet which is *within* a multicast prefix to trigger the "cloning" > semantic. I agree that the least confusing would be to only treat prefixes entirely contained in the known multicast prefixes as having "cloning" semantics. -Toke _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
