resolver: don't depend on v4mapped ipv6 to probe routability of v4 addrs
authorRich Felker <dalias@aerifal.cx>
Wed, 11 Jul 2018 19:03:34 +0000 (15:03 -0400)
committerRich Felker <dalias@aerifal.cx>
Wed, 11 Jul 2018 19:03:34 +0000 (15:03 -0400)
commit4f35eb7591031a1e5ef9828f9304361f282f28b9
tree87631061e55eb527b03c66b921119038fa426c80
parentb0d2b3a1e5820271c0f81d4c1fb8972a2f1141f5
resolver: don't depend on v4mapped ipv6 to probe routability of v4 addrs

to produce sorted results roughly corresponding to RFC 3484/6724,
__lookup_name computes routability and choice of source address via
dummy UDP connect operations (which do not produce any packets). since
at the logical level, the properties fed into the sort key are
computed on ipv6 addresses, the code was written to use the v4mapped
ipv6 form of ipv4 addresses and share a common code path for them all.
however, on kernels where ipv6 support has been completely omitted,
this causes ipv4 to appear equally unroutable as ipv6, thereby putting
unreachable ipv6 addresses before ipv4 addresses in the results.

instead, use only ipv4 sockets to compute routability for ipv4
addresses. some gratuitous conversion back and forth is left so that
the logic is not affected by these changes. it may be possible to
simplify the ipv4 case considerably, thereby reducing code size and
complexity.
src/network/lookup_name.c