Gee whiz, I really can not keep up with this thread. Why did I call it "craziness"?
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. 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. 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. 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. In addition to the main architectural point above, there are some specific advantages of site-local addresses that others have mentioned, but let me put my own spin on them: 1. Site renumbering. Preserving long-lived connections across renumbering is not so compelling - I think most renumbering events can be planned for a large enough time-scale. More interesting is that various random static configurations that use site-locals do not have to be tracked down and updated. 2. Auto firewall. The site boundary is automatically a firewall for the site-local prefix. This is a simple model, easy for administrators to understand and easy for applications to recognize and cope with. Yes you can also put up filters for global prefixes, but that's more error-prone. (Let me throw out an idea that just occurred to me - some simple defaults in router configuration could help prevent errors in site boundary configuration. For example if the router is configured to run BGP, then by default it could assume its interfaces are in separate sites.) There's the question of how much burden do scoped addresses create for applications. For most applications, even on multi-sited hosts, there's no burden at all if they are coded using sockaddrs. Distributed applications that send around addresses do have to cognizant of scoped addresses. However this is not hard to deal with. For example I checked on how one such distributed application that is being built at MS handles this issue. The application looks at the scope of the correspondent and sends its addresses of matching scope. In other words, when talking to a global address you send your global addresses and when talking to a site-local address you send your site-local addresses. There's the question of implementation effort for the network stack to support scoped addresses. This is hard to quantify but I would say it was small. (And necessary regardless of site-locals, unless link-locals are next up for revisionist architecture.) The additional code in source & destination address selection was about 10 lines each. The additional code in route lookup and destination cache management was worse, maybe 100 lines. A scope-id needs to be passed around as an argument to various functions so there was a very small impact in many other places. Rich -------------------------------------------------------------------- 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] --------------------------------------------------------------------
