Page MenuHomeFreeBSD

inet6: manally added addresses manage their own prefix
Needs ReviewPublic

Authored by on Aug 23 2022, 10:31 AM.
Referenced Files
Unknown Object (File)
Sun, Jul 7, 4:25 PM
Unknown Object (File)
Thu, Jul 4, 10:43 PM
Unknown Object (File)
Mon, Jul 1, 5:25 PM
Unknown Object (File)
Fri, Jun 28, 11:42 AM
Unknown Object (File)
May 21 2024, 1:20 PM
Unknown Object (File)
May 4 2024, 3:16 AM
Unknown Object (File)
Apr 27 2024, 8:17 AM
Unknown Object (File)
Apr 22 2024, 8:52 AM



Manage prefixes dervied from adding/deleting addresses via ioctl
seperately from those derived from Neighbor Discovery.

ndp(8) now only shows prefixes learned by Neighbor Discovery.
SIOCSPFXFLUSH_IN6 now only removes prefixes learned by Neighbor Discovery.

Test Plan

Setup rtadvd to announce a prefix on a router.
Setup a client to accept router advertisements.
Add an INET6 address outside of the advertised prefix.
Run ndp -p to only see the advertised prefix.
Run ndp -P to remove the advertised prefix keeping the manually added one.

Diff Detail

rS FreeBSD src repository - subversion
Lint Passed
No Test Coverage
Build Status
Buildable 47073
Build 43962: arc lint + arc unit

Event Timeline

  • Fix a minor issue managing the prefix with prior.

First of all, would like to thank you for rootcausing the issue & providing the solution.
I certainly agree that as of now, SIOCSPFXFLUSH_IN6 does not do what is supposed to and that needs to be fixed.

Speaking of the implementation, I have mixed feelings about removing prefixes derived from manually-assigned addresses from the prefix list. While the current code is certainly not ideal, concept of the abstraction prefix layer still set useful to me. Another thing is that I don't feel comfortable to merge such change to FreeBSD 12.

I'd rather prefer to address this specific issue in minimally-invasive way so it be easily backported and address the manual addresses & prefix list situation separately. I created D36312 which specifically fixes SIOCSPFXFLUSH_IN6 without touching routing layer. Do you have any concerns over landing the latter diff?

You've addressed my concerns, thanks.
If it lands, this revision no longer fixes anything as such but interestingly should still apply if anyone wants to go down the route of seperating this in the future.

I agree getting D36312 in first is the way to go, as it is a clean/straightforward MFC, and we can have a separate discussion/decision on this change.

Should we revisit this (with D36312 handled)?

IMO this revision can be closed, "overcome by events" :)