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

From: Warren Kumari <[email-masked]>
Date: Thu, 21 Nov 2019 14:54:47 +0800

Hi all,

The draft on fragmentation which was being mentioned in the Thursday
sessions was:

 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.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Nov 2019 07:54:23 +0000

On Thursday, 21 November 2019 06:54:47 UTC Warren Kumari wrote:
> ...

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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 21 Nov 2019 16:32:38 +0800

> was technically permitted by DNS itself, though in practice, not used before

Apologies, I was unable to parse the above -- what exactly is
incorrect? You said that the reference is incorrect, but then that
that is accurate.
What should it be changed to?

W

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Nov 2019 08:51:13 +0000

On Thursday, 21 November 2019 08:32:38 UTC Warren Kumari wrote:
> > can someone who knows the rfc editor please tell them that the reference
> > in this section is incorrect:

> > 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.

> that is accurate. What should it be changed to?

the apologies are from me not you! i was posting while breathing, and left out 
my conclusion thereby. i don't think RFC1035 should be blamed for reliance on 
IPv6 fragmentation, both because IPv6 did not exist at the time, and because 
any reliance on IP fragmentation of any kind was apocryphal -- its use was so 
rare and those rarities so failure-prone (inducing lookup failures, or 
selection of a different available server, or TCP retries) that it seems 
unfair to list it here.

it would be fairer to change the reference to "EDNS" (RFC2671)"[1], which did 
in fact rely on IP fragmentation in general and since it came during the IPv6 
era it can be accused of knowingly relying upon IPv6 fragmentation directly.

[1] i don't mean [Damas], which is a revision to RFC 2671 by later innocents.

if the authors or editors wish to correct this reference in another way, they 
could change "The following applications rely on IPv6 fragmentation:" to "The 
following applications implicitly or apocryphally rely on IP fragmentation:". 
in other words change IPv6 to IP, and make sure lack of actual reliance for 
the majority actual production use did not happen in the pre-RFC2671 era.

--

i want IP datagrams to outgrow the MTU of 10-megabit ethernet from 1980, and 
we're going to need PMTUD or some modern replacement to get there. but we 
won't get there with fragmentation, and i knew better when drafting RFC2671, 
and i thought (stupidly) that EDNS1 would be along with the MD (more data) bit 
soon enough to save us from the folly of fragmenting DNS messages. (this was 
idiocy on my part, for more than one reason.)

-- 
Paul