From owner-freebsd-net@FreeBSD.ORG Fri Aug 10 12:59:36 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 707F116A420 for ; Fri, 10 Aug 2007 12:59:36 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id A45D013C46A for ; Fri, 10 Aug 2007 12:59:34 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id WAA04625; Fri, 10 Aug 2007 22:59:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 10 Aug 2007 22:59:11 +1000 (EST) From: Ian Smith To: blue In-Reply-To: <46BC2811.7020807@zyxel.com.tw> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Max Laier , JINMEI Tatuya , freebsd-net@freebsd.org Subject: Re: A and AAAA DNS query process in getaddrinfo()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2007 12:59:36 -0000 On Fri, 10 Aug 2007, blue wrote: > JINMEI Tatuya / ???? wrote: > > >At Fri, 10 Aug 2007 13:45:46 +0800, > >blue wrote: > > > > > > > >>Although DNS resolver may lead to some delay or misbehavior of the upper > >>application, I think that would be caller's resposibility to decide > >>which result it would like to use. I am not so sure about the check in > >>KAME implementation, in getaddrinfo.c: > >> > >> > > > >(snip) > > > > > > > >>Why the check for avilable IPv4/IPv6 address, addrconfig(), only applies > >>when the hints' family type is AF_UNSPEC? I think if delaying the upper > >>application is a concern, the check should be applied no matter what > >>family type it is. > >> > >> > > > >I thought the v6fix document provided sufficient background to answer > >these questions, but in case it didn't I'm going to rephrase the > >points: > > > >- ideally, we'd not want to introduce the special behavior; as you > > indicated above, the ideal behavior for getaddrinfo() called with > > AF_UNSPEC would be to return all possible IPv4 and IPv6 addresses > > via A and AAAA queries. > >- unfortunately, however, a dual stack application running on > > IPv4-only node could suffer from various problems due to misbehaving > > DNS servers if the underlying resolver sends out AAAA queries. Note > > that the most typical behavior for such dual stack applications is > > to call getaddrinfo() with AF_UNSPEC. > >- the specific behavior of the KAME-snap version of getaddrinfo() is a > > workaround to mitigate the problem in the conflicting situation, yet > > still being compliant to the API specification. > >- since this is a workaround, we'd not want to do the same ugly hack > > for the less common case of getaddrinfo() called with AF_INET6. > > Also, in this case the node without an effective IPv6 address would > > not be able to make any IPv6 communication regardless of the > > getaddrinfo() results or how long it takes, and the application > > doesn't have any alternative network protocol unlike the case of > > AF_UNSPEC, so introducing the same hack doesn't actually help the > > application. > >- so, comparison between the AF_UNSPEC case and the AF_INET6/AF_INET > > case in terms of superficial consistency doesn't really make sense. > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > > > > Dear Jinmei: > > Thanks for your detailed explanation, and I have a deeper insight into > the problem that IPv4/IPv6 dual stack may introduce to current applications. > > Best regards, > > Yi-Wen Perhaps in some ways relevant to this discussion is a new (Aug 1) article by Geoff Huston, mentioning AAAA / A query order issues: http://www.circleid.com/posts/transition_to_ipv6_address/ Cheers, Ian