Re: [RFC] Multicast and IPv6 Link Local Addresses

[George Walker <georgewalkeriv@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]

> 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 <Jason@zx2c4.com> 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 <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.

[-- Attachment #2: Type: text/html, Size: 5938 bytes --]