[v6ops] Re: [DNSOP] Re: draft-hinden-v6ops-dns

Philip Homburg <pch-v6ops-13@u-1.phicoh.com> Mon, 24 June 2024 08:01 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 []) by ietfa.amsl.com (Postfix) with ESMTP id A963FC169401 for <v6ops@ietfa.amsl.com>; Mon, 24 Jun 2024 01:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E3fhKa_kIy-n for <v6ops@ietfa.amsl.com>; Mon, 24 Jun 2024 01:01:24 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD1AC1519B4 for <v6ops@ietf.org>; Mon, 24 Jun 2024 01:01:22 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #158) id m1sLedb-0000MjC; Mon, 24 Jun 2024 10:01:19 +0200
Message-Id: <m1sLedb-0000MjC@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: <CADyWQ+EZuwj_YeddGbF=_+FU3Zu9T+n_2a2t1qit62mSsJaiUQ@mail.gmail.com> <m18qz1jqrj.fsf@narrans.de> <5d188534-b428-3093-7a06-8d7cfa32339d@redbarn.org> <CADyWQ+GfY05m2ZU_mvdq1hNFamDX57RG74_2aHyv_KoY9McrQg@mail.gmail.com> <95d1f9f6-1d8a-35de-e345-1b86f4c6f43c@nohats.ca> <02ce992c-53dc-7571-8b0c-e1b10a94b82a@redbarn.org> <m1sKDjB-0000LXC@stereo.hq.phicoh.net> <2884fcff-5f3e-a733-f3f3-d1f06b8dafb0@redbarn.org> <407f50a1-5b5f-43fd-870a-bfce5f5b4f60@gmail.com> <CAN-Dau09YufDObur8FGS9ZtmHubAjg0xfYgab208EEVLzwgMeA@mail.gmail.com>
In-reply-to: Your message of "Sun, 23 Jun 2024 11:40:39 -0500 ." <CAN-Dau09YufDObur8FGS9ZtmHubAjg0xfYgab208EEVLzwgMeA@mail.gmail.com>
Date: Mon, 24 Jun 2024 10:01:17 +0200
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: [DNSOP] Re: draft-hinden-v6ops-dns
List-Id: v6ops discussion list <v6ops.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-vuJAycLcPny9k-tJ8LxyetbSkE>
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>

>    Shouldn't anywhere that 1500 bytes is known to be unsafe have
>    an appropriate MTU advertised in the RA announced to that network?
>    Also, 1400 leaves 48 bytes for a tunnel or optional headers.
>    It's not enough for nested tunnels but seems enough for a basic
>    IPv6-in-IPv6 tunnel. If that is not the case, how many more
>    bytes are needed for a basic tunnel? IPv6 DNS servers don't need
>    to assume the worst possible scenario for MTU when sending UDP
>    DNS packets. I believe they can be optimistic and use 1400 unless
>    they have direct knowledge otherwise, and IPv6 provides a very
>    usable mechanism to distribute such knowledge: the MTU option
>    in the RA.  

So I think the questions for v6ops are:
1) Do links with 1280 (or other small MTUs) matter, or is reality that you
   need 1500 to play and 1280 is just a thing of the past?
2) If somebody has a link with a small MTU do all links downstream how to have
   the same small MTU. Does that work in practice?
3) It is easy to see how TCP will pick up the MTU of the access link but
   what about DNS software? Do DNS clients pick up the link MTU and put the
   corresponding udp-bufsize value in DNS requests?