From owner-freebsd-net@FreeBSD.ORG Fri Aug 10 08:55:31 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 3271816A418 for ; Fri, 10 Aug 2007 08:55:31 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id CBD1A13C46A for ; Fri, 10 Aug 2007 08:55:30 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 16:55:29 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 16:55:29 +0800 Received: from [172.23.17.155] ([172.23.17.155]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 16:55:28 +0800 Message-ID: <46BC2811.7020807@zyxel.com.tw> Date: Fri, 10 Aug 2007 16:55:45 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <46BBE0E9.1070707@zyxel.com.tw> <200708100648.51663.max@love2party.net> <46BBFB8A.1080509@zyxel.com.tw> In-Reply-To: X-OriginalArrivalTime: 10 Aug 2007 08:55:28.0898 (UTC) FILETIME=[334B8620:01C7DB2C] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Max Laier , blue , 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 08:55:31 -0000 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