Looks good to me.

In D54562#1246854, @markj wrote:

In D54562#1246807, @zlei wrote:

It sounds reasonable to extend to prefix's lifetime.

Does this also affect those prefixes leaned from route advertisement ?
What's the desired behavior when an IPv6 router advertise shorter lifetimes ?

No, this only affects the handling of the SIOCAIFADDR_IN6 ioctl. RAs can still shorten the prefix lifetime via nd6_ra_input() -> prelist_update(). I think that's reasonable: if the administrator wants exclusive control over the prefix, they can disable ACCEPT_RTADV.

Added reviewers @ivy who introduced PREF64 (RFC 8781) support for rtadvd(8), and @hrs who wrote rtadvctl(8).

It sounds reasonable to extend to prefix's lifetime.

Looks good to me.

Looks good to me.

In D42972#1242756, @glebius wrote:

Well I think you're right. if_getifaddr() ( wrapper around ifp->if_addr ) is the right accessor to get link level address. Using that directly is much simpler than a iterator.

I will assert that it is not the right accessor. The struct ifaddr has also a lot of kernel internals that drivers don't need and ideally drivers should not depend on ifaddr layout. It should be as opaque as struct ifnet. The if_getifaddr() was created with a logic "every field of ifnet needs an accessor", but proper opaque-ing of stack internals is not so straightforward.

ALso, I plan to merge each commit as a single cherry pick and push them in one go. Looks to me like the best way, if merging them in a single commit is preferred please let me know.

In D54121#1242111, @ziaee wrote:

Sorry I forgot about this! This is a great improvement.

If you want, you can silence those linter warnings by prepending a zero width space, \&.

It appears the ifp->if_addr is not set to NULL ( atomically ) while the ifnet been detached.