[16NG] Re: flloding problem

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@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng