Re: DNSEXT WG Last Call: Message Size

[itojun@iijlab.net]

>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).

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.

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.


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