Subject: IPV6_JOIN_GROUP for v4 multicast

From: Lilian Fernandes <[email-masked]>
Date: Mon, 11 Mar 2002 13:16:13 -0600 (CST)

Hi,

I have a question about the IPV6_JOIN_GROUP socket option from
rfc2553bis-05. Is it intended that the user be able to use this socket
option to join IPv4 multicast groups as well? The user could do this by
specifying an IPv4-mapped IPv6 address for the IPv4 multicast address.

The RFC does not deal with this case specifically....I have attached the
relevant part of the rfc below:

------------------------------------------------------------------
IPV6_JOIN_GROUP

      Join a multicast group on a specified local interface.
      If the interface index is specified as 0,
      the kernel chooses the local interface.
      For example, some kernels look up the multicast group
      in the normal IPv6 routing table and use the resulting interface.

      Argument type: struct ipv6_mreq
[deleted some stuff]

The argument type of both of these options is the ipv6_mreq structure,
defined as a result of including the <netinet/in.h> header;

   struct ipv6_mreq {
       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
       unsigned int    ipv6mr_interface; /* interface index */
   };

Thanks,
_____________________________________________________________________

Lilian Fernandes
AIX TCP/IP Development - IBM Austin
Tel: 512-838-7966	Fax: 512-838-3509

--------------------------------------------------------------------
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: Antonio Querubin <[email-masked]>
Date: Mon, 11 Mar 2002 10:19:09 -1000 (HST)

> specifying an IPv4-mapped IPv6 address for the IPv4 multicast address.

Unfortunately the RFCs don't specifically define an IPv4-mapped IPv6
equivalent for IPv4 multicast addresses.  That section of the IPv6 address
architecture RFC only pertains to mapping IPv4 unicast addresses.

A suggestion was made last year to address this difference in behaviour at
the basic sockets API level since the address architecture was pretty much
fixed already.  But that suggestion came a little too late and now it's
been suggested that it be addressed instead in the advanced sockets API.

---

From: Lilian Fernandes <[email-masked]>
Date: Mon, 11 Mar 2002 14:32:31 -0600 (CST)

The advanced API does not address this yet....is there any way at all to
currently join an IPv4 multicast group on an AF_INET6 socket?
Or do applications need to open a separate AF_INET socket to join v4
groups?

Thanks,
Lilian

Lilian Fernandes

---

From: Markku Savela <[email-masked]>
Date: Mon, 11 Mar 2002 23:03:46 +0200

> From: Antonio Querubin <[email-masked]>

> architecture RFC only pertains to mapping IPv4 unicast addresses.

I don't see any problem here. IPv4-mapped format is just IPv4 address
represented in IPv6 addres format. Makes no difference whether IPv4
address is "unicast", multicast or loopback net. Its 1:1 mapping.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 11 Mar 2002 22:12:57 +0100 (CET)

> Or do applications need to open a separate AF_INET socket to join v4

When working on porting the java.net classes to transparently support
IPv6 we discovered that supporting IPv4-mapped addresses in IPV6_JOIN_GROUP
(as well as supporting an ifindex for an interface with no IPv6 for
IPV6_JOIN_GROUP and IPV6_MULTICAST_IF) was needed in order to get
good transparency.

Essentially when a java.net datagram socket is created it always corresponds
an AF_INET6 socket in the kernel (if the kernel supports IPv6) and 
IPV6_JOIN_GROUP and sendto() handle IPv4-mapped addresses.

  Erik

---

From: Antonio Querubin <[email-masked]>
Date: Mon, 11 Mar 2002 12:35:03 -1000 (HST)

> address is "unicast", multicast or loopback net. Its 1:1 mapping.

The RFC defines mapped addresses only for unicast addresses.  There is no
provision for dealing with mapped multicast addresses.  Hence the
problem...

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 13 Mar 2002 23:59:57 +0900

>>>>> On Mon, 11 Mar 2002 14:32:31 -0600 (CST), 
>>>>> Lilian Fernandes <[email-masked]> said:

> currently join an IPv4 multicast group on an AF_INET6 socket?

There's no such a *standardized* way, as far as I know.

> Or do applications need to open a separate AF_INET socket to join v4

If you want portability, I believe the answer is yes.

I'm even not sure if we really should allow the usage of
IPv4-mapped-multicast.  We had a very heated discussion even for
unicast addresses, and we were almost not able to reach consensus.  At
that time, one of main arguments to support the usage of IPv4-mapped
addresses was existing implementations and easy-porting of
widely-deployed unicast IPv4 applications.  I don't believe the
argument buys that much for multicast addresses/applications.

In any case, I don't think the advanced API is a suitable place to
define such a stuff.  Since the basic API defines both IPV6_JOIN_GROUP
and the usage of IPv4-mapped(-unicast) addresses, the appropriate
document would also be the basic API spec, *if we'd ever need to
standardize that*.  We should not use the advanced API as a kitchen
sink for arbitrary extensions.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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: Antonio Querubin <[email-masked]>
Date: Wed, 13 Mar 2002 08:15:14 -1000 (HST)

> There's no such a *standardized* way, as far as I know.

This is correct and the lack of a standard for dealing with it is the
problem.  But as has been noted through practical experience by some, it
would be extremely convenient if it were.  A goal of the APIs was to make
simpler the transition to IPv6 for existing programs.  That seems to have
worked for the unicast case but the lack of a similar standard works
against multicast programmers.

> argument buys that much for multicast addresses/applications.

And I would suggest that the same arguments still apply to multicast
addresses as well.  Otherwise this topic would not keep reappearing.  If
as you say, the arguments don't buy much for multicast
addresses/applications then wouldn't those same arguments also not buy
much for unicast addresses?  I think many programmers would agree that the
API makes it relatively simple to enable IPv6 in their existing unicast
applications.  So I'm having a difficult time understanding why such
arguments would inherently not apply to multicast as well or why multicast
should be treated noticeably differently than unicast in the API.

> sink for arbitrary extensions.

I agree.  However, when I proposed wording to include a provision for this
in the updated basic API, I think it unfortunately came a little too late.
So someone then suggested that this be handled in the advanced API
instead.  If you're suggesting that's no longer a good place for this then
do you have an alternative suggestion?

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 14 Mar 2002 11:47:55 +0900

>>>>> On Wed, 13 Mar 2002 08:15:14 -1000 (HST), 
>>>>> Antonio Querubin <[email-masked]> said:

> should be treated noticeably differently than unicast in the API.

In the unicast case, porting existing IPv4 applications (essentially)
only needs some keyword replacements, such as
s/AF_INET/AF_INET6/g
s/sockaddr_in/sockaddr_in6/g

In the multicast case, however, we'll also need to change semantical
part of the existing application.  For example: ip_mreq (for IPv4)
takes in_addr to specify an interface while ipv6_mreq (for IPv6) takes
an interface identifier.  Thus, we'll (sometimes) need to change
the syntax and/or semantics of command line arguments.  This also
means we need to introduce if_nametoindex() when porting.

It also seems to me that people emphasize the useful part of mapped
addresses tend to forget why some other people made objections to them
in the old discussions about the unicast case; mapped addresses
introduce additional complexity for address matching and access
control, and the complexity can be a security hole.

In my understanding, one of the reasons why we still go with mapped
addresses in the unicast discussion was because there were already
many existing (unicast) applications that relied on the usage of
mapped addresses and because we could not ignore them.  The situation
is different in this case; we do not even have an official document
that describes the usage of mapped-multicast addresses.  So, in this
case, we can/should concentrate on all the pros and cons.  If the
consensus is still for the usage of mapped addresses, I'll follow the
result.

BTW: I recall an old discussion about a protocol independent API for
multicast applications that Dave Thaler (@Microsoft) proposed -if my
memory is correct-.  I'd rather prefer this approach.

> do you have an alternative suggestion?

As Tim pointed out, we'll go to an API community such as POSIX, or, if
we still do some work in this group, we'll need a separate document.

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Mar 2002 07:33:54 +0200 (EET)

> s/sockaddr_in/sockaddr_in6/g

Not in the real world.  Who wants an application that can work _only_ with 
IPv6?  Nobody.  In the real world, sockaddr_storage and friends must be 
used and DNS lookup sections re-written with getaddrinfo and getnameinfo.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 14 Mar 2002 22:02:45 +0900

>>>>> On Thu, 14 Mar 2002 07:33:54 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> used and DNS lookup sections re-written with getaddrinfo and getnameinfo.

Though I admit that I may have oversimplified the description, you
missed the point (or I failed to describe the point well).  The point
is, whether using IPv4-mapped addresses for multicast addresses is
worth introducing or not.

Secondly (this is far from the point of the discussion, though), I did
not intend to say we can only consider applications that can work only
with *IPv6*.  What I meant was we can only use AF_INET6 sockets to
support *both IPv4 and IPv6* with the usage of mapped addresses
described in the basic API.  And, some server side IPv4 applications
can even be ported without sockaddr_storage, getaddrinfo(), or
getnameinfo().  This was also an argument by supporters of mapped
addresses.

					JINMEI, Tatuya

---

From: Keith Moore <[email-masked]>
Date: Thu, 14 Mar 2002 13:36:43 -0500

> Who wants an application that can work _only_ with IPv6?  Nobody.

strongly disagree.  IPv6 provides capabilities that simply don't
exist in IPv4 - among them the ability to provide large numbers of
stable addresses.  In other words, IPv6 enables applications that
cannot be widely deployed under IPv4, and for that reason it's  
entirely reasonable to write applications for IPv6 only.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Mar 2002 21:33:30 +0200 (EET)

> entirely reasonable to write applications for IPv6 only.

In this context, we're talking about an application that already existed 
for IPv4; entirely new kind of applications _might_ be written for IPv6 
only at some point, but that's an entirely different issue.