On Thu, 14 Mar 2002, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > >>>>> 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
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. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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] --------------------------------------------------------------------
