<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">If I understand correctly</span></font></blockquote><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">You do.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">I find that a very nice UI<br>solution. Wonderful.</span></font></blockquote><br></div><div id="AppleMailSignature">Thanks! Thinking about it definitely got me excited about what I could do with a secure multicast-capable network overlay...</div><br>Sent from my iPhone</div><div><br>On Apr 7, 2017, at 4:42 PM, Jason A. Donenfeld <<a href="mailto:Jason@zx2c4.com">Jason@zx2c4.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Hey George,</span><br><span></span><br><span>More excellent feedback, thanks. Be sure to CC the list next time though.</span><br><span></span><br><span>If I understand correctly, your suggestion is to not clutter</span><br><span>everything with a horrible "multi:" prefix, but instead allow</span><br><span>multicast addressees, which are well defined, to be added to multiple</span><br><span>peers, and only allow unicast addresses to be added to one peer at a</span><br><span>time keeping the current behavior. I find that a very nice UI</span><br><span>solution. Wonderful.</span><br><span></span><br><span>Jason</span><br><span></span><br><span>On Fri, Apr 7, 2017 at 6:02 PM, George Walker <<a href="mailto:georgewalkeriv@gmail.com">georgewalkeriv@gmail.com</a>> wrote:</span><br><blockquote type="cite"><span>Cons:</span><br></blockquote><blockquote type="cite"><span>- A bit too magical.</span><br></blockquote><blockquote type="cite"><span>- Seems to break paradigm.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Another is scalability --the computational and network overhead associated</span><br></blockquote><blockquote type="cite"><span>with making every peer irrevocably a member of every multicast group.</span><br></blockquote><blockquote type="cite"><span>Sending all multicast messages to all peers eliminates much of the benefit</span><br></blockquote><blockquote type="cite"><span>of having more than one multicast address. That could mean a lot of</span><br></blockquote><blockquote type="cite"><span>unnecessary handshakes! I can imagine applications for which this behavior</span><br></blockquote><blockquote type="cite"><span>would make (accidental or malicious) DoS very easy.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If you only have a lab-scale deployment and generous bandwidth, of course</span><br></blockquote><blockquote type="cite"><span>receive-side filtering is fine. But Wireguard's performance and general</span><br></blockquote><blockquote type="cite"><span>utility would suggest that some will want big far-flung networks that may</span><br></blockquote><blockquote type="cite"><span>well have need for lots of multicast groups (e.g. industrial IoT), while not</span><br></blockquote><blockquote type="cite"><span>being able to afford to broadcast everything to everyone.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thus, there'd have to be</span><br></blockquote><blockquote type="cite"><span>some explicit way of telling it, "yes I really do want this to be</span><br></blockquote><blockquote type="cite"><span>duplicated, not moved". Perhaps a "multi:" prefix?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I respectfully disagree concerning the necessity to add special, ugly,</span><br></blockquote><blockquote type="cite"><span>inconsistent UI for the multicast-as-multicast (instead of</span><br></blockquote><blockquote type="cite"><span>multicast-as-broadcast) approach. Multicast address ranges are well-known,</span><br></blockquote><blockquote type="cite"><span>specified in RFCs. That they behave a little bit differently from unicast</span><br></blockquote><blockquote type="cite"><span>addresses is expected behavior. Most of us ignore them and don't use those</span><br></blockquote><blockquote type="cite"><span>ranges most or all of the time, which works fine. Thus Multicast support</span><br></blockquote><blockquote type="cite"><span>(e.g. in routers) doesn't generally interfere with the actual vs. expected</span><br></blockquote><blockquote type="cite"><span>behavior of the unicast traffic most people use most of the time.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Anyone who is diddling with networking at this level already knows how to</span><br></blockquote><blockquote type="cite"><span>avoid multicast IPs when they intend unicast (whether they know they do or</span><br></blockquote><blockquote type="cite"><span>not).</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It doesn't seem problematic for a layer 3 VPN to treat adding a unicast</span><br></blockquote><blockquote type="cite"><span>address when such an address is already an allowedIP as different from</span><br></blockquote><blockquote type="cite"><span>adding a multicast address (moving in the first case, adding in the second).</span><br></blockquote><blockquote type="cite"><span>It sounds to me like doing the right (intuitive) thing in each case.</span><br></blockquote></div></blockquote></body></html>