[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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