From: Mark Borst <mark@borst.org>
To: David Stevens <dlstevens@us.ibm.com>
Cc: hessu@cs.tut.fi, netdev@oss.sgi.com
Subject: Re: node-local multicast issues
Date: Wed, 10 Nov 2004 16:17:31 +0200 [thread overview]
Message-ID: <1100096251.22964.7.camel@mn-2> (raw)
In-Reply-To: <OF18E2258F.5E2E252A-ON88256F47.007FA9FD-88256F47.0080590C@us.ibm.com>
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
next prev parent reply other threads:[~2004-11-10 14:17 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 [this message]
2004-11-10 19:46 ` Brian Haley
2004-11-11 10:18 ` Mark Borst
2004-11-11 11:21 ` Mark Borst
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=1100096251.22964.7.camel@mn-2 \
--to=mark@borst.org \
--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).