Which actually poses an interesting question: when should an application
just give up? IMHO, there is only one clear-cut case, i.e. when the
application actually contacted the peer and obtained an explicit
statement that the planned exchange should not take place -- the
equivalent of a 4XX or 5XX error in SMTP or HTTP.
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. 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.
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.
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.
Margaret