Date: Wed, 13 Jun 2001 09:27:50 +0900
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| i don't understand what is the point in this sentence... yeah,
Sorry about that, it is a common complaint about my writing, I shall
try to do better.
| for the purpose of analysis of A6,
| are you suggesting which parameter is more important than which?
| could you clarify if possible? (or, if it is not the point please
| forget about this note)
What I was trying to say was that people often look at renumbering and
say "I am never going to want to renumber every day, if I do it once a
year it will be too frequent" which may well turn out to be true.
However, it isn't the frequency of renumbering that matters really here,
what counts is how rapidly I can renumber when I need to - how much work
do I have to do to complete the renumbering sequence, and how long is that
going to take me? If I can get the renumbering down to the state where
I can complete the whole thing in under a day, then I could renumber every
day if I had to, but this doesn't mean that is what I will ever do.
On the other hand, saying "no-one will need to renumber more frequently than
once a month, as we'll always be able to let people keep their old addresses
that long during a transition" doesn't mean that the renumbering event can be
allowed take a month to be completed (a transition is usually going to be two
renumbering events, neither of which should take anything like a half month
even).
In your reply to Bill Sommerfeld you pointed out two other issues ...
- if you have hardcoded address in any of your router/host configs,
you will be in trouble (example: IBGP peer settings, /etc/named.conf
for zone transfer, packet filtering, anything that is written by
numeric IPv6 address).
This is absolutely true, and a reason we must strive to avoid all such
numerically encoded configurations. Even if it just means writing the
relevant config files using names, and then pre-processing them with a
script that does DNS lookups and converts the names to numbers, and while
doing so, remembers the minimum TTL it encountered, and re-schedules itself
to be run after that many seconds - and then any time the resulting
numerically encoded files change, causing them to be reloaded into the
appropriate router/process. This is something of a crude and inefficient
way to avoid configuring static addresses anywhere, but it is better than
the alternatives.
- to avoid canopener-in-can situation for records pointed to by NS
records, nameservers basically has to have "A6 0" records.
so for these records we don't have benefit from fragmented A6 records.
Yes, the NS records are (at the very least in the medium term, and perhaps
forever) going to have to be associated with names where the benefits of
A6 are unlikely to be achieved. For some truly huge organisations there
may be 30 or 40 systems running as published nameservers (nameservers
running not listed in any NS records don't count of course). Each of those
may have half a dozen A6 0 records associated with them perhaps (just guessing
at averages). So, there could be 200-300 records in addition to a few
"prefix" A6 records to be updated when a prefix changes. This still seems
manageable to me, and still a big win over having to update tens of thousands
of AAAA records.
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]
--------------------------------------------------------------------
