Date: Wed, 13 Jun 2001 18:14:14 +0900
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| sorry if any of my past draft/presentations/postings/whatever sounded
| like that. i was trying to analyze the minimal possible frequency
| for renumber, so that we can understand what is the true requirement
| to IPv6 DNS records. i should make it clearer next time.
It isn't so much your writings as a general attitude that I seem to
be detecting sometimes - that in practice renumbering isn't going to
be needed as frequently as some feared in the early IPng discussions,
and that consequently, renumbering isn't so important, and stuff which
is there to support it really isn't needed after all.
Incidentally, while I doubt anyone has any difficulty understanding what
you mean, you really mean the minimum period (or duration) of renumbering,
or the maximum frequency, discovering the minimum frequency wouldn't be
an interesting thing to look for ...
| the fact i've learned is that, once we advertise a DNS record
| (with old /48 prefix we are trying to get rid of), we cannot remove
| them till TTL for these record expires (since the record may be
| cached somewhere in the world).
We can't remove the prefix until the TTL on any record that includes the
prefix has expired (TTL + zone refresh time to be even more accurate),
that's for sure. Though, of course we can, and people do that kind of
thing every day - it just breaks things for a while in mysterious ways
that just "fix themselves" eventually - but it is not good at all.
In general we're probably going to want to leave prefixes listed and
deprecated for even longer than required by DNS TTLs, so open connections
using the things can keep on working - but there's certainly a relationship
between the value of the TTL, and how quickly an address can (safely) go
away completely.
| to help signing zone file with mixture of "A6 0" and "A6 x" (x != 0)
| we at least need a better signing tool...
I have no doubt but that we need a whole bunch of all kinds of better
tools. This doesn't surprise me in the least. I would be the last to
claim that we're anywhere near being able to do quick renumbering today.
I just don't want to erect barriers that will prevent us from getting
there someday. Software can be written and distributed to those who
need it (you have plenty of experience with that...) But people's
operational habits are extremely hard to alter, as is getting someone
else to support something new because it will be easier for me (or you).
| and again, zone signing cost analysis has to take a lot of things
| into account,
Yes, but it isn't only signing costs that are relevant here (though they
are certainly one factor). There's also how effective the DNS caches
are to be allowed to be. That is, when you are planning to renumber
a common way is to reduce the TTLs on all the old records first, so that
when the change hits things won't be so affected by the "wait for old
records to expire" factor you referred to. So, what is usually a one day
TTL might become a 30 minute TTL for the records to be changed. (That
is going to require re-signing as well...) Then when the change happens
the old addresses don't need to be kept around as long.
But of course, now all the DNS caches all over are fetching data from
the servers much more frequently than they used to - that's what we wanted
of course when the TTL was decreased, but it is an extra load on the net,
and longer delays for name lookups. With just a few records with short
TTLs (the ones that contain the prefix, rather than all of those that refer
to the prefix) that problem ought to be able to be reduced, while still
reaping the benefits.
With IPv6's ability to have multiple addresses (with the effects of that
properly defined, etc) this probably isn't as big an issue as it could
have been - as it is OK if others keep using deprecated addresses to reach
us, so there should tend to be less "old address works until time N, after
that new address works" that usually happens with IPv4 renumberings.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
