>>>>> On Wed, 13 Mar 2002 08:15:14 -1000 (HST),
>>>>> Antonio Querubin <[EMAIL PROTECTED]> said:
> 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 the unicast case, porting existing IPv4 applications (essentially)
only needs some keyword replacements, such as
s/AF_INET/AF_INET6/g
s/sockaddr_in/sockaddr_in6/g
In the multicast case, however, we'll also need to change semantical
part of the existing application. For example: ip_mreq (for IPv4)
takes in_addr to specify an interface while ipv6_mreq (for IPv6) takes
an interface identifier. Thus, we'll (sometimes) need to change
the syntax and/or semantics of command line arguments. This also
means we need to introduce if_nametoindex() when porting.
It also seems to me that people emphasize the useful part of mapped
addresses tend to forget why some other people made objections to them
in the old discussions about the unicast case; mapped addresses
introduce additional complexity for address matching and access
control, and the complexity can be a security hole.
In my understanding, one of the reasons why we still go with mapped
addresses in the unicast discussion was because there were already
many existing (unicast) applications that relied on the usage of
mapped addresses and because we could not ignore them. The situation
is different in this case; we do not even have an official document
that describes the usage of mapped-multicast addresses. So, in this
case, we can/should concentrate on all the pros and cons. If the
consensus is still for the usage of mapped addresses, I'll follow the
result.
BTW: I recall an old discussion about a protocol independent API for
multicast applications that Dave Thaler (@Microsoft) proposed -if my
memory is correct-. I'd rather prefer this approach.
>> 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?
As Tim pointed out, we'll go to an API community such as POSIX, or, if
we still do some work in this group, we'll need a separate document.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
