Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt

Paul Vixie <> Thu, 16 July 2020 07:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2E293A100C for <>; Thu, 16 Jul 2020 00:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YPOX7tTLXOP9 for <>; Thu, 16 Jul 2020 00:08:15 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 573CE3A1009 for <>; Thu, 16 Jul 2020 00:08:14 -0700 (PDT)
Received: from linux-9daj.localnet ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by (Postfix) with ESMTPSA id 84D56C3F16; Thu, 16 Jul 2020 07:08:10 +0000 (UTC)
From: Paul Vixie <>
To: Marek Majkowski <>, Mark Andrews <>
Date: Thu, 16 Jul 2020 07:08:09 +0000
Message-ID: <4349548.4ro6kVnuWS@linux-9daj>
Organization: none
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Jul 2020 07:08:18 -0000

On Thursday, 16 July 2020 03:12:45 UTC Mark Andrews wrote:
> > On 10 Jul 2020, at 01:34, Marek Majkowski <> wrote:
> > ...
> > 
> > Slide 34 and 35 indicate, with IPv6:
> > - 38% recursive resolvers fail to reassemble packets with
> > fragmentation extension header
> Which means 62% of the world properly handles fragmented UDP packets.

there's another form of tough love available to us, which is to first send 
fragments. that is, even in the questions, fragment so that the additional 
data section containing OPT is in its own fragment. and likewise in responses. 
don't send any unfragmented datagrams to anybody until they have demonstrated 
that they can reassemble one. make the problem belong to the 38%, and let them 
scream in pain.

when i suggested this approach to the community at DNS-OARC BKK, i was shot 
down. therefore, i now suggest an alternate form of tough love: always set DF, 
and never send (or accept) fragments.

for decades we have been liberal in what we accepted. that scaled negatively. 
so, just as we did last year by making EDNS mandatory, it's time we shifted 
the costs of badly configured networks onto their operators and away from the 
rest of us. either assume fragmentation's going to work, or assume it's not 
going to work.

> > You are suggesting to always use at most 1280 byte packets in IPv6.
> > The draft we are discussing does not suggest that. Did I misunderstand
> > something?
> I’m suggesting that if you send UDP/IPv6 packets > 1280 that you force them
> to be fragmented into 1280 octet fragments.

as the avoid-fragmentation draft explains, it's almost always true that the 
actual PMTU is higher than 1280, even if this has not been determined using 
PLPMTUD or similar.

also explained: why TCP's segment elasticity allows it to precisely meet an 
MTU requirement (whether regulatory like 1280, measured like PMTUD, or 

also: why 1280 for IPv6 corresponds to 68 in IPv4, which are both absurd.

and finally: why a UDP transmitter cannot know the maximum UDP payload size 
due to IP headers that it cannot always predict or control, and why 1232 is a 
bad guess even if the regulatory minimum (1280) is assumed.

those are the topics i'd like to see discussed. we are drifting.