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

Mark Smith <markzzzsmith@gmail.com> Mon, 17 June 2024 02:14 UTC

Return-Path: <markzzzsmith@gmail.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 4994EC1840D6; Sun, 16 Jun 2024 19:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.305
X-Spam-Status: No, score=-1.305 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hFL6p4Ju6JAD; Sun, 16 Jun 2024 19:14:55 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 0CC96C14F6A5; Sun, 16 Jun 2024 19:14:31 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-57cad4475e0so6809304a12.1; Sun, 16 Jun 2024 19:14:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718590469; x=1719195269; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iw9tIQkM6WL1n09GPWnnI8TLrYnXfh/i8dNR6Neagns=; b=G6f4cFTrb6GJrCSptQeaE9TSHOKOyBsvHpJMhF5mdQfioNGSfh+PNJB/ICw8Mgt1Ld XUCwWinSfWRZBdn2hf8kTvolsIv3odvxfNzXkOl2lGuD8wWsKM3clDfMLEdCGdezxfYb Zp2mLpjIsgE7gRqPhhb8vSI/+CacdtCsFK/CCDJglZbDj/gCWeFo1fv0JFhA+vl79UqJ Bwd3asVJLgr0iXEi92+QZSZPgcMOuARm3C8ScyYYh2GtlifnMrOnrr24Ka4yZH8sg4Kp lNse9GnnnFZUR/vynIcsEgEo9OS1JUcYIBJAM4PxuSl0yBIRanHK/3EDoSrXJfAxsQQQ WtUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718590469; x=1719195269; h=content-transfer-encoding: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=iw9tIQkM6WL1n09GPWnnI8TLrYnXfh/i8dNR6Neagns=; b=JUMeU3PLx+weyKg0egmeoeyLyXrw1j+H6atNefNBF3iJzjO0BJGhKdmybbg12+n0K7 4KBbWTCs73JiNTDv7FyDoStPFOe3wxIruyEob4k0AAvyQA+enV/VZjunitb1okFSv0tD i2i6ZdqWWZWReMGIATtOGkS0fW4xVmxaMjuOCK/nok1GN9pZdW+BeH7mwAo3txoaCHVK lXqsiwDGoN655eS8R3U/mA+xdL9D6LkhFZkgA/lSdLCuG6Ks2oafBrVg9tXl9T0eC1ke G4i5/RaMzry9+RJuXsaGnzVcUxZ9ZWlb2EgapF0fKRC3JTJlIouo283shZGlzPT2ZIv1 Vteg==
X-Forwarded-Encrypted: i=1; AJvYcCVvwbuO39t5GE8FCXjTAUj1AaKzzDSiAMs5hBNOtRbRfqq/lQT9V77xPlNCG0i/9Y+topiZBY7Ai7UvN0jN3MYGjZlx361Ktdgzyt3TeP8=
X-Gm-Message-State: AOJu0YxqGoiwf5qjxYh3DZp/pycZCDmnZ28zZnW9L3vUxRR6TL40HpMU kDA+jtsPa5FuhfjtDclVCa49hXXdimxF7MnSkJ0zWX46ryONqTy+KgmvWT/II8A+AVCEqAfJV6k owQZL51U4U7nkvqOaVMDgi67E8N4=
X-Google-Smtp-Source: AGHT+IHiJ3hDjbfoKA7I3p8c+ilD711vRdt3NAiDiCVYF+EXYWtc+K4Vl2XDhad2oIdYZwvruc/n4uy0qVd93l8wbls=
X-Received: by 2002:a05:6402:174b:b0:57c:bec1:ff4b with SMTP id 4fb4d7f45d1cf-57cbec1ffeamr5509552a12.10.1718590468739; Sun, 16 Jun 2024 19:14:28 -0700 (PDT)
MIME-Version: 1.0
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> <DA850D92-422D-4F74-961E-7B4A6038B33C@strayalpha.com>
In-Reply-To: <DA850D92-422D-4F74-961E-7B4A6038B33C@strayalpha.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Mon, 17 Jun 2024 12:14:01 +1000
Message-ID: <CAO42Z2yuYo0asVB9r-vTp5gJtja-N9ARrhAGnqSj8LxAAkcF3w@mail.gmail.com>
To: "touch@strayalpha.com" <touch@strayalpha.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-MailFrom: markzzzsmith@gmail.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: "C. M. Heard" <heard@pobox.com>, 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: [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/UiGTcrwvzSvWtbVrrus_vD8Z8YI>
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, 17 Jun 2024 at 10:28, touch@strayalpha.com <touch@strayalpha.com> wrote:
> 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).


I was surprised how often IP fragments were being dropped over the
Internet through peoples' measurements because I've seen and
configured packet filters many times on IP routers for many
organisations and ISPs and have never explicitly dropped them nor have
heard of people explicitly dropping them.

I realised it is more likely a symptom of the way people are taught to
do packet filters, and that they're specifically not taught to allow
IP fragments.

This following would be a typical example* of how people are taught to
do something like "permit" DNS over UDP, yet it would drop any IP
fragments containing UDP port 53 fragments.

access-list 100 permit udp any any eq 53
access-list 100 deny ip any any

If UDP ports were included in the UDP fragments then the above packet
filter would pass those UDP fragments, and that is why I suggested the
UDP fragmentation options.


* "Configure Commonly Used IP ACLs", last updated on November 21st
2023, mentions the 'fragments' option in the ACL command syntax,
however doesn't describe it or demonstrates using it in "commonly used

> 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
> _______________________________________________
> v6ops mailing list -- v6ops@ietf.org
> To unsubscribe send an email to v6ops-leave@ietf.org