Change Details

When pfctl parses a pool it is aware of address family of each host, at least when a host is an explicitly given IP address, not a pool or interface. But kernel can't receive nor store this information in struct pf_kpooladdr. Introduce pfctl_pooladdr and modify pf_kpooladdr so that address family can be preserved. Struct pf_nl_pooladdr already contains a variable for address family, but it was not used. Use it to send address family with pool addresses when loading pools. Another option would be to modify struct pf_pooladdr but that is used in the old ioctls and those can't be modified without breaking compatibility. Modify pfctl's print_pool to not recover address family from rule but use the stored address family for each address. Update source nodes to handle two address families: of the search address and of the redirection address. Modify nat and route source node creation to use pre-nat address family for search address and pool address family for redirection address. Even without RFC5549 this solves issues with source tracking for nat64 rules: it's the original IPv6 source address which gets mapped on an IPv4 gateway or IPv4 SNAT address. When reading states using netlink introduce PF_ST_RT_AF, so that pfctl does not need to recover route-to gateway's address family from the rule. Modify pf_map_addr() so that it is given a wanted adress family which is then compared to address family of stored addresses. For RFC5549 operation in round-robin mode each address (which can be a table or an interface) is evaluated twice: first for IPv6, then for IPv4. For RFC5549 operation the found address family will overwrite the requested wanted address family. In pf_route() check rt_af, it is not guaranteed to be AF_INET anymore because pf_map_addr() could have changed it. Construct appropriate gateway using rt_addr. ---- 8< ---- I still need to see how this works with pool types other than round-robin and single hosts, and there seems something wrong with source tracking for af-to.

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.

When pfctl parses a pool itNow that pf is aware of address family of each host,pool address and source at least when a host is an explicitly given IP address, not a pool ortracking uses distinct address family for source and redirection interface. But kernel can't receive nor store this information inadddresses it is possible to add a new pool option prefer-ipv6-nexthop struct pf_kpooladdr. Introduce pfctl_pooladdr and modify pf_kpooladdrwhich enables routing of IPv4 packets over IPv6 next hops for rules so that address family can be preserved. Struct pf_nl_pooladdr already contains a variable for address family, but it was not used. Use it to send address family with pool addresses when loading pools. Another option would be to modify struct pf_pooladdr but that is used in the old ioctls and those can't be modified without breaking compatibility. Modify pfctl's print_pool to not recover address family from rule but use the stored address family for each addresswith the route-to option. Update source nodes to handle two address families: of the searchAdd a pool option flag PF_POOL_IPV6NH, apply it to pools with a keyword address and of the redirection prefer-ipv6-nexthop. Modify pf_map_address. Modify nat and route source() to handle pools with addresses of different node creation to use pre-nfamilies. Use *naf as a hint about what address family for search address andthe forwarded pool address family for redirection address.packet is, Even without RFC5549 thisthen pick from the pool addresses of family that can be used solves issues with source tracking for nat64 rules: it'sas a next hop for the forwarded packet, controlled by the originalPF_POOL_IPV6NH IPv6 source address which gets mapped on an IPv4 gateway or IPv4 SNATflag. For NAT pools this flag is never set and thus pf_map_addr() address. When reading states using netlink introduce PF_ST_RT_AF, so that pfctlwill return an IP address of the same family as the forwarded packet. does not need to recover route-to gateway'sFor route-to pools when the flag is enabled IPv6 address family from thees can be rulereturned or IPv4 packets. Modify pf_map_addr() so that it is given a wanted adress family which is then compared to address family of stored addresses. For RFC5549 operation in round-robin mode each address (which can be a table or an interface) is evaluated twice: first for IPv6, then for IPv4. For RFC5549 operation the found address family will overwrite the requested wanted address family. In pf_route() check rt_af, it is not guaranteed to be AF_INET anymore because pf_map_addr() could have changed it. Construct appropriate gateway using rt_addrit (as *naf). ---- 8< ----Add tests for behaviour of pf_map_addr() both with PF_POOL_IPV6NH and I still need to see how this works with pool types other than round-robin and single hostswithout, for single IP addresses, and there seems something wrong with source tracking for af-toprefixes and subnets.