IETF Logo Mail Archive

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

"touch@strayalpha.com" <touch@strayalpha.com> Mon, 17 June 2024 00:27 UTC

Return-Path: <touch@strayalpha.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 D23B7C1840C8; Sun, 16 Jun 2024 17:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_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=strayalpha.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 oq28vD2FZwyx; Sun, 16 Jun 2024 17:27:34 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 6DE60C14CE5E; Sun, 16 Jun 2024 17:27:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zl0+w9A0Byv3cqePnXIkJrEtk0zXk6AMdSUxlq3J7eo=; b=dukuCaYomWX8orF6ibniWuRSif euCNVh3782kn976cMqspbPT4ILEj0ZvIOZGP44dPBYt+jNgbaJS56nqD8E1cmDZzrHwNt4wc5geHO py9Ccm20K+kMQ4Gl5tj8rRCEqeAVLWrW1Vm9FFOvfA84EnJpYkJWIDx2PYFdftY+sY+M+F70r9Bn2 wcJRnyZ7HcuOl3y/akCsHU2Hy4lXibfzcA9PxJHZqCOoFNi/CPBq1fmSJJPKfmnq9tBUWv/7qI2Ei 8b0oBj68rXDeAuLld1l1OeylD4Urs1NWf0kijF23TwUmJiTTjyjfRG5b+ORGKHLso5TzbkTs5odp+ FVeWGaZg==;
Received: from [172.56.189.229] (port=31665 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <touch@strayalpha.com>) id 1sJ0Dc-00DDlH-0S; Sun, 16 Jun 2024 20:27:32 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_326C67F0-3976-44E0-8529-312CABADE47D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <CACL_3VHkbVeno3i+T6saWCoVQnvmgvwxAWG34YK9EoHBubmPHw@mail.gmail.com>
Date: Sun, 16 Jun 2024 17:27:19 -0700
Message-Id: <DA850D92-422D-4F74-961E-7B4A6038B33C@strayalpha.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>
To: "C. M. Heard" <heard@pobox.com>
X-Mailer: Apple Mail (2.3774.600.62)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Message-ID-Hash: O46CF27OLO42MJUXB6P3Q3RMTXHOL5XW
X-Message-ID-Hash: O46CF27OLO42MJUXB6P3Q3RMTXHOL5XW
X-MailFrom: touch@strayalpha.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>, Suresh Krishnan <suresh.krishnan@gmail.com>, "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/hxRP7IQdV8nwHd3DRj-59AstDWE>
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>

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.

Joe

v2.35.0 | Report a Bug | By Email | System Status