We have the problem of scoped addresses whether the "site local" mechanism
is retained or not. Providing guidance on the responses an application is
to receive in response to scoping controls (firewalls) would be useful
regardless. If this problem is worth solving for the already-common case
of firewalls, solving it for site-local addressing does not seem to be too
much of a stretch.
Exactly, the only thing an address with a site-local prefix tell me is that
a filtering router or firewall is guaranteed to be in some arbitrary
path.
but you don't know which paths, so you don't know how to use that.
I'm mystified as to why an app would treat it any differently that
an IPv6 address generated with any other prefix.
some people believe that SLs would be more secure than globals, even though
this is an unwarranted assumption. some people believe they would be more
stable than globals, but providing stable local addresses isn't a good
solution to the renumbering problem - it's not as if all of the important
apps affected by renumbering are local. some people believe SLs would be more
efficient. some apps writers would avoid using SLs whenever possible because
they're not portable (and they'll lose when SLs are all that are available),
some apps writers will use them in preference to globals (and they'll lose
when they're expected to communicate across site boundaries), and other apps
writers will try to deal with all cases (adding a lot of complexity and still
not able to avoid the app failing for apparently arbitrary reasons). any of
these makes the behavior of apps less predictable.
Keith