<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="Gentium">Hello!</font><br>
    </p>
    <div class="moz-cite-prefix">On 8/29/23 00:13, Daniel Gröber wrote:
    </div>
    <blockquote type="cite"
      cite="mid:20230828221312.fw5pvnt4x7p2c52k@House.clients.dxld.at">
      <pre class="moz-quote-pre" wrap="">On Mon, Aug 28, 2023 at 07:40:51PM +0200, Juliusz Chroboczek wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">I've read the whole discussion, and I'm still not clear what advantages
the proposed route attribute has over having one interface per peer.  Is
it because interfaces are expensive in the Linux kernel?  Or is there some
other reason why it is better to run all WG tunnels over a single interface?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">Off the top of my head UDP port exhaustion is a scalability concern here,</pre>
    </blockquote>
    <p>For enterprise setups, this very easily _can_ get a scalability
      concern fairly easily.<br>
    </p>
    <blockquote type="cite"
      cite="mid:20230828221312.fw5pvnt4x7p2c52k@House.clients.dxld.at">
      <pre class="moz-quote-pre" wrap="">One wg-device per-peer means we need one UDP port per-peer and since
currently binding to a specific IP is also not supported by wg (I have a
patch pending for this though) there's no good way to work around this.</pre>
    </blockquote>
    There is a theoretical frankenstein approach, running a virtual
    machine (maybe netns is enough) for each of the public IP address,
    and connect them by veth. You do not want to do this, but
    theoretically, it should work.
    <blockquote type="cite"
      cite="mid:20230828221312.fw5pvnt4x7p2c52k@House.clients.dxld.at">
      <pre class="moz-quote-pre" wrap="">Frankly having tons of interfaces is just an operational PITA in all sorts
of ways. Apart from the port exhaustion having more than one wg device also
means I have to _allocate_ a new port for each node in my managment system
somehow instead of just using a static port for the entire network. This
gets dicy fast as I want to move in the direction of dynamic peering as in
tinc.</pre>
    </blockquote>
    <p>Even with my 6 machines running in weird locations, it's a mess.
    </p>
    <blockquote type="cite"
      cite="mid:20230828221312.fw5pvnt4x7p2c52k@House.clients.dxld.at">
      <pre class="moz-quote-pre" wrap="">All of that could be solved, but I would also like to get my wg+babel VPN
setup deployed more widely at some point and all that friction isn't going
to help with that so I'd rather have this supported properly.</pre>
    </blockquote>
    <p>All in all, I would also like to see this setup deployed
      worldwide. If we could somehow help on the BIRD side, please let
      us know.</p>
    <p>Thank you for bringing this up.<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</pre>
  </body>
</html>