[Swan-dev] libswan/ttoaddress.c: use getaddrinfo(3) instead of gethostbyname2(3)

Andrew Cagney andrew.cagney at gmail.com
Mon May 3 20:27:02 UTC 2021

On Mon, 3 May 2021 at 15:42, D. Hugh Redelmeier <hugh at mimosa.com> wrote:

> | From: Andrew Cagney <andrew.cagney at gmail.com>
> | On Mon, 3 May 2021 at 13:54, D. Hugh Redelmeier <hugh at vault.libreswan.fi
> >
> | wrote:
> |
> | > commit 379929c054bbe6022abbc456f5c1fd9bd453470d
> | >     We always accept the first result from getaddrinfo(3).  This may
> | >     change prioritization of IPv4 vs IPv6, but at least it matches RFC
> | >     3484 (according to the man page).
> | I'm not sure how much we want to trust getaddrinfo() to
> Do_The_Right_Thing
> | here.
> Yeah.
> getaddrinfo(3) says:
>         Normally, the application should try using the addresses in
>         the order in which they are returned.  The sorting function
>         used within getaddrinfo() is defined in RFC 3484; the order
>         can be tweaked for a particular system by editing
>         /etc/gai.conf (available since glibc 2.5).

Ah, glibc, so presumably linux.   There's always a weird flavour of the
month extension involved.

> The RFC itself is obsoleted by rfc 6724 but I don't know if anyone told
> getaddrinfo.
> I haven't understood 3484's ordering so I don't know if it does what
> we want.  But it does conform to a standard!
> | For instance, given a choice between IPv4 and IPv6 which will it return
> | first?  The documentation I'm reading states:
> |      By default IPv6 address entries are ordered before IPv4 ones, but
> the
> |      order of the entries in the list can be controlled using
> ip6addrctl(8).

> Which documention?  It's not in getaddrinfo(3) on my system.

NetBSD: https://man.netbsd.org/getaddrinfo.3

> | yet Pluto, at least for now, wants IPv4 to trump IPv6.  This so that
> | existing configs don't magically switch protocols and wanders into into
> the
> | suspect IPv6 tunneling IPv4 code path.
> |
> | (my best guess at RFC 3484 is that it should prefer IPv4 because
> | ::ffff:N.N.N.N will sort earlier, but I'm guessing and no documentation
> for
> | getaddrinfo() even hits at it complying with that RFC?)
> I hope that works out.  I'm too lazy to test until we see a problem.
> This seems like something the ipcheck unit testing should check.

I'd rather see code we can rely on.
And avoid linuxisms.

> I don't even know how often pluto resolves without specifyig an AF.
> We actually want both hosts of a connection to use the same AF and both
> subnets too.  I don't know how to say "any AF, but the same for these two
> domain names".
> As you say, we also want "same as last time we resolved this".  I
> would guess that getaddrinfo has a stable ordering so that this is not
> a worse problem than we had.
> This topic may deserve more thought.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20210503/d715203e/attachment.html>

More information about the Swan-dev mailing list