[v6ops] Re: [tsvwg] Carrying large DNS packets over UDP in IPv6 networks

Warren Kumari <warren@kumari.net> Mon, 17 June 2024 15:49 UTC

Return-Path: <warren@kumari.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224C1C1DA1F8 for <v6ops@ietfa.amsl.com>; Mon, 17 Jun 2024 08:49:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.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 QmU6UDwvE7gF for <v6ops@ietfa.amsl.com>; Mon, 17 Jun 2024 08:49:24 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 5E39AC1654F2 for <v6ops@ietf.org>; Mon, 17 Jun 2024 08:49:19 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a6f51660223so267029766b.0 for <v6ops@ietf.org>; Mon, 17 Jun 2024 08:49:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; t=1718639357; x=1719244157; darn=ietf.org; h=cc:to:subject:message-id:date:in-reply-to:references:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wwnFgMOyQ8J/QopUbvJW7MqIs2oIEQdu7+d6azajnzg=; b=Tlx41WKBGgFzDIIDtaDefZSqfRh/VXnc5k7UvZ4Um5XHjGjdhl6MrUKt+mj4uV07+s aWff2V1SGvuGCqJUjRdX2U/QxYkBfWjyTsyNLtECu0ODieoOaUjqpky3zJJqRJgUjSn0 i3Rhn2rF/aX9jb1WTonoycrMO5LztwnpmJLmVpd4Cx+96WviIRcJFWjXO/yvUChylMJL u9nXtGHGIx/YYlLH0OeYyd/I672EZ+XsSHZkIK1xjKC26Mo8M4SnnnsRtib/4Th12vlG S0Ii3Uy5vp9rfZI7WDRSOMDz2wMXIUCAkpheskxR9BX2HMhqHOORM1eS/+MWT2hj+R80 9nDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718639357; x=1719244157; h=cc:to:subject:message-id:date:in-reply-to:references:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wwnFgMOyQ8J/QopUbvJW7MqIs2oIEQdu7+d6azajnzg=; b=VBUUZsA0fmF4m2aVukMEH3LN+rER14MlqQ6AA+QHBdW84RJjzPCEXU7Vy6WZSG8f4A Xx/Q/KIcpDuQTbfQ+3P/8nMx62n1w/0MI/Ef2vb57CzueRYXJiBhzusgmVba0og7T1I7 vXKniHBwWZFJuFClXWYikZdO4z5OBcC1Eum/GAcfeS17IWMBo2IKR8PRjVNYm+UGlnYN ZlGI2aZM98G38t0dyDbbSdvCyGneKDRssULFzxFLX4PSr0UDYHnUI7tRYi26PA/WCi9Z 4dMl822QxVO6BOgkHgMrt6N4o1B1R8Z3PXUEzctswfjP/a5zEmpxCeLClrm1/B9zb8YL kBXg==
X-Forwarded-Encrypted: i=1; AJvYcCU9F6AynUrO6uGGqcOrTNjlvyN7vq2IOwoRc9kLLBpmOpfu900oBOGeQqMcnj0mc59IUllfmvzCd4wmjRHwfg==
X-Gm-Message-State: AOJu0YzG12ggVJpwa9uLhcPr+eJinXHmmEgNTNupkoKiHalCFcW8lTla hIJ/eti9/QBNSRSj0NYnuc8g3MckSZL338h2pA0P4xpJpVsbgsvCU5PLvTAOCGL5xQhq4kEsSfW tDlg27+oMBxuZDen4ePyG71I6H4SvZbdHRUfiNhS53Eqj8VHV
X-Google-Smtp-Source: AGHT+IHrWbQaiOpAtFI7YefiBzKzdLymgD9oJTPydEzgCRzDtaXPazstQT0+8PxBTEXzrBLVVDWTiwRmi0WPHjGXKlo=
X-Received: by 2002:a50:ab17:0:b0:57c:70be:6558 with SMTP id 4fb4d7f45d1cf-57cbd6c7462mr7627566a12.27.1718639356788; Mon, 17 Jun 2024 08:49:16 -0700 (PDT)
Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Mon, 17 Jun 2024 08:49:15 -0700
Mime-Version: 1.0
From: Warren Kumari <warren@kumari.net>
X-Superhuman-ID: lxj5hhy1.7660c644-c500-47c6-a5bb-c37346b1cff2
References: <E35DC12F-D1CE-4AE5-B155-612C639A348B@gmail.com> <DU2PR02MB10160CCA998D5A86B9F11F2C388C22@DU2PR02MB10160.eurprd02.prod.outlook.com> <CACL_3VGzQfn9Gp+Wvx6HDZt=Gbyurirgt8Sa3qah7TpNgLiQug@mail.gmail.com> <BAEBA468-9B3E-41ED-B609-1D0A9D4A0F6E@gmail.com> <Zm81hsg9-O6A3GCQ@Space.Net> <fd1db63a-b735-4906-9416-80a118be15dc@gmail.com> <CACL_3VHkbVeno3i+T6saWCoVQnvmgvwxAWG34YK9EoHBubmPHw@mail.gmail.com> <67F28381-A276-44F9-80D6-42973AB08095@gmail.com>
In-Reply-To: <67F28381-A276-44F9-80D6-42973AB08095@gmail.com>
X-Mailer: Superhuman Desktop (2024-06-14T19:05:48Z)
X-Superhuman-Draft-ID: draft00c89e3d6760c6f0
Date: Mon, 17 Jun 2024 08:49:15 -0700
Message-ID: <CAHw9_iJU_ZJqrQsDPHqGW0thqf6oWhG55_fvbPNZx6x0j6T=ig@mail.gmail.com>
To: Suresh Krishnan <suresh.krishnan@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000005bdcaf061b17e8ba"
Message-ID-Hash: MQ2GVXOYFRP4E3YWUTU5CMAEYRWZSOVY
X-Message-ID-Hash: MQ2GVXOYFRP4E3YWUTU5CMAEYRWZSOVY
X-MailFrom: warren@kumari.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-v6ops.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "C. M. Heard" <heard@pobox.com>, v6ops@ietf.org, tsvwg@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: [tsvwg] Carrying large DNS packets over UDP in IPv6 networks
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/N-V5EXQWRCopOvwDAYZQVUa-hsU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Owner: <mailto:v6ops-owner@ietf.org>
List-Post: <mailto:v6ops@ietf.org>
List-Subscribe: <mailto:v6ops-join@ietf.org>
List-Unsubscribe: <mailto:v6ops-leave@ietf.org>

On Mon, Jun 17, 2024 at 6:28 AM, Suresh Krishnan <suresh.krishnan@gmail.com>
wrote:

> Hi Mike,
>
> On Jun 16, 2024, at 7:30 PM, C. M. Heard <heard@pobox.com> wrote:
>
> On Sun, Jun 16, 2024 at 1:03 PM Brian E Carpenter wrote:
>
> I don't think a v6ops document should venture into DNS transport
> recommendations - especially as the question "TCP or QUIC" is, basically,
> independent of the underlying IP protocol (IPv4 fragments are not safe from
> eaten by intermediate grue).
>
> From Geoff's observations, I'm not sure that's true - that is, the best
> practice for DNS/IPv4 probably differs from the best practice for DNS/IPv6.
>
> That is correct, and one can see the evidence not just in Geoff's
> excellent presentation at IETF 119 (https://datatracker.ietf.org/meeting/
> 119/materials/slides-119-v6ops-operational-issues-00.pdf for those who
> missed it) but in https://datatracker.ietf.org/doc/html/
> draft-ietf-dnsop-avoid-fragmentation#name-on-path-fragmentation-on-ip
>
> Also, whether the final document(s) come out of v6ops or dnsop (or even
> tsvwg) is secondary to whether they say the right things. Perhaps we could
> ask the various WG chairs to coordinate?
>
> Excellent idea; it might help to push draft-ietf-dnsop-avoid-fragmentation
> out the door.
>
> Looking at the datatracker, I think that document might be ready to go out
> of the soon since the IESG evaluation is done and the positions indicate
> that the document is ready to move forward.
>


Actually, there is still some work to be done on this document — there is
much (convoluted) history here.
A very quick summary:
It is a BCP document, and was sent to the IESG with a number of unqualified
MAYs. The IESG felt that it was not really appropriate for a BCP to be this
"wishy-washy" and so some of these were "upgraded" to SHOULD e.g:
"R2.  UDP responders MAY set IP "Don't Fragment flag (DF) bit" [RFC0791] on
IPv4."
became
"R2.  Where supported, UDP responders SHOULD set IP "Don't Fragment flag
(DF) bit" [RFC0791] on IPv4."

and
"R7.  UDP requestors MAY drop fragmented DNS/UDP responses without
IP reassembly to avoid cache poisoning attacks."
became
"R6.  UDP requestors SHOULD drop fragmented DNS/UDP responses without IP
reassembly to avoid cache poisoning attacks."

However, the handling of DF bits is, um, inconsistent between operating
systems (and even different versions within an operating system), and so
implementations are not currently  following these recommendations  - and
if they could/did follow these recommendations, we are not at all sure that
they would work well. Implementers are, understandably, very reluctant to
have a **Best Current** Practices document which contains things that are
not Current, and which we are not sure would be Best even if they were.

And so I have asked the authors and implementers to work together to
address this - the document will end up Informational, and hopefully will
be republished after some time as a BCP, once we have some additional
experience. There was an email to the DNSOP list recently with new proposed
text, and we hope to have a new version of the document published soon.

W



> Regards
> Suresh
>
> _______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org
>
>