LGTM.

It seems to have affected MLDv6: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407

Yes, I think they were replaced with handlers from ipfw_sopt_handler.

LGTM.

LGTM.

I think adding MPASS is better than removing. There is no locking, and it is still possible, that the code you are modifying will first get ifp pointer and then this ifp will be unlinked and marked as DYING :)

• Add example of comapt layer.

• Rebase
• Document some features, also reduce the diff.
• Fix skipto/call arguments parsing.
• Fix mismerged reass/return opcodes
• Fix ipfw32 opcode version for NAT44 opcodes.
• ipfw: rework call action to drop packets on errors

It looks a bit confusing when you set net.inet.ipsec.random_id=1 and it does not work because default value of net.inet.random_id is 0.
It should be documented in ipsec(4).
Maybe just make ip_fillid_ex as ip_fillid_ex(struct ip *, bool do_randomid) and set net.inet.ipsec.random_id=0 by default?

In D49053#1118518, @zlei wrote:

> Do you think a IN_IS_ADDR_MULTICAST akin to IN6_IS_ADDR_MULTICAST is valuable ?

In D47534#1085033, @jlduran wrote:

Sigh, it looks like this commit broke the following test:

# create two interfaces
if1=$(ifconfig epair create)
if2=$(ifconfig epair create)
# assign IP addresses in the same subnet
ifconfig $if1 inet 192.0.2.1/24
ifconfig $if2 inet 192.0.2.2/24
# Verify that the route points to the first interface (fails, as $if2 was added last, it points to $if2)
netstat -r4n | grep 192.0.2.0/24

IMHO, we need to fix this behaviour. 
First PINNED route should have priority and second attempt to add the same route on $if2 should fail with EEXIST.
But then the test will fail, because after address deletion from $if1 there will not be any PINNED routes.