Subject: Re: Fwd: I-D ACTION:draft-chakrabarti-ipv6-addrselect-api-05.txt

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 13 Mar 2007 22:20:31 +0200

On Tue, 13 Mar 2007 16:23:23 +0900, JINMEI Tatuya / 神明達哉
<[email-masked]> wrote:
>  I thought I also pointed out
> the available space might not be that large since it's an 'int' field
> (which may be 16-bit long).

Wow... is there any implementation with a 16-bits ai_flags ?

> (The "abuse" aspect of the issue is not resolved even with ai_eflags,
> though, so I'm personally not 100% happy with the current
> specification).
>
> Regarding the example that would be broken by the extension to the
> addrinfo structure, it seems to me artificial and very rare (if it
> ever happens).

LibVLC 0.8.x (backend library to VLC media player) does exactly that in
its getaddrinfo wrapper, for the exact same purpose (i.e. apply
application-specific configurable IP version policy). I've now changed
the code to only allow "known" flags, but I can't fix older releases.

Another common case for wrapping and modifying hints has been the use
 of different protocols (SCTP, DCCP, UDP-Lite...) that are typically
 not accepted by getaddrinfo() implementations. Though to be fair, this
 is most often a single program, so there should be no version mixups.

Did anyone ask for feedback from POSIX people? I think getaddrinfo()
originally comes from there, right?

> It's not surprising that the extension is unfriendly
> with some tricky usage, but IMO the point is whether the benefit of
> the extension outweighs the possible breakages.  I'm actually not
> sure if I have a clear opinion on it; on one had, the breakage
> example given so far looks artificial as I said above (so a concrete
> example of an existing application would be helpful if it exists). 
> On the other hand, I don't see much benefit in this extension either,
> because, as far as I can see, only very few and special type of
> applications want to use it.

I'd personnaly love to have a replacement for getaddrinfo() that allows
optional selection of a source address (with two real extra hostname
and service name parameter) and returns a source address
in the structure. One use case was SSM multicast (where you must
 resolve both source and group address); another case is if the user
 insists on using a specific source address. Currently, I have to make
 two getaddrinfo() calls, and make some loop among both lists (and
 assume that won't break any policy).

That would also solve the IPv6 preference policy, with the added bonus
that you don't have to setsockopt() in addition to getaddrinfo(), and
don't have to do source address selection twice (once in getaddrinfo
 and once in connect).

But I understand that way beyond the scope of this document.

--
Rémi Denis-Courmont
http://www.remlab.net/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Stig Venaas <[email-masked]>
Date: Wed, 14 Mar 2007 19:06:10 -0400

>> addrinfo structure, it seems to me artificial and very rare (if it

I'm not convinced there is sufficient reason to add this new flag
either.
> originally comes from there, right?

AFAIK it was more or less done in parallel. The POSIX spec is almost
the same as the IETF one. It would definitely be good to check with
the Austin Group. AFAIK no one has yet.

>  assume that won't break any policy).

Yes, I've written such code myself using getaddrinfo separately for
the source and the group and then trying to match them. Not fun, but
I'm not in favour of adding new standardised calls for this.

Stig

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Mar 2007 15:24:13 +0100

On 2007-03-13 21:20, Rémi Denis-Courmont wrote:
...
> originally comes from there, right?

The first IETF draft that mentions it is
http://tools.ietf.org/id/draft-ietf-ipngwg-bsd-api-05.txt
which refers to
   [4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
        6.3.  November 1995.

So yes, but I think it was in effect a joint effort.

     Brian