Tony Hain wrote:
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.
BCPs cover business model, but before we argue whether it's a business model problem -- because if that's all it is the market can decide, then let's at least understand just how far we can get with it technically. See below.
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 we have different notions of "change" here. I don't see a need or a reason for an IP address to vanish like a routing update. Instead, it should linger for some "reasonable" period of time first until some other prefix is preferred (and that might yet again be the default) and then be removed some time after that.
In answer to your first sentence, however, I do believe work needs to be done in this space. It's not easy to renumber -- yet (although it's a lot easier than it was 10 years ago).
...
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.
First, I'd like to point out that even here there has been major improvement. I sit here and type on a desktop that changes IP addresses routinely, and I am able to send and retrieve mail, as well as participate in interactive multimedia conversations. Having said all that, I would agree that there remains a lot of work to be done. I think a key component, though, is seeing that renumbering occurs smoothly with DNS and that DNS properly identifies those objects that need identifying.
Perhaps it's time to revisit the work done by the old PIER working group so that we can get some understanding of where these addresses still get burried. This brings us back to Fred Baker's draft.
As to instability, I have to say that you can't know till we've tried and right now I don't really think we've done a good job of trying. In today's world, given today's tools, I would agree with you that there is a lot of instability and using the IP address as a stable identifier is your only option. So this is what network admins use -- not because they want to, but because they HAVE to. If they WANTED to use this sort of identifier, DHCP and PPP would not be so popular.
So, I'd suggest that we continue to flesh out the renumbering procedures draft, looking for those hidden addresses. I'd also suggest that until we've done that, we're going to go around in circles.
Eliot
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
