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 <[email protected]> wrote: > > > 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
