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

Andrew Cagney andrew.cagney at gmail.com
Mon May 3 23:46:54 UTC 2021


FYI,
https://testing.libreswan.org/v4.4-73-g379929c054-main/ikev2-ddns-03/OUTPUT/west.console.diff

On Mon, 3 May 2021 at 16:27, Andrew Cagney <andrew.cagney at gmail.com> wrote:

>
>
> 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
> POSIX:
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html
>
>
>> | 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/4631864a/attachment.html>


More information about the Swan-dev mailing list