Re: [RFC] net: ipv4: drop unicast encapsulated in L2 multicast

On Wed, 2014-08-27 at 11:53 +0200, Hannes Frederic Sowa wrote:

quoted

I don't know if that's really useful? OTOH, there surely must have been
a reason for this to be in the IPv4 RFC, so maybe for that same reason
it should also be in the IPv6 RFC?

Either it is an oversight, but RFC6085 3) tries to at least clarify the
multicast destination with LL unicast address. So there must have been
people trying to enfore a relationship between LL address and IPv6 one.

That seems to allow a multicast IPv6 frame in a unicast LL address,
which is a different situation but still ...

I think it would be OK to drop it by default in case we don't break any
other assumptions in the stack (e.g. CLUSTERIP).

Fair enough.

quoted

The question now is, in the absence of such a latter required check (and
indeed, in the case of CLUSTERIP), how we implement such a check.
Perhaps a sysctl is needed after all?

Yeah, unfortunate situation.

One could add those IP addresses as broadcast addresses (/32) to the
routing table, so the brd_input jump would be taken.

But this would still break users of CLUSTERIP until they install those
routes. :(

I'm not even sure I understand this part :)

Any suggestions?

As long as IPv6 doesn't mandate it in the RFCs I'm not really sure we
should just drop it, even if we think it won't cause any problems?

CLUSTERIP seems like a special configuration, but I'm not sure it can be
detected and automatically allowed?

johannes