> Keith Moore wrote: > > ... > > but if the normal way > > you get a site local is to buy a router, why would anybody need > > more site local prefixes than routers? > > Because routers have interfaces in multiple sites.
seems like a stretch for those 'sites' to not have routers themselves and thus, their own site prefixes. sure you can make each site a bridged ethernet, but then you are unlikely to have so many hosts on any of those ethernets that you can't subnet a single SL prefix for the whole thing. still, the idea isn't to force people to get prefixes or site-ids from a router vendor, it's to set up some cheap ways of distributing prefixes so that everyone who needs one probably gets one automatically. there can be other mechanisms for the few that don't get enough via this mechanism. > These arguments are contradictory. If an address isn't globally routed, > the app needs to deal with some addresses having a limited scope. true enough, but there's still a useful difference between a globally unique address with a limited scope, and an ambiguous address. if the app tries to send to a globally unique SL address with a limited scope, the message will either get there or it will fail. if the message fails it's almost certainly because there is no route to the destination - in other words, it's completely beyond the ability of either the app or the network to fix, everything has fulfilled its function as well as possible. also it's likely that the network can issue a network unreachable ICMP giving quick feedback to the app. if the app tries to send to an ambiguous address, like a LL or a SL without a site-id, and the transmission fails, it could be for any reason - the host is on the local net/site but is down, the host is on another network/site but there's no way to tell, the app didn't send the message through the right interface, etc. part of what I'm discovering is that if you want to make any kind of address selection algorithm work well, you need to ensure that IF there is an allowed signal path from source to destination, the hosts will (or are very likely to) (a) have addresses assigned to them that allow that signal path to be used, and (b) the address selection algorithm will choose a addresses that meet those criteria over those that do not. in order to meet condition (a) then we need to make sure that every site has a globally-unique prefix. in order to meet condition (b) then we need to make sure that globally routable prefixes are chosen in preference to site-specific prefixes. > I agree no address should ever be ambiguous, but that doesn't require > global uniqueness. The thing that is required is that the address be > unique within the scope of routability. the app has no good way of knowing about scope - and multi-faced DNS just doesn't cut it - DNS really doesn't know more about topology than any other app, and the DNS server has no control over who caches its messages. but it's not necessary that the app know about scope. it's only necessary that a) if the app can send a message to a destination, it can easily find out which address will work b) if the app can't send a message to that destination, it can find out quickly at least, I think this is the optimal result given the assumption that we don't have a completely connected network - i.e. that there will be some host pairs (A,B) for which A cannot reach B due to either the lack of a signal path or an administrative prohibition. none of this really requires that we get rid of limited scope addresses, just that we always use global address in preference to LS addresses. though if we can provide privately-routable provider- independent addresses then it's hard to see how to justify keeping ambiguous SL addresses in the architecture. 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] --------------------------------------------------------------------
