On Mon, 3 May 2021 at 15:42, D. Hugh Redelmeier <[email protected]> wrote:
> | From: Andrew Cagney <[email protected]> > > | On Mon, 3 May 2021 at 13:54, D. Hugh Redelmeier <[email protected] > > > | 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. >
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
