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 <georgewalkeriv@gmail.com> 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.