Subject: ENDS0

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Fri, 04 Aug 2000 06:13:47 +0900 (JST)

Report on ENDS0 stuff:

My proposal is to mandate EDNS0 for IPv6 transport. That is, DNS
servers/resolvers MUST use EDNS0 if DNS querys/answers are carried
over IPv6.

There is another proposal from DNSEXT wg, described in
draft-ietf-dnsext-message-size-00.txt. It is to mandate EDNS0 for A6.
That is, DNS servers/resolvers MUST use EDNS0 if they support A6.

In this morning, at the session of DNSEXT, Olafur Gudmundsson, one of
co-chairs of the wg and the author of message-size, made presentation
on message-size. I explained about my proposal after him.

My proposal is DNS-transport oriented while Olafur's one is
DNS-contents oriented. In other words, my proposal is IPv6 specific as
Olafur's one is DNS specific. Impression is that we can pick up both
proposals since they are not contradictional.

Olafur suggested me that my proposal be included in "IPv6 Host
Requirements", on which Marc Blanchet is working. There were no strong
objections araised against this from those who were in the DNSEXT
session.

If there are no objections from IPNG wg, I will help Marc to get the
draft out.

P.S.

The minimum size of resolver's buffer is defined 1280 by both ENDS0
and message-size. This means that UDP payload size can be 1280, so
DNS/IPv6 would be fragmented at servers.

Some of us believe that we need to change 1280 to a smaller
value. Discussions are going on at the DNSEXT ml (namedroppers). If
you are interested in this topic, please subscribe to the list.

--Kazu
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 04 Aug 2000 18:09:55 -0400

>If there are no objections from IPNG wg, I will help Marc to get the

I discussed this with the IPng WG chairs yesterday, and
one of them suggested that the message-size draft actually mandate
EDNS0 for hosts with IPv6 installed. This is a stronger requirement
than I was willing to make, but the other chair suggested to
ask the working group if they thing this is a good idea.

And if they mind that DNSEXT starts dictating IPv6 host requirements.

>you are interested in this topic, please subscribe to the list.

Just for your information, 1280 was put in there hoping for input on
what is the LARGEST value we can get away and avoid fragmentation
by IPv6 most of the time.

DNSSEC is the main motivator for the draft, IPv6 is a beneficiary.

Discussions on what the value should take place on DNSEXT mailing list
[email-masked]

Discussions on if EDNS0 should be mandated for IPv6 capable hosts
should take place here on ipng mailing list.

         Olafur

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Mon, 07 Aug 2000 20:58:59 +0900 (JST)

From: Olafur Gudmundsson <[email-masked]>
Subject: Re: ENDS0

> ask the working group if they thing this is a good idea.

Just for clarification. Does this mean dropping my proposal? Or pick
up both and put them into a draft of IPv6 host requirement?

> should take place here on ipng mailing list.

OK.

I would like to propose as follows:

(1) DNS resolvers MUST implement EDNS0 if they support IPv6 transport
    or AAAA/A6. Such resolvers SHOULD specify 2048 (*1) bytes as
    buffer size to servers. (This requires larger IPv6 reassemble
    buffer than the minimum, ie 1500.)

# (*1) need to discuss an appropriate size

(2) DNS servers MUST implement EDNS if they support IPv6 transport or
    AAAA/A6. They MUST assume client's buffer size is 1024 (*2) if
    clients doesn't specify their buffer size by ENDS0.

# (*2) 1024 comes from the IPv6 minimum MTU, 1280 = 256 + 1024.

--Kazu

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 08 Aug 2000 17:41:47 -0400

>up both and put them into a draft of IPv6 host requirement?

Do both.

># (*2) 1024 comes from the IPv6 minimum MTU, 1280 = 256 + 1024.

As I mentioned in the DNSEXT meeting, 1024 is unacceptably low.
1220-1240 is the number I'm thinking about. This is driven by DNSSEC
and the need to have multiple large signatures in certain high level
zones such as ".", "COM" etc.

As for worries about this causing fragmentation I humbly disagree, for the
following reasons:
1. DNS query is unlikely to traverse multiple tunnels to local server.
2. DNS query to a remote server is unlikely to traverse through a
IPSEC tunnel.

Thus we do not need to worry about extension headers at all and
can go to the upper limit of what IPv6 allows.

         Olafur

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Wed, 09 Aug 2000 10:56:44 +0900 (JST)

> zones such as ".", "COM" etc.

Since my proposal is that DNS resolvers SHOULD specify their buffer
value (e.g. 2048), using the default size (1024, 1220-1240, or what
ever) is a rare case.

So, I'm not particular to 1024 and I agree with 1220-1240.

--Kazu

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 09 Aug 2000 17:09:42 +0900

I have sent a clarification to namedroppers.  please revisit my email
	(if you don't have one, I'll resend)

>2. DNS query to a remote server is unlikely to traverse through a

	tunnel is NOT the issue.  the DNS UDP payload size requirement
	should be computed from minimum MTU (1280 in RFC2460) and minimum
	fragment reassembly requirement (1500 in RFC2460).

	IPv6 minimum MTU is 1280, so if you transmit any packet larger than
	1280 (UDP payload length > 1232) you will have chance for fragmentation.
	it is the reason why kazu picked 1024 (and note the use of SHOULD/MUST
	in his email).

>can go to the upper limit of what IPv6 allows.

	I don't understand why you say so.  Please check the logic behind
	IPv4 DNS UDP payload length.  It is set to 512, because minimum IPv4
	fragment reassembly size is 576.  the mergin between 576 and 512
	(576 - 512 = 64) came from IPv4 header, UDP header and possible IPv4
	options and extension headers.

	We *will* see extension headers in IPv6 DNS queries and replies.
	Please keep some room for them.

itojun

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 09 Aug 2000 09:19:52 -0500

> can go to the upper limit of what IPv6 allows.

Point 1 is probably valid, although it's possible there may be a
tunnel, perhaps even an IPSEC tunnel, to some centralized facility
for all "infrastructure" traffic including DNS.  Point 2 is less
clear, but let's take it as true.  Still, I don't think your
conclusion follows from the premises.

Allowing for one IPSEC tunnel-mode wrapping and nothing else requires
outer IP header		40
ESP wrapping		36 or more, typical
inner IP header		40
UDP header		 8
total			124 bytes -- allowing 1156 payload bytes,
which is probably less than you wanted.

If, on the other hand, the client uses EDNS0 to advertise the lesser
of its resolver DNS buffer size and its IPv6 reassembly buffer limit
(defaulting the latter to 1500 if it can't be determined by some API
function) and the server punts PMTU problems by pre-fragmenting down
to 1280, the "losing" cases are merely fragmented replies rather than
TCP retries or worse.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 10 Aug 2000 17:04:51 +0900 (JST)

From: Jun-ichiro itojun Hagino <[email-masked]>
Subject: Re: ENDS0 

> 	options and extension headers.

Sorry, itojun. I think you misunderstand this.

To my best knowledge:

512 is just defined by RFC 1034 as UDP payload size(ie. buffer size).

The maximum IPv4 hdr (60) + UDP hdr (8) + DNS UDP payload size (512)
equals to 580, which exceeds 576.

See Section 3.1, RFC 791:

    The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information.  For
    example, this size allows a data block of 512 octets plus 64 header
    octets to fit in a datagram.  The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

You can see magic number 64, which I think is meaningless, at least
these days.

# 4 bytes are missing...

--Kazu

---

From: [email-masked]
Date: Thu, 10 Aug 2000 19:35:32 +0900

>equals to 580, which exceeds 576.

	we should save enough room this time, then:-)

itojun

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Aug 2000 19:30:25 +0200

In your previous mail you wrote:

   

=> I propose:
 - 1024 (because of the rationate for 1280) for the *minimal* size
 - 2048 (more?) for the recommended and default size (ie. if someone
   wants less it MUST specify it and MUST NOT try too small).

Thanks

[email-masked]