Margaret Wasserman wrote: > Of course, in the case of site-local addresses, you don't > know for sure that you reached the _correct_ peer, unless you > know for sure that the node you want to reach is in your > site.
Since the address block is ambiguous, routing will assure that if you reach a node it is the correct one. This FUD needs to stop! > So, when working from a list of addresses that > includes a site-local, an explicit refusal from the node that > you reach at the site-local address (i.e. connection reset, > port unreachable, or an application-level refusal) might not > be a reason to stop working down the list. Your argument applies to global scope addresses, not ambiguous SL as currently defined. > > This is one case where the ambiguity of site-local addresses > causes problems that would not be caused by using addresses > that are globally unique, but unreachable. It does not, routing explicitly breaks in the presence of ambiguous addresses. That is the feature of ambiguity that many network managers want. What others want and we haven't provided is a stable address block that is unambiguous and unrelated to any providers they may be attached to. > > I understand that a collision of site-local addresses will be > rare in autoconfigured networks. But, in non-autoconfigured > networks, I'd still expect some proliferation of subnet == 1, > IID == 1. This is not a problem, it is seen by many as a feature since it prevents unintended exchange of routing information. Tony
