Subject: RE: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 4 Jun 2007 19:16:06 -0700

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.

Thanks,
Vidya

> -----Original Message-----
> From: The IESG [mailto:[email-masked]] 
> Sent: Monday, May 07, 2007 3:41 PM
> To: IETF-Announce
> Subject: Last Call: draft-chakrabarti-ipv6-addrselect-api 
> (IPv6 Socket API for Address Selection) to Informational RFC 
> 
> The IESG has received a request from an individual submitter 
> to consider the following document:
> 
> - 'IPv6 Socket API for Address Selection '
>    <draft-chakrabarti-ipv6-addrselect-api-05.txt> as an 
> Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and 
> solicits final comments on this action.  Please send 
> substantive comments to the [email-masked] mailing lists by 
> 2007-06-04. Exceptionally, comments may be sent to 
> [email-masked] instead. In either case, please retain the 
> beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-chakrabarti-ipv6-add
rselect-api-05.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
w_id&dTag=9992&rfc_flag=0
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 05 Jun 2007 17:37:36 -0400

Hi Vidya,

(Cc:ing Julien as well)

> address. There should be a procedure described for such applications

 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)?

Cheers
Suresh

---

From: Julien Laganier <[email-masked]>
Date: Wed, 6 Jun 2007 16:29:54 +0200

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

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

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 5 Jun 2007 11:44:31 -0700

Hi Vidya,

The following comment has been addressed already as part of Ted
Hardie's comments. A new API will  be provided to select/bind the
preferred source address before connect().

Thanks,
-Samita