Subject: Adopt Address Selection API as a WG document?

From: Brian Haberman <[email-masked]>
Date: Mon, 01 Mar 2004 23:25:54 -0500

All,
      The address selection draft authors have asked the WG to adopt
draft-chakrabarti-ipv6-addrselect-api-02.txt as a WG document.  Are
there any objections to the group adopting it?  As with other API
documents, this would be Informational in nature.

Regards,
Brian & Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 02 Mar 2004 06:20:48 +0100

In your previous mail you wrote:

=> I have no objection but I have a concern: as I don't expect to
see all applications changed to handle this I am really afraid that
this draft doesn't address the right problem...

Regards

[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Mar 2004 15:46:30 +0100

As we are seeing in the multi-addressing discussions in multi6,
there is indeed strong pressure from applications people against
apps having to know anything at all about address selection.
This becomes even more true when you get into Java land.

So while this API is probably harmless, I agree with Francis
its applicability is very limited. In fact, I would be tempted to
argue for it becoming Experimental. However, I think it is perfectly
valid for it to become a WG draft.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 2 Mar 2004 20:36:23 -0800 (PST)

> valid for it to become a WG draft.

The draft in question doesn't look at multiple addresses of the same 
type/properties, such as multiple prefixes in the case of multihoming.

The draft is about being able to choose between things like temporary and
public addresses, which is something which users/applications might care
about. And this is orthogonal to the multihoming aspects.

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Mar 2004 19:00:21 +0100

I don't disagree, and I didn't mean to imply that this is relevant
to multihoming. But in practice I think these choices will be made
by a separate policy mechanism, not by individual applications.

  Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 5 Mar 2004 14:29:38 -0500

these choices MUST be made by applications, not by a separate policy 
mechanism, because some applications cannot work unless the right kind
of address is assigned - and the OS cannot be expected to guess what
kind of address the application needs.

or to put it another way, if the policy is to say "you are not allowed
to use a public address" - the proper thing to do is to return an error
to the application that requested this kind of address so that it can
print a message to the effect "local network policy prevents this
application from working here" NOT to give the application an address
that doesn't suit its needs.

one of the tragedies of NAT was that the policies enforced by NAT are
not visible to the applications or users - so the apps get blamed for
the problems that the policies (implicit in NAT) cause.  we need to
not repeat that mistake.

so we certainly do need such an API.  however it's been too long since
I read this draft so I'll stop short of recommending _this_ API until
I've managed to reread it.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 5 Mar 2004 13:59:14 -0600

Some applications MAY prefer one address over another, but most applications
will not care.  IMHO the best solution is to allow the OS (and therefore
presumably the admin) to specify a default policy, but let applications
provide "hints" to the OS that other addresses may be better in certain
circumstances.  Of course, the OS should be free to not select an address if
it is so configured.

In most cases, a default of preferring any IP address in the same /48 as a
destination will work, followed by addresses in the same /8, followed by any
globally-reachable address.

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.  Only when there
are multiple _working_ combinations does an address selection policy matter.

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
----- Original Message ----- 
From: "Keith Moore" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Friday, 05 March, 2004 13:29
Subject: Re: Adopt Address Selection API as a WG document?

---

From: Keith Moore <[email-masked]>
Date: Fri, 5 Mar 2004 16:53:32 -0500

> circumstances.

no, that's ridiculous.  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 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).

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.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 5 Mar 2004 18:49:37 -0600

Thus spake "Keith Moore" <[email-masked]>
> > Some applications MAY prefer one address over another, but most
> > applications will not care.  IMHO the best solution is to allow the OS
> > (and therefore presumably the admin) to specify a default policy, but
let
> > applications provide "hints" to the OS that other addresses may be
> > better in certain circumstances.
>

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.  There
is no way for software alone to determine many of the variables involved in
address selection, especially things like security policies.  As long as the
API returns _something_ usable, it can be considered stable.

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

That argument is loaded with flawed assumptions.  There are many servers and
p2p usage scenarios that would be served just fine by local addresses.  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.

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.

> 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.  This would
then be fed into a different API function to determine the "best" pair for
the application's needs.

S

---

From: Keith Moore <[email-masked]>
Date: Fri, 5 Mar 2004 20:46:25 -0500

>>   applications need a stable API that works the
> 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

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.

> 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

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

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

> 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

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 5 Mar 2004 21:57:23 -0600

> needs a stable address, then the API MUST either comply or return an

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.

> > involved in address selection, especially things like security policies.
>

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.

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

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.

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

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

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.

> brain-damaged as IPv4+NAT from day one.  it will only get worse from

NAT is hopefully out, but firewalls are here to stay.  That's no reason to
give up on IPv6.

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

For reasonable values of N and M it can be done in a fraction of a second.
That's fast enough for me.

S

---

From: Keith Moore <[email-masked]>
Date: Sat, 6 Mar 2004 01:47:16 -0500

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

> be; that doesn't mean the API can't determine it via some sort of

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.

> 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

we _really_ need to get over the idea that sites should use address 
selection as a means of setting policy.

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

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

> addresses can reach all other addresses, and that is something we all 

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.

> superior to that of "local" addresses; that depends on where you're 

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.

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

> For reasonable values of N and M it can be done in a fraction of a 

that's simply incorrect.

Keith

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 7 Mar 2004 13:49:03 -0600

> of addresses. ...

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

> maybe it won't fail every single time it is used, but it won't be

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.

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

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

Right.  But I argue it's reasonable to allow an administrator to configure
hosts with local policies, which the apps transparently inherit.

> 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

---

From: Keith Moore <[email-masked]>
Date: Sun, 7 Mar 2004 16:42:46 -0500

> straightforward way of implementing the types of policies I hear 

what policies are those?  what kinds of filtering can be implemented 
with address selection that cannot be implemented without it?

> and the policy is able to find a valid address, the app can stay 

that's true only as long as the same policy applies to every host that 
is participating in the app.  any app that crosses policy domains has 
the potential for conflicts between those policies.  in one part of the 
network the policy is to favor globals; in another the policy is to 
favor locals.  there's no good reason to support this kind of 
inconsistency and complexity.  what we need are a set of rules for 
assigning addresses to hosts and for use of addresses by hosts and apps 
that works the same everywhere.  that doesn't stop networks from having 
policies, but it does mean that there are correct and incorrect ways to 
implement those policies.

> won't work because of firewalls or other necessary evils.

it is not at all clear that firewalls as we currently know them are 
necessary, though I do accept that they're going to continue to exist 
for awhile.  as long as packet filters exist the best we can hope for 
is to get them to return appropriate ICMP messages.

> only local addresses available because that is the administrator's 

the rules have to accommodate the fact that not everyone is connected 
to the public internet and not everyone has public addresses.  apps 
have to use local addresses if global addresses are not available.  of 
course this limits the app to whatever addresses are reachable.  but 
the same is true for global addresses, since as you point out, those 
addresses can still be filtered.

on the other hand, if your net has a global prefix, trying to limit a 
host or an app to a local prefix is not a very good way to implement 
policy.   it's the wrong tool for the job.

> the administrator doesn't want it used for local communication.

no, that's just wrong.  it's one thing to say that an app isn't 
expected to communicate if the network isn't wiling to route packets 
between its hosts.  it's quite another to say that it's appropriate for 
network admins to restrict which addresses an app or host can use in 
order to keep the network from routing packets between certain hosts.  
it's crude and imprecise, it imposes unnecessary complexity on hosts 
and apps, and it's unreliable.  it's much easier to reliably implement 
a policy if reachability is the same for every address that is 
available to a host than if reachability varies from one prefix to 
another.  it's also much easier to monitor network traffic for policy 
violations if this is the case.

> flawed in the presence of firewalls anyhow.

ARRRRRRRRRRGH!

no, they're not flawed.  it may be that what the app needs and how the 
admin has configured a firewall are mutually inconsistent.  that 
doesn't inherently mean there's something wrong with the app.

it's perfectly reasonable for some apps to operate that way.  it might 
be that the admin simply doesn't want that app to operate.  it might be 
that the admin has misconfigured the firewall.  it might be that 
present-day firewalls are too crude to allow the admin to implement the 
policy that he wants and still have the app operate.

but folks need to stop blaming apps for failing when they impose 
unreasonable conditions on their operation.

>   It is well within an

you're confusing two different things here.  one is policy, and the 
other is use of local addresses for stability.  if the app can 
reasonably make use of local addresses, telling the app "hey, you can 
use this more stable local address in place of this global one" is a 
useful thing to do.  then the app can optimize if it's able to do so.  
but this doesn't work equally well for all apps.  some apps need for 
every host to use the same address and for all of those addresses to be 
reachable by all participating hosts.  those apps probably don't want 
to use local addresses unless they're the only ones available.  this is 
something for the app to decide, not something for an admin to try to 
dictate with policy.

it's not reasonable to expect admins to know how every app operates and 
what they need in terms of addresses.
it is reasonable to let admins control which hosts or users or 
principals an app can talk to, but prefix assignment is not the right 
mechanism for the job.

> implicitly vary between sites.

having an API is useful - to a point.  different kinds of apps prefer 
different kinds of addresses.  some apps prefer privacy addresses; 
others need addresses that have a long-term association with the host.  
some apps prefer local addresses even when a global is available, 
others have the opposite preference.  some apps prefer an ephemeral 
address (like an address that changes when the host moves) for the sake 
of efficiency, others prefer one that will stay the same even if the 
host moves even though this is less efficient.  it's good to have an 
API that lets the host and app negotiate these things.

what's not a good idea is to expect this API to be a means for 
implementing policy.  the fact that the address selection is hidden by 
an API does not keep it from breaking apps.

> hosts with local policies, which the apps transparently inherit.

that's like arguing that it's reasonable to allow the administrator to 
unplug the machines from the mains and still expect the apps to work.  
sure enough, you can implement a policy of sorts by doing that - but 
it's a very crude mechanism.  we can't stop admins from doing things 
like this, but that doesn't mean we should tell them that it's a good 
way to implement policy.  (and an API won't help much)

> with local addresses at the firewall (as specified in the I-D)

which I-D is this?  I've been ill for several months and not able to 
keep up.

but that's a REALLY, REALLY Bad Idea - one which needs to be thoroughly 
discredited.

> and then

the method you're proposing is pretty complex already - it just puts 
the complexity in the hosts and apps (not only in having to implement 
the policy but in being expected to work around the resulting 
dysfunctionality)

if you must put policy in addresses, don't put it in the "local" vs. 
"global" bits - put it in the least significant bits of the subnet.  
that lets you write simple filtering rules at the routers without 
expecting apps to be contortionists.

here's the thing - it's rarely the case that an admin really wants to 
isolate a network or even a significant set of hosts.  what the admin 
typically wants (if he'll take the time to think about it) is to let 
some apps traverse boundaries and other apps not traverse those 
boundaries. also, it's less and less often the case that the boundaries 
that an admin wants to enforce conveniently coincide with routers.  of 
course admins try to arrange their networks that way, but there are 
constantly good reasons to make exceptions.  meanwhile app writers are 
standing on their heads trying to make their apps work in the presence 
of arbitrary constraints imposed by network admins -- even when the 
network admins weren't trying to break those apps.

what this means to me is that we need to provide better tools for 
network admins to specify policy to apps and to enforce that policy in 
depth.  but that's not the same thing as saying that we need to give 
network admins more tools for limiting which addresses a host or app 
can use.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 19 Mar 2004 22:56:53 +0900

>>>>> On Tue, 02 Mar 2004 06:20:48 +0100, 
>>>>> Francis Dupont <[email-masked]> said:

> this draft doesn't address the right problem...

I agree with Francis here.  I won't go into further details, since it
would simply be the same discussion I made on this before.  (note that
I'm not necessarily objecting to making it as a wg document.)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]