Subject: RE: AAAA/A6 thing

From: "Christian Huitema" <[email-masked]>
Date: Tue, 1 May 2001 10:25:18 -0700

> 	this part i don't really understand.  if we advocate "A6 0
<128bit>"
> 	there will be resolver implementation that does not chase A6
chains
> 	at all (like for cellphones or whatever).  if there's no need,
> 	there'll be no code.  then, there will be no possibility for "A6
> 	<non-zero> <less-than-128bit> <chain>".  so I don't really see
> benefit
> 	of "A6 0 <128bit>" than "AAAA".

I think we have to delineate the various motivation and arguments: we
want A6 to facilitate site renumbering and site multi-homing, while
reducing the rate of DNS update; we also want to avoid harmful effects
on the DNS resolution.

The motivation for A6 is still valid; no new argument there, I believe
it will be a great tool for network managers. There have been two
questions on its use, the linkage with the address allocation and the
depth of the hierarchy. The short answer to address allocation is router
advertisement; the short answer to the depth of the hierarchy is that a
depth of 1 is probably adequate to show significant benefits.

The motivation for using "A6 0 <128bit>" is the use of A6 during the
name resolution process, especially at the top level. We don't want root
servers spending their time chasing A6 chains, and we also don't want
the extra-load on root servers that could be caused by clients chasing
A6 chains. This means that the address records of name servers will have
to be explicitly updated when a site is renumbered. I believe that this
is a reasonable compromise; without A6 one would have to update all the
records; with the initial design we aimed at updating exactly one record
per site; with the compromise one would update a few records only.

We definitely need to gather operational experience. For example, an
assumption in the design of A6 is that the higher level of the hierarchy
will be very likely to be cached; whether this is true or false is easy
to measure after a modicum of deployment. Another assumption is that the
nodes can automatically update their addresses, and that the update
process can be synchronized with the DNS updates; this can indeed also
be tested. And, once we are done testing, we should document the
results.

Note that RFC 2874 packs together the use of A6 for name to IPv6 address
resolution, and the use of binary labels and DNAME for the IPv6 address
to name translation. When we conduct the evaluation, it may be useful to
separate the three points: A6, discussed above, DNAME, which has its own
set of benefits and issues, and binary labels, which is clearly an
extension to the core DNS name resolution mechanism.

-- Christian Huitema
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Ian Jackson <[email-masked]>
Date: Tue, 1 May 2001 21:03:48 +0100 (BST)

Christian Huitema writes ("RE: AAAA/A6 thing "):
> The motivation for A6 is still valid; no new argument there,

What motivation for A6 ?  Where can I read what the motivations were
of the authors of 2874 ?

As far as I can tell it was just cooked up in a back room somewhere
under the influence of mind-altering substances.  Now it may have been
properly discussed somewhere in some IETF WG, and it may even have
been designed (though clearly not by anyone who understands the DNS).
However I have asked several times for someone to point me at these
discussions, and I have had no concrete reference.

>  I believe it will be a great tool for network managers.

Please explain.

> We definitely need to gather operational experience.

No, we do not need to gather operational experience to see that
anything useful that can be done with A6 (ie client-side indirection
for the prefix) can be done with AAAA just as well if not better - all
you need is a half-decent tool to help you construct zone files, which
anyone serious has anyway.

We have a serious complexity problem with many IETF and related
protocols at the moment.  There should not be features in any
standards track protocol than cannot be clearly and cogently
justified.

The burden of proof is on A6 proponents to explain how doing the
prefix lookup in the client at resolution time, rather than at the
server side at data generation or load time, is a benefit.  This
burden has not even come close to being satisfied as far as I can see;
perhaps it was in the past (though I doubt it), but if so no-one seems
able to point us at the relevant messages.

> extension to the core DNS name resolution mechanism.

DNAME and bitstring are awful too, and should be abolished as well.
But at the moment we seem to be arguing about A6.

Ian.