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

From: [email-masked]
Date: Thu, 07 Mar 2002 06:20:16 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title		: Representing IPv6 addresses in DNS
	Author(s)	: R. Bush, A. Durand, B. Fink, O. Gudmundsson, T. Hain
	Filename	: draft-ietf-dnsext-ipv6-addresses-01.txt
	Pages		: 6
	Date		: 06-Mar-02
	
This document clarifies and updates the standards status of RFCs that
define direct and reverse map of IPv6 addresses in DNS. This document
moves the A6 and Bit label specifications to experimental status.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsext-ipv6-addresses-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-ipv6-addresses-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Roy Arends <[email-masked]>
Date: Thu, 7 Mar 2002 13:28:36 +0100 (CET)

> 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.

Either move 2672 (DNAME) to experimental or not. Deprecating DNAME RR
usage in the reverse tree implies that forward/reverse are technically
different. They are not.

Roy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 7 Mar 2002 08:57:18 -0500 (EST)

> usage in the reverse tree implies that forward/reverse are technically

The reason for not changing the status of DNAME is that there might
be other uses for DNAME than just supporting the reverse lookup.
Thus moving DNAME off the standards track is a larger question than
just for IPv6 addresses.

Lets do one thing at the time.

	Olafur

---

From: Roy Arends <[email-masked]>
Date: Thu, 7 Mar 2002 15:51:06 +0100 (CET)

> Thus moving DNAME off the standards track is a larger question than

Then please rephrase that part. The draft currently states that "the
intent of the document is that use of DNAME RRs in the reverse tree be
deprecated." which is IMHO not the same as "just for IPv6 addresses".

> Lets do one thing at the time.

Then please remove the disputatious premature suggestion.

Regards,

Roy

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Mar 2002 08:03:35 -0800

> be other uses for DNAME than just supporting the reverse lookup.

there *might* be reasons to keep nuclear weapons in your home.  there
*might* be reasons to eat broccoli.

YAGNI <http://xp.c2.com/YouArentGonnaNeedIt.html> and
<http://c2.com/cgi/wiki?DoSimpleThings>

randy

---

From: Johan Ihren <[email-masked]>
Date: 15 Mar 2002 16:02:29 +0100

Roy Arends <[email-masked]> writes:

> Either move 2672 (DNAME) to experimental or not. Deprecating DNAME
> RR usage in the reverse tree implies that forward/reverse are
> technically different. They are not.

Also, the following statement:

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

is plain wrong. 

In the forward tree without A6 the delegation hierarchy stays intact
while the RRs have to change. In the reverse tree without DNAME the
entire delegation hierarchy breaks apart since the names of the
delegation points change recursively all the way down the tree.

To call that "substantially identical" is, even to a very stretchable
imagination, still a mindboggling statement.

If you're determined to kill DNAME you should at least not use broken
justification for the deed.

Johan Ihrén
Autonomica

---

From: Johan Ihren <[email-masked]>
Date: 15 Mar 2002 16:53:19 +0100

> <http://c2.com/cgi/wiki?DoSimpleThings>

Another well known design rule is
        
        "Make it as simple as possible -- but not simpler"

My (still active) objection to your referral to YAGNI and similar
quips [when debating DNS support for renumbering] is that we're not
talking about unneeded functionality that can be retrofitted if and
when we decide that it indeed was needed.

We're talking about functionality that we basically already have,
since the deployed base is so small, but which will be impossible to
retrofit afterwards because of the deployment time once the base is
large.

I seem to remember that Olafur made a guesstimate of 16 years for new
DNS functionality (he was talking about some other functionality, but
that doesn't matter to the timeline) to propagate to a sufficiently
large fraction of the hosts that it could be said to be "deployed".
Once v6 takes off this will get worse, due to all kinds of embedded
devices and other non-computer thingies that will never get updated.

It may well be that A6 and DNAME were mistakes, although I don't think
so, but I really object to you trying to make light of the issue by
referring to it as a KISS(*)-problem.

This is *not* simple. It should not be treated as if it was simple.

Johan

(*) Keep It Simple Stupid.

---

From: Rob Austein <[email-masked]>
Date: Fri, 15 Mar 2002 13:21:13 -0500

> delegation points change recursively all the way down the tree.

This is why we have last calls.

The intent of the statement in the draft (derived from something I
wrote) was that the issues with DNAME chaining were substantially
similar to the issues with A6 chaining from the point of view of how
much work a resolver would have to do to chase down an answer.  As far
as I can recall, this is the first time that the distinction Johan
raised has come up, so I'd ask Johan to please suggest improved text
to the draft authors.

I'm pretty sure that the draft authors never intended to comment on
more general issues involving DNAME, only on use of DNAME as A6's
counterpart in the reverse tree, but given that this apparently is not
clear to all readers, the draft probably ought to say so explictly.

None of the above should be taken to indicate that I (or, I assume,
the ADs, or the WG chairs) are ignoring all the other discussion.
It's just that Johan's point is one on which I think there's some
chance of achieving consensus on rational engineering grounds, whereas
the larger discussion is starting to make me think that it's time for
me to re-read Danny Cohen's "On Holy Wars And A Plea For Peace".

--Rob

---

From: Johan Ihren <[email-masked]>
Date: 15 Mar 2002 22:55:03 +0100

Rob Austein <[email-masked]> writes:

Hi Rob,

> raised has come up, so I'd ask Johan to please suggest improved text

There was a long exchange on this on namedroppers in the beginning of
october last year, subject line is "DNAME (was: Re: I-D
ACTION:draft-ietf-dnsext-ipv6-addresses-00.txt)", i.e. it started when
I responded to the previous version of this draft.

As to improved text I am really at a loss. As I see this deprecating
DNAME for the reverse tree will either lead to "don't renumber" or
"lose the reverse tree when you renumber".

I'm not trying to be provocative here but if the authors want text to
justify deprecation they clearly cannot use things like "the reverse
tree is not important enough" or "it is so unlikely that renumbering
will happen anyhow", so instead I would suggest that they add some
text on exactly why DNAME is considered so dangerous in general and in
the reverse tree in particular. But that will not work either,
according to your next paragraph...

Well, then the only thing that remains is some text that details the
bad consequences of this choice without going into justification
(which will look kind of strange). If that is what is wanted I'll try
to write up something concise on my the to the IETF tomorrow.

> clear to all readers, the draft probably ought to say so explictly.

I admit that it was clear to me, but that doesn't make it less
important the the consequenses of deprecation of DNAME limited to the
reverse tree are clear, and judging from the draft it wasn't at all
clear that they were.

> me to re-read Danny Cohen's "On Holy Wars And A Plea For Peace".

I agree with this, and I did think before responding. But since my
point from last year apparently had been lost I think it was right to
reopen this for the umpteenth time.

And I simply had to respond when Randy waved a broccoli as his weapon
of choice in the battle against the A6/DNAME proponents... He really
has to modernize his weaponry ;-)

Johan

---

From: Randy Bush <[email-masked]>
Date: Fri, 15 Mar 2002 15:13:57 -0800

indeed, we've been here before.  the essense is

  o ipv6 does not actually support rapid or frequent renumbering,  it
    would be nice if it did, but it doesn't.  ask steve deering.

  o hence, adding mechanisms to the dns to support something that
    isn't there is kinda strange.

  o and the possibility that some strange dns hacks would then have
    to be an architectural constraint on ipv6 renumbering work ("no,
    you can't do that because that's not the way DNAME works") is
    actual damage, not just wasted work.

  o dname itself is quite prone to ill use and abuse, as we have seen
    in a lot of wgs who see it and get oh so clever ideas, e.g. enum.

so
  o we do not have a constructive immediate or visible use for it
  o it is dangerous
  o we have enough features and complexity already

randy

---

From: Robert Elz <[email-masked]>
Date: Sat, 16 Mar 2002 15:39:11 +0700

Date:        Fri, 15 Mar 2002 15:13:57 -0800
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  |   o ipv6 does not actually support rapid or frequent renumbering,  it
  |     would be nice if it did, but it doesn't.  ask steve deering.

It doesn't matter whether renumbering is rapid or frequent (terms with
no definitions anyway, so what is "frequent" to one person is amazingly
stable to another).

The point is that A6 makes renumbering easier.   There is simply no doubt
about that.  Whether you end up taking advantage every week, or only
once in your life - (or even never, but just use it to make the zone
file look cleaner, with less repeated information), it's added complexity
enables things to be simpler.   Like anything powerful, use it badly, and
it can most likely cause harm.

The real opposition to A6 seems to have largely been summed up in
Rob Austein's recent message (relating to the DNAME part):

  similar to the issues with A6 chaining from the point of view of how
  much work a resolver would have to do to chase down an answer

That is, it is harder for the resolver.   No question about that.   But the
resolvers get written once, there may be a hundred of them through the life
of IPv6 (just as likely merely a half dozen recycled over and over).
To make it easier for the resolver, we're going to make the administrators
lives harder.

This doc shouldn't exist.   What should exist are some guidelines for how
to use A6 (and DNAME too probably) well, and avoid causing the kinds of
problems that potentially might occur if they're badly configured.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Mar 2002 10:06:33 -0000

[ post by non-subscriber ]

Robert Elz writes:
> we're going to make the administrators lives harder

No. The administrator remains perfectly free to tell his server ``My
address is the address of math.uic.edu but ending with 181.''

A6 and DNAME delay this indirection until the last possible moment,
inserting it into the critical path in DNS lookups. That's a serious
mistake. That's what we're fixing. But indirection is still allowed. The
server can automatically watch the math.uic.edu address.

Perhaps the phrases ``synchronous indirection'' and ``asynchronous
indirection'' will make the issue more clear than my previous
``client-side indirection'' and ``server-side indirection.''
Aynchronous indirection has to be on the server side, of course, but 
what's really important is that it's happening in the background.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Mar 2002 08:11:07 -0000

> delegation points change recursively all the way down the tree.

As I said in October:

   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. ...

   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.

I also summarized in that message why I object to DNAME---not just its
primary intended application, but _any_ use of it.

---

From: Dean Anderson <[email-masked]>
Date: Sat, 16 Mar 2002 15:00:36 -0500 (EST)

The tasks of DNS administrators is usually something handled by scripts
and automation.  So whether something is "easier" for an administrator
depends on whether it can be automatically produced by a script or a
program.  A corporate renumbering is likely to be performed using a
computer with relatively unlimited resources, its very likely to be
handled with the help of automation tools and scripts, and is not very
likely something done by "hand", except perhaps in the smallest and most
trivial cases.

Even with IPv4, it is very common to see much of DNS administration
automated.  Why should we expect that trend to change? However, making the
resolver more complex severely affects the ability of small devices to use
IPV6 due to severe resource limitations on small devices.

Protocols are written for devices and users of those devices, not for
administators.

It is very clear that this issue basically divides along the lines of
which set of priorities is more important.  I think that administration
takes a back seat to operation. Especially when the administration part is
likely to be automated anyway.

I think it is important to have our priorities set properly, and that we
should have a simpler resolver, rather than simpler administration files.

		--Dean

---

From: Robert Elz <[email-masked]>
Date: Sun, 17 Mar 2002 14:29:11 +0700

Date:        16 Mar 2002 10:06:33 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | No. The administrator remains perfectly free to tell his server ``My
  | address is the address of math.uic.edu but ending with 181.''

That's sufficient sometimes.

But it isn't adequate for all cases.

The simple case where this fails is for the end user organisation, that
would currently be using NAT and a PPP - where their NAT is configured to
simply map into whatever address the provider's PPP happens to allocate.
That kind of organisation mostly simply doesn't know, or care, what
address they're being given.

We need to keep things this simple, for those who want it, while also
providing extra functionality - including the ability for the org to manage
their own DNS (which the provider would usually do now) and certainly without
NAT.

But the org will still want to simply use whatever prefix the provider gives
it, and not care at all when it changes.

That much can be done with the DNS server doing the creation of AAAA addresses
(which means continually polling the provider to see when a change might
happen).

But if the org also wants DNS security, and isn't prepared to have its
key left on line, then with AAAA there's simply no way.   On the other hand
with A6 it is simple.

	my-node	IN	A6	48 <trailing 80 bits> my-org-name.isp.net.
		IN	SIG	stuff

and in the provider's zone

	my-org-name	IN	A6	0 <my-org's prefix>
			IN	SIG	stuff

Nothing in my zone file changes when my prefix changes, nothing needs to
be re-signed, unless I decide to make a change to some internal addressing.

When my provider needs to change my prefix, they just do it, and re sign it
(which uses their key of course) - most likely allocating me two prefixes for
the transition period (and perhaps using router renumbering, or something
similar to advise my router to start advertising the new prefix and deprecate
the old - that part isn't a part of the DNS so isn't relevant here).

Everything just works...   without A6 it cannot.   There are times when 
deferring the resolution of the address provides advantages that doing it
early cannot

Of course, the DNS as a whole gains a bunch of smaller advantages this way
as well - the TTL on my-node (nor any of the other hundred similar ones)
doesn't need to be made any smaller than usual - since I keep my addresses
stable I can easily have that set to a week or so.   The only TTL that might
need to be reduced (depending upon how long the transition period is to be)
is that of my-org-name in the provider's zone.  When that's low, and times
out in someone else's cache, all they need to is a query for that one RR (and
its sig) and all the addresses that relate to my domain can be re-calculated.

Not everyone is going to want to operate this way - some won't trust their
provider to manage the name properly (though they have no option but to trust
the provider to make their prefix route correctly, this extra bit isn't
so much extra) - and that's OK, no-one is going to force anyone to run their
zone like this - it just needs to be available as an option for those who
want it.   We need to keep A6 to retain it as a possibility - if not, as
soon as someone in IPng, or some security WG, or wherever else work is needed
to make all this possible, starts to make a proposal, some DNS person will
stans up and say "you're wasting your time, it can't work, as the DNS can't
support that".

kre

---

From: Greg Hudson <[email-masked]>
Date: 17 Mar 2002 10:00:53 -0500

> To make it easier for the resolver, we're going to make the administrators

A more complicated DNS makes administrators' lives harder, because they
have to understand more about DNS to do their work.

A6/NS loops, if they ever happen (and I can't imagine that they won't
happen at least occasionally) make DNS administrators' lives harder.

More complicated resolvers make system administrators' lives harder,
because they fail more often and behave unpredictably more often.  I can
give an example with the current DNS: BIND 8 regularly fails to resolve
a name the first time and succeeds the second time.  I understand why
because I've carefully followed this and other lists and understand
how BIND 8 deals with out-of-domain glue.  How many administrators
understand?  If DNS's NS indirection were a simpler process, then this
would never have become an issue.

The job of a caching resolver is already way too complicated; unlike a
mail server, a web server, or an IMAP server, I cannot hope to
understand the internal workings of a caching resolver in a reasonable
amount of time, because the job being done is too Byzantine for easy
human comprehension.  (And I speak as someone who has written and
released a stub resolver.)  If you want to make this situation worse,
you are not an administrator's friend.

Against this we have the claim that A6 makes renumbering easier. 
Contrary to what you say, I think this claim falls apart under
scrutiny.  If only used within a zone, the benefit becomes an
implementation issue.  If used across zones, A6 means a party can
renumber a zone without changing its zone file; I am skeptical that
there are cases where you don't have the means to change a zone file but
do have the means to renumber all the machines it provides DNS
information for.  Maybe in a world with the fantasy of automatic IPv6
renumbering, A6 would make sense as the last piece of the puzzle, but it
doesn't make sense in today's world.

Moreover, when I think about being able to renumber a large,
heterogeneous organization like MIT, I think about being able to have
both prefixes for some period of time (ideally on the order of months)
and being able to renumber machines incrementally.  A6 doesn't make this
process any harder, but it doesn't make it any easier either; it only
helps me if I want to renumber in one fell swoop.

---

From: Robert Elz <[email-masked]>
Date: Sun, 17 Mar 2002 22:59:49 +0700

Date:        Sat, 16 Mar 2002 15:00:36 -0500 (EST)
    From:        Dean Anderson <[email-masked]>
    Message-ID:  <[email-masked]>

  | However, making the
  | resolver more complex severely affects the ability of small devices to use
  | IPV6 due to severe resource limitations on small devices.

Since we have lots of deployed clients now using AAAA lookups, there's
no way we can ever undo that - so for A6 to be used at all, it is going
to have to be via the back end cache doing A6 lookups, and sending back
the answers as if they were an AAAA record.  (Resolvers can generate A6
queries if they prefer of course, but now can never be required to).

So, that argument is irrelevant - small devices will be able to use AAAA
queries whether we put A6 or AAAA in the servers.

  | Protocols are written for devices and users of those devices, not for
  | administators.

The biggest direct user of DNS data are the administrators.  Everyone else
uses it only indirectly.

kre

---

From: Robert Elz <[email-masked]>
Date: Sun, 17 Mar 2002 23:17:26 +0700

Date:        17 Mar 2002 10:00:53 -0500
    From:        Greg Hudson <[email-masked]>
    Message-ID:  <[email-masked]>

  | Maybe in a world with the fantasy of automatic IPv6
  | renumbering, A6 would make sense as the last piece of the puzzle, but it
  | doesn't make sense in today's world.

I think this is the crucial point of this whole debate.   Those opposed
to A6 see it as unnecessary, and useless for anything we do today (and
more complicated, ...).  And they're most likely correct.

Those who support A6 want it there now, because if it isn't deployed now,
it can never be deployed.  It will simply be too late.

So, if we decide to discard A6 now, that "world with the fantasy of
automatic IPv6 renumbering" will never be more than a fantasy - and 50
years from now, you'd be able to look back and say "see, we were right."
But that very well may be only because of this decision.

If we want to retain even the possibility that one day we might get to
a state of fully automated renumbering, with nothing at all done at the
site being renumbered, then we must make sure we don't build any walls
now that will need to be worked around (or simply block progress) in the
future.   Discarding A6 is building that kind of wall.

  | Moreover, when I think about being able to renumber a large,
  | heterogeneous organization like MIT,

I don't care much about MIT and similar organisations.   There are only
perhaps a few thousand of those (maybe just a few hundred) globally, and
the rate of their increase isn't very fast.   The organisations that
matter are all the small businesses, with no staff that are even computer
literate, let alone DNS experts.

  | I think about being able to have
  | both prefixes for some period of time (ideally on the order of months)

MIT might get months, most other organisations may perhaps get a week.
But that's OK, a week is plenty of time, or should be, if we have done
our jobs properly.

  | and being able to renumber machines incrementally.  A6 doesn't make this
  | process any harder, but it doesn't make it any easier either; it only
  | helps me if I want to renumber in one fell swoop.

You're thinking in the IPv4 world.   It makes no sense to incrementally
renumber nets in IPv6, the only sane way is "one fell swoop" - at the
very least for each subnet, but it may as well be for everything.

Routers are advertising the prefixes for the nodes - all the nodes see the
new prefix at the same instant (give or take the odd RA interval, if some
node happens to miss one for some reason).

All IPv6 nodes deal with multiple prefixes without drame, they all know about
decrepated addresses, and what those mean, and how to deal with them.

Doing the basic renumbering (for a prefix swap, as opposed to an internal
network redesign) is dead trivial with IPv6.   It is only all the surrounding
baggage that complicates the issue.  That's what we need to keep working
away at eliminating.   Regardless of whether or not renumering ever becomes
"frequent" by any random person's definition of the term, there's no
justification at all for not making it easy.

Again, what we should be doing is explaining how to use A6 safely.  If,
in the near term, that means that servers should only be configured with A6 0,
that's OK.   A6 0 is isomorphic with AAAA (just a one byte longer RR),
so any argument that applies to AAAA is equally true of A6 0 - except that
the flexibility isn't lost with the latter.   If you want, we could even
ask servers to accept AAAA, and treat that as A6 0, so all those (tens...) of
admins who have become accustomed to building zone files with AAAA records
can just keep on doing that.   What's needed is that the back end resolvers
start using A6 queries to satisfy AAAA requests, and that servers process
A6 queries and return the answers.   As long as we get that much working
soon, and retain it, then we have a path forward.   Otherwise stagnation.

kre

---

From: Jim Reid <[email-masked]>
Date: Sun, 17 Mar 2002 08:56:55 -0800

>>>>> "kre" == Robert Elz <[email-masked]> writes:

    kre> You're thinking in the IPv4 world.  It makes no sense to
    kre> incrementally renumber nets in IPv6, the only sane way is
    kre> "one fell swoop" - at the very least for each subnet, but it
    kre> may as well be for everything.

This may well be the sane way to renumber. However the real world
isn't necessarily like that. In many large corporate nets, IP address
allocation is a mess. For example a /20 (say) gets allocated to some
location and then there are sub-allocations within that subnet to
departments or product divisions at that site. Renumbering in "one
fell swoop" can be impossible because each of those organisational
units decides -- usually for its own business reasons -- when its
resources can be renumbered. And that's before we enter the quagmires
caused departments (de)merging or when they're acquired or divested
from the company. Having A6 deployed would help with those sorts of
practical renumbering problems.

---

From: Robert Elz <[email-masked]>
Date: Mon, 18 Mar 2002 00:48:52 +0700

Date:        Sun, 17 Mar 2002 08:56:55 -0800
    From:        Jim Reid <[email-masked]>
    Message-ID:  <[email-masked]>

While you seem to be agreeing with me that A6 is good to keep, you
also are stuck in the mentality of an IPv4 user.

  | Renumbering in "one
  | fell swoop" can be impossible because each of those organisational
  | units decides -- usually for its own business reasons -- when its
  | resources can be renumbered.

This makes no sense for IPv6 - both addresses (old and new) can be
deployed together, both can work together, there's no reason to defer
starting to use the new one - the old one keeps on working during the
transition period.   And if this large corporate net (which again is not
where I see the biggest A6 benefit - it will help there, but it will
be a real winner in the much smaller enterprise nets) needs to arrange an
extended overlap because for some reason some segment of its organisation
can't give up the old addresses for some time - then it needs to do that.
In that case, the old addresses may just as well continue to be valid for
the rest of the organisation for the same period.

I know it is hard to see that IPv6 is not just like IPv4 with more bits,
especially when it is sometimes advertised that way (which avoids scaring
off those afraid of any change, I suppose).   But in this area, IPv6 is
just nothing like IPv4 at all - node configuration was one aspect of IPv4
that everyone agreed was horrid, and IPv6 has added all kinds of stuff to
make most of that horror vanish.

A6 can (in the future, we're not there yet) be a part of making another
horror vanish.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Mar 2002 23:31:34 -0000

It is essential for security that every record be signed frequently, at
least once every day or two. The reason for this is explained in detail
in http://cr.yp.to/djbdns/killa6.html.

Robert Elz writes:
> key left on line, then with AAAA there's simply no way.

False. The automatic update takes effect the next morning, when the key
is brought online again.

All of this has been amply discussed on the mailing list before. The
fact that you're bringing up the same bogus argument, having forgotten
the fundamental flaw in the argument, reflects a fundamental deficiency
in the IETF procedures.

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 19 Mar 2002 04:35:53 +0100 (CET)

> Thus moving DNAME off the standards track is a larger question than

I'm sorry, I don't understand the reasoning.

Either DNAME is too complex to be used (more risks than expected benefits)
so that we should not use it in "normal" DNS, or it is OK to use it. We
just have one DNS tree, and things behave the same in ip6.arpa as in the
other subtrees.

What is so special about ip6.arpa that we should not use DNAME there, but
anywhere else?

Mats

----------------------------------------------------------------------
Mats Dufberg				             Registry TeliaNet
[email-masked]                                  Skanova/AO Networks
+46 8 456 7274                                               Box 10707
+46 70 258 2588                                    SE-121 29 Stockholm
----------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Tue, 19 Mar 2002 19:09:33 +0700

Date:        17 Mar 2002 23:31:34 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | It is essential for security that ...

since what different people require from security differs, there is
almost nothing that is essential for everyone.

  | False. The automatic update takes effect the next morning, when the key
  | is brought online again.

No, the key is never on line.

And in any case this is just one example.

What's important here is that there is no demonstrated actual flaw with
A6, beyond that it is possible to configure it so as to create problems.
As it is with almost anything.  (Believe there's no way to misconfigure
BGP to create problems?  Or even as trivial as SMTP ?)  That is, it isn't
a flaw, it is a side effect of the flexibility.

kre

---

From: Derek Atkins <[email-masked]>
Date: 19 Mar 2002 10:27:51 -0500

> No, the key is never on line.

I believe that by "online" Mr. Bernstein meant that the key was
available to sign the zone.  Whether that means the zone was copied to
a dedicated non-networked server that contains the key, or perhaps the
smart-card was inserted into a reader, or whatever, is unimportant.
The point was that the zone gets resigned frequently.

Even better, if your zone is being pushed out from a database, you are
in great shape!  The database push can include the signing operation.
Or if you prefer the data can be signed as it enters the database.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Robert Elz <[email-masked]>
Date: Wed, 20 Mar 2002 15:56:21 +0700

Date:        19 Mar 2002 10:27:51 -0500
    From:        Derek Atkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | The point was that the zone gets resigned frequently.

No it doesn't.   That's just a theory of operation which is not
required at all (and is required even less for zones that contain
only the tail end of A6 records).   Signing the zone once a month,
and perhaps less frequently, is likely to be just fine for many sites.

Please stop telling me ways that it is possible to operate that happen
to fit with your theory of how the world should work.  Allow sites to
operate in ways that meet their own needs - even if that's something that
you would never personally do.  And don't cut off options just because
they're not useful to your way of operating - only if you can show that
they actually don't work.

Once again, no-one has done that for A6 (it would be kind of difficult,
as it is trivially easy to show that it does work in simple cases).

kre

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Mar 2002 08:38:07 -0800

> as it is trivially easy to show that it does work in simple cases).

indeed. A6 and DNAME work.  BIND9 implements the whole shebang, and it's
been tested in some labs hereabouts.

however, bitstring labels slow BIND9 down by quite a lot -- there were
fundamental architecture choices that had to be made "expensively" due
to properties of bitstring.  it would probably be worth 25% to 50% on
benchmark results to take them out.

we're doing "make" all over again.  ("the next morning i realized that
i'd restricted leading whitespace to have to be tab characters, but by
that time i couldn't change it to allow spaces as well, because five
other sites had downloaded it and i didn't want to break compatibility.")

recalling the embedded devices that do AAAA lookups seems to not be
possible.  even though we've got some flag days coming up for the
authority servers who want to run IPv6 (EDNS and DNSSEC come to mind),
the existing installed base of AAAA queriers, while of size ~0, is of
size >0.

---

From: Derek Atkins <[email-masked]>
Date: 20 Mar 2002 12:10:24 -0500

Frequency of signature is directly related to frequency of changes.
If you sign a zone once a month (say on the 1st), but then add (or
remove) records on, say, day 2 of the month, then there is an attack
where your added (or removed) records can be replayed without
detection.

-derek

---

From: Robert Elz <[email-masked]>
Date: Thu, 21 Mar 2002 18:08:15 +0700

Date:        20 Mar 2002 12:10:24 -0500
    From:        Derek Atkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | Frequency of signature is directly related to frequency of changes.

Yes, of course.

But some zones never change.   Literally never change.   The signatures
(and the TTLs) still shouldn't last forever, but expecting things that
never change to be resigned every day or week, just because some other
zone which might be subject to sudden changes needs that, is absurd.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Mar 2002 11:47:39 -0000

Robert Elz writes:
> Signing the zone once a month, and perhaps less frequently,
> is likely to be just fine for many sites.

No! If you're signing only once a month (plus unscheduled changes), then
you're using expiration dates at least a month away, so an attacker can
block a change until the end of the month. This is a security violation
at every site I've seen; changes have to take effect much more quickly
than that.

---

From: Robert Elz <[email-masked]>
Date: Thu, 21 Mar 2002 22:56:04 +0700

Date:        20 Mar 2002 11:47:39 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | No! If you're signing only once a month (plus unscheduled changes), then
  | you're using expiration dates at least a month away, so an attacker can
  | block a change until the end of the month.

Yes.

  | This is a security violation
  | at every site I've seen; changes have to take effect much more quickly
  | than that.

Sometimes they do, sometimes they don't.   In any case, this is for the
site concerned to decide.  They need to be informed, and make their own
decisions.

kre

---

From: Bruce Campbell <[email-masked]>
Date: Fri, 22 Mar 2002 04:00:18 +0100 (CET)

> at every site I've seen; changes have to take effect much more quickly

That is correct, however a lot of sites will operate with long intervals
between key signing until an attacker (or other failure) causes them to
rethink their site-specific policies.  We can recommend 'reasonable'
intervals that allow sites to recover quickly from their mishaps, but we
will find that some people will enjoy having a long length of rope.

Next topic please?

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B                      Operations