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

Suresh Krishnan <suresh.krishnan@gmail.com> Mon, 17 June 2024 10:01 UTC

Return-Path: <suresh.krishnan@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68239C15108D; Mon, 17 Jun 2024 03:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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=ham 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 hLFAJ4TLOn3l; Mon, 17 Jun 2024 03:01:37 -0700 (PDT)
Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 CDDCAC1D8753; Mon, 17 Jun 2024 03:01:37 -0700 (PDT)
Received: by mail-pf1-x429.google.com with SMTP id d2e1a72fcca58-7024d571d8eso3216868b3a.0; Mon, 17 Jun 2024 03:01:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718618497; x=1719223297; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Tf3HI50cDKlOv/egNrOOIObg4EwZhsFEMa84m1Tmf+I=; b=RJpTkqxHnb32l5ftWtlEbTdj84rZiRml7X5H3DKKFsqPs+aAcihzbVgn52w8/aHg3o 1+5bduAarcdKwtv1w2VknAKiOjaWua1wFKNjRn3g0fDHRx8KSSLp8wo3Cp8S3yLrmoBy CaGqYKn8MzDypvUVIAS2W5QL98o+mXJsGystUghdZpTWnQ8HJO3JsQUGtRh+fBbWnrFi 7u003KLc+D2NGzP0Zcrrd6OcJo7DkQXXABQdoPMOq2mE0wmCHqUk7TLLrCWzuuqGuuel vRVIQfvNOvPt0RBeTox60PHP03I9Veu2XNEwKVamQ0pfOKSPYmD7vD5zM0kzHZfgu/56 klLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718618497; x=1719223297; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Tf3HI50cDKlOv/egNrOOIObg4EwZhsFEMa84m1Tmf+I=; b=YWgoUcbAOy8RBiXRbtAM6MWIOCU4cn+2YYPdrSoZvRI1NNIKFiEYE9KWFxLH77ZxKt vGg3mO/cX3MyQEm74P9AIT+i1R4pHkKy+DX5v6KVf3tsWDYqghforM2cgbn/FNKaunJ4 H4H8LUDqR+nDaS25mfXJ41F6QSJcO9VEdDksEP5SB2NEiN8m9ecPtBJXP4pkm39VxU4x msZXrQH13PoL4vUNjwhYR3ZgHsZkQdZjm76+V5WH7cZszteWdxUpAYmOn8ycX7MJ6vJC KSnzAQVYzZrVZK4DU1kzt6vI1rXdX7NdGtBLHUAItkA2Qt9cLOr7Y1rAOG8wM0Rci2EV dYSA==
X-Forwarded-Encrypted: i=1; AJvYcCUkD/cQqZYt/C4OWw5RJwUzx+sfQQiRET5n06RBvcJ84AgCHH8+pl5hKuMIrCBLdLLoT7qNkes0wkQqysUbbS9BYlwtgRg3gxlC/XzWry8=
X-Gm-Message-State: AOJu0Yz5CT+JRcFHpfHrjF8AMHS9/QGXD2gdEPcRwLL0YwVP/z7uU3ev E3pdZ0PvuNfqtqOE14TJ++hxQEcrDx0hfkjJizp/7bsSLO+PUKgM
X-Google-Smtp-Source: AGHT+IF/yEFOOr/9QpF+Ujc2hy/UMlFG2zvTYvZkocM6pb+TUccTCvLsh9hAmLB6xdl19dTHXn7rTA==
X-Received: by 2002:a05:6a00:114e:b0:705:dd44:ae77 with SMTP id d2e1a72fcca58-705dd44b04emr11975089b3a.3.1718618496817; Mon, 17 Jun 2024 03:01:36 -0700 (PDT)
Received: from smtpclient.apple ([2401:4900:1cd1:edb7:5190:fda5:7812:6889]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-705ccb770c3sm7028400b3a.182.2024.06.17.03.01.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jun 2024 03:01:36 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Suresh Krishnan <suresh.krishnan@gmail.com>
In-Reply-To: <DA850D92-422D-4F74-961E-7B4A6038B33C@strayalpha.com>
Date: Mon, 17 Jun 2024 06:01:22 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <03EAA233-BF50-4B3B-9446-C86B0FF27A95@gmail.com>
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> <DA850D92-422D-4F74-961E-7B4A6038B33C@strayalpha.com>
To: touch@strayalpha.com
X-Mailer: Apple Mail (2.3731.700.6)
Message-ID-Hash: 3YJ3VDPBJO4VLFCDYS6MFXL6DWWCGLJ3
X-Message-ID-Hash: 3YJ3VDPBJO4VLFCDYS6MFXL6DWWCGLJ3
X-MailFrom: suresh.krishnan@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Brian E Carpenter <brian.e.carpenter@gmail.com>, Gert Doering <gert@space.net>, "v6ops@ietf.org" <v6ops@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [tsvwg] Re: [v6ops] Re: Carrying large DNS packets over UDP in IPv6 networks
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/_AwklLIUkhROYAhqZRrBf0h0VEM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>


> On Jun 16, 2024, at 8:27 PM, touch@strayalpha.com wrote:
> 
> Hi, all,
> 
>> On Jun 16, 2024, at 4: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
>> 
> 
> It might be useful to update some of the advice in that document in light of UDP-options. They allow a UDP packet fragmentation with reassembly at the UDP layer in ways that avoid some of the hazards of IP fragmentation (notably lack of ports for NAT traversal and too small reassembly ID space). 
> 
> In particular, it also affects the terminology used in that draft - e.g., the issues of “UDP fragments” apply to IP fragmented UDP packets, but not necessarily to UDP-fragmented UDP packets. The term “UDP fragment” no longer uniquely applies to the former.

Thanks for the info about the UDP options document Joe. It was a very interesting read. Have there been any measurements to see if packets with UDP options have similar success rates passing across the Internet as regular UDP options? Given that UDP never supported options I would expect so, but wanted to know for sure. Also, do you know about the implementation status across common client stacks?

Regards
Suresh