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