Christian,
>From a computer science perspective you are correct and theoretically you
are correct.
But database technology that has a performance cost greater than its
advantage will not
be deployed and users will reject it. None of us are completely against all
cases of
A6 and completely understand the benefits you site (they were true back in
the very
old days of OLTP for distributed systems so the theory is not new). I am
hearing three
complaints all I agree with as a note:
1. Client DNS implementations today are not equipped to cache lets say
greater
than 3 levels of A6 hierarchy.
2. Lets discuss the model of letting servers do the caching of A6 records
and
leave clients out of this performance pain as the servers also have the
ability to process much better this distributed database concept you
site.
3. Dan B has provided a model in other mail that the queries for servers
with
some change to the indirection model for A6 will improve the performance
of A6 records and again leave the client out of loop.
4. Several of us deploying IPv6 do not want to hold up the show till we get
the
A6 method right (ergo deployment) and to perform for our customers
adequately
and suggest just using AAAA records for now for deployment.
We did not have the implementation experience we have now two years ago. I
would argue
that whats happening is what many of us told the IETF would happen so I
think it totally
fair and correct that we revisit this issue with the scientific data we have
now to
beg the question is A6 ready or not. Should we put some controls on its use
and
deployment. But we don't have to do that for like reasons above with AAAA
records.
regards,
/jim
> -----Original Message-----
> From: ext Christian Huitema [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 25, 2001 11:37 AM
> To: Ian Jackson; [EMAIL PROTECTED]
> Subject: 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. 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
