Tony writes: The space
identified in RFC 1918 was set aside because people were taking whatever
addresses they could find in documentation.
There is a long and "interesting" history here, but it isn't directly relevant
to this discussion. I think it would be valuable to focus the discussion on Site Local,
rather than on RFC 1918 space.
SL was set aside because there are people that either want unrouted space, or don't want to continuously pay a registry to use a disconnected network. It is far cheaper to train an app developer (though there may be an exception or two) to deal with it than it is to fix all the ad-hoc solutions that people will come up with to replace SL.
I think you may underestimate how much trouble this might cause in applications.
As Dave Crocker noted in response to Margaret Wasserman's presentation
to the APPs Open Area meeting, applications have been designed so that they
do not know and don't need to know anything about network topology. If you
require applications to understand the consequences of different unicast address
scopes, you are changing a pretty fundamental assumption. While it is theoretically
possible to change that assumption, it is a major piece of work, and I believe that
the "sense of the room" was that the advantages of Site Local were not worth that
amount of work. As you note, this is subject to discussion and confirmation on
the mailing list and, ultimately, to the consensus of the IETF as a whole.
Margaret's presentation, for those not at the APPs open area, was derived from her
draft, found at http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact- 02.txt.
See especially section 3.7.
regards, Ted Hardie