Re: [DNSOP] Draft mentioned in meeting re: fragmentation .

Paul Vixie <paul@redbarn.org> Thu, 21 November 2019 07:54 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741F9120147 for <dnsop@ietfa.amsl.com>; Wed, 20 Nov 2019 23:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRuj9_mnd-k0 for <dnsop@ietfa.amsl.com>; Wed, 20 Nov 2019 23:54:32 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3B4120048 for <dnsop@ietf.org>; Wed, 20 Nov 2019 23:54:32 -0800 (PST)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C4A1BB0588; Thu, 21 Nov 2019 07:54:30 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Date: Thu, 21 Nov 2019 07:54:23 +0000
Message-ID: <5031667.0FC68XRKFj@linux-9daj>
Organization: none
In-Reply-To: <CAHw9_iLhqmfv9=2P2-Hybxd-ncctm8vk=eSo8S8jH+TDG6fhhg@mail.gmail.com>
References: <CAHw9_iLhqmfv9=2P2-Hybxd-ncctm8vk=eSo8S8jH+TDG6fhhg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qiMu2NWxavAdglWdHDabtm3ykk0>
Subject: Re: [DNSOP] Draft mentioned in meeting re: fragmentation .
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2019 07:54:51 -0000

On Thursday, 21 November 2019 06:54:47 UTC Warren Kumari wrote:
> ...
> 
>  IP Fragmentation Considered Fragile
>                    draft-ietf-intarea-frag-fragile-17
> https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/
> 
> 
> This is currently with the RFC Editor.

can someone who knows the rfc editor please tell them that the reference in 
this section is incorrect:

> 5.  Applications That Rely on IPv6 Fragmentation
> 
>    The following applications rely on IPv6 fragmentation:
> 
>    o  DNS [RFC1035]
>    o  OSPFv3 [RFC2328][RFC5340]
>    o  Packet-in-packet encapsulations

that's pretty accurate. RFC 1035 specified 512 octets as the maximum UDP 
payload, because adding UDP and IP headers, and IP options, yielded the 
largest IP datagram size that receivers were required to be able to reassemble 
if fragmentation occurred (576). in practice, this only happened on 
experimental links whose MTU might have approached the minimum (68).

in other words as much as i was stupid in EDNS for invoking fragmentation, it 
was technically permitted by DNS itself, though in practice, not used before 
EDNS.

-- 
Paul