[DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt

Jared Mauch <jared@puck.nether.net> Fri, 05 July 2024 18:25 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C063EC0900B3 for <dnsop@ietfa.amsl.com>; Fri, 5 Jul 2024 11:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=puck.nether.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNX_l6X_flnK for <dnsop@ietfa.amsl.com>; Fri, 5 Jul 2024 11:25:28 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2602:fe55:5::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D940FC14F6A3 for <dnsop@ietf.org>; Fri, 5 Jul 2024 11:25:28 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 1001) id BDC655401F2; Fri, 5 Jul 2024 14:25:09 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 puck.nether.net BDC655401F2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=puck.nether.net; s=default; t=1720203909; bh=g1LNBTGdqDoozMWu50B2ZXwYwVtchSpa7f440ZQa61o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ACs3DhbldF6JRIZSo1jzGfgZV4UB0Gg2I7hGIiFY2JfIqkB+JS7cm98wyiggw3Nrq QBLdzr8gyILc5T5lr5A81SblwvF9aGPj3nst8n3FXhSaxsfDWA79QRwymwQt2jR9iK 5WcET3sDLAXsQ56uEfqo6ijQb1hD8rFpCC8dTP6XgVNhld7nRRUcq83m4E401m67ed wqU/6gxQ0MUUmTHlWm/Zac6mFUJOpKcHephalEYsKohsOg0ixdWhCz1FwIGoVzv7NE RZF+Q/uz9w3/mvqV2LPnv9Y6BAVUxxAFSBA7ZDImLcIHjYQdCFleE968/Ay+rvuQK1 rbjyZGbf6AV7A==
Date: Fri, 05 Jul 2024 14:25:09 -0400
From: Jared Mauch <jared@puck.nether.net>
To: Petr Špaček <pspacek@isc.org>
Message-ID: <Zog6hS9f6iaFsK1O@puck.nether.net>
References: <171957523370.366291.478718063778248894@dt-datatracker-ff7f57fbb-ch6dm> <491D5E6C-41CC-4E63-B10F-2E8F4BDC2513@apnic.net> <CADyWQ+E+ae6F5yMLGza0aAogP4G7qeb4wY-3aiyaoQNOdfeWqQ@mail.gmail.com> <2880837.88bMQJbFj6@heater.srcl.tisf.net> <m1sPfl7-0000LiC@stereo.hq.phicoh.net> <e3f7f841-7732-f022-0fd3-187c1b1ee3b1@foobar.org> <43c5e0c2-5a82-4cb9-b1b1-d3aa35b2399d@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <43c5e0c2-5a82-4cb9-b1b1-d3aa35b2399d@isc.org>
Message-ID-Hash: NURBN56MJAPNY6XZ7MT2OJVD2ZCTRR5X
X-Message-ID-Hash: NURBN56MJAPNY6XZ7MT2OJVD2ZCTRR5X
X-MailFrom: jared@puck.nether.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [v6ops] Re: Re: Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-18.txt
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Oe0Mbw9ft4qy25TD8-vmISLtS4c>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

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 jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.