Eliot Lear wrote: > ... > No, I think that given today's technology I > believe we need > stable addresses so that lack of connectivity does not cause internal > transport connections to fail.
?!? > Yes, I wonder whether this could be > sufficiently handled by minimum length leases that are retained for > orders of months. This is a business model issue and out of scope. > > > > > Failing such, we seem to have limited > > range addressing > > and "graceful" renumbering as alternative options. Perhaps > there are > > others also? > > Yes: a default address, which is different from a limited > range address. The default address goes away when overriden. Reconcile this with your first point. Maybe you don't care if a file mount drops every time the SP provided prefix changes, but there are many business critical applications where disruption is simply unacceptable. Just because dropping connections is acceptable in one environment does not invalidate the requirement for stable addresses in another environment. > ... > I think I've contributed some words to Fred's draft, at this > point. But > this is where I would put my ernest efforts. Getting from > one prefix to > another is indeed painful at this point and probably requires some > protocol development here and there. For instance, consider the NS > record that is stored in the GTLD servers. How does that get updated > automatically? > > Then there is the order of operations in terms of both internal and > external DNS servers. We need to see that authentication is widely > implemented for DDNS (SIG(0) and such). DNS is the least of the concerns, because it is a 'centralized' database that the network manager knows will need to be dealt with. The real problems are all the places that addresses get stored by the end users, therefore out of sight. You can say this is wrong and bad procedure, but it happens regularly, and often for business critical reasons. Prefix overlap is the best we are going to do in terms of renumbering, and that is still unacceptable instability for internal-only applications. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
