Re: Use cases for PMTUD and PLPMTUD (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Michael Richardson writes:
> --=-=-=
> Content-Type: text/plain
> 
> 
> Mark Andrews <[e-mail]> wrote:
>     >> I didn't think PLPMTUD worked any better in this situation, or are I
>     >> wrong he re?
> 
>     > Conceptually you do PLPMTUD by adjusting the EDNS UDP size advertised
>     > in the query until you get a response.  This isn't strict PMTUD as it
>     > also accounts for firewalls that are blocking fragments, firewalls that
>     > still think DNS is limited to 512 byte UDP payloads.  Unfortunately you
>     > only have about 3 seconds to do this all in as well as talking to other
>     > servers.  The DNS doesn't have a way of signaling "fragment at this
>     > size".
> 
> I'd forgotten about doing it this way.
> I now recall you explaining it many times before :-)
> 
> It would seem that ICMP based PMTUD is useless for DNS too, and that we
> should do away with 1981?

There is a difference between trying to avoid something and doing
away with something.  Named turns off PMTUD for the sockets it opens
because even with TCP there isn't the recovery time available to
deal with lost PTBs.

That said RFC 1981 works well when the PTB get through for TCP and
if most of the DNS/UDP traffic was fragmented it would work reasonable
well there too however DNS/UDP packets are variable sizes and you
have 1 in N packets being fragmented and the MTU knowledge times
out.  N is dropping and more sites sign their zones.

Firewall developers really don't know how to handle DNS.  They do
lots of really stupid things like dropping EDNS != 0 packets for
no sane reason, dropping EDNS requests with a EDNS option or EDNS
flag set.  EDNS specified safe default behaviours for all these
event but firewall developers seem to think they know better.

Ahhhh this EDNS flag bit is set, the world may end, lets drop the
packet and break the protocol instead of reading the protocol spec
and seeing that the default is for the server to ignore the bit.

Similarly dropping ICMP PTB and fragments.  The world will not end
if you let through a "bad" ICMP PTB or a IP fragment.

Mark

>     > Named tracks successful answers/timeouts with different EDNS udp sizes
>     > as well as the actual response sizes that have got through.
> 
>     > ; [edns success/4096 timeout/1432 timeout/1232 timeout/512 timeout]
> 
>     > Too many timeouts with a particlar size and we stop offering a EDNS UDP
>     > buffer of that size and fallback to the next break point.  These values
>     > are set for 4in6/6in4 + a UDP header.  timeouts with a smaller EDNS
>     > buffer size also count against larger sizes.
> 
>     >> i.e: both are broken for UDP, and in the DNS/UDP case, the server
>     >> never retransmits either... so absent using TCP, it will always just
>     >> fail.
> 
>     > But the client re-queries leading to a re-transmission.
> 
>     >> --
>     >> Michael Richardson <[e-mail]>, Sandelman Software Works
>     >> -= IPv6 IoT consulting =-
>     >>
>     >>
>     >>
>     >>
>     >> --=-=-= Content-Type: application/pgp-signature; name="signature.asc"
>     >>
>     >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux)
>     >>
>     >> iQEVAwUBVrduiYCLcPvd0N1lAQJ7RQf/bInuCsHmVH6AONDSavt/Ut1/xo0NdnRp
>     >> 1vtfg2LwHG5cUJGNpHOdnlg0OdhIJS9KVYN6xP0FQqbfTq4E6zRpoBkw4kMFQFWK
>     >> cYOe8MaXx4FJFWF6MWcugglhWRkFQeSaQyYcn0Odhmeoc7w2/ehlsTfuFNGCnpH9
>     >> 2bJS2Og80JWMDy7Q95IL6JrsKE1/VDDLpJJkQTfqPboZ1BG5Vn6IlDUT+lEMsZly
>     >> By2CSNBglAqVtU5fUPYCa6yCx92I2g8MYePqkjclN1dAlELhlOUllsrJ8F3kCuFs
>     >> 4eT9yAOtU4W7tP/Ka3bBdJTRYnS31NXozgdIlPsnhZ7mXdrks1tQcg== =kitT
>     >> -----END PGP SIGNATURE----- --=-=-=--
>     > --
>     > Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia
>     > PHONE: [phone] INTERNET: [e-mail]
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> --=-=-=
> Content-Type: application/pgp-signature; name="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQEVAwUBVrjckYCLcPvd0N1lAQI/1wf/f42aJtsGxKjkEwNFSedh2jJCEs7H9hhW
> onkwzKj+d+D9zhWwJyiqrZ2C/jLaxz+N6KowvCO8/+xNrbo0yDca5RLfcqWyEMkz
> hb3zwQiDoBdoTFiZ/R+leTWclTx2h9lMzqyCB4cL69PNgmQBFy5NxwSdGE79AUiP
> uQJhbfxxjkKXNkddgAj3z6q8UFuikZQSeYfrAUyoqF+6L/ZlqDIvHLZnw8w1YA5p
> 2krSML8S5XdA0YBcOuH3CAXvLG9tYQiLkRso3UG4OPqD9JgydSUJM/4ef+7cIOOq
> LSl9YKXN2r2E9rcCCye0RL5LPyYo+deL1ZieYOAqaUuKgxW9e7Ozaw==
> =Nax3
> -----END PGP SIGNATURE-----
> --=-=-=--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]