<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 26, 2023 at 5:18 AM Juliusz Chroboczek <<a href="mailto:jch@irif.fr">jch@irif.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> While you're absolutely right that this MUST NOT happen, in practice it does.<br>
<br>
I think we're in at least partial agreement.  The point I'm making is that<br>
this configuration is not something that's supported by IP, and that VPN<br>
implementations that cause MTU blackholes are quite simply buggy.<br></blockquote><div><br></div><div>Agreed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  (There's an argument to be made that IPv6 should support variable MTU<br>
  links.  Good luck pushing this idea at the IETF, which, of late, appers<br>
  to be mostly interested in breaking the e2e principle and proxying<br>
  everything at the application layer.  Sorry for the rant.)<br></blockquote><div><br></div><div>(As a proxy enthusiast, I have thoughts :P. In my view, the e2e principle</div><div>as we knew it broke when people started deploying TCP "accelerators".</div><div>We brought back transport-layer e2e with QUIC thanks to e2e encryption.</div><div>So in my view, QUIC is e2e but TCP, UDP, and IP are not. In that world,</div><div>CONNECT-UDP allows you to maintain e2e because it allows QUIC.</div><div>Sorry for the rant reply, but I couldn't resist)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Of course, in practice misconfiguration happens, and so it's a good thing<br>
to be able to be able to automatically detect misconfiguration and discard<br>
the link.</blockquote><div><br></div><div>Definitely. Thanks for implementing and deploying that by the way.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It would be even better to be able to notify the network<br>
administrator of the issue, but that would be a little more work than I'm<br>
willing to do right now.<br></blockquote><div><br></div><div>babeld automatically emailing sysadmins sounds like a fun time :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(For example, we could send Hellos in a small packets, in order to<br>
discover neighbours, and then send a small number of Ack Requests padded<br>
to MTU to every discovered neighbour.  If a neighbour never answers the<br>
Ack Request, then it's fairly strong evidence that there's something wrong.)<br></blockquote><div><br></div><div>(You could even perform dichotomy there to measure the exact MTU and update</div><div>the OS link MTU based on that, but I agree that's not necessarily babeld's job.)</div><div><br></div><div>David </div></div></div>