Keith; At 01:43 PM 11/13/02 -0500, Keith Moore wrote:
These are generic examples. Please provide me with the name of one of these apps. Also:> >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.
* why is A sending the B's IP address to C, why not send the FQDN or some other name and let C look up the address?
* How is this scenario different from the case where a filter blocks the B to C communications channel? Wouldn't the app 'see' the same failure mode? In this case the use of global addresses doesn't help does it?
Standards track documents are suppose to describe the protocol operation in enough detail that inter-operable implementations can be written. Where are the bake-off results that show that scoped addresses present an unsolvable problem?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 toI don't grog this answer. Address selection policies is precisely the problem I think you're talking about. If an app gets a list of addresses back from a name lookup query it somehow has to order these addresses and decide which ones to try and in what order. Since a v6 host can have multiple globally unique addresses or a set of scoped addresses, the app must have some way of determining which address to use. I would think that having a know set of scoped prefixes (Global, SL, LL) would make it easier, instead of harder for the app to start the sorting process.
> 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
------------------------------------ Richard A. Carlson e-mail: [EMAIL PROTECTED] Network Research Section phone: (630) 252-7289 Argonne National Laboratory fax: (630) 252-4021 9700 Cass Ave. S. Argonne, IL 60439 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
