> 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.
yes, they're perfect examples of second-system effect. to the extent that we can deprecate them we're doing everyone a favor and making IPv6 much more usable. IPv6 is a good design with a few warts which we'd be better off without. A6 was one wart. SLs are another. fortunately we can eliminate the warts without doing harm to IPv6. > Second, scoped addresses are an important part of the IPv6 architecture > because they reflect today's internet architecture. when you have a train wreck, you don't call the resulting jumble of cars and debris '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. yes, but people have had to resort to poor solutions because of a shortage of address space in v4. that and some really bad ideas have been tried which are now being found wanting. nobody is suggesting that sites abandon firewalls, or that sites be forced to advertise all of their hosts' addresses using DNS. what is being argued rather forcefully is that having site-local addresses (and having apps be expected to use them) adds a lot of complexity without providing a significant benefit in return. > 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. no it's like saying that SLs are a bad idea except perhaps for a few corner cases where they don't do much harm - and rather than burdening everyone with having to deal with SLs we should discourage their use except in those corner cases. in other words, we're just recognizing reality. >How would we handle intermittently connected sites, or > partially connected sites? give them globals, of course. > What would happen when a network that is > using site-locals gains global connectivity? same as when a network changes providers. they have to renumber, and there's a transition period during which both kinds of addrs are used. > This seems like a recipe > for encouraging v6 NAT, which is not something we want. no more than any other kind of renumbering. we need to work out a complete and convincing renumbering solution but SLs aren't a part of that. > 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. no, it doesn't follow. first because nobody has been able to define what the "right thing" is - or to be more accurate, it looks like the "right thing" is "avoid SLs at all costs". second because this essentially expects apps to perform routing in the absence of any routing information, and anyway that's the network's job. in other words, just because SLs have been in the address architecture for a long time doesn't mean that their effects, or how to use them, were understood. when apps people start looking at these things the emerging understanding is that they're a bad idea except for some corner cases where apps don't have to deal with them anyway. one way to put it is that SLs should be discouraged to the extent that a default set of addr selection rules (_not_ the ones currently in effect) will work just fine. > 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. about the only benefit to having them be visible to apps is so that apps can avoid using them - and this only works if sites are discouraged from using them. expecting apps to make reasonable decisions about which addrs to use in which contexts is extremely naive because apps simply don't have access to the necessary information to inform those decisions and because they don't want to absorb that complexity even if they did have access to that information. > 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. I agree that this is an interesting idea. > 2. Auto firewall. The site boundary is automatically a firewall for the > site-local prefix. actually it seems about as easy for routers to implement a similar function for globals. what SLs give you is the ability to mix and match routable and non-routable addrs and you can control whether a host or app has external acces depending on which address you tell that host or app to use. but this isn't a very secure way of doing access control. > 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. it doesn't work. then you can't do referrals between sites. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
