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

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 21 Mar 2003 16:29:43 -0800 (PST)

>    context. How do you handle the case of an application which have several 
>    threads of execution trying to modify a single context in a
>    contradictory way (e.g. TMP vs PUB, etc.) ?
>    
> => this is an implementation problem: there are a lot of possible
> solutions: use a lock, use a context per thread, etc.
> 

As Erik explained before, having per-socket knob provides better control
on the implementation pieces and it can also satisfy per process behavior.

> PS: about RFC 3484 tuning :
>  - the policy table (I use it for global tuning on KAME: it works well)
>  - SR2: lower/greater scope (already noticed but not yet in the document)
>  - SR4: home/care-of (already in the document)
>  - SR5: outgoing interface (already noticed, not yet in the document,
>    no proposed wording?)
>  - SR7: temporary/public (already in the document)
>  - SR8: longest matching prefix (IMHO it is covered by the policy table)
>  - DR4: indirect home/care-of
>  - DR7: native/tunnel (something is needed here, perhaps through
>    the interface stuff, aka SR5)
>  - DR8: lower/greater scope (same than SR2)
>  - DR9: longest matching prefix (same than SR8)

This is quite useful! Thanks a lot for the details.

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

> I remember there are concerns about the longest matching prefix on
> more than 64 bits, perhaps we need something here too, even I don't
> like the idea to fix/extend the RFC 3484 by an API (cf CGAs :-).

Does anyone else have any comments on this item ?

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: Sat, 22 Mar 2003 22:40:32 +0100

In your previous mail you wrote:

   As Erik explained before, having per-socket knob provides better control
   on the implementation pieces

=> no, it gives the same kind of control, and only in modified pieces
of code.

   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.

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

Thanks

[email-masked]