On Wed, May 29, 2024 at 12:20:09PM +0200, Matus UHLAR - fantomas wrote: ! > On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote: ! > > rinetd manages 2 separate connections and should work with PMTUD. ! ! On 28.05.24 22:17, Peter wrote: ! > I'm wondering how it would. The connections are TCP, the PMTU works ! > via ICMP6. ! ! No, Path MTU discovery works with TCPv4 using ICMPv4 as well. ! (although it was/is quite common to block ICMP packets which can make it not ! work properly)
That is a different matter, lots of people switch them off and things do still work, because we're in most cases allowed to defragment (firewalls do that) and refragment at any point on the way as needed. Blocking ICMPv4 a practise that is certainly annoying, but what can we do? With v6 things simply won't work. ! > So I would assume, the ICMP "packet too big" message ! > reaches the host where rinetd runs, is swallowed by the kernel, and ! > the kernel sets the MTU in it's hostcache. Or something along that ! > line. ! ! > The TCP traffic however gets forwarded by rinetd to the internal ! > appserver(s) - which never get the message that they should reduce ! > their MTU. ! ! The data from one TCP connection are sent through another TCP connection, ! where both connections are separate with separate MTU and PMTUD. A new quintuple, then. Hm. Not sure why I was unhappy with that... one reason was probably that a webserver would not be able to know the client address. But I think this goes into off-topic here. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
