All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.