Re: [RFC] Multicast and IPv6 Link Local Addresses

["Jason A. Donenfeld" <Jason@zx2c4.com>]

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.