I am about to embarrass myself by asking two stupid and naive
questions. But it feels like time for one of us who is not
strongly involved emotionally with one side or the other of this
issue to do so. It seems to me that "site local" is actually
two different things:
(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?
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".
Given that, and given the argument that some important and
hard-to-reverse decisions have been made that use that address
range, is it plausible to:
(1) Remove, deprecate, or otherwise dispose of, the
feature.
(2) Permanently retire the address range so it is never
allocated and identify it in the relevant records as
"retired".
Now, we have pretty strong statements around to the effect that,
if an address range isn't allocated, one is not supposed to use
it and certainly isn't supposed to let it leak. One could even
reinforce that with a statement/ standard/ BCP encouraging
filtering the range, which would bring us more or less back to
the 1918 situation (reserved space, no semantics). 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?
john