Keith Moore wrote: > there is no justification for the idea that internal-use > applications have a greater need for stability than other > applications.
Not in an academic environment, but when people's jobs are on the line they tend to set the bar *much* higher. One example of an app that requires stability is maintaining the multi-$M cash flow through the database backend to a company's ecommerce app. The bar becomes 'did you do everything you could with current technology to keep it running?' When the answer is 'no, I could have put in a NAT to isolate those systems from any external prefix change', what do you think will happen? It doesn't matter that the IETF said 'nat is bad & crashing applications during a renumber is not a problem', they will do what they have to before they allow a failure. > > actually, it's not clear that there is a significant class of > inherently "internal-use applications". for most things that > people put into that category (e.g. printing, file access), > there are significant and valid use cases for running them > across network boundaries. Running them across network boundaries does not invalidate the need for them to be stable when run internally. It would be nice if people would stop trying to invalidate someone else's requirements just because their own are different. Limited range prefixes do not solve all known problems. They simply solve a subset of the existing problem space. Yes a single aggregatable PI address would solve many of the same requirements, but not all. There will still be a need for prefixes which are explicitly not routed, even accidentally as part of some larger aggregate. fwiw: I have offered documents about a PI space on a couple of occasions, but the chairs have not taken that up. I suspect part of that is due to the multi-homing discussion being handed to multi6. As recent threads show, this topic can't be isolated in an off-the-radar wg because it is the core of the disagreement here. By definition all IPv6 interfaces are multi-homed, and those that can reach off link have to deal with multiple scopes. Wishing that there was a single flat globally routed address space is not going to make it happen. 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] --------------------------------------------------------------------
