Subject: Re: Comment on draft-reid-ipv6ok-00.txt

From: Kevin Darcy <[email-masked]>
Date: Fri, 01 Nov 2002 18:04:41 -0500

Jim Reid wrote:

> >>>>> "Kevin" == Kevin Darcy <[email-masked]> writes:
>
>     Kevin> Why allocate a bit in the EDNS0 extended flags, which
>     Kevin> you'll probably never be able to de-allocate/re-allocate?
>
> Because it's the best (or least-worst) way to indicate a resolver is
> AAAA aware.
>
>     Kevin> Use an OPTION record instead. For an option which is
>     Kevin> basically just boolean, it only takes up 4 octets (2 for
>     Kevin> the option code and 2 for the length field); hardly enough
>     Kevin> to break the bank, and when the option is no longer needed,
>     Kevin> it can simply be phased out.
>
> Presumably you mean an OPT pseudo-RR as defined in RFC2671? Well the
> prime reason for not going down that road was that it would probably
> mean extra traffic and more latency. Clients are likely to be doing
> EDNS0 probes to negotiate bigger UDP payloads, especially when they
> can reasonably anticipate receiving a bigger payload because of AAAA
> or SIG records or whatever. So since there can only be one OPT RR per
> request/response, your suggestion would require another request/response
> to send some OPT record to indicate AAAA-awareness. That would have to
> be repeated for each DNS transaction. Unless the server kept state of
> course. But that would get ugly very quickly: suppose a client had two
> resolvers, one of which was AAAA-aware and another that wasn't.

Actually, I meant OPTION records in the "variable" part of the original
request's OPT pseudo-RR. See section 4.4 of RFC 2671. There would be no
need for a subsequent request/response transaction.

> The second reason for using an EDNS0 bit was because they are available.

Well, they're available until they're all used up. AFAIK, there are 65536
available OPTION-CODEs but less than 16 bits (= 16 independent boolean
options) available, because some have already been reserved or spoken
for, in the extended flags. Which is going to be exhausted sooner? The set
of protocol elements which deserve an extended flag is supposed to be a
"small collection which we expect to be so popular that it would be a waste
of wire space to encode them as {attribute, value} pairs" (quoting EDNS0
Section 4.2). I don't know that the protocol element you propose meets that
very high requirement.

> And the precedent has already been set in RFC3225: using one of those
> bits to indicate DNSSEC-awareness. In fact much of the draft was
> shamelessly plagiarised from RFC3225.

I don't necessarily agree that RFC 3225 should be using extended-flags bits
either, although the justification for that is probably stronger.

- Kevin

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>