From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11464 invoked by alias); 31 Jul 2012 15:01:19 -0000 Received: (qmail 11451 invoked by uid 22791); 31 Jul 2012 15:01:15 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Jul 2012 15:01:03 +0000 From: "psimerda at redhat dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug network/12377] getaddrinfo() should disregard link-local IPv6 addresses for AI_ADDRCONFIG purposes Date: Tue, 31 Jul 2012 15:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: network X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: psimerda at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-07/txt/msg00270.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=3D12377 --- Comment #19 from Pavel =C5=A0imerda 2012-0= 7-31 15:01:01 UTC --- > > > words, if there is no IPv4 connectivity, avoid making "IN A" lookups. > >=20 > > This is exactly what AI_ADDRCONFIG doesn't do. On my system it edits the list of addresses *after* doing any sort of parsi= ng and optional lookup. And AF_UNSPEC with AI_ADDRCONFIG without IPv4 and IPv6 connectivity does not do the same thing to IPv6 addresses as with IPv6 connectivity. I can test this for you when it's fixed. But also *please* document the exa= ct expected behavior and its purpose in the manpage. > On my system, it does exactly this on my system. I don't see any IN A que= ries > sent to the DNS server when I only have 127.0.0.1 configured on my system= , only > IN AAAA. If it was only doing this, I would have *no* objections. > > It breaks various non-DNS cases. >=20 > With that I agree completely. I don't see any good reason to apply > AI_ADDRCONFIG logic in other cases than when using DNS. For what it's wor= th, I > believe that Mac OS X still implements getaddrinfo() only when doing forw= ard > DNS IN A/AAAA lookups (in other words the original RFC 2553 specification= ). I > can try to get that confirmed if you're interested. Then we have a way out. It should be done only for DNS (or for a list of global-address-only methods that would only include DNS for the beginning). > > *None* of my objections was DNS-related. All were about either literal > > addresses, /etc/hosts names or possible link-local NSS plugins. >=20 > Ok - I think we're kind of in agreement, then - perhaps talking about two > different use cases, really. I see AI_ADDRCONFIG as only useful for DNS > ("forward" DNS, i.e. IN A/IN AAAA). However, in that case, it is also *ve= ry* > useful. However, for it to be useful in the IPv4-only host case (which is > presently the most important one, given the amount of defective resolvers > embedded in IPv4-only home gateways that choke on IN AAAA queries), you'l= l also > need to disregard the automatically configured link-local IPv6 addresses = on the > host when deciding whether or not to suppress the IN AAAA query or not, > otherwise you'll pretty much never do it. Then of course yes. You can guess that contacting DNS-resulted IPv6 address= es without a global/site IPv6 address is not necessary. > > That said, if bug 14413 was resolved, you could do this sort of black m= agic > > entirely in nss-dns.so. Without it, it's really hard to implement a > > working implementation of AI_ADDRCONFIG. > >=20 > > Maybe you could just specialcase DNS, it's a hack but certainly not wor= se > > than what we're doing now. >=20 > A hack, perhaps...or simply a return to the good old original RFC 2553 > specification. ;-) It specifies the getaddrinfo(), that's the bug 14413 I mentioned above. If = you strictly follow the spec, you're afaik not ignoring link-local. In this cas= e, the specifications deserves a fix too. I'm already trying to do this with RDNSS: See http://tools.ietf.org/html/draft-gont-6man-slaac-dns-config-issues-00 But, this is orthogonal to the solution of the current problem. --=20 Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are on the CC list for the bug.