> "::ffff:224.x.x.x" is not a multicast address, per WG consensus, since
> it doesn't start with ff... so you must not do that.

Clearly the above isn't a multicast on the wire.

But from the perspective on the API's use of IPv4-mapped addresses does
it make sense to 1) support multicast addresses, and 2) if so
what form should they have at the API.

I've seen good reasons to support it - one case being porting the java.net
socket classes to work over IPv6 and Ipv4 transparent to the application.

Thus to me the question is whether we should use the currently
defined IPv4-mapped address format and stick IPv4 multicast addresses inside,
or define some new address format for "IPv4-mapped multicast addresses".

> There is no current specification that allows any type of v4-mapped
> multicast addresses, but in my opinion, ff0e::ffff:224.2.127.254 is a 
> good way to specify it.

Isn't there a risk of this creating a perception that the above address
should work on the wire in an IPv6 multicast packet?

If people end up wanting these to work on the wire then there is a risk
of
1) ending up "importing" the IPv4 multicast memberships into IPv6
   multicast memberships by prepending ff0e::ffff:/96
2) folks desiring translators between IPv6 and IPv4 which strip/add
   the above prefix as part of the translation.

Thus I see significant risk going down this path since I don't think we
want the complexity of pretending to provide easy interoperability between
IPv4 and IPv6 multicast. It is bad enough that folks view the complexity of
SIIT as being necessary in some deployment.

So I'd argue for just sticking IPv4 multicast addresses in ::ffff:0:0/96
at the API and have the implementations which support mapped addresses
do the right thing to send/receive IPv4 multicast packets in that case.

   Erik

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to