Hey George, On Fri, Apr 7, 2017 at 4:13 PM, George Walker <[email protected]> wrote: > I'm far from an IP muticast expert, but it would seem more consistent with > the existing cryptokey routing paradigm if the packets addressed to the > multicast range went to every peer on that interface which had the multicast > address addressed among its "allowedIPs." Then, the only difference between > configuring multicast and unicast is how many peers may have the same > allowedIP.
Thanks for this feedback. Indeed this is the initial design I had thought about and discussed quite a bit. In the name of "simplicity" I had been nudged back toward the easier special case semantics. I suppose it's still up in the air. == Peers Sharing Multiple AllowedIPs Entries == Pros: - Highly configurable. - More clear what's happening. Cons: - Right now there is a strict one-entry-one-peer enforcement, to maintain the one to one. This has the nice property that if you try to add the same allowed-ips to the same peer, by accident, the allowed-ip simply _moves_. I rather like this behavior. Thus, there'd have to be some explicit way of telling it, "yes I really do want this to be duplicated, not moved". Perhaps a "multi:" prefix? I don't know, but it's uglier UI stuff to grok. == Special Cased Broadcast/Multicast Addresses == Pros: - Simple on and off switch. Cons: - A bit too magical. - Seems to break paradigm. Hm. Jason _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
