Thus spake "Keith Moore" <[EMAIL PROTECTED]> > >> that's not a stable API, that's an API that behaves differently in > >> different environments - and the differences are sufficient to break > >> applications. it's simply not acceptable to give applications > >> temporary addresses when they need stable addresses. if an app says > >> it > >> needs a stable address, then the API MUST either comply or return an > >> error. > > > > I'm not proposing that the API return something that conflicts with the > > app's requirements. I'm saying if there are multiple valid > > possibilities, > > which one the API returns may vary according to site-specific policies. > > if the app says "I can accept either of these kinds of addresses", then > it's perfectly acceptable for the API to return either of those kinds > of addresses. ... > > > I'm also saying that what requirements an app is allowed to specify > > needs a lot of study so that programmers don't accidentally disallow > > valid return values. > > I agree that it's hard to get the specification right, though I think > part of the answer is to encourage programmers to specify functional > behavior rather than specific prefix types.
I think we're in violent agreement on the above points. > whether it's a good idea to encourage sites to use address selection as > a means of policy enforcement is a separate question. IMHO this is not > sound architecture. but that's a separate question from the API. I'm not convinced it's sound either, but I can't figure out a more straightforward way of implementing the types of policies I hear customers ask for. > > I meant the application can't statically determine what a site's policy > > will be; that doesn't mean the API can't determine it via some sort of > > configuration. > > the more I think about it the clearer it becomes that specifying > application policy at the network level is like trying to make fine > furniture with a chainsaw - it's the wrong tool for the job. so the > API that the app uses to deal with the network is not the right place > to inform the app about policy. I don't think the app needs to be aware of policy if it's hidden behind the API -- presumably the policy will be configured and implemented in the OS or some system library. As long as the app can specify what behavior it needs and the policy is able to find a valid address, the app can stay oblivious. > however, having the API inform the app when there's a conflict between > what the app requested and what the API/host/network is able to do > means that the app can provide a clear error message, and that's > extremely valuable. Agreed. > >>>>> I'm not convinced that such an API is immediately useful, however, > >>>>> since it seems to assume a prior means of determining which > >>>>> addresses > >>>>> will work at all. Most applications will be faced with a scenario > >>>>> where the source has N addresses, the destination has M addresses, > >>>>> and it won't be clear which of the N*M combinations will work > >>>>> without testing them all. > >>>> > >>>> you're absolutely right about this part. about the only thing the > >>>> API > >>>> can reasonably do is let the application specify whether it can use > >>>> a > >>>> temporary "privacy" address (as in a web browser) or whether it > >>>> needs > >>>> a public address (as in a server or p2p app). > >>> > >>> That argument is loaded with flawed assumptions. There are many > >>> servers and p2p usage scenarios that would be served just fine by > >>> local addresses. > >> > >> in other words, the app _might_ just happen to work if the cards fall > >> right. that's not a model that app writers can work with. people > >> expect apps to work no matter where they're plugged in, and expecting > >> customers to guess whether the problem is in the app or in the network > >> configuration is not an acceptable means of operation. > > > > Instead, you propose that apps fail because they make questionable > > assumptions about what is acceptable. > > the app writer knows what his app needs from the network. if the > network doesn't provide what the app needs, the app is likely to fail. > maybe it won't fail every single time it is used, but it won't be > reliable. Even if the API were to return what the app asks for (e.g. a global address), there are still a large number of cases where that address still won't work because of firewalls or other necessary evils. On a slightly different note, there may be many servers or p2p apps with only local addresses available because that is the administrator's intent. Having these apps fail because no global address is available doesn't make sense, even if it does print a friendly error on the screen. This case is only marginally different than one where a global address is available but the administrator doesn't want it used for local communication. > > "Needs a global address" is an inherently flawed expectation; "needs an > > address which can reach a given address" is not. > > there are apps that need global addresses in order to function > properly. there are other apps which need addresses that are > reachable by an arbitrary number of hosts which might be participating > in the application now or at sometime in the future (though they don't > need to be global). other apps only need pairwise reachability. "Function properly" and "reachable by an arbitrary number of hosts" are both flawed in the presence of firewalls anyhow. It is well within an administrator's right to block such applications from leaving the local network, and in that case a local address becomes superior to a global one due to stability. > > I never suggested that; I gave a simple case of two mutually exclusive > > local policies which are both perfectly reasonable, but would cause apps > > to needlessly fail if they make unfounded static assumptions. > > it's not "perfectly reasonable" for local policies to expect apps to > vary how they choose addresses from one site to the next. That's the whole point of providing an API -- the app just specifies its requirements and which available address is returned (if any) will implicitly vary between sites. > > There is no consistent view of the network independent of location. > > Not all addresses can reach all other addresses, and that is something > > we all need to live with. > > true. but if for whatever reason the network cannot or is prohibited > from routing traffic between two points, it needs to be clear that it's > not the app's job to do so. expecting the app to be aware of network > topology, local policy, or whatever is not reasonable. Right. But I argue it's reasonable to allow an administrator to configure hosts with local policies, which the apps transparently inherit. > > In particular, it is not guaranteed that "global" addresses' > > reachability is > > superior to that of "local" addresses; that depends on where you're > > located. > > there are conditions where a local address will be bound to a host > longer than a global address, and it's certainly desirable for apps to > be able to identify those conditions and to use local addresses in > those cases when they are otherwise consistent with the app's needs > (not under all conditions). > > OTOH, if a network doesn't know how to route its own global addresses > (while they're still associated with that network), it's thoroughly > broken and we shouldn't expect apps to compensate for that. An "obvious" security scheme for corporate networks is to block all packets with local addresses at the firewall (as specified in the I-D) and then block access to server farms from non-local addresses (in case there's a leak or misconfiguration at the firewall, and to simplify configuration and auditing). Since the servers inside that farm will only have local addresses themselves, it is logical to require any hosts contacting them use local addresses as well. I welcome any suggestions on how to accomplish the same goals without increasing overall complexity. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
