Christian Huitema writes ("RE: A6 benefits? "):
> The motivation for A6 is the key database paradigm that atomic
> information (e.g. a site prefix) should be stored exactly
> once. [...]
I agree with Dan's criticism of this argument, namely that it's pretty
much just a mantra rather than a claim that can be justified and
understood. But I want to say more in response to it:
The DNS is not `a database' in that sense; it is indeed a component of
a very unusual large distributed database, but other components
include the software that updates and generates zonefiles.
And it's certainly not true that database systems do not replicate
information. Indeed, the database of which the DNS is part does a lot
of replication of information, deliberately, to support availability
and other useful properties.
There is no reason, as I've explained, why even with AAAA records the
prefix for a given network need be *originally* stored and managed
more than once per administrative domain; there is a wealth of
software that could manage the replication of this information into
the zone files.
So this argument in favour of A6 does not apply, because managing and
storing the prefix information once does not imply A6 and can be done
perfectly well (better, indeed) with AAAA.
> ... The ease of update argument is clear: it is simpler to update
> one record for a large site than to update all records for all nodes
> in the site;
With adequate software this is simply not true.
> this is particularly true when the use of DNS security increases
> wildly the cost of any given update.
A reasonably modern computer can easily do 100 1kbit RSA signatures
per second. So, if each host in a network needs an AAAA RR and a PTR
RR and the corresponding NXTs, that's 4 signatures, so a complete
renumbering of a 1000-host network would take approximately 40 seconds
- less time than it would probably take to propagate the new zone to
the secondaries !
> We did in fact have this discussion in depth 2 years ago, when we
> submitted the draft to the working group.
It's a shame that I wasn't involved in the relevant WG(s) at the time.
I'd heard about AAAA, which seemed obvious and reasonable, and I made
the assumption - with hindsight clearly naive - that insanity like A6
wouldn't get too far. I suppose should have seen which way the wind
was blowing when I read the IPSEC I-Ds, but I thought that the
insanity there was mainly due to the evil influence of cryptography
politics.
> The caching argument is also a natural consequence
> of the "atomic information" property: each component of the information
> can be given an appropriate TTL,
...
> Jim, Randy and some other have made the argument that A6 would increase
> the load on the DNS, by requiring several transaction for any given
> exchange. This type of argument, however, does not take caching into
> account. Prefixes are common to several nodes [...]
This argument, as an argument in favour of A6, is bogus, as a small
amount of thought demonstrates. Consider what happens if you want to
find the address of a host you've not talked to before:
With AAAA, you have to look up the AAAA RR (which won't be in your
cache) and now you have the address.
With A6, you have to look up the original A6 (which won't be in your
cache), and then sometimes (if the next A6 isn't cached), the next
one, and possibly so on up the chain.
So for a host you haven't talked to before A6 is never even as cheap
as AAAA, let alone cheaper. A6 is only cheaper under certain obscure
TTL conditions when you talk to a host you've spoken to recently
(first A6 in the cache), but which has been renumbered since (next A6
timed out) - and even then is only cheaper by one query for each
renumbered host.
When you talk to a network you haven't seen recently the A6 is always
more expensive.
Since you speak to new networks and new hosts (or networks and hosts
whose data has timed out) much more often than networks you are
already speaking to, AAAA involves fewer queries.
Ian.
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
