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

"C. M. Heard" <heard@pobox.com> Mon, 17 June 2024 14:30 UTC

Return-Path: <heard@pobox.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 D285EC180B70; Mon, 17 Jun 2024 07:30:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.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_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 (1024-bit key) header.d=pobox.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tKg_vYUPLolL; Mon, 17 Jun 2024 07:30:33 -0700 (PDT)
Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E4FC1519A4; Mon, 17 Jun 2024 07:30:32 -0700 (PDT)
Received: from pb-smtp1.pobox.com (unknown []) by pb-smtp1.pobox.com (Postfix) with ESMTP id 8CD0E21B09; Mon, 17 Jun 2024 10:30:29 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=w7N958Qg01Ak00eoFHYQDKJGleOrVqO0 HE7Zx9yCx/0=; b=lSJJRZO7BJHwZ5eSDeGu+Z7F5pr+sxG3o0RSBBt9cD8EWL2k tiDVRcZoVUN32bUuR0piR/BpPRsrGT1hRAlO9ajp420/EmU+ELPRnHyPE2Uc7i6P uWpqvI2YAQSA96u/SYXyKhLYHc37x2wInI8yTlUqezEYqThzZd6ZZPwfbQw=
Received: from pb-smtp1.nyi.icgroup.com (unknown []) by pb-smtp1.pobox.com (Postfix) with ESMTP id 8420521B08; Mon, 17 Jun 2024 10:30:29 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-ed1-f48.google.com (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id EBF1121B07; Mon, 17 Jun 2024 10:30:28 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-57c6011d75dso5447381a12.3; Mon, 17 Jun 2024 07:30:28 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCUikLUsYpOG0riXK/1tT4YsW3RNITKJuQt1Pc/k+UiURbPwQ9WlrZsMrUPYHeR8hnOc3OEnBhUTBo06ClRaPA==
X-Gm-Message-State: AOJu0Yx6KI0o7Ry/7IRMK/e/69H6iIAyIas4Jeg2cJR6XRGzZ6MHJIka GYYpR+jOCQsZc/EmVgtxv1llzVhoLOylIenLA1y6b5mwRzwqV2RTc4qYnb3EOlKBTqA3cgy56ii ZcSg4T0CZmFNLMUfvIj/1R1ca9HA=
X-Google-Smtp-Source: AGHT+IE9hVbVzeE/Zp8UKdzzqkV4timY9+NzbQRgw32EQUSZdW9tCF9XvjkDsuJhI+Da30c/Z+Wo1p1Z9BpAgtekjf0=
X-Received: by 2002:a17:906:b4e:b0:a6e:fa0a:4899 with SMTP id a640c23a62f3a-a6f60cefe7emr616974066b.16.1718634627899; Mon, 17 Jun 2024 07:30:27 -0700 (PDT)
MIME-Version: 1.0
References: <E35DC12F-D1CE-4AE5-B155-612C639A348B@gmail.com> <DU2PR02MB10160CCA998D5A86B9F11F2C388C22@DU2PR02MB10160.eurprd02.prod.outlook.com> <D231A141-0422-458A-8513-F1C8B719D16C@gmail.com> <DU2PR02MB10160023BA09BCA05D446CBD088CD2@DU2PR02MB10160.eurprd02.prod.outlook.com>
In-Reply-To: <DU2PR02MB10160023BA09BCA05D446CBD088CD2@DU2PR02MB10160.eurprd02.prod.outlook.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Mon, 17 Jun 2024 07:30:08 -0700
X-Gmail-Original-Message-ID: <CACL_3VG-L==7jT-U7k=Z50ZF=Kxy7uMnrv_dO45D_UVFRqgy2g@mail.gmail.com>
Message-ID: <CACL_3VG-L==7jT-U7k=Z50ZF=Kxy7uMnrv_dO45D_UVFRqgy2g@mail.gmail.com>
To: Suresh Krishnan <suresh.krishnan@gmail.com>, Mohamed Boucadair <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary="0000000000007eb4e8061b16cea4"
X-Pobox-Relay-ID: 2518BDCC-2CB6-11EF-B6A3-5B6DE52EC81B-06080547!pb-smtp1.pobox.com
X-MailFrom: heard@pobox.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: "v6ops@ietf.org" <v6ops@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [v6ops] Re: [tsvwg] 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/zIS7GeirqE7CdeCDkH5k8bLgSBU>
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 Mon, Jun 17, 2024 at 6:15 AM Mohamed Boucadair wrote:

> [ ... ]
> > De : Suresh Krishnan <suresh.krishnan@gmail.com>
> > Envoyé : lundi 17 juin 2024 12:10
> > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> > Cc : v6ops@ietf.org; tsvwg@ietf.org
> > Objet : Re: [v6ops] Carrying large DNS packets over UDP in IPv6
> > networks
> >
> >
> > Hi Med,
> >
> > > On Jun 14, 2024, at 10:10 AM, mohamed.boucadair@orange.com
> > wrote:
> > >
> > > Hi Suresh, all,
> > >
> > > (ccing tsvwg)
> > >
> > >  FWIW, large DNS packets was the main driver for the FRAG UDP option:
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-32#section-11.4
> .
> >
> > Thanks for this pointer. I read the draft based on your message
> > as well as Joe's mail downthread. It is very interesting and I
> > would love to learn more about the implementations on the client
> > side and whether it would be a viable alternative in the near
> > term.
> >
> [Med] I'm aware of
> https://datatracker.ietf.org/meeting/103/materials/slides-103-tsvwg-sessa-51-cco-and-implementation-status-for-udp-options-02
> (or long version
> https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones-00)
> Gorry may have more to share here I guess.

For a more complete version of that work see in

That work found that approximately 20% of packets with UDP options sent to
DNS servers included in the test failed to elicit a response and concluded
that the cause was on-path filtering.

As I pointed out earlier in this thread, there is a short draft that
proposes a backward compatible and incrementally deployable method for
using UDP options to allow DNS over UDP to transmit large DNS responses.
One of the key features of the proposal is that an option client signals
its ability to accept UDP fragmentation by including the MRDS option (
in its requests (or at least in those expected to elicit a large response).
As long as the network does not drop packets with UDP options, this should
work very well: options-aware servers would send large responses using UDP
fragmentation, uptions-unaware servers would truncate large  responses
(causing fallback to TCP), and small responses would be sent normally. But
if a significant number of client requests with the MRDS option get dropped
in the network, then the client would need to implement some kind of
probing method to determine if the path supports UDP options. It is then
unclear whether one might not end up better off to just rely on truncation
and fallback to TCP. See
more discussion.

Mike Heard