On Wed, 2014-08-27 at 11:53 +0200, Hannes Frederic Sowa wrote: > > 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
