> 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.
they don't need to be communicating globally, or to have connectivity to the public Internet. all they need is to have *some* node in the app that is communicating off-site. if that is the case then the ambiguity of SLs will still cause problems. > (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). apps aren't aware of site boundaries. > 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. indeed, that's part of the difference. > I believe that applications > expecting to communicate globally will have access to global addresses. again, it's not communicating globally, it's communicating off-site. and it's not sufficient to just give the nodes with direct off-site connectivity global adddresses - every node in the application, regardless of whether it can directly communicate off-site, needs a global address. > Without such access, I don't think it is reasonable for an application > to expect global connectivity. I think the assumption that a site can get away with just assigning globals to some nodes, and yet expecting other nodes to participate in applications along with those nodes that have off-site connectivity and use globals, is naive and effectively produces onerous requirements for those applications. > > 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? yes, if you don't connect directly to the Internet. > > > 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. scope-ids are not globally scoped. they're only meaningful to the local host. and the scope-id isn't part of the address. so yes, they are 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). and what is the purpose of the proxy if not to route messages? and just what do you think the proxy is going to use for addresses to enable it to refer to a nodes on other side of the proxy? guess it's going to have to implement its own addressing and routing after all. > > > 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 yes, we've been over this before - if the party doing the referrals is off-site (and yes, I work with apps where this can easily happen) then this filtering algorithm prevents the referral to site-local nodes if those nodes don't have globals. > 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). the app has to deal with renumbering anyway. why should it have to implement different solutions for local-only nodes vs. other nodes? > > 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. false. 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. they will. but global connectivity is not a necessary condition for needing global addresses. apps need global addresses if any node in the app (present or future, directly connected or not) is off-site. > 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. I'd like to belive that, and that would surely simplify things. But we've got someone arguing that it's okay to implement security by assigning globals only to some nodes on a site, and letting the others deal with SLs. > 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. I don't have a huge problem with that - as long as globals are reliably available to any node that isn't on an isolated network, writers of multi-party apps will surely realize that the simplest way to solve their problem is to avoid using SLs. the other apps can use them if they want to. (I think it will still cause problems when they do so, but these mostly affect the local network administration, and the local network admin can always fix it by disabling SLs) > > 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. intermittently connected networks that lack a stable address prefix, and a couple of other corner cases. but more things will work if those networks can somehow manage to use globals. 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] --------------------------------------------------------------------
