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

David Farmer <farmer@umn.edu> Sun, 23 June 2024 21:24 UTC

Return-Path: <farmer@umn.edu>
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 8667EC14F5F6 for <v6ops@ietfa.amsl.com>; Sun, 23 Jun 2024 14:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=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=umn.edu
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 iGCmMdSQKZtW for <v6ops@ietfa.amsl.com>; Sun, 23 Jun 2024 14:24:46 -0700 (PDT)
Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E5EC14F5E9 for <v6ops@ietf.org>; Sun, 23 Jun 2024 14:24:45 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 4W6kd86cwgz9vC8x for <v6ops@ietf.org>; Sun, 23 Jun 2024 21:24:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIag2Xy93p5T for <v6ops@ietf.org>; Sun, 23 Jun 2024 16:24:44 -0500 (CDT)
Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 4W6kd836RWz9v90D for <v6ops@ietf.org>; Sun, 23 Jun 2024 16:24:44 -0500 (CDT)
DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p6.oit.umn.edu 4W6kd836RWz9v90D
DKIM-Filter: OpenDKIM Filter v2.11.0 mta-p6.oit.umn.edu 4W6kd836RWz9v90D
Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2ec617f8b6fso1353291fa.0 for <v6ops@ietf.org>; Sun, 23 Jun 2024 14:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; t=1719177883; x=1719782683; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=U+BMI7GtS4BmL5ZKQ8NcQVyAYkd/YdltAclBnWyv9Bk=; b=dx69VxN2K0+/9qRjnV/pXNoAXbropy6lZm8TtGd+LUgmfgBvcfwPqGQ6QaSMxQ5mRr /OIcEVQu98JovFcVC4vTXkLHZCGKWJWO83mVJSDFhuf/MJ/miAs6idisqwrmRpgVZP8C Gl7HPkcdBkYgmSZw8wZ0OFHUNQuvgUMjye0aDBzIHKMOhsUp6CT1mL/64ium4ifdCjgM hu2zW+EQirjZd+1bSFJfjWLh/srBZ9c2rnf40YNKwfPlnggAGr4gFPlN8bCcJFV9+yDz VuZ2oFCjnXbFMURHKmOaO4Z1PJzSehuEXY2C9grq9npHyjD2HwPJdal9tAIlliIhqzzb S35Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719177883; x=1719782683; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=U+BMI7GtS4BmL5ZKQ8NcQVyAYkd/YdltAclBnWyv9Bk=; b=pDkdfhIlMvBPXymHzFb9s21t6fw0mIeeixGfm/8SHCqsPtJVTdI9mb/MCr5mQIf0tL aPaTp4aGvpBWyNlT/qTWHgCKP3V0EaJl2NtL7OMmNq9iJlaHznHl4ffFOlDviy3MX+Ts 3vIQRdbR8K8bCmzWYRyWIrOk9KU4anRHwAEQI4gEmQ3UiY2Se+mabigOCCWgtZYmjasW HmQQTOaLBBXMB+5B4wOsvtVV+wh/yzyUJdVgCBu+93M+XyrWdTAEJysxEM3vehfsvoMi M2Cy9S+lZFEoIuNtxI52YXeS4H4Wke4Dz1oLXBOi6r9eEBWq45oBi2Lmsz1LQhjuyIIw n7cA==
X-Forwarded-Encrypted: i=1; AJvYcCW6bJHW7P/y3W8i9QllxdWSB/28yDm7awIJshw8yUe2eq7yH/bbEqjh8BoT8vF606N+RmnzdVsZJyAb349APw==
X-Gm-Message-State: AOJu0YxgVmOAKP2J/HJ79ZlWNRRMe0+ERii8iUVroWhOWgLX7bBPXBmz 3lF+iuNSfii93/nDvrcdUOXPmylKXJ2WCm9FcasKq7ng1Ggm5ykfX29rQubGEximmS+699/EYLp XcyWxkNx3M2LCTu3OW++h0EDurYLM1RqSJsBnxqGlzPnc6GG8ny++/kROOQgmNc7pD+08weB1Ck c/lUMb6hHGOEO7kWZf64nZyw==
X-Received: by 2002:a2e:6a02:0:b0:2e1:2169:a5cc with SMTP id 38308e7fff4ca-2ec5931d8c3mr23683161fa.15.1719177882997; Sun, 23 Jun 2024 14:24:42 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEcmE/+iDuQOR2uOhbJEUobvpsTv1XFB2h82rsZCM2Hwo2cZL1tR/+WtcuB71hV6QGVxoSa3Fz3YAEp5ZCaHJ8=
X-Received: by 2002:a2e:6a02:0:b0:2e1:2169:a5cc with SMTP id 38308e7fff4ca-2ec5931d8c3mr23683051fa.15.1719177882494; Sun, 23 Jun 2024 14:24:42 -0700 (PDT)
MIME-Version: 1.0
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> <b327b9e3-faab-472c-996c-440a919c9273@gmail.com>
In-Reply-To: <b327b9e3-faab-472c-996c-440a919c9273@gmail.com>
From: David Farmer <farmer@umn.edu>
Date: Sun, 23 Jun 2024 16:24:25 -0500
Message-ID: <CAN-Dau2qBzdakGQmm-SagLAPbk=Mgt7b=3MkUfyKw9HcjX72hw@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000fe0390061b954a0c"
Message-ID-Hash: XUHPKQWZTK3K6MEN5IOHHOKJJPUSNMJ7
X-Message-ID-Hash: XUHPKQWZTK3K6MEN5IOHHOKJJPUSNMJ7
X-MailFrom: farmer@umn.edu
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: Paul Vixie <paul@redbarn.org>, v6ops@ietf.org
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/gk0zA-IQlz-JC5AawL7KD9Z4SyE>
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 Sun, Jun 23, 2024 at 15:09 Brian E Carpenter <brian.e.carpenter@gmail.com>
wrote:

> On 24-Jun-24 04:40, David Farmer wrote:
> >
> >
> > On Thu, Jun 20, 2024 at 3:23 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> >
> >       That doesn't mean that recommending 1400
> >     or 1500 is wrong, if there is *certainty* that IPv6-in-IPv6 is absent
> >     in a particular deployment scenario.
> >
> >      > this number should be stamped out everywhere. 1232
> >      > likewise. the safe-to-use effective MTU (1500)
> >
> >     In the general case, it still isn't safe.
> >
> >
> > 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.
>
> I don't understand how that helps if there is a 1280-byte bottleneck in
> the middle of the path from the DNS responder to its client, unknown to
> either end. I fully agree that this is an unusual situation.
>
>      Brian


I guess I’m saying that such bottlenecks don’t typically happen without one
end or the other knowing about them. Or maybe I can put it another way: It
is bad network engineering to create such bottlenecks without ensuring one
end or the other knows about them. If one end or the other knows about it,
they should adjust their MTU accordingly.

Such bottlenecks usually don’t happen accidentally; they typically occur
because of remote access VPNs or, these days, what is known as SD-WAN.
Typically, VPN clients automatically reduce the MTU, and SD-WAN solutions
frequently manage the tunnel path with BFD and path MTU detection between
the SD-WAN tunnel endpoints. In either of these cases, you should not have
unknown MTU bottlenecks occurring; the devices that are impacted should be
able to be informed, at least with IPv6.

Thanks