The motivation for A6 is the key database paradigm that atomic
information (e.g. a site prefix) should be stored exactly once. This has
major consequences on ease of update, as well as caching. 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; this is
particularly true when the use of DNS security increases wildly the cost
of any given update. The caching argument is also a natural consequence
of the "atomic information" property: each component of the information
can be given an appropriate TTL, which means that information that does
not change, such as the lower bits of a node's address, can be stored
with a longer TTL than the site's prefix. The DNS is basically a
distributed database; database theory applies; storing atomic
information exactly once is a basic tenet of database theory; the A6
design is a direct consequence of the theory.
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; the probability that a
prefix information will be cached increases for prefixes that are closer
to the root. If I am looking for the address of "node.example.com", and
I am returned an A6 that contains the node identifier and a reference to
"site-prefix.example.com", there are some serious chances that the A6
record for "site-prefix" is already present in my local cache. This is
specially true if the requesting node is itself a member of the
example.com domain.
We did in fact have this discussion in depth 2 years ago, when we
submitted the draft to the working group. The arguments on each side of
the issue have not changed. Usage examples showed that the DNS load
would be lessened, not increased, if we did caching right, and that the
total amount of information required to encode the addressing data for a
site would be lessened, not increased, in the case of multi-homed site.
In short, the A6 design trades off some additional design complexity for
a lesser management load and a lesser use of DNS resource when either
renumbering or multi-homing are frequent.
-- Christian Huitema
> -----Original Message-----
> From: Ian Jackson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 24, 2001 4:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: A6 benefits?
>
>
> Steven M. Bellovin writes ("Re: A6 benefits? "):
> > In message <[EMAIL PROTECTED]>, "D. J.
> Bernstein" writes:
> > >Is there some other claimed benefit of A6?
> >
> > Apart from not wanting more polling, the idea is to
> facilitate rapid
> > renumbering.
>
> When I described A6 to someone recently they said they thought it was
> so that you could renumber entire networks automatically based on core
> topology changes without the relevant leaf network admins' having to
> do anything.
>
> At the time I dismissed this idea as absurd; we have enough
> reliability problems as it is without large sites and networks being
> made unuseable even internally because someone somewhere at a
> different organisation made a mistake in a configuration and causes
> the DNS to start giving out wrong addresses.
>
> I haven't seen much motivation for A6 in the relevant RFCs and I-Ds,
> so perhaps I'm barking up the wrong tree - in any case, some
> explanation of why this is a good thing and how it is expected to be
> used would be helpful.
>
> Alternatively, perhaps I'm wrong and it is indeed the intent of the
> IPNG working groups that renumbering could happen entirely
> automatically, and need not involve an action by the administrator of
> the site being renumbered. If so I have to say I'm rather alarmed,
> but perhaps I've missed some vital reason why this is a good idea.
>
> On the other hand, I can't see another good reason for A6. After all,
> if renumbering is going to require an administrative action by the
> people who run the site being renumbered, they might as well use the
> entirely normal and standard zone changing mechanisms to do it.
>
> If an admin feels that doing a search-and-replace on their zone files
> is too difficult or error-prone, then they can easily use one of any
> number of tools to help them generate the zone files semiautomatically
> so that they only have to configure the network number in one place.
> If renumbering is too frequent to do like that (more than once a
> month, say) then I'm sure people will develop software to help manage
> it, and perhaps there would be a role for an IETF protocol for doing
> so in a secure and reliable way.
>
> So the whole thing leaves me very confused: either A6 is part of
> something that to me at the moment looks like a mad scheme (with all
> due respect to the people that thought it up), or it's a way to stop
> it from being difficult to be an IPv6 DNS administrator even if you're
> too lazy to find a Perl script and too stupid to write one.
>
> > AAAA is especially problematic if DNSSEC is used, since that would
> > require resigning the entire zone -- and that's expensive.
>
> It seems to me that renumbering your entire network, which will
> involve reconfiguring and possibly breaking zillions of machines,
> adjusting firewalls, etc. etc., is *exactly* the kind of thing that
> security mechanisms should be controlling.
>
> Complaining that the security mechanisms make it too difficult, or
> hard for third parties to do, seems to be missing the point rather.
>
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
