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

[Paul Vixie <[e-mail]>]

On Thursday, 16 July 2020 03:12:45 UTC Mark Andrews wrote:
> > On 10 Jul 2020, at 01:34, Marek Majkowski <[e-mail]> 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 
guessed.)

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.



-- 
Paul