At Wed, 11 Feb 2004 12:57:24 -0800, Bob Hinden wrote: > > > > - 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.)?
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. :) -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
