On Fri, 5 Dec 2008, YOSHIFUJI Hideaki / ???? wrote:
quoted text
> I think similar issue(s) have been pointed out several times.
> IPv4-mapped addresses are not portable, unfortunately, anyway, and
> people should use native interface, especially for multicasts.

Yes, there are problems with portability of mapped address usage, but 
that doesn't have to mean that we shouldn't try to make it as useful 
as reasonable.

quoted text
> BTW, do you know what kind of socket option do they use for 
> setting/getting ttl etc?
>
> If we fully support "IPv4-Mapped" function, we should transparently
> configure ipv4-multicast parameters etc. as well.

It does this:

setsockopt(7, SOL_IPV6, IPV6_MULTICAST_HOPS, [1], 4) = 0

In Java MulticastSocket API, if you only specify the port and not 
multicast group, it will bind to "::", and it succeeds.  Afterwards 
Java issues an IPv4 IGMP join:

setsockopt(7, SOL_IP, IP_ADD_MEMBERSHIP, "\351\f\f\f\0\0\0\0\0\0\0\0", 12) = 0

So Java implementation will parse whether the group is IPv4 or IPv6 
multicast -- it isn't using MCAST_JOIN_GROUP API.  It could be argued 
that if it already knows the protocol, it _could_ create IPv4 socket 
from the start, instead of doing this via a mapped v6 socket.

Of course, if Java used the protocol-independent MCAST_JOIN_GROUP etc. 
API, it would not need to even know whether the group was v4 or v6. 
And from that perspective also it would probably make sense to support 
a v4-mapped-address bind().

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html