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