John, > John C Klensin wrote: > (1) A set of semantics and expectations about, > e.g., applications behavior, otherwise known > as "the feature". > (2) An address range. > Is that correct, or is that controversial too? It looks correct to me although I will detail the feature part below. > Now part of the justification for IPv6 is to > have "enough" address space. We may be moving > toward that being the only justification, but > that is another discussion. "Enough" presumably > includes sufficient headroom that we can make a > mistake about allocation strategies and deal > with it by simply retiring the block. One would > not want to do that often, especially with large > blocks, but we ought to be able to survive more > than "never". Correct. There are 1,024 possible /10s, for example. Screwing up with three or four is not such a big deal. I'm not saying it's good, but if the resolution of the issue is that we have to iterate three times on a solution and end up wasting three times a /10, be it. > But an enterprise that thought it needed local > space could presumably use that range, with > appropriate filters, etc., but without assuming > that, e.g., applications would treat it in a > special way. > I don't expect this suggestion to make anyone > on either side happy, but is it possibly a way > out of the "you can't really deprecate that > without causing worse damage" part of this mess? The feedback I am getting from enterprise operators is that they generally don't care about any special application behavior. At the application level, for all practical purposes there is no need to differentiate site-locals from other addresses. The arguments I have heard from app developers indicate that there are trying to fix issues that are none of their concern. If I design a network that makes apps break, it's my problem, not theirs. Specifically, enterprise operators generally: - Are inclined not to use the multi-address capability of IPv6. Inside the enterprise network, it brings complications that are not worth the advantages, _especially_ for parts of the network that are earmarked as private. - Do not flood root servers with reverse lookup queries for private addresses (I want my traceroutes to work on the inside of the network too, so I long ago configured reverse lookup for private addresses on my internal DNS servers). - Deal with ambiguity when there is a collision like when sites merge. Besides, IPv6 ambiguity for private addresses could be resolved. What enterprise operators care about is router behavior, so something along the lines of scoping will have to be delivered at some point. This point does not need to be right away as it could be accommodated with manual filters that will remain in place anyway for defense in depth considerations. Michel.