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. 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. > > There is no way for software alone to determine many of the variables > > involved in address selection, especially things like security policies. > > which is why having security policies that expect hosts or apps being > able to select addresses is a complete crock, and we should not be > endorsing such brain-damage. 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. > >>> 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. I, as a user, want my apps to at least _attempt_ to work instead of giving up because the address set on my machine (or the policy I created) doesn't live up to the app's expectations. "Needs a global address" is an inherently flawed expectation; "needs an address which can reach a given address" is not. > > For instance, some admins may prefer intra-company communication use > > local addresses even if global addresses are available, while other admins > > may prefer the opposite. You won't get far ignoring the "whims" of the > > person who owns all of the hosts in question. > ... > our task is to define how the network operates in such a way that > > a) network admins can define reasonable policies, AND > b) apps can function as long as policies permit, AND > c) if the app breaks because of a conflict with policy, it's obvious > that this is why the app breaks > > our task is NOT to let the network admin do whatever the hell he wants > and expect the app to be able to function in the presence of arbitrary > brain damage 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. > > The application writer can't possibly anticipate all ways his code > > will end up being used, which is why I believe that a per-host policy > > (hidden behind an API) is the best way to go. > > no, that's why giving applications a reasonably consistent view of the > network independent of location is the only way to go. 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. 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 is absolutely no point to deploying IPv6 if it's going to be as > brain-damaged as IPv4+NAT from day one. it will only get worse from > there. NAT is hopefully out, but firewalls are here to stay. That's no reason to give up on IPv6. > >> it is, and always has been, completely unreasonable to expect either > >> hosts or apps to have to choose between a number of > >> (source,destination) address pairs in order to successfully connect > >> with other hosts. no API can solve that problem. > > > > Not true; it would be fairly trivial to implement an API function that > > tests all N*M pairs and return the set of pairs which appear to work. > > it would be trivial to implement, and unacceptably slow and unreliable. > and yes, I've written the code and tried it out. For reasonable values of N and M it can be done in a fraction of a second. That's fast enough for me. 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 --------------------------------------------------------------------
