pf: Make af-to less magical

Summary

Contributed by Peter N. M. Hansteen on 2026-01-16 from the raising my family dept. Seasoned networkers will know to tell you that legacy IPv4 and modern IPv6 are, in fact, not directly compatible, and shipping traffic between IPv4 and IPv6 network requires address family translation. On our favorite operating system and its siblings, that special case has been handled via the af-to option and special case rules since back in the OpenBSD 5.1 days. But that special case has always felt a bit awkward to some, and now David Gwynne (dlg@) is airing a patch on tech@ with a view to making af-to "less magical". In the message titled pf: make af-to less magical, David explains the motivation, List: openbsd-tech Subject: pf: make af-to less magical From: David Gwynne <david () gwynne ! id ! au> Date: 2026-01-16 2:11:57 Message-ID: aWmebWvdwBi6z98j () animata ! net i only recently figured out that af-to is very special in pf, but i dont think it should be. currently af-to has the following restrictions: 1. it only works for incoming packets, ie, you can only use it on "pass in" rules in pf. 2. it forces the translated packet to be forwarded. a consequence of these, and 2 in particular, is that only one state is created for an af-to connection over the firewall. this is unlike other forwarded connections where there's generally two states created, one when the packet comes in from the wire into the stack, and another when the packet goes out from the stack to the wire. this difference means that af-to is special cased in pf a lot. i'm arguing that it would be better if we made af-to less special, which is what this diff does. the important bit here is af-to no longer forces forwarding of packets. this is implemented by having pf_test called by ip_input push the translated packet into ip6_input instead of ip6_forward. this leads to a problem where we need to skip processing by pf_test in this nested ip6_input call after the packet has been translated. this is the same problem we...