Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets

From: "Dave Thaler" <[email-masked]>
Date: Wed, 2 May 2001 09:24:04 -0700

> -----Original Message-----
> From: Markku Savela [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 4:31 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: multicast IPv4-mapped IPv6 addresses/sockets
> 
> 
> > If this is not system-specific then it seems that the handling of
> > IPv4-mapped multicast addresses was something left out of either the
> IPv6
> > socket API or perhaps an IPv4-mapped multicast address should be
> > explicitly defined?  For example, 224.2.127.254 might be mapped to
> > ff0e::ffff:224.2.127.254 instead of ::ffff:224.2.127.254?  Linux
would
> > accept the first address but not the latter in a multicast socket
call.
> 
> In our IPv4/IPv6 stack (for EPOC) I was tentatively planning to handle
> any "::ffff:224.x.x.x" as "multicast" destination. Thus, the idea was
> that one could join and leave IPv4 multicast groups using the IPv6 API
> and plain IPv4 multicast addresses in IPv4-mapped format.
> 
> Can anyone see any problems with this?

"::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.

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.

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

---

From: Markku Savela <[email-masked]>
Date: Wed, 2 May 2001 20:08:03 +0300

> it doesn't start with ff... so you must not do that.

I should have pointed out, that the stack implements both IPv4/IPv6,
but all addressess are stored in IPv6 format, and all processing is
uniform for both IPv4 and IPv6.

Internally, IPv4 is using IPv4 mapped addresses. Thus, as far as I'm
concerned, 224.x.x.x is same as ::ffff:224.x.x.x. I don't see any
reason to differentiate between them.

When I say I treat ::ffff:224.x.x.x as multicast, I'm just
implementing IPv4 multicast as I should. The "non-conformant" part was
whether I should accept IPv4 multicast operations that use the IPv6
multicast API (and was tentatively considering it a "feature" :)

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 4 May 2001 12:14:30 +0200 (MET DST)

> 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".

> multicast addresses, but in my opinion, ff0e::ffff:224.2.127.254 is a 

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