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. 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 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.
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.
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. 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.
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.
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.
we _really_ need to get over the idea that sites should use address selection as a means of setting policy.
"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.
... 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.
it's not "perfectly reasonable" for local policies to expect apps to vary how they choose addresses from one site to the next.
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.
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.
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.
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.
I agree. but having filtering in the network, and expecting apps or hosts to do address selection, are two different things.
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 simply incorrect.
Keith
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
