<div dir="ltr"><div>Hi Jason, Juliusz, Toke, Dave, et. al.,</div><div><br></div><div>A year ago we discussed Multicast addressing and the move semantics for allowedIPs. Recently, I've been mulling over move semantics and their implication for WireGuard's support for anycast addressing.</div><div><br></div><div>Unlike Multicast addresses, there are no designated address ranges for anycast: an anycast address is just a unicast address that's advertised in more than one place. As I understand it, the move semantics for allowedIPs preclude anycast addressing, as IP addresses can only be assigned to one peer at a time. This makes me wonder if it might be more correct to allow unicast allowedIPs to be assigned to more than one peer, treating them as anycast in that case.<br></div><div><br></div><div>The problem I see with allowing anycast addressing in WireGuard is the potential for breaking TCP and other stateful protocols. Perhaps that could be addressed by somehow keeping sessions localized to a particular peer, e.g., by using a distance metric (perhaps based upon GeoIP lookups) or hash-based binning. I'm not sure what the best way to handle failover.</div><div><br></div><div>Also, if memory serves, move semantics account for a large proportion of the troubleshooting requests that show up on this list, suggesting to me that the status quo --elegant though it is!-- may not be especially intuitive.<br></div><div><br></div><div>What do y'all think?</div><div><br></div><div><br></div><div>Best regards,</div><div>George</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 7, 2017 at 4:42 PM, Jason A. Donenfeld <span dir="ltr"><<a href="mailto:Jason@zx2c4.com" target="_blank">Jason@zx2c4.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hey George,<br>
<br>
More excellent feedback, thanks. Be sure to CC the list next time though.<br>
<br>
If I understand correctly, your suggestion is to not clutter<br>
everything with a horrible "multi:" prefix, but instead allow<br>
multicast addressees, which are well defined, to be added to multiple<br>
peers, and only allow unicast addresses to be added to one peer at a<br>
time keeping the current behavior. I find that a very nice UI<br>
solution. Wonderful.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Jason<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
On Fri, Apr 7, 2017 at 6:02 PM, George Walker <<a href="mailto:georgewalkeriv@gmail.com">georgewalkeriv@gmail.com</a>> wrote:<br>
> Cons:<br>
> - A bit too magical.<br>
> - Seems to break paradigm.<br>
><br>
><br>
> Another is scalability --the computational and network overhead associated<br>
> with making every peer irrevocably a member of every multicast group.<br>
> Sending all multicast messages to all peers eliminates much of the benefit<br>
> of having more than one multicast address.  That could mean a lot of<br>
> unnecessary handshakes!  I can imagine applications for which this behavior<br>
> would make (accidental or malicious) DoS very easy.<br>
><br>
> If you only have a lab-scale deployment and generous bandwidth, of course<br>
> receive-side filtering is fine.  But Wireguard's performance and general<br>
> utility would suggest that some will want big far-flung networks that may<br>
> well have need for lots of multicast groups (e.g. industrial IoT), while not<br>
> being able to afford to broadcast everything to everyone.<br>
><br>
> Thus, there'd have to be<br>
> some explicit way of telling it, "yes I really do want this to be<br>
> duplicated, not moved". Perhaps a "multi:" prefix?<br>
><br>
><br>
> I respectfully disagree concerning the necessity to add special, ugly,<br>
> inconsistent UI for the multicast-as-multicast (instead of<br>
> multicast-as-broadcast) approach.  Multicast address ranges are well-known,<br>
> specified in RFCs.  That they behave a little bit differently from unicast<br>
> addresses is expected behavior.  Most of us ignore them and don't use those<br>
> ranges most or all of the time, which works fine.  Thus Multicast support<br>
> (e.g. in routers) doesn't generally interfere with the actual vs. expected<br>
> behavior of the unicast traffic most people use most of the time.<br>
><br>
> Anyone who is diddling with networking at this level already knows how to<br>
> avoid multicast IPs when they intend unicast (whether they know they do or<br>
> not).<br>
><br>
> It doesn't seem problematic for a layer 3 VPN to treat adding a unicast<br>
> address when such an address is already an allowedIP as different from<br>
> adding a multicast address (moving in the first case, adding in the second).<br>
> It sounds to me like doing the right (intuitive) thing in each case.<br>
</div></div></blockquote></div><br></div></div>