On Wed, 13 Mar 2002, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > >>>>> On Mon, 11 Mar 2002 14:32:31 -0600 (CST), > >>>>> Lilian Fernandes <[EMAIL PROTECTED]> said: > > > The advanced API does not address this yet....is there any way at all to > > currently join an IPv4 multicast group on an AF_INET6 socket? > > There's no such a *standardized* way, as far as I know.
This is correct and the lack of a standard for dealing with it is the problem. But as has been noted through practical experience by some, it would be extremely convenient if it were. A goal of the APIs was to make simpler the transition to IPv6 for existing programs. That seems to have worked for the unicast case but the lack of a similar standard works against multicast programmers. > > Or do applications need to open a separate AF_INET socket to join v4 > > groups? > > If you want portability, I believe the answer is yes. > > I'm even not sure if we really should allow the usage of > IPv4-mapped-multicast. We had a very heated discussion even for > unicast addresses, and we were almost not able to reach consensus. At > that time, one of main arguments to support the usage of IPv4-mapped > addresses was existing implementations and easy-porting of > widely-deployed unicast IPv4 applications. I don't believe the > argument buys that much for multicast addresses/applications. And I would suggest that the same arguments still apply to multicast addresses as well. Otherwise this topic would not keep reappearing. If as you say, the arguments don't buy much for multicast addresses/applications then wouldn't those same arguments also not buy much for unicast addresses? I think many programmers would agree that the API makes it relatively simple to enable IPv6 in their existing unicast applications. So I'm having a difficult time understanding why such arguments would inherently not apply to multicast as well or why multicast should be treated noticeably differently than unicast in the API. > In any case, I don't think the advanced API is a suitable place to > define such a stuff. Since the basic API defines both IPV6_JOIN_GROUP > and the usage of IPv4-mapped(-unicast) addresses, the appropriate > document would also be the basic API spec, *if we'd ever need to > standardize that*. We should not use the advanced API as a kitchen > sink for arbitrary extensions. I agree. However, when I proposed wording to include a provision for this in the updated basic API, I think it unfortunately came a little too late. So someone then suggested that this be handled in the advanced API instead. If you're suggesting that's no longer a good place for this then do you have an alternative suggestion? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
