IPv6 neighbors get added too eagerly

[ghost]

When receiving an IPv6 neighbor solicitation packet, the sender gets added to the neighbor cache even if the NS was not intended for this node. Then a NS packet is sent back to the sender.

This has some bad consequences:

• The neighbor table gets filled up quickly with addresses that don't have any intention to communicate with the Zephyr node.
• Zephyr generates unnecessary NS packets to addresses it doesn't want to communicate with. In networks with many Zephyr nodes there will be avalanches of NS packets triggering new NS packets.
• On an Ethernet segment with N Zephyr nodes, the neighbor cache size must be >=N, otherwise the network is saturated with NS packets between the nodes.

This behavior strikes me as odd, and not in line with RFC 4861 section 7.2.3 which states that neighbor solicitation packets to an address not on the receiving interface should be discarded.

The responsible code is in handle_ns_input() which calls handle_ns_neighbor() too early (before deciding to respond the the NS), which calls net_ipv6_nbr_add().

Any idea if this behavior is intentional? Would anything break if it were changed to add a cache entry only in the cases where a neighbor advertisement gets sent?

Environment: zephyr-v2.1.0-915-gd4ad36e8d6
Impact: Annoyance, NET_IPV6_MAX_NEIGHBORS must be set unnecessarily high

[tbursztyka]

Any idea if this behavior is intentional?

No, that's clearly a bug.

Would anything break if it were changed to add a cache entry only in the cases where a neighbor advertisement gets sent?

Well no, it would fix the bug you found :)

[jukkar]

Would anything break if it were changed to add a cache entry only in the cases where a neighbor advertisement gets sent?

Would you be able to submit a PR that fixes this?

[ghost]

Would you be able to submit a PR that fixes this?

Yes, that is my intention.

[jukkar]

Would you be able to submit a PR that fixes this?

Yes, that is my intention.

Thanks, much appreciated!