Subject: multicast IPv4-mapped IPv6 addresses/sockets

From: Antonio Querubin <[email-masked]>
Date: Wed, 2 May 2001 00:45:15 -1000 (HST)

I've run into a problem with converting multicast applications originally
designed for IPv4 to use IPv6 socket calls.  Is there any set convention
for handling multicast IPv4 addresses mapped to IPv6 addresses?
(Apologies in advance if I'm asking the wrong mailing list - I'd already
posed this question to other IPv6 mailing lists but apparently am not
reaching the right people who might know the answers).

Consider a unicast application program originally written for IPv4.  A
programmer can easily convert the IPv4 socket calls to IPv6 socket calls
and just use IPv4-mapped IPv6 unicast addresses.  The IPv6 socket API
(RFC-2133 or RFC-2553) specifies that when IPv4-mapped addresses are used,
the connection is made using IPv4.  Unless it's dealing with low-level
calls, the application program doesn't need to know whether it's really
using IPv4 or IPv6.  It just has access to an open socket.  However, I've
run into a problem with handling multicast IPv4 addresses with IPv6
sockets.

For example, let's say I have an application that I want to convert to
using IPv6 sockets and that I normally pass it an IPv4 unicast
name/address on the command line.  If this were an IPv4 unicast program,
it might typically do a gethostname to obtain the IP address and then open
up a connection.  Converted to using IPv6, the gethostname() (or
getipnodename()) would return an IPv4-mapped address looking something
like ::ffff:192.168.1.1.  The IPv6 socket API handles this automatically
and makes an IPv4 connection.  Pretty simple.

But when it's a multicast program the situation changes, the gethostname()
will still return an IPv4-mapped address, however this mapped address is
not useable (at least not under Linux and gcc).  If for example, I specify
sap.mcast.net (224.2.127.254) on the command line to this multicast
program, when it does the gethostbyname() it gets back
::ffff:224.2.127.254.  But this doesn't appear to be a useable multicast
address to Linux.  The socket calls, up to where one sets the multicast
TTL or joins the multicast groups, do work.  But once I try to set the
multicast TTL or join the group, the ::ffff:224.2.127.254 address is
rejected as invalid.  The only way I've found to make this work is to
either create the socket using IPv4 socket calls only, or use an actual
IPv6 multicast address to begin with.

Well at least that's how Linux and gcc have been behaving so far for me.
So is this perhaps a socket API implementation problem specific to Linux
or is it caused by the RFCs not specifically defining how an IPv4-mapped
multicast address should be handled?

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.

--------------------------------------------------------------------
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: [email-masked]
Date: Wed, 2 May 2001 13:07:26 +0200 (CEST)

> reaching the right people who might know the answers).

ftp://playground.sun.com/pub/ipng/mail-archive/ipng.200009
and search for:
"Subject: v4 mapped multicast addresses"

	rvdp

---

From: Markku Savela <[email-masked]>
Date: Wed, 2 May 2001 14:31:04 +0300

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

---

From: Jim Bound <[email-masked]>
Date: Thu, 3 May 2001 00:25:51 -0400 (EDT)

Antonio,

I don't know Linux at this detail.  We should test this on all systems.
But if Linux is treating the mapped portion as v6 at the point of the send
and not stripping off all but the low order 32bits when the packet goes to
Linux version of the DLI then it will get wacked for sure.  Also I wold
check the address family you believe was set for AF_INET for the multicast
interface set and join operation.  Those might be hosed too if my
suspicion is correct????

/jim

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 4 May 2001 03:06:27 -1000 (HST)

> interface set and join operation.  Those might be hosed too if my

Actually I think Linux is just treating ::ffff:224.x.x.x returned from
gethostbyname() as an IPv4 unicast rather than multicast address.  Hence
the API socket calls work up until a multicast-specific action is
requested.