JINMEI Tatuya / ???? wrote:
At Fri, 10 Aug 2007 13:45:46 +0800,
blue <[EMAIL PROTECTED]> 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.
[EMAIL PROTECTED]
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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
