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

From: Jim Reid <[email-masked]>
Date: Fri, 01 Nov 2002 05:47:52 -0800

>>>>> "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.

The second reason for using an EDNS0 bit was because they are available.
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.

--
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/>

---

From: Jim Reid <[email-masked]>
Date: Wed, 06 Nov 2002 09:52:33 -0800

>>  Presumably you mean an OPT pseudo-RR as defined in RFC2671?

    Kevin> Actually, I meant OPTION records in the "variable" part of
    Kevin> the original request's OPT pseudo-RR. 

Of course you did. The caffeine hadn't kicked in when I sent that
reply. Apologies.