In your previous mail you wrote:
>>>>> On Fri, 21 Mar 2003 00:39:12 +0100,
>>>>> Francis Dupont <[EMAIL PROTECTED]> said:
> A draft has been submitted to address source address selection at
> the per-socket (and per apps) basis. Currently it discusses preferences
> of source address selection by the application for privacy addresses,
> mobileipv6 addresses and Cryptographically generated addresses.
> Thus the application can reverse the sense of default source address
> selection by using the proposed APIs.
> => I have a major concern about the style of the API: it is at the
> socket level ([gs]etsockopt()) when it should be in the context of
> applications:
> - nobody wants to modify every applications in order to use the API
> (an unfortunately many applications can want to toggle one of the
> address selection knobs)
> - at the opposite a global knob is not flexible again.
I tend to agree, but do you have any concrete and feasible suggestion
to implement this?
=> in an UNIX context, I can split the question into three parts:
where to put the information, how to manage it, how to use it.
For the place, there are two big options:
- in user or proc structure, i.e., somewhere in the state of the process,
exactly like user credentials with possible sharing, etc.
- in environment variables, i.e., like RES_OPTIONS for tuning of
the resolver library via the process context.
In the second case, the obvious managing functions are [gs]etenv() but
this makes a textual form of tuning tables and knobs necessary.
In the first case, the best is to add a sysctl() like you already did
for the policy table. An inheritance rule completes this part.
There are two main ways to use the information: inside the kernel (like
the policy table or the proposed [gs]etsockopt()) or inside the standard
library (like the current resolver tuning).
Try first with the policy table (because you have already a good support
for a global one and because it is the main way to tune address selection,
i.e., I already use it on some multi-homed nodes and there are some cases
where I'd like to have a per-application policy).
Thanks
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
