Re: [RFC net-next] ipv6: update NUD_FAILED neighbors from NA messages
From: Lawrence Lee <hidden>
Date: 2026-08-28 16:54:05
Also in:
lkml
On Thu Aug 27, 2026 at 9:05 AM UTC, Ido Schimmel wrote:
On Tue, Aug 25, 2026 at 06:07:44PM +0000, Lawrence Lee wrote:quoted
Sorry I should have been more specific before. Maybe a better way to phrase it is that this would be analogous to IPv4 in the sense that it allows NUD_FAILED neighbors to change states upon receipt of a NA, but by using NUD_STALE it remains consistent with RFC9131 Section 6.1.1.I think that your setup is quite unique and I don't necessarily agree with the statements regarding the CPU load, but it doesn't change my conclusion: IMO it makes sense to transition from FAILED to STALE when receiving NAs (most likely unsolicited given FAILED state). Mention in the commit message that trying to resolve FAILED neighbours by periodically probing them (e.g., using NTF_EXT_MANAGED) adds extra work compared to having the kernel stop ignoring the information that it's getting via NAs. Also mention that the approach taken here is more conservative than IPv4, which by default transitions FAILED neighbours to STALE upon receiving GARPs.
I will be sure to mention these points in the message. Is it appropriate to credit you with a 'Suggested-By' tag in the commit messages as well? I'm not sure what the proper attribution convention is here for commit message content.
Note that you also need to update the RFC 9131 comment in ndisc_recv_na() and the description of accept_untracked_na in Documentation/networking/ip-sysctl.rst. In addition, please add a test case in tools/testing/selftests/net/ndisc_unsolicited_na_test.sh Before submitting, please read: https://docs.kernel.org/next/process/maintainer-netdev.html Run the CI checks locally: https://github.com/linux-netdev/nipa#running-locally And LLM review: https://github.com/sashiko-dev/sashiko#1-local-review-recommended Thanks
Will do, thanks for the suggestions. I will submit a patch once the tree re-opens.