Subject: Re: [node req] Issue37: EDNS0 support

From: Bob Hinden <[email-masked]>
Date: Wed, 11 Feb 2004 12:57:24 -0800

>
> >     - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
> >       octets.
> >
> > .. I'm operationally concerned about the last SHOULD.  As far as I
> > know, EDNS0 is not really implemented.  It does not seem to include a
> > SHOULD to something that hasn't seen practical, wide-spread
> > deployment
> > already.  I'd recommend removing this or rewording it to a MAY.
> >

Is there a technical problem with EDSNO (e.g., broken, doesn't scale, too 
complex, etc.)?  Or has it not been deployed because it hasn't been 
implemented.  If it's the latter than making it a SHOULD be implemented 
would appear to be the right message.

Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Feb 2004 22:43:39 +0100

=> I simply disagree with the "as far as I know, EDNS0 is not really
implemented". IMHO this is not true and not only in DNSSEC testbeds
where EDNS0 is really needed.

Regards

[email-masked]

---

From: Rob Austein <[email-masked]>
Date: Wed, 11 Feb 2004 17:00:19 -0500

At Wed, 11 Feb 2004 12:57:24 -0800, Bob Hinden wrote:
> complex, etc.)?

No.  It's somewhat baroque due to the need for retrofitting it into an
old protocol, but there's nothing complex about it.  There simply
hasn't been a pressing need to deploy it in stub resolvers that only
deal with IPv4.

> Or has it not been deployed because it hasn't been implemented.  If
> it's the latter than making it a SHOULD be implemented would appear
> to be the right message.

Server-side support for EDNS0 has been deployed for a long time, as
has client-side support in recursive name servers.  Certainly there
are server implementations that don't support ENDS0, but then there
are server implementations that don't support AAAA RRs or IPv6 either.

Client side support for EDNS0 in stub resolvers has not been critical
with IPv4 because the addresses are smaller than in IPv6.  We have
known for a long time that adding AAAA RRs to the mix is likely to
push us over the packet size limits.  See RFC 3226: it needs updating
(A6 RRs rather than AAAA RRs) but it is a proposed standard.

So, in summary, I do not agree with Pekka about changing this SHOULD
to a MAY.  Changing it to a MUST, perhaps. :)

---

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Feb 2004 23:56:35 +0200 (EET)

> where EDNS0 is really needed.

I'm not really sure what you're saying -- do you mean "EDNS0 is really 
needed in DNSSEC testbeds" and 
 a) "thus EDNS0 is needed" , 
 b) "and EDNS0 has been implemented otherwise as well", or
 c) something else?

AFAIK, most BSDs implment EDNS0 but none of them enable it by default.  
Linux glibc doesn't implement it.  Microsoft does not implement it
(not sure).  

BIND does implement it, but the *point* here is stub resolver support
("node requirements"), not the support in DNS servers.

AFAIK, we don't have real deployment experience of this.  I don't
think we know the full consequences resulting from EDNS0 use because
it hasn't been widely used yet. Thus, I'm a bit hesitant to put
wording as strong as SHOULD here.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Feb 2004 23:15:37 +0100

=> b)

=> I believe the problem is that some buggy DNS codes don't like at all
EDNS0 queries.

   Linux glibc doesn't implement it.

=> please fix this!

   Microsoft does not implement it (not sure).

=> same (if true).

=> but the deployment issue is more in servers.

=> please ask the dnsop WG if you have a doubt. And look at RFC 3226
even it should be updated.

Regards

---

From: Bob Hinden <[email-masked]>
Date: Wed, 11 Feb 2004 15:25:26 -0800

Rob,

>to a MAY.  Changing it to a MUST, perhaps. :)

So we should be encouraging people to include it in their IPv6 
implementations.  Hence a SHOULD for EDNSO in IPv6 node requirements as 
currently written.  Or as you suggest a SHOULD++. :-)

Thanks,
Bob

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 12 Feb 2004 14:07:34 +0900

>>>>> On Wed, 11 Feb 2004 23:56:35 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> wording as strong as SHOULD here.

If this is your main reason, I disagree.

First, as Rob pointed out, we have enough experience about the client
side of EDNS0 in DNS recursive servers, which I believe can be applied
to the deployment at stub resolvers.

Secondly, the node requirement document contains other SHOULDs of
which we have little real deployment experience:

   Nodes that need to join multicast groups SHOULD implement MLDv2
   [MLDv2].
   (Section 4.6)

   Hosts SHOULD support route optimization requirements for
   correspondent nodes described in Section 8.2 of [MIPv6].
   (Section 7)

With your logic, we'd also have to change these SHOULDs to MAYs
(perhaps you've already insisted this?).  IMO, the deployment status
and experience about EDNS0 (the client side or even at stub resolvers)
is much more mature than that for these SHOULDs.

I personally do not think supporting EDNS0 at stub resolver is crucial
even with AAAA RRs (at least *without* DNSSEC RRs), BTW, because such
resolvers usually only need short sizes of packets; short enough to
meet the 512-byte requirement.  In this sense, I would not oppose to
the SHOULD, but I'm not insisting a SHOULD.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]