Let's continue the renumbering debate only in ipng@; please strip ngtrans
from Cc: if replying.
On Thu, 2 Aug 2001, Robert Elz wrote:
[snip]
> What we're supposed to be doing (what we set out to do way back when
> ipng first started) is to remove as many impediments to easy renumbering
> as possible. That is, every time we find something that looks like it
> will cause problems, we look for a solution that will allow those
> problems to be avoided.
>
> We don't simply say "there's this other problem that isn't solved yet,
> so there's no point doing anything about this one" - that's defeatism.
>
> We can do better than that - but we have to keep working on each problem,
> each little obstacle to renumbering, as we find it.
I have a pragmatic (as probably most others) approach toward renumbering.
Getting it working is completely is probably at least as difficult problem
as working public key infrastructure problem (not that these have to be
necessarily related, but the biggest problems aren't necessarily technical
in nature).
I'm not going into automatic router renumbering itself. But "site
renumbering", a manual operation, can be made to "kinda work", I think.
The most important issue is getting all hosts (or 99.5%) autoconfigured.
If this can't be assumed, we've already lost the battle against
scalability. 1, 10, even 30 routers or very important servers can be
manually reconfigured in an acceptable amount of time, but if all servers,
much less end-nodes, were to be reconfigured manually too.. not nice.
Therefore, in practise, we should remove impediments to using
autoconfiguration and having to manually specify network settings even if
you do (e.g. DNS) if those come up.
If this is agreed upon, the issues here are:
1) accept the fact that if there is no DNS service (e.g your network
cable breaks and you reboot, the computer may get stuck at boot more or
less indefinitely), you're on your own.
(this could be worked around by vendors' some automated mechanism of
copying the "last-known" addresses needed at boot to hosts.txt or
something)
2) implement auto-discovery of dns servers e.g. with anycast (work
already in full swing)
3) implement a mechanism to assign other than EUI64 suffixes
automatically. IMO, this is required for servers -- having EUI64
identifier in DNS for a server is IMO unacceptable. I want my servers to
be like PRFX::1, PRFX:1::10 etc. -- short, stable and easily remembered.
(not that there is need for anything from IETF here -- this is just an
approach vendors could use, as the autoconfigured prefix is already
known).
Any others?
Practically, now renumbering sites would be _much easier_ already (ie.
doable) if these were to be achieved.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
