[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt
Hello.
In article <Pine.LNX.4.53.0309151105180.18225@giskard.ing.unife.it> (at Mon, 15 Sep 2003 11:52:06 +0200 (CEST)), Mauro Tortonesi <mtortonesi@ing.unife.it> says:
> to support AI_ADDRCONFIG, USAGI project's libinet6 simply checks if the
> system supports ipv4 or ipv6 by trying to create an AF_INET or AF_INET6
> datagram socket. this is wrong, IMVHO, as the resolver should test for
> ipv4 or ipv6 connectivity (e.g. by looking at the routing table) and not
> for ipv4 or ipv6 support in the stack.
We never look into routing table, but addresses.
Well, the method to check non-link-local addresses are
available may be wrong.
I evetually chenge it to try to explore whole addresses
on the node using rtnetlink ("routing socket" in BSD term).
> i don't know what's kame behaviour, but from what i've seen in:
>
> http://orange.kame.net/dev/cvsweb.cgi/kame/kame/lib/libinet6/Attic/getaddrinfo.c?rev=1.2
>
> it seems the KAME project's libinet6 does not support AI_ADDRCONFIG.
> itojun, am i wrong?
KAME supports AI_ADDRCONFIG (and USAGI's idea is from KAME's here).
http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/libinet6/getaddrinfo.c
BTW, I'm not against IPv4-mapped addresses. :-)
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA