I meant this thread: https://lists.freebsd.org/pipermail/freebsd-net/2019-October/054632.html

We removed this code two years ago, since it adds big penalty for routers where are tens of thousands IPv6 routes.
However, someone in the mail list recently complained that we have not a method for route expiring, probably we can rework this code to implement such feature.

Commited in rS355712.

Update the patch.

Since replay field is optional, I think you need add the check that it is not NULL.

I think there is no need in such comment.

LGTM.

The most of code that uses m_pullup() does check first, that the call is needed. Do you think that now it is considered as light enough, to do not check this?

Make address copying also conditional for consistency.
Add comment describing the goal of condition.

In D22243#486266, @lutz_donnerhacke.de wrote:

If copying the LL addr is happening every time a parent interface is added (bcopy) , why not schedule the update too unconditionally?
It will only happen on changing the parent interface anyway.

I'm agree with the change, but I have doubts that we have fixed all places in the kernel, where zone id is checked and properly initialized. Usually we keep zone id embedded in the address. Do you have some tests to check this code?

If you know that the problem occurs only with BPF, bpfwrite() invokes if_output() already in epoch section.

Does this mean that you concluded in the IETF mailing list to drop this support?

What happens ifp->if_softc will become NULL just after this 'if (sc == NULL)' check? It looks like epair_remove_ifp_from_draining(ifp) also uses if_softc field.

Committed in https://svnweb.freebsd.org/changeset/base/349267
Forgot to specify phabricator URL...

In D20616#445619, @kristof wrote:

Only if the firewall needs to read/write actual packet data. Protocol headers (TCP, IP, etc.) are always stored in a normal mbuf at the start of a packet's mbuf chain. Unmapped mbufs only hold payload data that is stored in a socket buffer, so most of the filters I can think of off the top of my head as well as things like NAT should only operate on the normal mbuf holding the headers.

Okay, thanks. That should indeed just work. The 'pf_check_proto_cksum()' flow, assuming there's no hardware assist, might break. I suspect that hardware which uses unmapped mbufs is always going to have checksum offload, so that's probably not an issue either.