Hey George, More excellent feedback, thanks. Be sure to CC the list next time though.
If I understand correctly, your suggestion is to not clutter everything with a horrible "multi:" prefix, but instead allow multicast addressees, which are well defined, to be added to multiple peers, and only allow unicast addresses to be added to one peer at a time keeping the current behavior. I find that a very nice UI solution. Wonderful. Jason On Fri, Apr 7, 2017 at 6:02 PM, George Walker <[email protected]> wrote: > Cons: > - A bit too magical. > - Seems to break paradigm. > > > Another is scalability --the computational and network overhead associated > with making every peer irrevocably a member of every multicast group. > Sending all multicast messages to all peers eliminates much of the benefit > of having more than one multicast address. That could mean a lot of > unnecessary handshakes! I can imagine applications for which this behavior > would make (accidental or malicious) DoS very easy. > > If you only have a lab-scale deployment and generous bandwidth, of course > receive-side filtering is fine. But Wireguard's performance and general > utility would suggest that some will want big far-flung networks that may > well have need for lots of multicast groups (e.g. industrial IoT), while not > being able to afford to broadcast everything to everyone. > > 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 respectfully disagree concerning the necessity to add special, ugly, > inconsistent UI for the multicast-as-multicast (instead of > multicast-as-broadcast) approach. Multicast address ranges are well-known, > specified in RFCs. That they behave a little bit differently from unicast > addresses is expected behavior. Most of us ignore them and don't use those > ranges most or all of the time, which works fine. Thus Multicast support > (e.g. in routers) doesn't generally interfere with the actual vs. expected > behavior of the unicast traffic most people use most of the time. > > Anyone who is diddling with networking at this level already knows how to > avoid multicast IPs when they intend unicast (whether they know they do or > not). > > It doesn't seem problematic for a layer 3 VPN to treat adding a unicast > address when such an address is already an allowedIP as different from > adding a multicast address (moving in the first case, adding in the second). > It sounds to me like doing the right (intuitive) thing in each case. _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
