> [EMAIL PROTECTED] said:
> > >> I don't understand how can flags to getaddrinfo(3) affect source
> > >> address selection. where does it take effect in the following code?
> > >getaddrinfo implementation itself? of course, then libc would have to
> > >aware of src addresses and such..
> >
> > getaddrinfo(3) does not open socket, so getaddrinfo(3) cannot perform
> > [gs]etsockopt.
>
> This is how I understand the motivation behind these flags:
>
> The destination address selection algorithm itself needs to compare each
> destination with its chosen source address. If the application has
> input into the source address selection mechanism via the defined socket
> options, then the application also needs to relay these source address
> preferences to the destination address ordering algorithm so that it can
> obtain accurate source address information for each destination.
The draft tries to explain the reason of extension of AI_PREFER_SRC* flags
in section 4. But it looks like it needs more clarification.
The idea actually came from the "Implementation Considerations" section
of RFC3484 where it explains that two ways getaddrinfo() can sort the
destination addresses before passing them to the apps -- 1) by passing
the dest addr to network layer or kernel and have it sort the destination
addresses on the basis of source addresses available 2) by retrieving the
source address information from the network layer and then sort the
destination address list based on the knowledge of source addresses.
So, in this case, I can think of an example: a node has configured
a TMP address and as well as PUBLIC address on it's interfaces, now
the application does setsockopt() to use TMP address as source address,
but if it does *not* set the AI_PREFER_SRC_TMP flag in the getaddrinfo()
call, getaddrinfo() will return dest-addr corresponding to srcaddr with
PUB, TMP order (following RFC3484 rules).
Hence it was felt that having additional flags in the addrinfo would be
useful for getaddrinfo() to make it's behavior compatible with the
altered source address selection
.
>
> If the destination ordering is implemented in the kernel, then
> getaddrinfo() will need to pass the application's source address
> preferences down with the list of destinations so that the algorithm can
> accurately do its job.
>
> It's still unclear to me if all of the newly defined AI_* flags are
> really needed. Do they each impact the ordering of the addresses in
> cases that make a difference? For example, there is no destination
> address ordering rule that takes temporary source addresses into
> account, so in what case would setting AI_PREFER_SRC_TMP change the
> order of destinations?
It's a good point. There is no specific rule for prefering public over
temporary in the destination address selection rule. But there is a rule
for source address selection on public vs temporary. So, it implies that
if getaddrinfo() may want to sort destination addresses keeping the
source address ordering in mind. Thus if there are different destination
addresses available corresponding to PUB, TMP src addresses, then AI_PREFER_SRC
flags would be useful in that case.
Similarly for Mobile IP usage case, the default destination addr is home-addr,
but if a MN wants to initiate a connection with another MN in foreign network
it can do so by prefering the COA address as source address and setting
AI_PREFER_SRC_COA flag in getaddrinfo() to return the destination address in
COA, HOA order. Same rule applies for CGA and non-CGA cases.
-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]
--------------------------------------------------------------------
