> >No. Scopes reduce the ablity of the network to support apps. > >They make it harder to produce an app that works independently > >of network location, and they don't add a single extra capability > >that wasn't present already. > > You keep saying that some apps will fail with scoped addresses. My poor > brain can't grasp why this is so. Can you give me a detailed example of > how an app will fail if it has multiple scoped addresses to choice from?
example 1: Process A sends the addresses of process B to process C. Processes B and C are in different scopes. (Either one might or might not share a scope with A.) Process C cannot communicate with process B using SLs that it has received from A. example 2: A sends the addresses of B to C. This time B and C are in the same scope, but A does not have access to that scope. If A sends the SL addresses of B to C, C can talk to B. However A has no way of knowing whether this is the case. If on the other hand A filters SLs in addresses that it sends to C (as some have suggested is appropriate), C may be unable to talk to B for lack of an address that works, even though B and C share an address scope. In either example the problem is solved if B and C have global addresses, and all referrals filter SL addresses. But that's not realistic given current address allocation policies. And if we change the address allocation policies to permit any network to get a global prefix, there's even less reason to have SLs. > I don't mean that it may be hard to for the app to decide which address to > use. Yes that's a hard problem, and we don't have a solution to it yet, > but that doesn't seem a good enough reason to kill site locals to me. Standards-track protocols are supposed to have no known technical omissions with respect to the requirements placed on them, and are supposed to have resolved known issues. An addressing architecture that expects apps to solve an unsolved problem that is acknowledged to be difficult doesn't seem like it meets either of those criteria. > I also don't mean that an app can get confused and it will fail to connect to > the correct proper destination if it uses a scoped address at the wrong > time. Yes this can happen, but it's still part of the address selection > problem, not a basic problem with an app. Address selection doesn't solve this problem. Basically what the app has to do is implement its own addressing (so it can disambiguate hosts using the same address) and routing (so it can operate across site boundaries - because this will be necessary for many apps). > I'm looking for something like FTP and NAT. FTP exchanges IP addresses in > data messages which fail when NATs cause these addresses to change. There > are all kinds of kludges that try to work around this problem, but the > basic issue is that the E2E property of IP was lost and the apps suffer for > this change. > > I don't see the same thing happening with site-local's, everyone agrees > that they aren't a v6 NAT replacement so apps are not allowed to propagate > site locals outside of the site boundary. No, everyone does not agree on that. First because apps aren't aware of topology so they don't know when they're propagating an address outside of a site boundary. Second because expecting apps to be aware of topology imposes too much of a burden on those apps. Third because if those apps don't have alternatives to using SLs they'll be forced to use them. Fourth because if the apps reliably do have alternatives to SLs (for networks that aren't isolated) then there's not much reason to have SLs at all. > Yes, hosts need to be aware of > the site boundary, no, not hosts. hosts aren't making those decisions. apps are. > but that is still an address selection problem not a > problem with the app itself. Site-locals are unique within the site > boundaries and look just like a global IPv6 address, so what is a specific > example where an app will be broken by using a site-local address? see above. 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] --------------------------------------------------------------------
