[16NG] Re: flloding problem

Hi Alex,

> What do you think about 'IPv6 flooding' not being ff:ff.. but '33:33',
> and about the necessity to not deliver a multicast IPv6 packet to an
> IPv6 stack that hasn't expressed interest in it?  Is this necessary in
> your view?

I thought it over. Ok, I think we don't have to allow flooding (though you
think the flooding MUST NOT be allowed).

>From now on, Iet's focus on the multicast which avoids flooding.

Thanks,
Jihoon

2007/1/19, Alexandru Petrescu <alexandru.petrescu@motorola.com>om>:
>
> Jihoon Lee wrote:
> > Hi Alex,
> >
> >> More specifically, we can define it as being packets addressed to
> >> any link-layer address prefixed by 33:33 (see the post-scriptum
> >> why).
> >
> > Sure. I agree. To support IPv6 transparently over ETHCS over 802.16,
> > multicasting (or broadcasting) packets in both directions of which
> > MAC addresses are 33:33:x:x:x:x is sufficient.
>
> Let's focus on the flooding problem, not solution.

> >> I think we need to identify what are the means to avoid flooding.
> >
> > I'm sorry, I don't know what you're referring to. Anyway, I presume
> > that you mean that flooding (i.e., broadcast) is inefficient in terms
> >  of bandwidth usage comparing to multicast. Am I correct?
>
> Ok, flooding is not broadcast.
>
> Up to now we agreed flooding is sending to 33:33-prefixed packets.
> Broadcast is sending to ff:ff:ff:ff:ff:ff address.  It's completely
> different.
>
> > As Gabriel said before, it's about efficiency. IMHO, supporting
> > either multicast or broadcast (just flood 33:33:x:x:x:x packets)
> > should be fine.
>
> Ok, I must say I disagree.  I completely respect Chair indications with
> respect to administrative, but I think that oppinion was expressed as a
> technical oppinion, not as Chair, so anyone can disagree with it.
>
> It is a very strong goal, and much more than qualifying as 'efficient or
> less efficient', to not deliver the IPv6 multicast packet to a stack
> that hasn't indicated willingness to participate into that multicast
> group.  Or, to deliver a multicast packet only to a stack that has
> expressed interest in it.  This is a requirement, as I see it.  What do
> you think?
>
> I can mention a scenario where this flooding can become a tsunami: if
> one doesn't use link-layer filtering rules, or MLD, then an attacker can
> send a packet to a 33:33 address and falsely put 33:33 in its src
> address.  At which point everybody will respond to everybody, and more
> everybody to everybody, etc.  A broadcasted NS is but an example.
>
> Oftentimes this behaviour that I called 'tsunami' people call actually
> 'flooding'.  So our flooding problem would be so too.
>
> What do you think about 'IPv6 flooding' not being ff:ff.. but '33:33',
> and about the necessity to not deliver a multicast IPv6 packet to an
> IPv6 stack that hasn't expressed interest in it?  Is this necessary in
> your view?
>
> Alex
>