applications need a stable API that works the same from one platform to another, not one that changes at the whim of some network administrator. and we don't need an API that only works for "most applications".
The API itself will be stable, it's only the returned value(s) that may change based on exactly where a host lives and how it's configured.
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.
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.
As long as the API returns _something_ usable, it can be considered stable.
what is "usable" varies from one application to another. perhaps I misunderstand you but you seem to be proposing a model where the app should be happy with whatever it gets, no matter how dysfunctional. as NATs have aptly demonstrated, it's completely unreasonable to expect many kinds of apps to function in that kind of environment.
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.
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.
sounds like the Golgafrincham Ark B. "what if they want fire that is nasally fitted?"
yes, network admins will do whatever they want, no matter how stupid it is.
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
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 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.
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.
Keith
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
