unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Robin Tarsiger <rtt@dasyatidae.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: ai_flags in calls to getaddrinfo
Date: Fri, 1 Jan 2021 18:19:16 -0600	[thread overview]
Message-ID: <e66ddd68-97a7-79e4-52a0-5239dd21eee4@dasyatidae.com> (raw)
In-Reply-To: <83sg7kg6vi.fsf@gnu.org>

Eli Zaretskii wrote:
>> I notice that EAI_NODATA isn't mentioned in the Windows docs[1],
> 
> Yes, because Windows has its own codes for socket-related errors.
> Look for WSANO_DATA.  I said "EAI_NODATA" to avoid using Windows
> specific terminology that people might be unfamiliar with.

Ah, I see. In any case it does seem like the same thing.

>>  2. If a program requests a name that exists and has addresses of
>>     some families (such as IPv4 addresses), but the program has
>>     specifically requested another family (such as IPv6)?
> 
> The address returned when AI_V4MAPPED is used is a valid IPv6 address,
> isn't it?  That is, it can be used in IPv6 connections, and will allow
> such connections to work as intended, right?

Basically no; only yes under a very constrained perspective. The socket
mechanism on an OS that supports this compatibility mechanism will do
translation behind the scenes, but that's the extent of it. You should
never see these on the wire, and they are not routable over the IPv6
Internet. If the local host is not running an IPv4 stack, or does not
have an appropriate IPv4 address, they cannot be communicated with from
that host. Any actual IPv6 connectivity on the local host is irrelevant.
They are, in fact, IPv4 addresses in disguise. That's _all_ they are.

Is there a case where an application would ask for the IPv6 family
specifically _without_ caring about the above? Because if it mainly
cares about being able to pass the address into connect(), then it
should just be family-agnostic with a nil FAMILY, and potentially use
locally-available connectivity hints if some mechanism for them is
there, no? (And make-network-process already internalizes the name
lookup.) And if it wants addresses of either family but to specifically
prefer IPv6 addresses if they exist (which is basically what AI_V4MAPPED
does), it can rearrange the list.

>> To put it differently: from my perspective, the main use for AI_V4MAPPED
>> is when there is no IPv4-handling code path at all, and all IPv4 addresses
>> are routed through the "IPv6" path as compatibility-mapped, which can
>> save some complexity and hassle elsewhere.
> > Isn't that the common use case?

Where would you expect to see an IPv6-only code path in an elisp program?
In C, this happens when porting programs out of the IPv4 world, largely
due to type rigidity in C, and then lingers. But in elisp, treating addresses
from families not recognized by the application as opaque is easy, because
of the boxing and dynamic typing; you just don't introspect into them in
the first place. And if the application _does_ want to introspect into them,
then it will want to handle IPv4 addresses by IPv4 standards, at which point
having them represented in native form is better.

(See RFC4038 section 4.2 for a more authoritative description, in the
context of the surrounding section 4 about transition mechanisms.)

Having _both_ v4-mapped addresses and true multi-family address
representation in the same place is the worst of both worlds. Now
you have to handle both families _and_ you have to handle two different
representations for the same IPv4 address. This may not always be
possible to avoid, but we can avoid creating the issue where it didn't
previously exist.

For server sockets it is likely a different trade-off, though even then
I would say that if the Emacs implementation chooses to use a single
"IPv6"-with-dual-stack-underneath socket for C-side simplicity (which
would be reasonable---this in fact would fall into the exact "porting
C code out of the IPv4 world" case), it should then do the detection of
actually-IPv4 addresses and convert them as IPv4 before they hit
the elisp layer. (I haven't checked whether it does this.)

> Lisp programs that want to be so strict will have no problem
> identifying "fake" IPv6 addresses and filtering them out, I think.

This is basically true, but per above it is a needless cost.

>>> On the
>>> system in question, using the patched code and nil as FAMILY in the
>>> network-lookup-address-info yields the expected result, including,
>>> surprisingly, what looks like a valid IPv6 address, even though
>>> specifying 'ipv6 for FAMILY does indeed return a compatibility-hacked
>>> IPv4 address.
>>
>> What happens if you pass nil for FAMILY but without the AI_V4MAPPED
>> patch, on that system?
> 
> I get only an IPv4 address.

Okay, that is interesting. I wonder if the AI_ALL flag on Windows is
overriding some equivalent of AI_ADDRCONFIG, now. I'll see if I can
check this from the C level on my machines too.

Incidentally, distinguishing NXDOMAIN ("name does not exist at all")
from "nothing in any recognized address family" may not be (portably,
reliably) doable with getaddrinfo AFAIK (though the distinction this
would have to the application from the perspective of a "look up
addresses" API is unclear to start with), and distinguishing
"nothing in this address family, maybe-or-maybe-not anything in
others" when an address family _is_ provided may also not be. So
having a warning come from network-lookup-address-info in case of
all successful lookups of nothing is a bit fraught to start with,
but since it is the existing behavior, I think it may be necessary
to look at how existing elisp code uses this function to figure
out what's expected.

The lookup-google test is sort of asking to fail on locked-down
resolver configurations in its current form, too... and I wonder
if lookup-family-specification may want to be separated into
"works for known" and "doesn't work for unknown" and/or use
localhost instead...

-RTT



  reply	other threads:[~2021-01-02  0:19 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-31 15:06 ai_flags in calls to getaddrinfo Eli Zaretskii
2020-12-31 22:40 ` Robin Tarsiger
2021-01-01  7:43   ` Eli Zaretskii
2021-01-01 11:40     ` Robin Tarsiger
2021-01-01 12:04       ` Robin Tarsiger
2021-01-01 12:48       ` Eli Zaretskii
2021-01-02  0:19         ` Robin Tarsiger [this message]
2021-01-03 16:00   ` Eli Zaretskii
2021-01-11 10:47     ` ai_flags in calls to getaddrinfo, broader call for reproducibility check Robin Tarsiger
2021-01-11 12:42       ` Robert Pluim
2021-01-11 15:25       ` Eli Zaretskii
2021-01-11 15:47         ` Robert Pluim
2021-01-11 16:44           ` Eli Zaretskii
2021-01-11 17:07             ` Robin Tarsiger
2021-01-11 17:53               ` Robert Pluim
2021-01-11 18:30                 ` Robin Tarsiger
2021-01-11 18:42                   ` Robert Pluim
2021-01-11 19:28                     ` Stefan Monnier
2021-01-11 20:12                       ` Robert Pluim
2021-01-11 20:41                         ` Eli Zaretskii
2021-01-11 20:55                           ` Stefan Monnier
2021-01-11 21:02                           ` Robert Pluim
2021-01-11 21:09                             ` Lars Ingebrigtsen
2021-01-11 21:15                               ` Robert Pluim
2021-01-11 22:42                                 ` Lars Ingebrigtsen
2021-01-12  9:40                                   ` Robert Pluim
2021-01-12 12:49                                     ` Lars Ingebrigtsen
2021-01-12 13:04                                       ` Robert Pluim
2021-01-12 14:08                                         ` Lars Ingebrigtsen
2021-01-12 14:29                                           ` Robert Pluim
2021-01-12 18:06                                             ` Lars Ingebrigtsen
2021-01-12 15:14                                       ` Stefan Monnier
2021-01-12 15:45                                         ` Eli Zaretskii
2021-01-12  3:29                             ` Eli Zaretskii
2021-01-11 20:46                 ` Eli Zaretskii
2021-01-11 20:56                   ` Robert Pluim
2021-01-12 15:01                     ` Eli Zaretskii
2021-01-12 15:36                       ` Robert Pluim
2021-01-12 15:42                       ` Eli Zaretskii
2021-01-12 16:00                         ` Robert Pluim
2021-01-12 16:05                           ` Eli Zaretskii
2021-01-12 17:56                             ` Robert Pluim
2021-01-11 19:32           ` Basil L. Contovounesios
2021-01-11 20:19             ` Robert Pluim
2021-01-11 23:57           ` Andy Moreton
2021-01-12  9:44             ` Robert Pluim
2021-01-12 11:56               ` tomas
2021-01-01 10:59 ` ai_flags in calls to getaddrinfo Lars Ingebrigtsen
2021-01-01 12:50   ` Eli Zaretskii
2021-01-02  5:40     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e66ddd68-97a7-79e4-52a0-5239dd21eee4@dasyatidae.com \
    --to=rtt@dasyatidae.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).