ip6_tryforward() decrements the hop limit after the outbound pfil hooks,
whereas ip_tryforward() and ip6_forward() do it before them. The hooks
therefore see a packet one hop older than the one that leaves, and a hook
that transmits the packet itself does not decrement it at all: pf's
route-to and reply-to on an outbound state send it on with the hop limit
it arrived with.
Decrement it right after the check, before the route lookup, as the other
two paths do. Errors sent after that point quote the decremented value,
as they do on those paths.
pf_refragment6() hands the fragments of a forwarded packet it
reassembled to ip6_forward(), which decrements the hop limit again, so
on the slow path such a packet has always lost two hops at this router,
and with this change it would on the fast path as well. Give the hop
back before ip6_forward(), unless ip6stealth is on, in which case
neither path decrements. fragmentation_pass:v6_refrag_hlim checks both
paths.
Fixes: 5a1842a2 ("Add ip6_tryforward() - a run to completion ...")
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")