I have sent a clarification to namedroppers. please revisit my email
(if you don't have one, I'll resend)
>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.
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).
>Thus we do not need to worry about extension headers at all and
>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
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
