Hello,

Some random comments:

The proposed API adds a new IPv6-level socket option
(IPV6_ADDRESS_PREFERENCES). IMHO, it ought to
also specify that this can also be used as a "non-sticky" option through
sendmsg() ancilliarry data, like other IPv6 options found in the
advanced IPv6 API.

It might be nicer to have the SA/SB DA/DB example for getaddrinfo() in a
subsection of its own mentionning that it is an example. The struct
definition should probably be moved into an appendix as an example
implementation detail. Similarly, the actual specification part of that
chapter deserves to be separated from introductory text and example.

The example getaddrinfo() is flawed. DO NOT let this flow into an RFC...
freeaddrinfo() must be applied to the pointer returned by getaddrinfo(),
i.e. the pointer to the first struct addrinfo in the linked list. Your
code is essentially equivalent to freeaddrinfo(NULL) !

Please specify the interaction between AI_PREFERENCES and AI_PASSIVE -
the current spec seems to assume AI_PASSIVE is not set.

More seriously, there are some design flaws in the proposed
getaddrinfo() extensions:

For a start, there is a race condition if the locally available
addresses or the routing table change between the getaddrinfo()
invocation and connect() calls, we may get unwanted results. Maybe a
solution would be to return ai_bindaddr and ai_connaddr instead of just
ai_addr.

Also, extending the byte size of an already existing structure might
pose some problem: imagine an application initializes a "hint" struct
addrinfo, and passes it to a library API that would tweak it depending
on some configuration or whatever, then the application would use the
same hint as a parameter to getaddrinfo(). Now what if the application
was built with the old-style struct addrinfo without the ai_eflags, but
the library uses it? we risk a buffer overflow there.

IMHO, it might be wiser to define extended getaddrinfo, freeaddrinfo and
struct addrinfo variants (geteaddrinfo ?) - that woud allow to use the
ai_bindaddr and ai_connaddr thing at the same time.

Regards,

-- 
Rémi Denis-Courmont,
looking for a job
http://www.simphalempin.com/home/infos/CV-en.pdf

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------