Re: DNSEXT WG Last Call: Message Size

[Olafur Gudmundsson <ogud@tislabs.com>]

At 08:42 PM 11/29/00, itojun@iijlab.net wrote:

> >This is a DNSEXT WG last call on this document, please send your comments
> >to mailto:namedroppers@ops.ietf.org
> >
> >This document updates RFC2535 and RFC2874 (A6)  to demand larger
> >UDP message size than 512  bytes. This document mandates that any
> >entity supporting either DNSSEC or A6 records must support EDNS0 on queries
> >and responses.
> >The motivation(s) for this is the increase in size of DNS answers caused
> >by DNSSEC, IPng, TSIG and large the desire for large answer sets.
> >The document assumes that modern operating systems can do UDP reassembly,
> >thus this the single UDP message requirement can be relaxed and this is
> >less costly than falling back on TCP for all large answers.
> >
> >This WG last call ends December 17'th 2000.
>
>         I have one comment to the draft.  Isn't it necessary for us to 
> document
>         some recommendation on fragmentation?  for example, addition of the
>         following section would be better for readers...
>
>         if it is out of scope of the document, i should come up with separate
>         document (actually, this is not a DNS issue but IPv6 UDP issue).


I agree there might be some merit to do this but I'm not sure
I want to put that text in this documentation. I think a small
clarification in the host IPng requirements document is better.


>itojun
>
>
>Fragmentation and path MTU discovery
>
>Unlike IPv4, IPv6 mandates path MTU discovery.  No packets will be fragmented
>en route.  Therefore, for both servers and resolvers, large UDP 
>queries/replies
>may not reach the peer.  Intermediate routers will transmit ICMPv6 too big
>message in that case.
>There can be couple of implementation choices.  (3) is the easiest but
>could be inefficient.  (1) puts some assumption to operating system, can
>be slow on catch up to the new MTU (due to timeout), but is easy enough to
>implement.  (2) should present the best behavior, but implementation could
>become too complex, specifically for server side.

DNS servers can be implemented as "answer and forget" servers thus
it is not within scope to require that they implement retransmission in
UDP. Storing state on the servers to do retransmission is more expensive
than answering a new query. Not to mention the DOS potential of such
mechanism.


>1. Do nothing special, rely upon path MTU discovery.  Send a large packet 
>as is.
>    If answer does not come back, retrnansmit the large packet again
>    after retransmission timeout, assuming that the operating system
>    has notified of smaller MTU and automatically fragment it.
>2. Try to implement retransmission logic.  When server/resolver receives
>    ICMPv6 too big message, retransmit query/reply using the new path MTU.
>3. Always fragment large UDP queries/replies to IPv6 minimum mtu (1280 octets
>    according to RFC2460), to avoid path MTU discovery completely.


The last option was my intention, BUT if the server can learn the MTU
from the small query packet then 1.would be optimal.
The middle solution will not work, as that requires server to allocate
state that is only removed after time out, unless there is feedback that
the data got to the client.
Based on the experience we had in the DNSSEC/IPv6 WES we held
Friday and Saturday after the IETF all the implementations present
handle fragmentation well.
The problems with large UDP answers are mainly going to show up
in networks with high loss ratios.
Message size combined with DNSSEC-OK bit will minimize the transmission of
the MEGA DNS answers except to the hosts interested in DNSSEC.

         Olafur



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.