inet6: manally added addresses manage their own prefix

[roy_marples.name]

Summary

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.

[roy_marples.name]

• Fix a minor issue managing the prefix with prior.

[roy_marples.name]

• Fix a minor issue with prior.

[melifaro]

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?

[roy_marples.name]

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.

[emaste]

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.

[emaste]

Should we revisit this (with D36312 handled)?

[driesm]

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