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

Tim Wicinski <tjw.ietf@gmail.com> Fri, 05 July 2024 00:37 UTC

Return-Path: <tjw.ietf@gmail.com>
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 CFBC6C110D2E; Thu, 4 Jul 2024 17:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RXJVm7voX4Tv; Thu, 4 Jul 2024 17:37:59 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 3E6DDC1840EF; Thu, 4 Jul 2024 17:37:59 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2ee794ec046so12224351fa.2; Thu, 04 Jul 2024 17:37:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720139876; x=1720744676; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SlUzHIkvJsG1KPZO7g3/hTkrDZoMLr9wEb/ZI7lBDnk=; b=a8bcs/14Cs8+H9nfmjg9QUavkGOkEn8dE7dyLIjqJOYN68/K1LRNnygNFHGE3v78Lj 1FMjCVNFN4kIklOs/82nOELTg42s+HQCijeyqJGPPqxROXP68+E20UdW4yZ4XtoLKDB7 c2/sLTxiYTEeDr4f3NM0n1gLPVORgxC+qVD87vzugUIUCsN3L3TkcwjIDnQwFyeia8r7 3PvUlZ3HOSNszPPUBoEW3eIDmpWrqTCpdDRT8E0dzabckDIH+1z+/169Dm+QPAh9m5Wl ox/R+lezxL7CWEemSdxkPqdB9r5soYiHqS7A7Y1Y1xl2Mx8zKMK/argd3Dr/DrAJA3BH h22w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720139876; x=1720744676; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SlUzHIkvJsG1KPZO7g3/hTkrDZoMLr9wEb/ZI7lBDnk=; b=YOtBK4TykEh3s4tYNP/yZGQnQ/Bs7lp7QPZP4yNSEqHj6MhA5vPhSArBOUkzjSE7GO Cpjhxrf+6h537CL10cwx6aoQP1D1CEveANlLDTxSdzegXIrL3ivSNCxTCYrZsvTXagPw IrzWxG0Q4u+O/TgnbgVIkejyyYg75jtjCXTn9fXw6jmdcjrTtUuzJvF5TCy+Dqxj4I/5 ZGCZUCCbiCoR8oysud44W8GWqruHaRDQOK3TAnEBWc1yegGYupdZCcl1fdiXPx+7u7xm gabgJmxSPqAuDMb1q5weLGyAk1jTBbapktnLWVQQ+6fTjXYPIyX7Pl1voss7V/O2qHdT o0zQ==
X-Forwarded-Encrypted: i=1; AJvYcCWFI3mk2sw48fhbFTnE4hr6h5BADR3Deue/sVzPjCy+lcoX4oi5bIvCudjCgIxw4oAMTsTYJjG/ipUcXVgzAg==
X-Gm-Message-State: AOJu0YzDGuBeR/BFHLBwbLnim0T3lBYJYWkcqJihao9yBRwL8kExB/Rw 2wsLWj0tBpmt6NR6GUlHkFZDDtou7HxXw+vqR+lrwpMJJ/3kDe6QPkt+tGllRHRe8DeeU8nG3lb kwKi3OiRsDon/tYI4rD0jY3szniOYgMB4
X-Google-Smtp-Source: AGHT+IHEqmTcJ/Ent1pv2H1+r3JB5HghlF0+OBkFX2/NUqztbAxJbk0PK73WtzJBSAPa/SuaD9EdUdepjQZPJhxuLXU=
X-Received: by 2002:a2e:9b01:0:b0:2ee:4ec2:8232 with SMTP id 38308e7fff4ca-2ee8eda15e2mr20006381fa.25.1720139876244; Thu, 04 Jul 2024 17:37:56 -0700 (PDT)
MIME-Version: 1.0
References: <171957523370.366291.478718063778248894@dt-datatracker-ff7f57fbb-ch6dm> <CAN-Dau1zxTmsGLHMe3b6TyH1-pk5om5wde1OfqM04NkngrDZoQ@mail.gmail.com> <CADyWQ+E15E+cZ8mMZP+w4Ps2iwettQg4j49seOdhaXw5_bN0+g@mail.gmail.com> <23577391.6Emhk5qWAg@heater.srcl.tisf.net>
In-Reply-To: <23577391.6Emhk5qWAg@heater.srcl.tisf.net>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Thu, 04 Jul 2024 20:37:44 -0400
Message-ID: <CADyWQ+FJk8JPGtpycqdgDdx+hTd=ZDkU622vMW8savy2g76T9A@mail.gmail.com>
To: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000049a599061c75462c"
Message-ID-Hash: XICZVWATECIRLV7MA7ZKEZ3IJPVWMKX7
X-Message-ID-Hash: XICZVWATECIRLV7MA7ZKEZ3IJPVWMKX7
X-MailFrom: tjw.ietf@gmail.com
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: v6ops@ietf.org, dnsop@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [v6ops] 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/mdRZE8Jycixbc2CoRV86ekwlDso>
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>

Paul

On Thu, Jul 4, 2024 at 6:41 PM Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>
wrote:

> On Thursday, July 4, 2024 7:05:22 AM PDT Tim Wicinski wrote:
>
> > On Tue, Jul 2, 2024 at 9:26 PM David Farmer <farmer@umn.edu> wrote:
>
> > > 2. Also, maybe R5 should have text similar to R3 with "...the minimum
>
> > > of...the interface MTU, the network MTU...and 1400 bytes..." Instead of
>
> > > "It should use a limit of 1400 bytes, but a smaller limit MAY be used."
>
> >
>
> > Something like this:
>
> >
>
> > "UDP requestors should limit the requestor's maximum UDP payload size  to
>
> > use the RECOMMENDED size of 1400 bytes, but a smaller limit MAY be used."
>
> As before, I'd like to future-proof this document. 1400 may not survive
> and should not be a hard limit. If someone ever gets PLPMTUD working, or if
> local knowledge includes MTU over a topology as a static configuration,
> then the recommended value should be ignored, and the measured or locally
> defined limit should be the operational maximum for that datagram.
>
> Thus, not only a smaller limit, but also a larger limit, may be sometimes
> used. This document need not enumerate all such cases, but should not
> require revision if 1400 turns out to be like 640KB -- not a sensible limit
> for all possible futures.
>

I agree with you on future proofing, and I did not seem to craft that in my
suggestion.

David mentions R5 should have similar text 'flow' (my word) as R3.

Here is R3

   R3.  UDP responders should compose response packets that fit in the
   minimum of the offered requestor's maximum UDP payload size
   [RFC6891], the interface MTU, the network MTU value configured by the
   knowledge of the network operators, and the RECOMMENDED maximum DNS/
   UDP payload size 1400.  (See Appendix A for more information.)

Here is R5

   R5.  UDP requestors should limit the requestor's maximum UDP payload
   size.  It should use a limit of 1400 bytes, but a smaller limit MAY
   be used.  (See Appendix A for more information.)


Me trying (and perhaps failing again) :

UDP requestors should limit requestor's maximum UDP payload size that fit
in the minimum
of the offered requestor's maximum UDP payload size, [RFC6891],
the interface MTU, the network MTU value configured by the knowledge of the
network operators,
and the RECOMMENDED maximum DNS/UDP payload size 1400.



tim

>
> --
>
> P Vixie
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org
>