From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2026 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Request for reports on ipv6 issues Date: Sun, 30 Sep 2012 15:05:46 -0400 Message-ID: <20120930190545.GM254@brightrain.aerifal.cx> References: <20120930165718.GA3043@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1349032468 1840 80.91.229.3 (30 Sep 2012 19:14:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Sep 2012 19:14:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2027-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 30 21:14:33 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TIOyH-0005My-7K for gllmg-musl@plane.gmane.org; Sun, 30 Sep 2012 21:14:33 +0200 Original-Received: (qmail 1457 invoked by uid 550); 30 Sep 2012 19:14:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1449 invoked from network); 30 Sep 2012 19:14:26 -0000 Content-Disposition: inline In-Reply-To: <20120930165718.GA3043@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2026 Archived-At: On Sun, Sep 30, 2012 at 12:57:18PM -0400, Rich Felker wrote: > One area I've been meaning to address for a while is the quality and > completeness of ipv6 support in musl. I've never used ipv6 seriously > so while I can read the specification for how the interfaces are > supposed to behave, I don't have any good intuition beyond that. > > I know AI_ADDRCONF is not supported, and should be. I also know glibc > has experienced a lot of bugs with it not behaving as expected, so > this one probably requires some attention to the details. The concept of having an "address configured" seems to be poorly defined. So far, the approach that seems ideal to me is, when AI_ADDRCONFIG is specified, attempting to connect a datagram socket to each candidate address. This will not generate any network traffic, and will succeed if and only if the kernel thinks there's a route. This approach also allows us to obtain the source address that would be used to make a connection, so that the semantics of RFC 3484 could be implemented if desired. However, I'd rather not go there unless a need is demonstrated. It may be possible (albeit a stretch) to claim the current behavior (igoring AI_ADDRCONFIG entirely) is conformant when used on Linux systems in the default configuration, since the loopback interface by default has IPv4 and IPv6 addresses configured. Whether this behavior suffices to make applications happy, I have no idea. > Apparently ipv6 has some sort of "scope" which I don't understand, and > which I don't think we handle now. Link local addresses, etc., are only valid in the context of a particular scope id. For link-local, that id is the interface number. This explains why POSIX standardized the otherwise-apparently-useless if_nametoindex and if_indextoname functions: to fill in the scope id of ipv6 link-local addresses. Rich