Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API

From: Samita Chakrabarti <[email-masked]>
Date: Sun, 23 Mar 2003 22:57:21 -0800 (PST)

> 
>    and it can also satisfy per process behavior.
>    
> => this is not true: I don't want to patch and recompile all applications.
> My concern is you provide a device then look for its usage, I prefer to
> get requirements and only after look for ways to satify them.
> 

I assume these socket options would be applicable more for new type of 
applications. But I don't see a problem in updating existing application with 
new socket option and recompile them, if the application wants to serve special
cases. For example, it's not surprizing that common network application 
be modified for running on mobile devices. 

Also, per-socket control is more desirable than just per-process control, as 
one application may choose to set different source address for different
set of sockets. I don't think threading (as you mentioned before)  is a good
 alternative to that.

>    > There is no equivalent in destination rules to SR7, so AI_XXXX_TMP & co
>    > are useless (this is in fact obvious :-).
>    
>    Yes, SR7 does not have a corresponding DR?. But getaddrinfo() is supposed
>    to sort the destination addresses keeping source address selection rules
>    (in this case, its SR7) in mind. Hence the AI_PREFER_SRC_* flags make sense
>     for TMP and PUBLIC.
>    
> => if there are for each prefix a TMP and a PUBLIC addresses AI_PREFER_SRC_TMP
> & co are strictly useless so are candidate for a garbage collection when
> we'll run out of bits in ai_flag...

I am not sure I understand your point here. I understand that ai_flag bits are
limited. But if there are multiple prefixes with TMP address  and 
AI_PREFER_SRC_TMP is set, TMP addresses will be preferred. I assume that TMP
addresses will be sorted among themselves as per other src address selection
 rules. 

Thanks, 
 -Samita

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Mar 2003 18:57:48 +0100

I assume these socket options would be applicable more for new type of 
   applications. But I don't see a problem in updating existing
   application with new socket option and recompile them, if the
   application wants to serve special cases. For example, it's not
   surprizing that common network application be modified for running
   on mobile devices.
   
=> Oops, I believe the purpose of your draft is to help Mobile IPv6
deployment... (:-)

   Also, per-socket control is more desirable than just per-process
   control, as one application may choose to set different source
   address for different set of sockets.

=> what I propose is not pure per-process control, it is to put the
control in the context of processes. It gives immediatly a per-process
control but with a way to manage the context from applications, it gives
a per-socket control too.

    I don't think threading (as you mentioned before) is a good
    alternative to that.
   
=> first I didn't introduce threading in this discussion, second IMHO
you haven't understand my answer about how to implement though-the-context
control with threads.   
       
   > we'll run out of bits in ai_flag...
   
   I am not sure I understand your point here.

=> easy, if you have in each prefix a public address and some temporary
addresses the flags don't affect the source prefix choice.

Thanks

[email-masked]

---

From: Julien Laganier <[email-masked]>
Date: Mon, 24 Mar 2003 20:00:28 +0100

Francis Dupont wrote:
>    > => this is not true: I don't want to patch and recompile all
>    > applications. My concern is you provide a device then look for its
>    > usage, I prefer to get requirements and only after look for ways to
>    > satify them.
>

Though it may be with me with to be able to control this stuff through a 
process structure, I cannot find how your two points above are related to the 
goal of that draft which is to help IPv6 deployment. It does not necessarily 
conflict with your proposition, as it may not be the single _one_ means to 
tweak address selection. Some type applications may require frequent usage of 
this sort of tweaking, and it may be boring and not portability-proof to ask 
devellopers to manage themself these things through sysctl or whatever. The 
goal of that API is to provide a simple way to manage socket level 
preference. There is already IPV6_PKT_INFO that allows to manipulate address 
things, and these options just allows a more loose-grained control over that. 
Your idea may be a good proposal too and I cannot see why they would be 
exclusive.

>    > => if there are for each prefix a TMP and a PUBLIC addresses
>    > AI_PREFER_SRC_TMP & co are strictly useless so are candidate for a
>    > garbage collection when we'll run out of bits in ai_flag...
>

Yes, but there are situations when one does not want to have such a 
configuration.

Thanks,

--julien

---

From: Francis Dupont <[email-masked]>
Date: Mon, 24 Mar 2003 22:46:10 +0100

The goal of that API is to provide a simple way to manage socket level 
   preference.

=> my concern is your goal is to fulfill a requirement from developpers
than my goal is to fulfill a similar requirement from users. As there
are far more users than developpers and as developpers are users too and
as my proposal works for both users and developpers, I consider you are
just solving the wrong problem...

   There is already IPV6_PKT_INFO that allows to manipulate address 
   things, and these options just allows a more loose-grained control
   over that.

=> I don't believe that IPV6_PKT_INFO is a good example of a developper
friendly device (:-).

=> they are not exclusive but we should work first on the most flexible/
general one. And before ask users about what they'd like to get.
As an user my immediate needs are:
 - a policy table in the context
 - a global flag to choose the largest scope
 - nothing about home/care-of or temporary/public as I don't use
   these features.
Today I have (in recent KAME codes) only a global policy table which
is not enough on multi-user boxes.

Thanks

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Mar 2003 13:17:33 +0100 (CET)

> a per-socket control too.

Francis,

I didn't understand how the per-process context also
gives you per-socket control. Are you considering having
setsockopts in addition to per-process context controls?
Or are you arguing that the setsockopt type of control
is not necessary?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Mar 2003 21:12:24 +0100

I didn't understand how the per-process context also
   gives you per-socket control.

=> this is like playing with UIDs, which are in the context of the application
and can be set by set[e]uid() & co, to permit or deny access to privileged
ports. My idea is to tune the context before performing some operations
and to reset it after to its previous setup.

   Are you considering having
   setsockopts in addition to per-process context controls?

=> we can get both or even implement the per-process context via
setsockopts.

=> they are not necessary when a more general/flexible type
of control is available and I argue this is the case for
the process context stuff.

Thanks

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 Mar 2003 09:52:02 +0100 (CET)

> => this is like playing with UIDs, which are in the context of the
> application and can be set by set[e]uid() & co, to permit or deny access to
> privileged ports. My idea is to tune the context before performing some
> operations and to reset it after to its previous setup.

While the semantics of such an approach is well-documented and
understood in the uid space, I think it is hard to introduce new such
mechanisms due to the side effect dangers.
Assume you introduce env/context source address selection knobs
and that both getaddrinfo() and connect()/sendto() will use them.
First problem that appears is that internal to getaddrinfo() sockets might
be connected (e.g. to connect to a DNS server, LDAP, whatever else).
It is hard to guage the possible impact of such side effects, but I think
they in general make the system much harder to understand. (Yes, they
are a form of global variables and I think passing explicit arguments
results in less complexity that using global context.)

   Erik