> If I understand correctly You do. > I find that a very nice UI > solution. Wonderful. Thanks! Thinking about it definitely got me excited about what I could do with a secure multicast-capable network overlay... Sent from my iPhone > On Apr 7, 2017, at 4:42 PM, Jason A. Donenfeld wrote: > > 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 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.