In message <20050425180959.GA20220@netbsd.org>,
Bill Studenmund writes:

[...]

>> Re: not seeing forest for trees: yes, I've been working with policy
>> issues, and an SO_BINDTODEV-like implementation for some years
>> now. Personally, I find that to be a *much* better solution for what
>> you say (in a subsequent message) you want.
>
>I disagree. What I want is something that works well for a client. A new
>call, of any sort, means each client has to be changed to support it. 
>want something where I configure the stack to do what I want, and then all
>clients do the right thing.


I am skeptical this is technically feasible, at least if we agree to
consider both `clients' and `servers'. I see no good way to specify
all desired policies in the way you propose, short of a firewall-style
filter language: write your policies in the languuage, then insert
them into the kernel.

For my purposes, which are server-oriented, that is overkill.  The
performance overhead for interpreting such rules, for every packet
sent and recieved, is not acceptable for the kinds of environments I
care about -- multiple 1 gig NICs at saturation, or 10GbE NICs.  I'd
like to talk about that separately; I will reply separately (a third
time, sorry!) about that.



>We have one netinet and tens to hundreds (to thousands) of clients. Making
>
>each client have to change for this doesn't scale well. I'd rather we
>change one thing to get it right rather than thousands of things.


>I understand your description of problems with Linux NFS. However I don't
>see how any change to how addresses are picked will break WORSE than we
>have now. :-)


Huh? one of my points all along, is that David's initial proposal
*DOES* make things worse --- much worse --- in the kind of networks I
deal with on a day-to-day basis. I beleieve I have given both you and
Manuel and David examples of just what breaks. Should I repeat them?


OTOH, david is making progress up the learning curve: he now proposes
that, when interfaces have multiple addreses, he has to revert to rely
on some ordering (or what I called priority) of addresses. At least,
David's latest proposals (in his message to Manuel) are moving in that
direction.

I have been doing just that myself, privately, for some years now.
My experience is that relying on address-addition order (i.e., ifconfig
order) is a very bad idea: IP addreses can come and go dynamically,
and when they come or go, the *order* of specific addresses changes.

Suppose you have an interface with 4 addreses. One of them is removed
(due to VRRP, or CARP, or manual removal and later re-addition, or
whatever good and sufficent reasons the super-user has at the time).
At that point the order of the 4 addresses in the in-kernel list
changes.  Thus, outbound IP addresses change, and *stay* changed,
until a reboot (or some other process which removes all addresses and
adds them in the desired, admin-intended order).

My experience is also that you can't stop people from making changes
which affect address ordering; and that therefore relying on addreses
is fundamentally not an good solution for a general-purpose OS.


Okay. I acknowlege above that David is making progress in the right
direction.  But I continue to beleive that adding IPv6-derived
``scoping'' to IPv4 is in violation of the clear intent of RFC-1122,
and also in violation of well-established prior art. That's one very,
very big hammer agians the proposal. But combine that idea with a
proposal to hardcode specfic, non-sysadmin-configurable heuristics as
policy, inside the kernel, and you have enough for a reasonable,
knowledgeable person, to decide that David's proposal, as stated, is
out-of-court: no further discussion required.  But I could live with
an optional, explicitly-specified, ordering of which addresses to choose.



OTOH, I am (if its not clear) in favour of adding explicit priority to
IP addresses on interfaces with multiple addresses. But, based on my
own private but extensive experience with doing so, I claim such
priorites *need* to be explicit, not implicit -- either by as-listed
order or via ``scoping'' rules (zeroconf link-local addresses
excluded, should we implement them).

In passing, I note,, that applying the same ``priorities'' to
multi-homed machines with a single address per NIC, will in fact
address Manuel's problem (which you say nothing will fix) as well as Tom's.