In your previous mail you wrote: Forgive me if this has been discussed already, but should applications be able to use v4 mapped multicast addresses the same way they use v6 multicast addresses? => this was never specified in API specs but perhaps it is not very reasonable because multicast APIs are too different (no scope in IPv4 for instance). I have been working under the assumption that draft-ietf-ipngwg-rfc2553bis-00.txt intends just this, => obviously it is not the case for everybody. but there is at least one popular implementation that doesnt support this (yet). => in the scope ID usage for multicast discussion one suggested to retrofit IPv6 multicast API goodies into the IPv4 multicast API. I have no strong opinion about this (it is a good idea if it is easy to implement *and* to explain to common programmers) but we have the IPv4 multicast API designer in the list then I'd like to get other's opinion.... And if v4 mapped multicast addresses are allowed by the basic API, shouldn't IN6_IS_ADDR_MULTICAST() return !0 for v4 mapped multicast addresses? => I disagree. IN6_IS_ADDR_MULTICAST() is for real IPv6 addresses only, for IPv4 mapped multicast one should use IN6_IS_ADDR_V4MAPPED() then the common but not standardized macro to extract the IPv4 address and finally IN_MULTICAST() (with the good endian :-). Regards [EMAIL PROTECTED] PS: until a too well known router vender provides IPv6 multicast routing, this discussion has a little interest because IPv6 multicast is not available in the real world (or we'll come back to Mbone nightmares). -------------------------------------------------------------------- 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] --------------------------------------------------------------------
