netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: Vasily Averin <vvs@parallels.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Cong Wang <amwang@redhat.com>
Subject: Re: bride: IPv6 multicast snooping enhancements
Date: Tue, 10 Feb 2015 12:44:28 +0100	[thread overview]
Message-ID: <20150210114428.GK2489@odroid> (raw)
In-Reply-To: <54D9C4ED.6040601@parallels.com>

Hi Vasily,

On Tue, Feb 10, 2015 at 11:44:29AM +0300, Vasily Averin wrote:
> This patch prevent forwarding of ICMPv6 in bridges,
> so containers/VMs with virtual eth adapters connected in local bridge cannot ping each other via ipv6 (but can do it via ipv4)

If a host wants to receive packets, then it needs to signalize
that via MLD. If your host does not do that, then it is expected
to not receive ICMPv6 echo requests to multicast addresses. An
exception is ff02::1, that should always work.

> 
> Could you please clarify, is it expected behavior?
> Do we need to enable multicast routing or multicast_snooping on all local ports on such bridges to enable just ICMPv6?

Nope, you shouldn't. You'd need multicast listeners. You shouldn't
need to play with the bridge settings to fix protocols.

> I believe ICMPv6 is an exception and should not be filtered by multicast spoofing.

Signaling multicast joins is mandatory by the IPv6 standard. If
your protocol/application does not do that, then it seems to me
that the application might be broken.


By the way, which kernel version(s) are you using?

Cheers, Linus

  reply	other threads:[~2015-02-10 11:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-04  0:13 bride: IPv6 multicast snooping enhancements Linus Lüssing
2013-09-04  0:13 ` [PATCH net-next 1/2] bridge: prevent flooding IPv6 packets that do not have a listener Linus Lüssing
2013-09-04  0:13 ` [PATCH net-next 2/2] bridge: apply multicast snooping to IPv6 link-local, too Linus Lüssing
2013-09-05 16:36 ` bride: IPv6 multicast snooping enhancements David Miller
2015-02-10  8:44 ` Vasily Averin
2015-02-10 11:44   ` Linus Lüssing [this message]
2015-02-10 13:59     ` Vasily Averin
2015-02-12 11:41       ` Linus Lüssing
2015-02-12 12:01         ` Vasily Averin

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=20150210114428.GK2489@odroid \
    --to=linus.luessing@c0d3.blue \
    --cc=amwang@redhat.com \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vvs@parallels.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).