netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Borst <mark@mwborst.com>
To: David Stevens <dlstevens@us.ibm.com>
Cc: hessu@cs.tut.fi, netdev@oss.sgi.com
Subject: Re: node-local multicast issues
Date: Thu, 11 Nov 2004 13:21:53 +0200	[thread overview]
Message-ID: <1100172113.24452.10.camel@mn-2> (raw)
In-Reply-To: <1100096251.22964.7.camel@mn-2>

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

      parent reply	other threads:[~2004-11-11 11:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-09 10:21 node-local multicast issues Mark Borst
2004-11-09 23:21 ` David Stevens
2004-11-10 14:17   ` Mark Borst
2004-11-10 19:46     ` Brian Haley
2004-11-11 10:18       ` Mark Borst
2004-11-11 11:21     ` Mark Borst [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1100172113.24452.10.camel@mn-2 \
    --to=mark@mwborst.com \
    --cc=dlstevens@us.ibm.com \
    --cc=hessu@cs.tut.fi \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).