netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* IPv6 multicast bind(), esp. v4-mapped addresses
@ 2008-12-05  6:42 Pekka Savola
  2008-12-05  7:11 ` YOSHIFUJI Hideaki / 吉藤英明
  0 siblings, 1 reply; 5+ messages in thread
From: Pekka Savola @ 2008-12-05  6:42 UTC (permalink / raw)
  To: netdev

Hi,

Java multicast API uses IPv6 sockets internally unless IPv6 is 
disabled.  In other APIs as well it might be beneficial to be able to 
use IPv4 through IPv6 mapped addresses.  This works fine with unicast, 
but there are problems with this in multicast (I've also included 
broadcast here because ipv4 side does that, I don't see the case for 
it myself).

Specifically, bind() to a v6-mapped v4 multicast address fails with 
EADDRNOTAVAIL:

bind(7, {sa_family=AF_INET6, sin6_port=htons(2000), 
inet_pton(AF_INET6, "::ffff:233.12.174.101", &sin6_addr), 
sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL (Cannot 
assign requested address).

Two questions:

  1) should this be supported?  I think we're talking about a change in
     net/ipv6/af_inet6.c, replacing something like (not tested, adapted
     from net/ipv4/af_inet.c):

273         if (addr_type == IPV6_ADDR_MAPPED) {
274                 v4addr = addr->sin6_addr.s6_addr32[3];
275                 if (inet_addr_type(net, v4addr) != RTN_LOCAL) {
276                         err = -EADDRNOTAVAIL;
277                         goto out;
278                 }
279         } else {

with:

          if (addr_type == IPV6_ADDR_MAPPED) {
                  v4addr = addr->sin6_addr.s6_addr32[3];
 		 if (inet_addr_type(net, v4addr) == RTN_MULTICAST ||
 		     inet_addr_type(net, v4addr) == RTN_BROADCAST) {
 			inet->saddr = 0; /* Use device */
                  } else {
 	                 if (inet_addr_type(net, v4addr) != RTN_LOCAL) {
 	                         err = -EADDRNOTAVAIL;
 	                         goto out;
 	                 }
 		}
          } else {


  2) it appears that ip_nonlocal_bind sysctl only supports ipv4.
     Similar option or applying the same for v6 may be useful,
     especially if 1) is not changed, such a toggle might be useful
     with v6 as well.

You can see some specification discussion on this topic here:
http://www.mail-archive.com/ipng@sunroof.eng.sun.com/msg02134.html

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: IPv6 multicast bind(), esp. v4-mapped addresses
  2008-12-05  6:42 IPv6 multicast bind(), esp. v4-mapped addresses Pekka Savola
@ 2008-12-05  7:11 ` YOSHIFUJI Hideaki / 吉藤英明
  2008-12-05  7:42   ` Pekka Savola
  0 siblings, 1 reply; 5+ messages in thread
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2008-12-05  7:11 UTC (permalink / raw)
  To: pekkas; +Cc: netdev, yoshfuji

Hello.

In article <alpine.LRH.2.00.0812050820380.28482@netcore.fi> (at Fri, 5 Dec 2008 08:42:37 +0200 (EET)), Pekka Savola <pekkas@netcore.fi> says:

> Two questions:
> 
>   1) should this be supported?  I think we're talking about a change in
>      net/ipv6/af_inet6.c, replacing something like (not tested, adapted
>      from net/ipv4/af_inet.c):
> 
> 273         if (addr_type == IPV6_ADDR_MAPPED) {
> 274                 v4addr = addr->sin6_addr.s6_addr32[3];
> 275                 if (inet_addr_type(net, v4addr) != RTN_LOCAL) {
> 276                         err = -EADDRNOTAVAIL;
> 277                         goto out;
> 278                 }
> 279         } else {
> 
> with:
> 
>           if (addr_type == IPV6_ADDR_MAPPED) {
>                   v4addr = addr->sin6_addr.s6_addr32[3];
>  		 if (inet_addr_type(net, v4addr) == RTN_MULTICAST ||
>  		     inet_addr_type(net, v4addr) == RTN_BROADCAST) {
>  			inet->saddr = 0; /* Use device */
>                   } else {
>  	                 if (inet_addr_type(net, v4addr) != RTN_LOCAL) {
>  	                         err = -EADDRNOTAVAIL;
>  	                         goto out;
>  	                 }
>  		}
>           } else {

I think similar issue(s) have been pointed out several times.
IPv4-mapped addresses are not portable, unfortunately, anyway, and
people should use native interface, especially for multicasts.

BTW, do you know what kind of socket option do they use for setting/getting
ttl etc?

If we fully support "IPv4-Mapped" function, we should transparently
configure ipv4-multicast parameters etc. as well.


>   2) it appears that ip_nonlocal_bind sysctl only supports ipv4.
>      Similar option or applying the same for v6 may be useful,
>      especially if 1) is not changed, such a toggle might be useful
>      with v6 as well.

I don't think this could not be an answer.

--yoshfuji

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: IPv6 multicast bind(), esp. v4-mapped addresses
  2008-12-05  7:11 ` YOSHIFUJI Hideaki / 吉藤英明
@ 2008-12-05  7:42   ` Pekka Savola
  2008-12-05  8:03     ` David Miller
  0 siblings, 1 reply; 5+ messages in thread
From: Pekka Savola @ 2008-12-05  7:42 UTC (permalink / raw)
  To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev

On Fri, 5 Dec 2008, YOSHIFUJI Hideaki / ???? wrote:
> I think similar issue(s) have been pointed out several times.
> IPv4-mapped addresses are not portable, unfortunately, anyway, and
> people should use native interface, especially for multicasts.

Yes, there are problems with portability of mapped address usage, but 
that doesn't have to mean that we shouldn't try to make it as useful 
as reasonable.

> BTW, do you know what kind of socket option do they use for 
> setting/getting ttl etc?
>
> If we fully support "IPv4-Mapped" function, we should transparently
> configure ipv4-multicast parameters etc. as well.

It does this:

setsockopt(7, SOL_IPV6, IPV6_MULTICAST_HOPS, [1], 4) = 0

In Java MulticastSocket API, if you only specify the port and not 
multicast group, it will bind to "::", and it succeeds.  Afterwards 
Java issues an IPv4 IGMP join:

setsockopt(7, SOL_IP, IP_ADD_MEMBERSHIP, "\351\f\f\f\0\0\0\0\0\0\0\0", 12) = 0

So Java implementation will parse whether the group is IPv4 or IPv6 
multicast -- it isn't using MCAST_JOIN_GROUP API.  It could be argued 
that if it already knows the protocol, it _could_ create IPv4 socket 
from the start, instead of doing this via a mapped v6 socket.

Of course, if Java used the protocol-independent MCAST_JOIN_GROUP etc. 
API, it would not need to even know whether the group was v4 or v6. 
And from that perspective also it would probably make sense to support 
a v4-mapped-address bind().

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: IPv6 multicast bind(), esp. v4-mapped addresses
  2008-12-05  7:42   ` Pekka Savola
@ 2008-12-05  8:03     ` David Miller
  2008-12-10  7:22       ` Pekka Savola
  0 siblings, 1 reply; 5+ messages in thread
From: David Miller @ 2008-12-05  8:03 UTC (permalink / raw)
  To: pekkas; +Cc: yoshfuji, netdev

From: Pekka Savola <pekkas@netcore.fi>
Date: Fri, 5 Dec 2008 09:42:43 +0200 (EET)

> It does this:
> 
> setsockopt(7, SOL_IPV6, IPV6_MULTICAST_HOPS, [1], 4) = 0
>
> In Java MulticastSocket API, if you only specify the port and not
> multicast group, it will bind to "::", and it succeeds.  Afterwards
> Java issues an IPv4 IGMP join:
>
> setsockopt(7, SOL_IP, IP_ADD_MEMBERSHIP, "\351\f\f\f\0\0\0\0\0\0\0\0", 12) = 0
>
> So Java implementation will parse whether the group is IPv4 or IPv6
> multicast -- it isn't using MCAST_JOIN_GROUP API.  It could be
> argued that if it already knows the protocol, it _could_ create IPv4
> socket from the start, instead of doing this via a mapped v6 socket.

>From what I've read, ipv4 mapped addresses are full of all kinds of
tricky cases and issues.  And, given that, using ipv4 mapped address
for ipv4 multicast is just asking for trouble in my opinion.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: IPv6 multicast bind(), esp. v4-mapped addresses
  2008-12-05  8:03     ` David Miller
@ 2008-12-10  7:22       ` Pekka Savola
  0 siblings, 0 replies; 5+ messages in thread
From: Pekka Savola @ 2008-12-10  7:22 UTC (permalink / raw)
  To: David Miller; +Cc: yoshfuji, netdev

On Fri, 5 Dec 2008, David Miller wrote:
> From what I've read, ipv4 mapped addresses are full of all kinds of
> tricky cases and issues.  And, given that, using ipv4 mapped address
> for ipv4 multicast is just asking for trouble in my opinion.

FWIW, I've communicated this issue to Java developers.  Let's hope 
they'll enhance their Java shim layer to avoid mapped addresses some 
time in the future:

http://mail.openjdk.java.net/pipermail/net-dev/2008-December/000494.html

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-12-10  7:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-05  6:42 IPv6 multicast bind(), esp. v4-mapped addresses Pekka Savola
2008-12-05  7:11 ` YOSHIFUJI Hideaki / 吉藤英明
2008-12-05  7:42   ` Pekka Savola
2008-12-05  8:03     ` David Miller
2008-12-10  7:22       ` Pekka Savola

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).