> So, getting rid of site locals doesn't remove much of the motivation, and > there are no ready solutions to fulfill some real needs; which worries me. > Is it possible that by killing site locals, we set the stage for people to > do something worse? Will people still use FE0C, even if it is deprecated? > Will people pick random prefixes for use as site local / private addresses? > What is the amount of work to depreciate site locals - how many RFCs need > to be updated? I'm not convinced that deprecating site locals really solves > anything.
[Sorry for the long email, but I don't intent to post on this subject very often, if ever again.] John, I think there is a large difference between what is sactioned/blessed/approved in a standards track RFC, and what folks might actually choose to do on their own in at least two spaces: If we have site-locals in an RFC (with some limiting restrictions) I can envision folks down the road wanting to improve on site-locals by wanting to write a standards track RFC on how to extend them to be more useful i.e. by pushing more towards their full glory (which the community clearly does not want at this point in time). I ask myself what tools the IETF as a community will have to push back on such a proposal should it arrive. It is clearly much easier to push back if the IETF can ask "what problem are you solving" as part of specifying the site-local addresses RFC, but if site-locals are already specified in an RFC we will not have that tool to help the community come to a shared understanding of the goals. If we have site-locals in an RFC (with limitations) there is likely to be an larger pressure on vendors to improve their implementations wrt site-locals. I can envision well-intentioned customers that would want multi-sited hosts or routers, and vendors feeling forced to implement them. This is much less likely if "site-locals" is just an undocumented "pick any prefix if disconnected" approach than something sactioned. Of course, if we really want site-locals in their full glory we should standardize them. But as I said at the mike in SF I don't find any important problems that site-locals solve for which we don't have other solutions, which motivate the added complexity in the routing, DNS, application, etc spaces. The claimed motivations I've found over the years are: 1. Try to isolate communication within a site from site-renumbering. 2. Serve as a security token to simplify configuration of filtering in simple devices. 3. Provide address space to clouds which are disconnected. 4. Provide address space to clouds which are intermittently connected. (and perhaps I've missed some that are more than mere variants than the above.) I embarked on trying to make #1 work a few years back but, with the assumption that a significant number of nodes will use MIPv6, to make MIPv6 nodes be able to benefit from this while in their home site yet function when they move outside their home site, the complexity flew through the roof. And the philosophical point about "aren't we here to make global communication work?" made me personally drop that pursuit. For #2 we have bellovin/zill prefix option extensions which provide a strict superset of what one could do with site-locals in this area. (Folks might want to debate whether #2 is a good idea or not, but that debate is independent of whether site-locals or bellovin/zill advertisements are used for this. I'm only here to state that site-locals are not needed to solve this problem should we wish to solve it.) For #3 any (random) prefix suffices - there is no need to designate a prefix in the addressing architecture for this. Whether a particular domain uses fec0::/10 or dead::/16 doesn't matter AFAIK - in any case they need to renumber should they connect to the Internet *or* connect privately to some other previously isolated/disconnected site. 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. 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. 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. 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. 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] --------------------------------------------------------------------
