Re: [RFC] ipv6: always join solicited-node address
From: Bjørn Mork <bjorn@mork.no>
Date: 2013-10-31 15:01:32
Hannes Frederic Sowa [off-list ref] writes:
On Mon, Oct 14, 2013 at 09:09:59AM +0200, Bjørn Mork wrote:quoted
Yes, but that would also make the IP layer try to resolve IP to link layer addressess both for IPv4 and IPv6, which just won't work. At least not for IPv4, where there just is no way to transport an ARP to the modem. And I assume it may fail for IPv6 too on any sane device.I don't think that clearing the IFF_NOARP flag would kill connectivity for either IPv4 or IPv6.
It does, because the neigbours cannot be resolved.
It may compromise security for IPv6 though (no idea how the telco network behind the modem looks like).quoted
quoted
Is this a specific bug of the modem you are using or are all devices powered by this driver like this?Unfortunately I have no IPv6 enabled SIM myself, so I have no information about other devices. This report was based on user feedback. I assume the bug is specific to this firmware implementation, probably extending to all similar devices from the same vendor. But it could be more common than that. The fact that the bug is there indicates that this works just fine in Windows. Yes, I realize that I am in ugly-hack-to-workaround-firmware-issues land again... But it sure would be nice to have some way for a driver to indicate that L2 neighbour tables are meaningless, but that any incoming requests should still be answered.L2 neighbour tables are resolved on demand and won't be queried for the link you are talking about (at least for IPv6, but I assume IPv4, too). A new flag should have clear semantics then: * split IFF_NOARP to IFF_NOARP and IFF_NONDISC * split IFF_NOARP to IFF_NOLLRESOLV_RESPONSE and IFF_NOLLRESOLV_MODIFY (each one flag which is applicable for both IPv4 and IPv6) I tend to lean towards the last alternative but still wonder if this is just overhead for this one buggy device.
Thanks a lot for your review and thoughts on this. I do agree 100% with your last comment here, and ended up with an in-driver workaround instead. It's not beautiful, but at least it doesn't add a lot of core code for this very special purpose. Bjørn