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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf