Subject: RE: A6 benefits?

From: "Christian Huitema" <[email-masked]>
Date: Thu, 25 Jan 2001 08:37:18 -0800

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-masked]]
> Sent: Wednesday, January 24, 2001 4:46 PM
> To: [email-masked]
> Subject: Re: A6 benefits? 
> 
> 
> Steven M. Bellovin writes ("Re: A6 benefits? "):
> > In message <[email-masked]>, "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-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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: Bill Manning <[email-masked]>
Date: Thu, 25 Jan 2001 13:19:49 -0800 (PST)

% 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

	What has changed is some empirical, operational experience
	with A6/DNAME records. The expectation that the mgmt load 
	would be less appears to be based on the premise that the
	overall "clue" factor would rise. What has occured is that
	the clue factor is (still) tending flat, with a rising 
	population. The tools are -NOT- in place to ease the administrative
	complexities, (just where are my offsets anyway?) and the
	encoding methods are fairly non-obvious to the normal 
	operational crowd. While the design may be conceptually 
	elegant, the barriers to adoption are looking -very- high.

	(where oh where is a simple DNAME replacement for:
		%dig -x 192.168.10.10 
	 'cause 
		%dig -x 3ffe:1::c620:242 
	fails. Note that I can "cut" the v6 address from my
	ifconfig.  But now, w/o my useful -x flag, I'm stuck
	with this:
		%dig 2.4.2.0.2.6.c.0.0.(yes, you need them all).1.e.f.f.3.ip6.int

	Not at all operationally friendly.
	The DNAME & A6 wigets are just to wierd to type in. 

	Your mileage may vary.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Jan 2001 16:28:57 -0600

Bill Manning wrote:
...
>         The DNAME & A6 wigets are just to wierd to type in.

Clearly they should be generated by tools, as should any bulk
update of AAAA records. I don't see this as a decision factor.

   Brian

---

From: Bill Manning <[email-masked]>
Date: Thu, 25 Jan 2001 15:20:27 -0800 (PST)

% 
% Bill Manning wrote:
% ...
% >         The DNAME & A6 wigets are just to wierd to type in.
% 
% Clearly they should be generated by tools, as should any bulk
% update of AAAA records. I don't see this as a decision factor.
% 
%    Brian

Generally yes. Operators still need to manipulate the lables and
addresses during troubleshooting. basic tools like dig are indispensible.
If you don't see this as a problem, you clearly don't work with DNS
on a regular basis as an operator.

bulk manipulation argues for tools. debugging problems has near zero
to do with bulk updates. And the tools do not exit. The protocol designers
didn't think it was important and the code developers were just implementing
protocol specs. Having worked with both AAAA/A & PTRs as well as A6 & DNAME
records, I'll avoid the later as long as possible. When their use outweighs
the pain of operational deployment, they will be used. Right now, they
are more trouble than they are worth.

-- 
--bill

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Jan 2001 00:11:19 -0000

Christian Huitema writes:
> submitted the draft to the working group.

I'm skeptical. I can't find server-side indirection discussed anywhere
in the archives. Please provide a verifiable reference.

> information (e.g. a site prefix) should be stored exactly once.

Not just a ``paradigm,'' but a ``key paradigm''! Wow. I see the light!
We have to abolish PTR records, because they repeat information from A
records. Clients that want reverse lookups will have to try forward
lookups on random names. Information should be stored exactly once!

Perhaps you are unaware that there are entire books on the design of
serious databases: credit-card databases, airline reservation databases,
etc. All the designs violate your ``key paradigm'' in a huge number of
ways. Information is stored more than once for the sake of security
(e.g., double-entry bookkeeping for auditors), reliability (e.g.,
transaction logs), speed (e.g., caching, reverse indices), etc.

> This has major consequences on ease of update, as well as caching.

These are certainly issues to consider. They deserve rational analysis,
not ignorant religious nonsense like ``storing atomic information
exactly once is a basic tenet of database theory.''

---Dan

---

From: Robert Elz <[email-masked]>
Date: Fri, 26 Jan 2001 23:13:52 +0700

Date:        Thu, 25 Jan 2001 15:20:27 -0800 (PST)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  | Generally yes. Operators still need to manipulate the lables and
  | addresses during troubleshooting. basic tools like dig are indispensible.

Yes, they are...   But Bill, dig didn't exist in the early days of
IPv4 DNS either, and you actually had to type backwards IPv4
addresses with .IN-ADDR.ARPA in them to nslookup (and hope that
idiot tool was deciding to work that day).

Tools like these come from the needs of the community who are actually
using the things - when there is enough use of IPv6 reverse lookups
that someone gets frustrated enough, the tools will appear, just as
they did for IPv4.   What's more, that's the way it should be, I don't
want someone building diagnostic tools before the actual needs have
been discovered, or we'll end up with another piece of trash like
nslookup...

kre

---

From: Bill Manning <[email-masked]>
Date: Fri, 26 Jan 2001 08:59:38 -0800 (PST)

% 
%     Date:        Thu, 25 Jan 2001 15:20:27 -0800 (PST)
%     From:        Bill Manning <[email-masked]>
%     Message-ID:  <[email-masked]>
% 
%   | Generally yes. Operators still need to manipulate the lables and
%   | addresses during troubleshooting. basic tools like dig are indispensible.
% 
% Yes, they are...   But Bill, dig didn't exist in the early days of
% IPv4 DNS either, and you actually had to type backwards IPv4
% addresses with .IN-ADDR.ARPA in them to nslookup (and hope that
% idiot tool was deciding to work that day).

	True... but nslookup did. Have you tried looking up a
	fragment of a DNAME or BITSTRING lable recently?  
	Not for the faint of heart (or without some OOB information).
	Chaining is "fun" :)

---

From: Ian Jackson <[email-masked]>
Date: Fri, 26 Jan 2001 19:04:23 +0000 (GMT)

Christian Huitema writes ("RE: A6 benefits? "):
> 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 !

> 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
> can be given an appropriate TTL,
...
> 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.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Jan 2001 19:18:52 -0000

Christian Huitema writes:
> 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.

Everything changes. Machines acquire extra IP addresses. Machines
disappear. Even MAC addresses change: network cards die. (It isn't
always possible, never mind easy, to reprogram the MAC address on the
new card.)

Those of us who write caches don't want to deal with users asking ``why
am I getting the old address?'' when a novice administrator starts with
a silly 6-week TTL and then suddenly realizes that he has to change the
address. My cache never saves data for more than a week.

Yes, TTLs vary. Yes, some fraction of queries will be saved by longer
TTLs. But every record, no matter how stable, will be refreshed
periodically. A careful analysis takes all of this into account.

---Dan

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Jan 2001 14:54:00 -0600

Yes, I was thinking about bulk renumbering, not about diagnosis.
I haven't had to dig on a regular basis recently, but I used to do
it all the time...

    Brian