[16NG] Re: flloding problem

["Jihoon Lee" <jhlee at mmlab.snu.ac.kr>]

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 at motorola.com>:

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

_______________________________________________
16NG mailing list
16NG at ietf.org
https://www1.ietf.org/mailman/listinfo/16ng