Subject: DNSEXT WG Last Call: Message Size

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 29 Nov 2000 14:17:58 -0500

This is a DNSEXT WG last call on this document, please send your comments
to mailto:[email-masked]

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-01.txt

This draft is on standards track, if you disagree with that please state why
in your response.

         Olafur

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2000 08:30:36 -0000

I object to this document, for several reasons:

   * Sections 1.2 and 1.3 are silly. Normal A6 responses don't overflow
     a 512-byte UDP packet. Root servers don't need IPv6 addresses. The
     claimed 13-server limit for UDP packets can be shattered with no
     protocol changes.

   * It's a layering violation to say ``MUST use EDNS0'' when you mean
     ``MUST use a protocol that handles 1024-byte packets efficiently.''
     Why shouldn't we use DNS over, for example, an improved version of
     T/TCP that can handle 1024-byte packets as efficiently as UDP?

   * The underlying efficiency argument is bogus. The document claims
     without justification that requiring TCP ``will cause significant
     overhead and delays.'' In fact, unless there are _frequent_ TCP
     packets, the extra load from those packets is a negligible portion
     of DNS load, not to mention total load.

Does anyone have logs showing a noticeable number of TCP retries? What
was the actual server load, and what difference did TCP make? What are
some examples of the responses that forced TCP retries?

---Dan

P.S. I would like to receive Cc's of all further messages on this topic,
for reasons explained in http://cr.yp.to/djbdns/namedroppers.html.

---

From: [email-masked]
Date: Thu, 30 Nov 2000 10:42:12 +0900

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

---

From: [email-masked]
Date: Thu, 30 Nov 2000 22:25:10 +0900

>     claimed 13-server limit for UDP packets can be shattered with no

	While I agree that 512-byte UDP packet is good for normal A6 responses,
	I strongly disagree that root servers do not need IPv6 addresses.
	In the near future lots of IPv6-only networks will appear.  How do
	you think they will contact root servers?

itojun