On Fri, Jul 05, 2024 at 02:14:19PM +0200, Petr Špaček wrote:
> On 05. 07. 24 12:50, Nick Hilliard wrote:
> > Philip Homburg wrote on 05/07/2024 11:01:
> > > Can we go back to reality? There is no PMTU discovery for DNS replies
> > > over UDP that works at scale. It doesn't work, it never worked.
> >
> > specifically, short of implementing end-to-end circuits, it can't work
> > reliably. There is no way for an endpoint to detect intermediate
> > topology changes between itself and another endpoint, short of heuristic
> > and/or post-hoc interpretation of what's going on in the data plane.
>
> I understand why Paul Vixie does not like 1400 set in stone.
There's a lot of hidden legacy inside IP around the various
frame sizes from FDDI, POS/SDH and this current layer driven out of IEEE
that many of us are familar with.
> Having said that I think it's in fact _not_ set in stone because the text
> says RECOMMENDED.
Yes, my concern is we slowly end up on the rfc6919 slope.
> My interpretation is that it means "if you don't know any better use 1400",
> but RECOMMENDED is more concise.
There is overall guidance missing in the IETF around how to
handle this, and we're watching portions play out again and again, be it
around nameservers, transports and here with MTU where we are more
strictly defining these beavhiors. If I see NDP with MTU of a future
value, what should my application use? Should each application have
it's own system for clamping this?
https://datatracker.ietf.org/doc/html/rfc4861#section-4.6.4
We continue to have a problem whereby we know the problem exists
and keep shifting it, so now it's not a firewall problem anymore, it's a
UDP problem or Protocol/application over UDP problem (ie: QUIC).
There's likely no easy way for an application to know what the expected
MTU is for a given destinaton even if it's discoverable via EOPNOTSUPP
errno.h
MSS clamping for TCP and the abandonment of backwards
compatability in other ecosystems really makes me wonder about the harm
from making it work vs going out and trying to address the problems.
It would be good for there to be a conversation with the IEEE
Liasons at least to think about the future.
- Jared
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
