netinet6: Set PFIL_FWD in ip6_tryforward()

[rcm]

Summary

ip6_forward() has run the outbound hooks with pfil_mbuf_fwd() since
b52b61c0b6b1, and ip_tryforward() since 1f4c3887e3fa, but
ip6_tryforward() still calls pfil_mbuf_out(). pf therefore handles a
packet on the IPv6 fast path as locally generated: it skips the
packet-too-big error it sends with the untranslated addresses, and
pf_refragment6() sends reassembled packets out through ip6_output()
instead of ip6_forward(), so their fragments leave with the hop limit
not decremented.

Use pfil_mbuf_fwd() in ip6_tryforward() as well. The new
fragmentation_pass:v6_refrag_hlim test sends a packet that pf
reassembles and refragments through the fast path, and checks that its
fragments leave with the hop limit decremented once; before this change
they leave with it unchanged.

Fixes: b52b61c0 ("pf: distinguish forwarding and output cases for ...")
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")

[kp]

tests/sys/netpfil/pf/fragmentation_pass.sh

204

I figured we might as well test the slow path too, like this:

diff --git a/tests/sys/netpfil/pf/fragmentation_pass.sh b/tests/sys/netpfil/pf/fragmentation_pass.sh
index d5310d6eeb58..81a2237ec902 100644
--- a/tests/sys/netpfil/pf/fragmentation_pass.sh
+++ b/tests/sys/netpfil/pf/fragmentation_pass.sh
@@ -202,6 +202,9 @@ v6_refrag_hlim_body()

        # The fast path: pf must refragment through ip6_forward().
        refrag_hlim 0
+
+       # Test the slow path too
+       refrag_hlim 1
 }

 v6_refrag_hlim_cleanup()

But that actually fails for me. It shows this output: 4508 bytes from 2001:db8:43::3, icmp_seq=0 hlim=62 time=0.832 ms

I believe the issue is that ip6_forward() decrements the the hop limit before the pfil_mbuf_fwd() call, but ip6_tryforward() does it after.

To make it all even more fun pf also calls ip6_forward(), so in the slow path we end up decrementing twice.

And now that I look at your other reviews I see you fix that in D61039 ...