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