Hi Suresh, please see below:
On Tuesday 05 June 2007 23:37, Suresh Krishnan wrote:
> Hi Vidya,
>
> (Cc:ing Julien as well)
>
> Narayanan, Vidya wrote:
> > All,
> > I'm passing along a comment from one of our
> > developers. Sorry, I have not closely read the
> > draft myself. But, if more clarification is
> > needed, I'll be happy to get more information.
> >
> > In section 13, the draft describes a procedure
> > applications should follow in case they require to
> > use the address according to the selection
> > preferences specified (they should not communicate
> > with 'wrong' address and fail). The procedure
> > requires the application to do a 'connect()' in
> > step 3. The application may not even want to
> > connect (may be a TCP application) in case it is
> > not getting a non-preferred address. There should
> > be a procedure described for such applications
> > too.
>
> From what I understood from the draft, the API is
> used for specifying only preferences and not hard
> requirements. This text from Section 1 of the draft
> explains the reasoning.
>
> Specifying hard requirements for address
> selection would be problematic for several reasons.
> The major one is that in the vast majority of cases
> the application would like to be able to communicate
> even if an address with the 'optimal' attributes is
> not available.
>
> The authors can correct me, but I personally don't
> see how it is possible to check this
> deterministically without actually using connect()
> or sendto(). For argument's sake let's assume such a
> solution exists and the application verifies that a
> preferred address exists. What is to say this
> preferred address will not vanish before it is
> actually used (connect or sendto)?
As part of discussion with IESG, we decided to take
care of such TCP applications by defining a new bind
function which binds a socket to the source address
that would get selected to communicate with a given
destination address, according to the preferences
expressed by the application:
int addrselectbind(int s, struct sockaddr *saddr,
const struct sockaddr *daddr,
socklen_t addrlen,
int flag pref);
It is called by passing as argument the socket, a
memory location so that addrselectbind() can store the
source address to which the socket is going to be
bound, the destination address and the application
preferences so that address selection algorithm can
happens.
On return, the application can use the validation
function on the returned source address to make sure
the address that got selected fullfills its
requirements, and prior to sending any data with
sendto() or connect():
short inet6_is_srcaddr(struct sockaddr_in6 *srcaddr,
uint32_t flags);
In case the address vanish before it is used, I think
this is orthogonal to specification of this API: It is
already possible with the usual socket API that an
application binds to an address, then that same
address gets unconfigured before the application
eventually connect() or sendto(). Presumably the
connect() call will fail with EADDRNOTAVAIL (i.e. the
specified address is not available on this
machine), and I'm not so sure if sendto() will fail and
what errno would be appropriate: FreeBSD's sendto()
manpage doesn't mention EADDRNOTAVAIL, only
EHOSTUNREACH...
Best,
--julien
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf