Eliot Lear wrote: > ... > >>>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.
So how does the system work when a new app comes up while the initial one is still running with the 'lingering' address? Does it take the new or the old one? If new, how does it contact a node that is currently in the prefix space of the lingering address, since the internal route will claim that is still on link? For that matter, how do bits get routed to the 'lingering' interface if the prefix has been moved in the routing system? What if the lingering one is one of the apps that insists on passing the now stale address to a 3rd party? I don't believe there are any realistic current technologies that make this work. Your argument ammounts to making the address stable for the duration of the app, but there is no way for the app to tell the routing system how long it will need it. The requirement is for applications to be stable, independent of what is happening at the SP interconnect. Given TCP behavior, this leads to a requirement for address stability. > > 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). Renumbering host interfaces is easier, but there is a lot more involved in a renumbering scenario. While it arguably viable to renumber external prefixes using the RA overlap technique, that is not sufficiently stable for internal-use applications. If there is no space set aside for this purpose, network managers will simply take a random number and use NAT. Business critical stability will trump 'the good of the Internet' every time. > ... > > 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. > You are arguing that the capability of doing something within the context of a single trust domain will translate into the interdomain space. While I agree that an authenticated DDNS is a critical component, we are nowhere near close to a scalable definition of that. Primarily due to lack of a decent ubiquitous key infrastructure. Tony > 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] --------------------------------------------------------------------
