From: Jan Stancek <jstancek@redhat.com>
To: "Linus Lüssing" <linus.luessing@web.de>
Cc: netdev@vger.kernel.org, Florian Westphal <fwestpha@redhat.com>,
bridge@lists.linux-foundation.org
Subject: Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest
Date: Tue, 4 Mar 2014 03:02:36 -0500 (EST) [thread overview]
Message-ID: <624414844.12834668.1393920156458.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20140304000041.GY5090@Linus-Debian>
----- Original Message -----
> From: "Linus Lüssing" <linus.luessing@web.de>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: netdev@vger.kernel.org, "Florian Westphal" <fwestpha@redhat.com>, bridge@lists.linux-foundation.org
> Sent: Tuesday, 4 March, 2014 1:00:41 AM
> Subject: Re: bridge is not forwaring ICMP6 neighbor solicitation to KVM guest
>
> Hi Jan,
>
> On Mon, Mar 03, 2014 at 05:45:49PM -0500, Jan Stancek wrote:
> > There is also bridge on host B. I assume that doesn't matter
> > but I could set up host B without bridge if needed.
>
> It can matter, but in this case it doesn't :).
>
> > > What I'm curious about is, whether the guest receives
> > > the MLD query and responds with an MLD report. I suspect that
> > > either the bridge doesn't get an MLD report and therefore is
> > > shutting down the according port or there's a bug in parsing the
> > > MLD report in the bridge code.
> >
> > I'm no expert in this area, but shouldn't neigh. solicit packets
> > be forwarded to all ports regardless of any/no MLD reports?
>
> That's the beauty of IPv6 Neighbor Discovery using these neat
> solicited-node multicast addresses :). With IPv4 and ARP
> requests there's no other way than flooding. But for IPv6 we know
> in advance behind which bridge port someone interested in the
> neighbor solicitation message might be (assuming MLD is working,
> properly), allowing us to save bandwidth.
>
> In this case, MLD is not working properly, the main issue is the
> following:
>
> Host B sends broken MLD queries, the source address should be an
> IPv6 link-local one, not "100:0:600:0:78fb:100::". MLDv2 mandates
> this (see RFC3810, section 5.1.14.: "Source Addresses for
> Queries").
>
> Though I couldn't find that requirement for MLDv1, Linux ignores
> MLDv1 queries with a non-link-local source address, too (see
> net/ipv6/mcast.c, igmp6_event_query() ). So Linux never sends an
> MLD report in reply to these broken queries.
>
>
> The second "minor" but in this case fatal issue is, that the
> bridge code doesn't have this link-local-src check, therefore
> kicking the snooping into gear even though it shouldn't because we
> don't have a _working_ querier.
>
> I'm going to make a patch for the bridge code adding this sanity
> check.
>
>
> For the broken query, ok, it's your manually crafted query. But
> did you see a query with such a bogus source address "in the
> wild", too? (I'm curious how urgent this sanity check is)
It's real packet I managed to capture during one such occurrence.
I'm sending it with small C program over raw socket, but it's byte
by byte exact copy of what I captured with tcpdump previously.
I'm not sure how that packet came to existence. Based on IPv6 address
it came from host B, but all host B was doing at the time
was running RHEL6 with couple qemu-kvm instances. KVM guests were
set up to use bridge, so I'm assuming if any of them crafted
this packet, source IPv6 address would be different.
Regards,
Jan
>
> Cheers, Linus
>
next prev parent reply other threads:[~2014-03-04 8:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1566805413.12693479.1393872931017.JavaMail.zimbra@redhat.com>
2014-03-03 19:47 ` bridge is not forwaring ICMP6 neighbor solicitation to KVM guest Jan Stancek
2014-03-03 21:27 ` Linus Lüssing
2014-03-03 21:40 ` Vlad Yasevich
2014-03-03 23:03 ` Linus Lüssing
2014-03-03 22:45 ` Jan Stancek
2014-03-04 0:00 ` Linus Lüssing
2014-03-04 8:02 ` Jan Stancek [this message]
2014-03-04 10:52 ` Linus Lüssing
2014-03-04 11:06 ` Jan Stancek
2014-03-04 21:37 ` Linus Lüssing
2014-03-05 12:10 ` Jan Stancek
2014-03-05 14:27 ` Linus Lüssing
2014-03-05 14:57 ` Jan Stancek
2014-03-12 4:37 ` Linus Lüssing
2014-03-12 7:45 ` Jan Stancek
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=624414844.12834668.1393920156458.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--cc=bridge@lists.linux-foundation.org \
--cc=fwestpha@redhat.com \
--cc=linus.luessing@web.de \
--cc=netdev@vger.kernel.org \
/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).