>>>>> On Thu, 14 Mar 2002 07:33:54 +0200 (EET),
>>>>> Pekka Savola <[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
> Not in the real world. Who wants an application that can work _only_ with
> IPv6? Nobody. In the real world, sockaddr_storage and friends must be
> used and DNS lookup sections re-written with getaddrinfo and getnameinfo.
Though I admit that I may have oversimplified the description, you
missed the point (or I failed to describe the point well). The point
is, whether using IPv4-mapped addresses for multicast addresses is
worth introducing or not.
Secondly (this is far from the point of the discussion, though), I did
not intend to say we can only consider applications that can work only
with *IPv6*. What I meant was we can only use AF_INET6 sockets to
support *both IPv4 and IPv6* with the usage of mapped addresses
described in the basic API. And, some server side IPv4 applications
can even be ported without sockaddr_storage, getaddrinfo(), or
getnameinfo(). This was also an argument by supporters of mapped
addresses.
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]
--------------------------------------------------------------------
