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