Subject: [node req] Issue37: EDNS0 support

From: [email-masked]
Date: Wed, 11 Feb 2004 21:14:40 +0200

assigned issue 37

> From OPS Directorate (Pekka):
> 
> I've reviewed this along the line, and it's pretty good stuff.
> 
> I've sent 3 editorial typos to the author directly.
> 
> One bigger issue, which may not be worth a Discuss, but 
> something that 
> IMHO should be discussed in some forum:
> 
>         All nodes that need to resolve names SHOULD implement stub-
>   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
>   support for:
>                                                               
>                                                               
>           
>     - AAAA type Resource Records [RFC-3596];
>     - reverse addressing in ip6.arpa using PTR records [RFC-3152];
>     - 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.
> 

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

---

From: [email-masked]
Date: Thu, 12 Feb 2004 07:28:51 +0200

Hi All,

I'm comfortable with the SHOULD, following the many comments sent already.
I haven't seen any information on how including SHOULD would break anything.

John

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