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

Philip Homburg <pch-v6ops-13@u-1.phicoh.com> Fri, 21 June 2024 18:58 UTC

Return-Path: <pch-b538D2F77@u-1.phicoh.com>
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 0064AC151707 for <v6ops@ietfa.amsl.com>; Fri, 21 Jun 2024 11:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
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 0PgykLa-EIVu for <v6ops@ietfa.amsl.com>; Fri, 21 Jun 2024 11:58:46 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [IPv6:2a10:3781:2413:1:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9075DC15108D for <v6ops@ietf.org>; Fri, 21 Jun 2024 11:58:45 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1sKjT4-0000JpC; Fri, 21 Jun 2024 20:58:38 +0200
Message-Id: <m1sKjT4-0000JpC@stereo.hq.phicoh.net>
To: v6ops@ietf.org
From: Philip Homburg <pch-v6ops-13@u-1.phicoh.com>
Sender: pch-b538D2F77@u-1.phicoh.com
References: <E35DC12F-D1CE-4AE5-B155-612C639A348B@gmail.com> <CAN-Dau0q+XJzrVWayCfVuTiMfUJVXVZmzZLQ4A6WOMaJApV1fA@mail.gmail.com>
In-reply-to: Your message of "Fri, 21 Jun 2024 12:18:20 -0500 ." <CAN-Dau0q+XJzrVWayCfVuTiMfUJVXVZmzZLQ4A6WOMaJApV1fA@mail.gmail.com>
Date: Fri, 21 Jun 2024 20:58:38 +0200
Message-ID-Hash: SZCB2LVH7M22F5LC4WZZQ2XCXG55ISTB
X-Message-ID-Hash: SZCB2LVH7M22F5LC4WZZQ2XCXG55ISTB
X-MailFrom: pch-b538D2F77@u-1.phicoh.com
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: David Farmer <farmer=40umn.edu@dmarc.ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: 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/LF5yQzHJ1g3qP7XUfVIlvu6uZjw>
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>

>    If it is known that there are
>    multiple nested tunnels in use or other conditions that restrict
>    the MTU to less than 1500 bytes, then it seems logical to drop
>    to the minimum IPv6 packet size of 1280 and maximum DNS UDP
>    payload size of 1232 instead of trying to optimize for a larger
>    DNS UDP payload size.  

That seems to me as a bit of implicit IPv4 promotion. Requiring operators of
DNS software to know where tunnels are otherwise DNS over IPv6 will fail
but it will work for IPv4.

Then people measure loss rates of DNS over IPv6 compared to IPv4 and find that
IPv4 works better.

It's not great engineering if the operator of an application protocol needs to
know the details of the network configuration.