All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: David Stevens <dlstevens@us.ibm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	brian.haley@hp.com, netdev@vger.kernel.org,
	netdev-owner@vger.kernel.org
Subject: Re: multicast: bug or "feature"
Date: Fri, 19 Oct 2007 12:49:50 -0400	[thread overview]
Message-ID: <4718E02E.1080603@hp.com> (raw)
In-Reply-To: <OFDA173EE1.60049F6E-ON88257379.0052A408-88257379.00544DA0@us.ibm.com>

David Stevens wrote:
> netdev-owner@vger.kernel.org wrote on 10/19/2007 04:43:27 AM:
> 
>> Vlad Yasevich <vladislav.yasevich@hp.com> wrote:
>>> Now, to figure out what IPv6 does different and why it works.
>>> Seems to me that the two should have the same behavior.
>> IPv6 on Linux uses a per-interface addressing model as opposed
>> to the per-host model used by IPv4.
> 
>         For link-local addresses, yes.
> 
>         It's really a security feature; the ordinary
> case where you'd receive something on an interface that's
> using one of your source addresses is when someone is spoofing
> you, has a duplicate address, or maybe an (unintentional)
> routing loop. All of those are error cases, so dropping a
> received packet that claims to be sent by you is a reasonable
> thing to do.

I can see this as a good feature for unicast, but starting to
doubt it just a little bit for multicast.  With IGMPv3/MLDv2 and source
filtering, this could be done as a filter on individual sockets.

The problem them becomes IGMPv2 and MLDv1.

>         If you're getting link-local source addresses for your
> IPv6 multicast packets, that may explain it. The link-local
> addresses are required to be unique and valid only for that
> link, so IPv6 should not consider a different interface's
> link-local address as "local" for a destination address, or
> a packet using that source address as bogus.

Looks like the only time IPv6 does any type of source filtering
is when CONFIG_IPV6_MULTIPLE_TABLES is turned on.

I need to turn this on and see if I get the same results or not.

>         For a global address, v4 and v6 use the same rules--
> for a destination you can receive it on any interface for
> any global address. So, if your source address was a global
> IPv6 address and it worked, I'd guess IPv6 just isn't checking
> the source address. I don't know that it's required by RFC for
> either v4 or v6, though it's probably a good idea.

I've reproduced the multicast traffic using both global and link-local
addresses (both source and destination were of the same scope in the
tests, i.e. either global or link-local).

So, it appears that IPv6 didn't do any source verification for multicast
traffic.

-vlad

  reply	other threads:[~2007-10-19 16:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-17 19:58 multicast: bug or "feature" Vlad Yasevich
2007-10-17 20:10 ` David Stevens
2007-10-17 20:23   ` Vlad Yasevich
2007-10-17 20:29     ` David Stevens
2007-10-17 21:25       ` Vlad Yasevich
2007-10-17 23:11         ` David Stevens
2007-10-18  1:20           ` Vlad Yasevich
     [not found] ` <47166BD5.7090207@hp.com>
2007-10-17 20:19   ` Vlad Yasevich
2007-10-18 16:17 ` Vlad Yasevich
2007-10-19 11:43   ` Herbert Xu
2007-10-19 15:21     ` David Stevens
2007-10-19 16:49       ` Vlad Yasevich [this message]
2007-10-19 17:43         ` David Stevens
2007-10-19 18:43           ` Vlad Yasevich
2007-10-19 20:23             ` David Stevens
2007-10-19 20:39               ` Brian Haley
2007-10-19 21:25                 ` David Stevens

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=4718E02E.1080603@hp.com \
    --to=vladislav.yasevich@hp.com \
    --cc=brian.haley@hp.com \
    --cc=dlstevens@us.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev-owner@vger.kernel.org \
    --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 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.