> 1.  Introduction
> 
>    Currently IPv6 socket API extensions does not provide a
>    mechanism to choose a particular source address other than simple
>    bind() operation.
> 
> This is not really true.  We can also specify the source address by
> the IPV6_PKTINFO socket option or ancillary data item defined the
> advanced API.  This does not matter much, though, because we still
> need to specify a particular source address.
> 

Point noted. The text in the draft was written in the context of basic socket
 api in mind, hence it only refers to bind(). 
 
>    Furthermore, the approach is to define two flags for each purpose, 
>    so that an application can specify either that it prefers 'X' or
>    prefers 'not X', or it can choose not to set either of the flags
>    relating to 'X' and leave it up to the system default, perhaps while 
>    specifing its preferences for some other attribute of the source
>    addresses.
> 
> Hmm, I'm not sure if this is really possible with the API described...
> later the draft says (in Section 3):
> 

Please see the comment below. 

>     The flags defined in this document are:
> 
>     IPV6_PREFER_SRC_HOME
>     IPV6_PREFER_SRC_COA
>     IPV6_PREFER_SRC_TMP
>     IPV6_PREFER_SRC_PUBLIC
>     IPV6_PREFER_SRC_CGA
>     IPV6_PREFER_SRC_NONCGA
> (...)
>     .... If the option is not set, the system selects
>     a default value. Setting conflicting flags at the same time results
>     in the error EINVAL.
> 
> I read this to mean unless IPV6_SRC_PREFERENCES is explicitly
> specified, the kernel will choose the default values for all the
> parameters. 

If IPV6_SRC_PREFERENCES is not specified then the source addresses
are chosen by the system. Assuming that the system implements RFC3484
(default addr selection ), it will choose the appropriate source
address as per address selection rules. Intent of this draft is to
alter the knob of source address selection from the system level
to per socket level. 

> If my understanding is correct, how can I specify a
> preference for HOME vs COA but keep the default for TMP vs PUBLIC?

Not sure exactly what you are looking for, but I try to explain here.

It only applies to a per-socket basis. So, while one socket in an app
sets its SRC preference to COA and sends outgoing packet with srcaddr=COA,
other socket in same or different application can choose to setsockopt(s,
IPV6_SRC_PREFERNCE, &flags, ...) where flag indicates IPV6_PREFER_SRC_TMP
and packets sent through that socket use TMP addr as source address. 
At the sametime, a third application which does not set IPV6_SRC_PREFERNCES,
sends packet with a source address determined by the kernel by following
generic systemwide source address selection rules. 

Thus there is no concept of default parameter value of each type of addresses
here, by 'default' , the draft means the value chosen by the kernel. We can
clarify that if that is not quite clear in the draft.

> Am I supposed to unset both IPV6_PREFER_SRC_TMP and
> IPV6_PREFER_SRC_PUBLIC?  But isn't it a conflicting configuration
> since these two are exclusive flags?
> 

No. one does not need to unset all other flags in order to set  one
specific flag.  But, I suppose (not specified yet) one can set a combination
of flags if it makes sense (i,e. IPV6_PREFER_SRC_PUBLIC| IPV6_PREFER_SRC_COA),
if the COA has both temporary and public addresses. Although, it does not make
too much sense to me, other than it makes things complex; but it is an 
implementation option.

> The current specification is at least unclear to me on this, and
> perhaps even contradicts itself.  We could clarify this point, but I'm
> afraid the result would be complicated and unintuitive...
> 
> 5. IPv4-Mapped IPv6 Addresses
> 
>    IPv4-Mapped IPv6 addresses are not supported for setting preference
>    on home, care-of-address, CGA, non-CGA, public or privacy auto-
>    configured addresses as source addresses.
> 
> "privacy auto-configured addresses" should just be "temporary
> addresses" to be consistent with the rest of this draft.

Ok. There has been some comments on the list about restriction on supporting
IPv4-mapped addresses. 

Thanks for your comments.

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

Reply via email to