From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robin Tarsiger Newsgroups: gmane.emacs.devel Subject: Re: ai_flags in calls to getaddrinfo Date: Fri, 1 Jan 2021 18:19:16 -0600 Message-ID: References: <83sg7mggls.fsf@gnu.org> <838s9dgkzt.fsf@gnu.org> <05b7ddd3-2a37-8ae6-31b8-07e212538595@dasyatidae.com> <83sg7kg6vi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="974"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 02 01:20:08 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kvUeN-000AaW-GY for ged-emacs-devel@m.gmane-mx.org; Sat, 02 Jan 2021 01:20:07 +0100 Original-Received: from localhost ([::1]:53022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvUeM-0002qf-Az for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 19:20:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvUdd-0002Pl-Ji for emacs-devel@gnu.org; Fri, 01 Jan 2021 19:19:21 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:39837) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvUda-0007mX-IY; Fri, 01 Jan 2021 19:19:21 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8F6875C0041; Fri, 1 Jan 2021 19:19:16 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 01 Jan 2021 19:19:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=pF+y83Xp+x8ifYqDmQLOaNpLEr/Q2uqwJ6Pzx6o+K rs=; b=rH4kDha0Mdq1YJoENgrUyhU2Hdnp+D6azSPNmIprFanUQsmAOCAqbXqtu YQWwGSo2dnimj7Pr6EWPDv1coMiJ4EZIRL3/DOoDgQuSEVOJO10F9W90TINDr6l0 y37i7uc3MftpYq9c39UGSa6FdwBk7bZEjo9opQKHb1LkGXCdh1jEhX0VSTu1jylB cKYuiHueLo0Py+wIh0kpQeRWJkadpnDzdvELv9xCSybkcJGdRHCFx9QEjRWSlJrR Ak75M3HK5WsYxtW5XohxXvjfZT0pjgm61EB8mC+6q12/X+ucMf83shGSoToc4iVN 1We896IfVz7r5OFKU8uIJjHW2bTwQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddvkedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepvfhfhffukffffgggjggtgfesthekredttdefjeenucfhrhhomheptfhosghi nhcuvfgrrhhsihhgvghruceorhhtthesuggrshihrghtihgurggvrdgtohhmqeenucggtf frrghtthgvrhhnpedvudfggeffieegkeeuueefvdekffekheevvddtgeevledthefhkeef fefgkefgkeenucfkphepjeeirddvheefrdejhedrfeegnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomheprhhtthesuggrshihrghtihgurggvrdgt ohhm X-ME-Proxy: Original-Received: from [192.168.1.65] (76-253-75-34.lightspeed.austtx.sbcglobal.net [76.253.75.34]) by mail.messagingengine.com (Postfix) with ESMTPA id 07F9E1080059; Fri, 1 Jan 2021 19:19:15 -0500 (EST) In-Reply-To: <83sg7kg6vi.fsf@gnu.org> Content-Language: en-US-large Received-SPF: none client-ip=66.111.4.28; envelope-from=rtt@dasyatidae.com; helo=out4-smtp.messagingengine.com X-Spam_score_int: -52 X-Spam_score: -5.3 X-Spam_bar: ----- X-Spam_report: (-5.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-2.749, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262275 Archived-At: 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