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

[Paul Vixie <[e-mail]>]

On Thursday, 21 November 2019 08:32:38 UTC Warren Kumari wrote:
> On Thu, Nov 21, 2019 at 3:54 PM Paul Vixie <[e-mail]> wrote:
> > 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.

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

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