node-local multicast issues

node-local multicast issues

[Mark Borst]

Hello all

I am doing some experiments with node-local multicasting as a means of
inter-process communication. I am using debian unstable with linux
kernel 2.6.8 with MIPL 2.0 patches. Now I am running into some problems.

I want to keep the node-local packets on the 'lo' interface. I do that
by setting socket option IPV6_MULTICAST_IF to the 'lo' ifindex. Then I
use sendmsg() to send the message. As a result I get the error "Network
is unreachable". When I started analyzing it, I found the following:

The default routing table in my system includes this route:

ff00::/8	::	U     256    0        0 eth0

There is no route for this to 'lo'. Which makes all attempts to send
nodelocal (ff01::/8) multicast packets to 'lo' go wrong. When I add the
following routes, it works:

ff01::/16	::	U     1      0        0 eth0
ff01::/16	::	U     1      0        0 lo

When I don't use IPV6_MULTICAST_IF, the packets get sent to 'eth0', but
when I set it to 'lo' the packets get sent to 'lo'. So far so good.

The next thing I notice is that I see the ff01::/8 packets on eth0 with
ethereal. Does that mean that they are actually sent out on the wire? If
so, then this would violate the semantics of nodelocal multicast.

So the question rises: what is the intended behaviour here? As I
understand it, ff01::/8 traffic is interface local, and you should use
IPV6_MULTICAST_IF to select which interface you want to use. Traffic
sent to ff01::/8 on 'eth0' will not be seen on 'lo'. This is however
prevented by not having a route to 'lo'. Should these routes be set per
interface by default?

Please enlighten me.

Regards,

-- 
Mark Borst
Researcher
Network and Protocols Group
Tampere University of Technology, Finland

Re: node-local multicast issues

[David Stevens]

        The loopback device doesn't have IFF_MULTICAST set, so technically
it is not a multicast-capable device, and you shouldn't be able to join a 
group on it.
I think the way it ought to work is that you join the group on any device, 
with
IPV6_MULTICAST_LOOP set and local guys should hear the node-local 
multicasts,
but it shouldn't be sent on the wire. Multicasting could be supported on 
loopback, too,
but it doesn't matter all that much unless there are no multicast-capable 
real devices.
        However, it appears that node-local multicasts are being sent out 
the device,
at least on an early 2.6 kernel I did a quick test with. There probably 
isn't anything
enforcing the node-locality in the send path, which I would consider a 
bug. :-)

                                                +-DLS

Re: node-local multicast issues

[Mark Borst]

On Tue, 2004-11-09 at 15:21 -0800, David Stevens wrote:
>         The loopback device doesn't have IFF_MULTICAST set, so technically
> it is not a multicast-capable device, and you shouldn't be able to join a 
> group on it. 

That is Linux-specific, right? At least KAME's 'lo' does support
multicast, and their README says: 

Each interface joins the solicited multicast address and the
link-local all-nodes multicast addresses (e.g.  fe80::1:ff01:6317
and ff02::1, respectively, on the link the interface is attached).
In addition to a link-local address, the loopback address (::1) will be
assigned to the loopback interface.  Also, ::1/128 and ff01::/32 are
automatically added to routing table, and loopback interface joins
node-local multicast group ff01::1.

On Windows I don't see 'lo' joining ff01::1.

RFC 3513 tells me:

2.7.1 Pre-Defined Multicast Addresses

    All Nodes Addresses:    FF01:0:0:0:0:0:0:1
                              FF02:0:0:0:0:0:0:1

   The above multicast addresses identify the group of all IPv6 nodes,
   within scope 1 (interface-local) or 2 (link-local).

Does that imply that the linux stack doesn't conform to RFC 3513?

> I think the way it ought to work is that you join the group on any device, 
> with IPV6_MULTICAST_LOOP set and local guys should hear the node-local 
> multicasts, but it shouldn't be sent on the wire. Multicasting could be supported on 
> loopback, too, but it doesn't matter all that much unless there are no multicast-capable 
> real devices.

>         However, it appears that node-local multicasts are being sent out 
> the device, at least on an early 2.6 kernel I did a quick test with. There probably 
> isn't anything enforcing the node-locality in the send path, which I would consider a 
> bug. :-)

Even more interesting: an other node responded to 'ping6 ff01::1' so
there is some bug somewhere ;)

On another note: 'ping6 ff02::1' gives "connect: Invalid argument" on
linux. On KAME it says "ping6: UDP connect: Network is unreachable". The
only implementation that gives me replies is Solaris. This also sounds
like a bug to me.

Regards,
-- 
Mark Borst
Researcher
Network and Protocols Group
Tampere University of Technology, Finland

Re: node-local multicast issues

[Brian Haley]

Mark Borst wrote:

> On another note: 'ping6 ff02::1' gives "connect: Invalid argument" on
> linux.

You've got to use -I with that, maybe ping6 could give a hint.

> The only implementation that gives me replies is Solaris.

My trusty Tru64 UNIX box works as well :)

-Brian

Re: node-local multicast issues

[Mark Borst]

On Wed, 2004-11-10 at 14:46 -0500, Brian Haley wrote:
> Mark Borst wrote:
> 
> > On another note: 'ping6 ff02::1' gives "connect: Invalid argument" on
> > linux.
> 
> You've got to use -I with that, maybe ping6 could give a hint.

I found that too. With -I it works fine.

> 
> > The only implementation that gives me replies is Solaris.
> 
> My trusty Tru64 UNIX box works as well :)

Good ;) My testing wasn't anything near exhaustive, just a short test ;)


-- 
Mark Borst
Researcher
Network and Protocols Group
Tampere University of Technology, Finland

Re: node-local multicast issues

[Mark Borst]

It's a pity that I have to reply to myself.

On Wed, 2004-11-10 at 16:17 +0200, Mark Borst wrote:
> On Tue, 2004-11-09 at 15:21 -0800, David Stevens wrote:
> >         The loopback device doesn't have IFF_MULTICAST set, so technically
> > it is not a multicast-capable device, and you shouldn't be able to join a 
> > group on it. 
> 
> That is Linux-specific, right? At least KAME's 'lo' does support
> multicast, and their README says: 
> 
> On Windows I don't see 'lo' joining ff01::1.
> 
> RFC 3513 tells me:
> 
> 2.7.1 Pre-Defined Multicast Addresses
> 
>     All Nodes Addresses:    FF01:0:0:0:0:0:0:1
>                               FF02:0:0:0:0:0:0:1
> 
>    The above multicast addresses identify the group of all IPv6 nodes,
>    within scope 1 (interface-local) or 2 (link-local).
> 
> Does that imply that the linux stack doesn't conform to RFC 3513?

My tests show that interface-local multicast actually works, when I get
my implementation right. So interface-local multicast on 'lo' does
work. 

However, pinging ff01::1 on 'lo' still doesn't get me any reply.

> 
> > I think the way it ought to work is that you join the group on any device, 
> > with IPV6_MULTICAST_LOOP set and local guys should hear the node-local 
> > multicasts, but it shouldn't be sent on the wire. Multicasting could be supported on 
> > loopback, too, but it doesn't matter all that much unless there are no multicast-capable 
> > real devices.
> 
> >         However, it appears that node-local multicasts are being sent out 
> > the device, at least on an early 2.6 kernel I did a quick test with. There probably 
> > isn't anything enforcing the node-locality in the send path, which I would consider a 
> > bug. :-)
> 
> Even more interesting: an other node responded to 'ping6 ff01::1' so
> there is some bug somewhere ;)
> 
> On another note: 'ping6 ff02::1' gives "connect: Invalid argument" on
> linux. On KAME it says "ping6: UDP connect: Network is unreachable". The
> only implementation that gives me replies is Solaris. This also sounds
> like a bug to me.

As already mentioned, one needs to specify the interface with -I to make
it work.

-- 
Mark Borst
Researcher
Network and Protocols Group
Tampere University of Technology, Finland