First, because it's not productive to revisit old design decisions. Scoped addresses and the notion that nodes would have multiple addresses of different scopes are design decisions from many years ago.
I can understand this argument, but I don't think it fully applies here...
We did decide to include site-local addressing in the architecture years ago, but only fairly recently did we start documenting how it would actually _work_. The scoped addressing architecture is still an I-D (not any sort of RFC), and I think it is appropriate to consider (and even re-consider) the architecture described in that I-D.
Second, scoped addresses are an important part of the IPv6 architecture because they reflect today's internet architecture. The internet is no longer a fully-connected network of nodes with static addresses. (I get the impression that some participants in this thread would like to turn the clock back 20 years!) The world is more complicated now. Sites have strong boundaries; firewalls and two-faced DNS are commonplace for enterprise networks. Addresses occasionally change.
I think that one of the goals of IPv6 is to enable the simplification of the Internet architecture. Maybe this is naive and idealistic, but I hope that, when we turn the clock forward 20 years, we'll find a flatter and simpler Internet architecture than we have today, enabled by IPv6. One way that I think we could help to make this change is be advocating the use of globally-unique addresses on private networks.
The idea of restricting site-locals to completely disconnected networks doesn't make much sense to me. It's like saying you can have them but not really. How would we handle intermittently connected sites, or partially connected sites? What would happen when a network that is using site-locals gains global connectivity? This seems like a recipe for encouraging v6 NAT, which is not something we want.
These are valid questions/concerns, and I think it makes sense to discuss them. However, I'm not sure that we know the answers to all of these questions, even if site-locals are used side-by-side with global addresses. How would that work for intermittently connected sites? Partially-connected sites? Sites that gain global connectivity? Sites that renumber? Etc. One of the issues with having a "tool" like site-local addressing is that it is easy to see it as a panacea to solve a huge number of problems. In actuality, site-local addressing will not solve the bulk of the problems you've listed without other things also being defined -- like explicit support for site-locals in applications, and in the DNS.
In my opinion, IPv6's explicit architectural support for multiple addresses and scoped addresses are two of its advantages over IPv4. Because they're baked in from the start, applications can do the right thing with scoped addresses. And one way or another they will be there eventually (look at how scoped addresses have crept into IPv4), so it's better if applications that need to know about them are coded that way from the start.
Unfortunately, I don't think that most IPv6 applications are (or will be) coded from scratch. In general, folks are trying to port IPv4 applications, and the need to understand all of the issues surrounding site-local addresses will represent a significant hurdle and/or be ignored -- both of which are bad. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
