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
