Erik Nordmark wrote: > ... > I think #4 (which I didn't talk about at the mike) is a red > herring. Perhaps the issue is a restatement of #1 (due to the > ISP implicitly forcing a > renumbering each time the site connects) in which case the > points about #1 applies. And note that making site-locals > help with #4 (and #1) involves having nodes be configured > with both globals and site-locals i.e. it brings in most (but > not all) of the complexities of the full-fledged site-local support.
It is not a red herring. Input sent to me for the requirements doc: Research ships at sea intermittently connect via INMARSAT, or when in port, the shipboard network is connected to shore via Ethernet. Of utmost importance is that the systems on board the ship all function, providing data collection and analysis without interruption. Static addressing is used on most intra-ship network components and servers. It's quite expensive to operate a research ship, so eliminating points of failure is important. Scientists on board collaborate with colleagues back home by sharing of data and email. Private address space is employed for several reasons: 1) it provides the ability to allocate significant address space to each ship without needing to worry about how many computers will be on a given cruise. 2) it provides separate address space for each ship. 3) it simplifies filtering to ensure shipboard traffic is not permitted to transmit out or bring up expensive satellite links. Granted the larger address space argument goes away, but this is an example of a network that attaches intermittently, and via different providers. Yet the requirement is that the internal communications not be interrupted, ever. Telling a network like this that they have to invalidate any current prefix and renumber everything into the current provider space is a non-starter. Giving them the option to add the current provider's prefix to those nodes needing external connectivity is the appropriate approach. > > > Note that the community seems to have an unrelated desire to > get "PI space" for free - and in some cases site-locals seem > to be confused with some form of PI space or stepping stone > to PI space. The confusion derives from the fact that some want PI space for connected networks, while others want PI space for disconnected ones. The requirements for those are somewhat different. Space for disconnected networks must be freely available, or people will pick random numbers because those don't require approval or payment. A registry costs money to run, so there is no reasonable way to get registered values for free, and the IETF can't pick up the tab. > There is some work (in and around multi6, > ipv6mh, and hip) that is looking at two space systems > (identifier and locator separation) that can hopefully > provide something of similar look and feel as PI addresses. This approach does not solve the problem that the connected PI community wants solved. They are looking for isolation from the costs of renumbering. What we are finding is that the multi-prefix per host model mitigates the host part of that cost, but the configuration of the infrastructure also has a high manual labor cost. The two space system makes it much more difficult for the infrastructure to figure out what is going on in order to apply the appropriate policies to the intended identifier. On top of that, the costs for manually reconfiguring the infrastructure don't go away. > Yes, this is no small task. But I sure hope we can spend > energy on that longer term and harder problem than continuing > to delude ourselves that site-local addresses have benefits > with justify their added complexity. The problem at the moment is that those who are looking at the application development complexity are refusing to acknowledge the operational complexity caused by the lack of alternatives. Yes there are promises that someday we might solve a few of the problems, but until every requirement is met it is irresponsible of the WG to remove an architectural component that people are using in the current IPv4 network. Tony > > So let's not ask what deprecating site-locals solve - let's > ask what problems site-locals solve. They were added to the > addressing architecture at a time when there was little if no > wide-spread understanding of the larger > implications. I hope we have learned some from the > discussions over the last few years (on ipng and zeroconf as > well to some extent) so that > we can try to do this cost/benefit analysis. > > Respectfully, > Erik > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
