Defining a prefix for those only made it *possible* for apps to
recognize which ones might be restricted.
But it doesn't help apps know *how* those addresses are restricted.
No, but a limited hint is useful in many situations. Should we have
better tools? By all means. That does not mean we get rid of something
that has some utility before we show that it has none because there
are alternatives.
it's not as if all of the utility for scoped addresses is positive. it
does make sense to get rid of things with significant negative utility,
particularly when the supposed positive utility is not compelling.
site-local is not useful as a limited hint that the addresses are
restricted, because the scope of such restrictions is still invisible to
apps, and because there is no policy for use of site-local by apps which
will work reliably across different network setups. and any measures
that apps might undertake to work in the presence of site-locals will
work even better (more efficiently and more reliably) if globals are
used.
I do not buy the assertion that 'apps need to pass addresses around'.
you're simply mistaken about that. until we have reliable, universal,
distinguished names for (possibly virtual) hosts that can be used as
endpoints in TCP and UDP, etc., and as long as there is ever a need
to unambiguously refer to a network location, we're going to need to
pass addresses around.
It is possible for apps to choose passing around names and let the
topology get sorted out by the name resolution infrastructure.
not in any naming system that we have today, or are likely to have
deployed within ten years.
As I said to JCK, you can't have it both ways. You can either choose
to keep it all below the app layer by passing around names, or if the
app chooses to reach down and get topology information it has bought
into the responsibility to understand what it is doing.
not if the app treats the addresses as opaque tokens.
You insist on the right to reach down and get lower layer information,
but refuse to accept the responsibility that goes along with having
it.???
overloading of IP addresses to be multiple things (among them endpoint
identifiers, interface identifiers, network locations, host
identifiers, even authentication principals) is deeply embedded in the
IP architecture. you may think it's a poor compromise, and lots of
people would agree with you. but nobody has demonstrated a
complete solution that appears to be a better way for things to work.
and given this deliberate overloading, it's disingenous for you to claim
that addresses are inherently lower layer information (more correctly,
they're shared between layers), and that apps that use addresses as
opaque tokens somehow have some new responsibility for dealing with
ambiguity that you've decided to burden them with.
defining a prefix didn't change the architecture - asserting
that the same prefix could be reused in multiple locations
did change the architecture.
This is more an argument to define ways to disambiguate the current
space than it is to remove a well-known prefix for use in local
scopes.
I don't believe there is a good way to disambigate the current SL space;
there simply aren't enough bits available. Nor do I believe (for
reasons cited elsewhere) that it is desirable to burden hosts and apps
with having to deal with more addresses than are necessary to name the
network locations to which they are attached, nor to embed information
about reachability within addresses, nor to expect hosts and/or apps to
select the "right" set of addresses to get from point A to point B.
so there are indeed other problems with site local even if you make them
globally unique; it's just that lack of uniqueness is the worst problem.
Operational decisions established the architecture, and
it is our job to define the technologies that work within that
architectural reality.
indeed. this is precisely why we are deprecating site locals
- because they do not work within the architectural reality.
No, the apps that insist on reaching down and getting lower layer
information that they don't understand is what doesn't work.
wrong. if they tried to treat those identifiers as anything other than
opaque tokens, I might agree with you. but very few apps do that, and
I'm not worried about those that do. indeed, it's the expectation that
apps need to start treating addresses as other than opaque tokens, for
instance by having to use different addresses in different situations
in order to reach the same point on the network, that I'm arguing
against.
Keith