Subject: Re: I-D ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt

From: Robert Elz <[email-masked]>
Date: Mon, 01 Oct 2001 18:57:12 +0700

On the off chance this pseudo-last-call ends before I have a chance to
get on the net again, I object to this draft as well - certainly to it
going anywhere until there's some actual evidence, rather than superstition
to support it.

eg: 2(c) which is currently ...

   c) It is not known if the benefits of A6 outweigh the costs and
      risks.

can exactly equivalently be written as ...

   c) It is not known if the costs and risks of A6 outweigh the benefits.

which when read gives exactly the opposite impression as the former
choice of words.

What's more, that's true whether the term "A6" there is shorthand for
"deployment of A6 RRs" or "failure to deploy A6 records".

kre

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Matt Crawford <[email-masked]>
Date: Mon, 01 Oct 2001 08:54:00 -0500

> > Just a note; I support this but in all honesty, perhaps s/consensus/rough
> > consensus/ would be closer to the community opinion. :-)
> 
> The point of the document is to judge consensus, editors tried to
> capture the "sense of the room" in London and this is now put out
> for judging what kind consensus is  for the recommendations, by the
> working group.

In London we were told that the last part of the joint meeting, but
there was only a voice poll.  The minutes told us that consensus
would be judged on the mailing list.  On the mailing list we were
told to wait for this document.  This document asserts a consensus
that did not exist in the meeting, the minutes or on the list.  (I
have re-read the archives and still maintain this opinion.)

Furthermore, this document makes some purely technical claims that
were soundly rebutted on the mailing list before and after the
meeting.
			Matt Crawford

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 01 Oct 2001 10:15:40 -0700

> ...

uh-oh.  matt, i thought you knew the secret handshake so i wasn't worried
that i didn't (know it).  i guess things are worse than they seemed.

---

From: Rob Austein <[email-masked]>
Date: Mon, 01 Oct 2001 13:01:26 -0400

Date: Mon, 01 Oct 2001 08:54:00 -0500
   From: Matt Crawford <[email-masked]>

Please specify.

(Is it really necessary to CC the IESG on this discussion?)

---

From: Matt Crawford <[email-masked]>
Date: Mon, 01 Oct 2001 13:57:32 -0500

>    were soundly rebutted on the mailing list before and after the

1. That the time to collect an N-link chain of A6 records is
proportional to N.

2. That the chance of failure to complete a chain is "roughly
proportional to N, since each of the queries involved in resolving an
A6 chain has roughly the same probability of failure as a single AAAA
query."

Finally, one that was either invented out of whole cloth for this new
document or the result of a gross misunderstanding of something you
wrote in -ipv6-dns-tradeoffs-00:

3. That "The issues for DNAME chaining in the reverse tree are
substantially identical to the issues for A6 chaining in the forward
tree."

> (Is it really necessary to CC the IESG on this discussion?)

If we are to believe what the chairs have said, then yes.  In a
strictly logical universe, perhaps not.

---

From: Rob Austein <[email-masked]>
Date: Mon, 01 Oct 2001 14:04:00 -0400

Please specify.

---

From: Johan Ihren <[email-masked]>
Date: 02 Oct 2001 17:38:30 +0200

In the draft I stumbled upon this:

> 4 DNAME in IPv6 reverse tree

>    The issues for DNAME chaining in the reverse tree are substantially
>    identical to the issues for A6 chaining in the forward tree.
>    Therefore, in moving RFC 2874 to experimental, the intent of this
>    document is that use of DNAME RRs in the reverse tree be deprecated.

I cannot remember anything about explicitly deprecating DNAME
anywhere. The contentious issue was obviously A6 vs AAAA, the
bitstrings were more or less non-starters and DNAME was more or less
glanced over and deferred back to DNSEXT as purely a DNS issue.

But regardless of that, there is one issue of DNAME that did not come
up and that I think is worth pointing out explicitly:

        With DNAME it is possible to renumber (i.e. change the prefix)
        without changing the *name of the zone* containing the data.

Without DNAME that is no longer possible. And this is true regardless
of whether the reverse tree is based upon bitstrings or nibbles.

And regardless of how often various people think we will or should
renumber, there is from an operations point of view a rather sharp
difference between a change in zone contents (which happens all the
time) and a change in zone names (which require new nameserver
configurations, new agreements with slaves, new delegations, etc,
etc). And all this recursively all the way down the tree from the
point of the prefix change...

AAAA in the forward tree will cause more changes to forward
zones in time of a prefix change but at least the changes will be in
the *same* zone. Not so in the reverse tree without DNAME.

In short: the maintenance headaches in the reverse tree go way up
without DNAME regardless of whether we have A6 or AAAA in the forward
tree. And since they are orthogonal issues the future of DNAME in the
reverse tree should be decoupled from whatever happens to A6.

And I believe that deprecating DNAME in the reverse tree will either
cement a no-renumbering future or kill of the reverse tree for v6
entirely.

Regards,

Johan Ihren
Autonomica

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Oct 2001 17:30:19 -0000

If you're following a chain of n out-of-bailiwick pointers, and each
pointer has probability p of succeeding, independently of the other
pointers, then your chance of reaching the end of the chain is p^n. A
more sophisticated analysis, taking account of timeouts and retries and
multiple servers, produces essentially the same formula. 

As I put it in http://cr.yp.to/djbdns/killa6.html, the success chance
decreases exponentially with the number of out-of-bailiwick pointers.

p^n is approximately 1 - (1-p)n if n is not very large and p is close to
1, so the failure chance is roughly proportional to n.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Oct 2001 18:02:01 -0000

Johan Ihren writes:
> there is from an operations point of view a rather sharp difference
> between a change in zone contents (which happens all the time) and a
> change in zone names

This is a local problem, and you are wildly exaggerating the difficulty
of solving it.

None of IETF's DNS-replication protocols handle new zones. That's why
ISPs use better replication protocols, such as rsync. Better protocols
are becoming increasingly popular at small sites too.

See http://cr.yp.to/djbdns/faq/axfrdns.html#what for a more detailed
discussion of DNS replication.

Similar comments apply to configuration-file formats, web-based DNS
administration tools, etc. Saying ``This rare operation is difficult
with our current tools; what a disaster it would be if the operation
were more frequent!'' ignores the fact that tools can and do change.

---Dan

---

From: Matt Crawford <[email-masked]>
Date: Wed, 03 Oct 2001 09:41:37 -0500

> pointers,

With or without the undefined "out-of-bailiwick" modifier, this is a
large *if* not supported by facts in evidence, and directly
contradicted by recommendations of RFC 2874, section 6.

---

From: Johan Ihren <[email-masked]>
Date: 03 Oct 2001 18:19:28 +0200

> This is a local problem, and you are wildly exaggerating the difficulty

How is it a local problem when it recursively propagates down the
entire hierarchy below the point of the prefix change?

> were more frequent!'' ignores the fact that tools can and do change.

While I'm all in favour of new tools I see no tool on the horizon that
will make reconstructing an entire delegation hierarchy even
semi-automatic.

The main problem as I see it is not one of better zone-replication
protocols, nor tools automating inclusion of new zones, etc, but
rather one of delegation management and to some extent
trust. Automation of new delegations, in a possibly quite deep
hierarchy implies a certain amount of trust between several layers and
I think that is very far off. As it should be, for security reasons.

Regards,

Johan Ihren
Autonomica

---

From: "Andy W. Barclay" <[email-masked]>
Date: Wed, 03 Oct 2001 09:59:51 -0700

I feel you are over-simplifying the problem.

You are assuming that each of the queries is independent. I know
that its not an absolute, but I feel that generally, a dependency
exists,
such that if query "n" succeeds, query "n+1" has an increased chance
of success.
This would imply that the p^n is too pessimistic.

--
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

And The Lord said unto the Good Shepherd "Get
lost...This is cattle country"

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 03 Oct 2001 17:04:19 -0400

> are becoming increasingly popular at small sites too.

As much as it surprises me, I'm mostly in agreement with Dan here. The
lack of automatic zone-creation and -deletion is a *MAJOR* shortcoming of
the DNS protocol suite -- every vendor of DNS management tools seems to do
it differently, and interoperability between the different methodologies
is basically non-existent. This is creating a high degree of "vendor
lock-in" to specific products.

I keep hearing vague claims that automatic zone-creation and -deletion is
barred by some sort of insurmountable security issue, but, frankly
speaking, that's a crock of you-know-what. Even if it were true, any such
security issue would be out of the scope of the DNS protocol _per_se_.

Where I part ways with Dan is in the solution to the problem. He seems to
feel that generic tools like rsync and ssh are appropriate for the task. I
would prefer for automatic zone-creation and -deletion to be made part of
the protocol so that the solution could be self-contained within a
DNS implementation and not have as much dependency on operating-system
architecture and configuration.

- Kevin

---

From: Johan Ihren <[email-masked]>
Date: 04 Oct 2001 17:28:56 +0200

> architecture and configuration.

...and I still think that you are both focusing on the wrong
issue. Zone creation is a problem, yes, but it is possibly a question
of implementation (mostly).

The real issue is reconstructing the delegation hierarchy for the
entire subtree when every single owner name has changed.

Regards,

Johan Ihren
Autonomica

---

From: "D. J. Bernstein" <[email-masked]>
Date: 6 Oct 2001 01:55:30 -0000

> entire subtree when every single owner name has changed.

What's the big deal? If you're changing 128.248.* to 131.193.*, for
example, then obviously you're also changing *.248.128.in-addr.arpa to
*.193.131.in-addr.arpa. This is a straightforward one-pass operation if
the DNS data file format was designed by a competent programmer.

---Dan

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 7 Oct 2001 11:00:19 +0200

> the DNS data file format was designed by a competent programmer.

You obviously haven't tried in real life. 

I'm really sorry, Dan. This is something you can't use to throw
blame on the Bind company; the master file format is the small (if
any at all) problem.

The big issue is to find people that run subzones and get them to
understand that they must perform the necessary steps, as well as
updating the rest of the network structure, since all must happen
in coordination.

As this now is a matter for the DNSOP wg (if at all an IETF matter)
I will stop.

Regards,
-- 
Måns Nilsson			MN1334-RIPE
http://vvv.besserwisser.org	

GOOD-NIGHT, everybody ... Now I have to go administer FIRST-AID to my
pet LEISURE SUIT!!

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Oct 2001 20:13:31 -0000

> You obviously haven't tried in real life. 

UIC renumbered half its network a few years ago. DNS records were the
easiest part of the process.

UIC had already delegated math.uic.edu to the math department. That zone
had a bunch of records referring to 128.248.178.*, for example. The
math.uic.edu administrator had to change those to 131.193.178.*.

You seem to be claiming that DNAME would have eliminated the need for
UIC to notify the math.uic.edu administrator that the network was being
renumbered. That's ridiculous.

Ihren was talking about something different: namely, the difficulty of
renaming the 178.248.128.in-addr.arpa zone to 178.193.131.in-addr.arpa.
Automating this change is difficult with BIND's configuration-file
format. But it's easy with the tinydns data format.

Ihren was claiming that, in a world of frequent renumbering, renaming
zones of this type would be a serious problem. My point is that, in a
world of frequent renumbering, people would use tools that make the
renaming easy. This is a purely local issue.

Coming back to the protocol issues: We could use DNAME to eliminate
zones of this type. But Ihren was wildly overestimating the benefits of
eliminating these zones. Meanwhile, there are huge costs:

   * We'd have to change the DNS software on millions of computers
     before we could start deploying DNAME records.

   * Deploying DNAME records would hurt the reliability of DNS lookups,
     as explained in http://cr.yp.to/djbdns/killa6.html.

So I continue to object to DNAME.

> understand that they must perform the necessary steps,

In case you haven't noticed, your DNS data includes a list of all your
child zones. It even tells you the names of the relevant servers!

Finding all the relevant DNS servers is trivial compared to finding all
the other places---in disk files and, for machines that shouldn't be
rebooted, in RAM---where IP addresses are stored.

Of course, there's also the _really_ big issue of eliminating long-lived
TCP connections from the Internet protocol suite. I've seen a few people
talking about renumbering sites every day; I haven't seen them give any
details of how they'll keep their ssh login sessions going.

None of this is rocket science. If the idea of frequent renumbering is
meant to be taken seriously then all the problems will be solved. This
doesn't mean that we should mindlessly adopt a proposal merely because
it is labelled as ``support for renumbering.''

---Dan

---

From: Randy Bush <[email-masked]>
Date: Mon, 08 Oct 2001 01:32:47 -0700

> If the idea of frequent renumbering is meant to be taken seriously then
> all the problems will be solved. This doesn't mean that we should
> mindlessly adopt a proposal merely because it is labelled as ``support
> for renumbering.''
                 ^ without clearly and simply describing how the ENTIRE
                   frequent and/or fast system will COMPLETELY work.
                   without hand-waving.

randy