Sorry for not responding earlier..
On Wed, 1 Sep 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:
One really weird case where AI_ADDRCONFIG would be the only solution
is that the host performing getaddrinfo hasn't configured global IPv6
addresses and DNS queries for AAAA resource records cause serious
problem like the ones documented in
draft-ietf-dnsop-misbehavior-against-aaaa-01.txt. However, we
basically think we can only solve this by fixing and upgrading the
broken servers, rather than by an introducing additional hack in the
host implementation.
But from the practical point of view, do you see this happening fast
enough to suit the IPv6 deployment? Remember that we have experienced
the same issue with ECN: it has been PS for 3 years or so, and even
now it hasn't been generally turned on because it causes the users to
see breakage.
So, IMHO it would make sense to think *real* hard whether there are
reasonable ways to work around this particular problem
(draft-ietf-dnsop-ipv6-issues points out a couple of possibilities,
e.g., firing off the queries in parallel or after e.g. 1 sec if there
is no response, etc.)
At least, this issue should not affect the users who don't use IPv6
(IMHO), so a solution like AI_ADDRCONFIG seems to be called for.
If the work around can be a complete solution, even if it's ad-hock, I
agree that it's worth considering. I also tend to agree that your
suggestion of the parallel query plus short timeout can be considered
as this type of work around.
Yep.
My point on AI_ADDRCONFIG was that it cannot be a complete solution to
the AAAA misbehavior issue since it doesn't help in the case where we
have IPv6 connectivity.
It seems like a good solution for the case where you want to deploy
dual-stack -enabled nodes which would not necessarily get IPv6
connectivity (e.g., nodes, which wouldn't activate 6to4, Teredo, or
the like automatically, but just wait for native IPv6).
The good side of using something like AI_ADDRCONFIG would be that the
vendors would be less reluctant to enable IPv6 by default if you
wouldn't even try to look up the v6 records (causing potential
problems) *until* you get v6 connectivity.
Remember, it's of utmost importance to be able to *safely* deploy
*IPv6 capability*, even if that capability would not be used
immediately...
However, AI_ADDRCONFIG would need to be enabled by default (like with
sysctl -- the RFC is unclear with this when it describes something
like "AI_DEFAULT" but doesn't say more on that -- it's not clear
whether that's assumed to be the default setting) for that to work,
because otherwise all the apps would need to be modified which seems
too late now...