Keith Moore wrote:
Tony, this discussion is about ambiguous addresses. Your
persistent attempt to conflate it with packet filtering
and/or routing policy isn't shedding any light on the
argument. And you're smart enough to know the difference.
Yes, but you keep changing the argument. On 4/18 it was:
introduction of scoped addresses causes far more problems than it
solves.
Today it is ambiguity. I was trying to separate the discussion by
focusing explicitly on the scoped address issue.
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 does not *make* apps deal
with the problem of leaking addresses outside their scope
of relevance
(unless you take the viewpoint that end users actually expect
applications to work right, and will require it once it is
possible).
Experience indicates that this is exactly what happens. You
cannot expect apps to not leak addresses outside of their
scope because apps do need to pass addresses around and they
have no way of being aware of their scope boundaries. The
way to solve this problem is to make addresses unique.
I do not buy the assertion that 'apps 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. 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.
Applications are not required to understand topology,
unless and until
they insist on passing around topology specific information.
Another attempt at disinformation on your part. The fact
that the current internet architecture doesn't provide us
with reliable endpoint identifiers that are independent of
topology information is not a justification for asserting
that applications should not pass around the best endpoint
identifiers that are available to them. And very few
applications use these as anything other than 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.
??? If the app chose to use a name as the endpoint identifier, it would
have the conflict.
There is no magic here, and defining a prefix didn't change the
architecture.
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.
Get your arguments straight, and you will realize all this deprecate SL
nonsense is a waste of time. We need to solve the fact that apps refuse
to acknowledge they are ignoring topological reality, and the ambiguity
argument become simply a matter of subnet routing collisions during
mergers.
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. Deprecating
SL makes absolutely no difference to this, because the same issues will
crop up for globally unique local scope addresses. Before you say it,
the 'connect to the wrong node' argument is an IPv4 artifact. With IPv6
auto-conf, or even manual conf using a discarded MAC, the probability of
a SL address actually pointing to two nodes is close to zero, and even
lower than that for those both being reachable from participants in the
same multi-party app.
Go back through all your arguments about the evil's of SL, and see how
many go away if the prefix is disambiguated. Then look at the fact that
A can't tell C the difference between Bl & Bg unless there is some
indicator.
Tony