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