Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers

[Masataka Ohta]

Mark Andrews wrote:

 So?  Fragmented packets *do* get through the network.  Where
 they don't it slows up DNS resolution and the firewall usually
 gets fixed to allow fragments.
 
 Yes, hopefully within a decade or two, some firewall maybe fixed.
 So?
 
 Actually the firewalls get fixed pretty quickly in most cases.

If you are thinking of ideal world with relatively new firewalls,
maybe.

The problem is that, in the real world, there are a lot of
firewalls with maintenance period expired.

 But, even today, how much, in your opinion, is the assured-to-be- 
 safe DNS message size over IPv6 with 1280B of MTU?
 
 Well we have space for around 700 bytes of additional header space 
 before EDNS@512 will fail due to fragments being dropped.  Now I'm 
 sure one could artificially consume those 700 bytes but for the 
 moment I'm not worried.

You haven't answered my question.

How much, in your opinion, is the assured-to-be-safe DNS message
size over IPv6 with 1280B of MTU?

Without such size, statements like:

 BIND 9.10 changes the first state to do variable-size probing: it
 will try 512, 1232, 1432, and 4096, starting at the bottom and
 working up and down depending on what works. The middle numbers come
 from the minimum IPv6 MTU minus space for headers, and the ethernet
 MTU minus v4 and v6 headers to allow for tunneling.

can not be made.

Masataka Ohta

PS

It should be noted that my modest proposal to have some
(e.g. 256B) reasonable limit on the extension header
length with an explanation that applications such as DNS
need some limit was formally rejected by IPv6 WG (in
Danvers meeting in 1995, IIRC) that you should expect
more.

IPv6 is produced by collective stupidity.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers

[Paul Vixie]

i think there's a necessary and healthy tension between the installed
base and new technology. i would not like to see every new application
designed to run inside TCP/80, even though that's the only universal
wide area protocol. and we won't see any new application that requires a
forklift upgrade of the whole internet before it can be used -- no market.

in this case i think mark's approach is right, because it works better
for people who fix their firewalls, but it finds a way to work, no
matter what. this puts a little bit of pressure on middlebox makers who
mindlessly constrain future protocols.

sardonically, the reason i chose fragmentation for EDNS rather than a
new MD (More Data) bit in the flags and a new fragment number N of M
option in the OPT RR, is that i imagined getting EDNS deployed in less
than five years. now that it's been almost fifteen years and we're still
fiddling with it, i can see that i made the wrong choice in RFC 2671.

vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop