<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 3 May 2021 at 15:42, D. Hugh Redelmeier <<a href="mailto:hugh@mimosa.com">hugh@mimosa.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">| From: Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com" target="_blank">andrew.cagney@gmail.com</a>><br>
<br>
| On Mon, 3 May 2021 at 13:54, D. Hugh Redelmeier <<a href="mailto:hugh@vault.libreswan.fi" target="_blank">hugh@vault.libreswan.fi</a>><br>
| wrote:<br>
| <br>
| > commit 379929c054bbe6022abbc456f5c1fd9bd453470d<br>
<br>
| >     We always accept the first result from getaddrinfo(3).  This may<br>
| >     change prioritization of IPv4 vs IPv6, but at least it matches RFC<br>
| >     3484 (according to the man page).<br>
<br>
| I'm not sure how much we want to trust getaddrinfo() to Do_The_Right_Thing<br>
| here.<br>
<br>
Yeah.<br>
<br>
getaddrinfo(3) says:<br>
<br>
        Normally, the application should try using the addresses in<br>
        the order in which they are returned.  The sorting function<br>
        used within getaddrinfo() is defined in RFC 3484; the order<br>
        can be tweaked for a particular system by editing<br>
        /etc/gai.conf (available since glibc 2.5).<br></blockquote><div><br></div><div>Ah, glibc, so presumably linux.   There's always a weird flavour of the month extension involved.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The RFC itself is obsoleted by rfc 6724 but I don't know if anyone told<br>
getaddrinfo.<br>
<br>
I haven't understood 3484's ordering so I don't know if it does what<br>
we want.  But it does conform to a standard!<br>
<br>
| For instance, given a choice between IPv4 and IPv6 which will it return<br>
| first?  The documentation I'm reading states:<br>
|      By default IPv6 address entries are ordered before IPv4 ones, but the<br>
|      order of the entries in the list can be controlled using ip6addrctl(8).<br></blockquote><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Which documention?  It's not in getaddrinfo(3) on my system.<br></blockquote><div><br></div><div><div>NetBSD: <a href="https://man.netbsd.org/getaddrinfo.3">https://man.netbsd.org/getaddrinfo.3</a></div><div>POSIX: <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html">https://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html</a></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
| yet Pluto, at least for now, wants IPv4 to trump IPv6.  This so that<br>
| existing configs don't magically switch protocols and wanders into into the<br>
| suspect IPv6 tunneling IPv4 code path.<br>
| <br>
| (my best guess at RFC 3484 is that it should prefer IPv4 because<br>
| ::ffff:N.N.N.N will sort earlier, but I'm guessing and no documentation for<br>
| getaddrinfo() even hits at it complying with that RFC?)<br>
<br>
I hope that works out.  I'm too lazy to test until we see a problem.<br>
This seems like something the ipcheck unit testing should check.<br></blockquote><div><br></div><div>I'd rather see code we can rely on.</div><div>And avoid linuxisms.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I don't even know how often pluto resolves without specifyig an AF.<br>
<br>
We actually want both hosts of a connection to use the same AF and both <br>
subnets too.  I don't know how to say "any AF, but the same for these two <br>
domain names".<br>
<br>
As you say, we also want "same as last time we resolved this".  I<br>
would guess that getaddrinfo has a stable ordering so that this is not<br>
a worse problem than we had.<br>
<br>
This topic may deserve more thought.<br>
</blockquote></div></div>