Re: glibc's getaddrinfo() sort order
Kurt Roeckx wrote:
Hi,
I'm not agreeing with the glibc maintainer(s) about wether getaddrinfo()
should sort the results or not. I think the current way it sorts things
does not work at all in IPv4, and I think it hurts more than it does
good.
Reading again the RFC 3484, I've some doubt on understanding the
exact problem and our discussion.
The title of document is:
"Default Address Selection for Internet Protocol version 6 (IPv6)"
Abstract
This document describes two algorithms, for source address selection
and for destination address selection. The algorithms specify
default behavior for all Internet Protocol version 6 (IPv6)
implementations. They do not override choices made by applications
or upper-layer protocols, nor do they preclude the development of
more advanced mechanisms for address selection.
The two algorithms
share a common context, including an optional mechanism for allowing
administrators to provide policy that can override the default
behavior. In dual stack implementations, the destination address
selection algorithm can consider both IPv4 and IPv6 addresses -
depending on the available source addresses, the algorithm might
prefer IPv6 addresses over IPv4 addresses, or vice-versa.
All IPv6 nodes, including both hosts and routers, must implement
default address selection as defined in this specification.
So it seems that RFC 3484 should be applied only to IPv6.
Using it for IPv4 (or mixing IPv4 and IPv6) is optional, so not
applying rule 9 for IPv4 is allowed by the RFC and thus
there is not interoperability problems.
BTW there is no need for the IPv4 part of:
> 3. We recommend to the IETF that RFC3484 s6 rule 9 should be
> abolished, definitely for IPv4, and probably for IPv6 too.
FYI there is some corrections for destination selection for IPv6
on the ietf site (unfortunately I forget the links on an extensive
research about RFC 3484 and IPv4)
ciao
cate
Reply to: