[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adopt Address Selection API as a WG document?

>> 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 

>  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.


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6