Page MenuHomeFreeBSD

pf: Add prefer-ipv6-nexthop option for route-to pools
Needs ReviewPublic

Authored by vegeta_tuxpowered.net on Jun 10 2025, 7:45 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Aug 5, 3:10 AM
Unknown Object (File)
Mon, Aug 4, 10:22 AM
Unknown Object (File)
Thu, Jul 31, 11:26 AM
Unknown Object (File)
Sat, Jul 26, 12:40 AM
Unknown Object (File)
Fri, Jul 25, 4:52 PM
Unknown Object (File)
Fri, Jul 25, 3:39 AM
Unknown Object (File)
Wed, Jul 23, 2:07 PM
Unknown Object (File)
Tue, Jul 22, 12:51 AM

Details

Reviewers
kp
Summary

Now that pf is aware of address family of each pool address and source
tracking uses distinct address family for source and redirection
adddresses it is possible to add a new pool option prefer-ipv6-nexthop
which enables routing of IPv4 packets over IPv6 next hops for rules
with the route-to option.

Add a pool option flag PF_POOL_IPV6NH, apply it to pools with a keyword
prefer-ipv6-nexthop.

Modify pf_map_addr() to handle pools with addresses of different
families. Use *naf as a hint about what address family the forwarded
packet is, then pick from the pool addresses of family that can be used
as a next hop for the forwarded packet, controlled by the PF_POOL_IPV6NH
flag. For NAT pools this flag is never set and thus pf_map_addr()
will return an IP address of the same family as the forwarded packet.
For route-to pools when the flag is enabled IPv6 addresses can be
returned or IPv4 packets.

In pf_route() check rt_af, it is not guaranteed to be AF_INET anymore
because pf_map_addr() could have changed it (as *naf).

Add tests for behaviour of pf_map_addr() both with PF_POOL_IPV6NH and
without, for single IP addresses, prefixes and subnets.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

I'm going to need to take a deeper look later (probably when I'm back home from BSDCan). First impressions are that the implementation is probably good, but I really dislike the 'RFC5549' naming of the flag and variables. Unfortunately I don't immediately have a better suggestion.

In D50781#1159156, @kp wrote:

really dislike the 'RFC5549' naming of the flag and variables. Unfortunately I don't immediately have a better suggestion.

How about:

  • prefer-ipv6-nexthop
  • prefer-ipv6-nh
  • ipv6-nexthop
  • ipv6-nh

The term "next hop" is often preferred over "gateway", at least by networking people, and is already used in man pf.conf. The option with the word "prefer" hints that the IPv6 next hop is preferred, not enforced, because the code will first try to get an IPv6 address from the pool, but if that's impossible it will try IPv4, at least for IPv4 packets. Options with "nh" instead of "nexthop" make the option shorter, for those of us who want their rules to fit in 80 columns ;)

In D50781#1159156, @kp wrote:

really dislike the 'RFC5549' naming of the flag and variables. Unfortunately I don't immediately have a better suggestion.

How about:

  • prefer-ipv6-nexthop
  • prefer-ipv6-nh
  • ipv6-nexthop
  • ipv6-nh

The term "next hop" is often preferred over "gateway", at least by networking people, and is already used in man pf.conf. The option with the word "prefer" hints that the IPv6 next hop is preferred, not enforced, because the code will first try to get an IPv6 address from the pool, but if that's impossible it will try IPv4, at least for IPv4 packets. Options with "nh" instead of "nexthop" make the option shorter, for those of us who want their rules to fit in 80 columns ;)

Yeah, "ipv6-nexthop" seems pretty good.

Couple small remarks (I do still owe you a deeper look, probably sometime next week during the hackathon):

  • we need to add something to the man page about this. In the man page we should reference the RFC.
  • there are a couple of small cleanup changes that would be better as part of a separate commit. Things like introducing struct pfctl_pooladdr, and changing 'af' from int to sa_family_t. That makes reviewing this patch easier (because smaller), and the small cleanup patches are trivially obviously correct.

I don't have strong views on the use of rfc5549 in the test names. It's fine there, but if you prefer to use ipv6_nexthop or something that's fine too.

vegeta_tuxpowered.net retitled this revision from WIP: pf: Add RFC5549 support for route-to to pf: Add RFC5549 support for route-to.
vegeta_tuxpowered.net edited the summary of this revision. (Show Details)
vegeta_tuxpowered.net retitled this revision from pf: Add RFC5549 support for route-to to pf: Add prefer-ipv6-nexthop option for route-to pools.Fri, Aug 8, 3:36 PM