Keith Moore writes: > In either example the problem is solved if B and C > have global addresses, and all referrals filter > SL addresses.
Yes, nodes communicating globally should have global addresses, and then there is no problem. (Although again, I think you're being overly draconian with the second bit since referrals only have to filter site-locals from leaving their site as opposed to filtering all site-locals, but that's a nit). It seems what we're arguing about here isn't technical at all. These arguments keep circling around our preconceptions about how we expect IPv6 networks will be set up and used. I believe that applications expecting to communicate globally will have access to global addresses. Without such access, I don't think it is reasonable for an application to expect global connectivity. > But that's not realistic given current address > allocation policies. I don't follow this. Are you saying it is hard to get global IPv6 addresses? > > 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). Not really. Since the scope-id is part of the sockaddr_in6, the full address isn't ambiguous. Apps don't have to "implement their own addressing". Or routing, for that matter. Apps wanting to operate across a site boundary will need to use global addresses (or an application-level proxy on a node connected to both sites). > > 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. Sure they do. I've gone over this before. If you're an app, don't provide a site-local in a referral to anyone who isn't themselves communicating with you via a site-local. And also provide the global (or even just the global, if the app doesn't care about being robust against renumbering or global prefix loss). > Second because expecting apps to be aware of topology > imposes too much of a burden on those apps. They don't need to. See above. > Third because if those apps don't have alternatives to > using SLs they'll be forced to use them. Please explain why they won't have global addresses if they have global connectivity. The only apps that don't have an alternative should be those on disconnected networks, and people seem ok with letting them use site-locals. It's the opposite freedom I want to preserve, to let apps have the alternative to use a site-local instead of a global should they be inclined to do so for communication within their site. > 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. Intermittently connected networks. I believe you agreed to this point in another thread. --Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
