[PATCH] fw4: add masquerade-prefix snat type

[Jonas Lochmann]

On Sun, Jan 12, 2025 at 10:17:01PM -0500, Michael Richardson wrote:
> 
> Hi, I understand the that this does *NPTv6* RFC6296 when forwarding traffic
> with source addresses that do not fit into the uplink ISP.

I do not agree with this. NPTv6 as described in RFC6296 is about stateless
prefix rewriting. Due to that, it is limited to the prefix length of the
smaller network. This patch is implementing stateful address rewriting
that is not limited to the prefix size of the smaller network.

In scenarios like load balancing, the system is stateful in any case
because one TCP flow must use the same source IP (and thus uplink) during
its whole lifetime (assuming that we do not use multipath TCP).

Another reason for the statefulness is the processing of traffic from the
uplink: It is not clear if the corresponding outbound traffic was
rewritten or not, e.g. because the flow started before the prefix from
this uplink was announced or not announced anymore in the private network.

All in all, I consider calling this feature NPTv6 misleading.

> You've called this masquerade-prefix, and I think that will confuse people
> into thinking it's like "NAT44" aka NAPT, when it's different.

After an internet search, I assume that NAT44 is a stateful NAT using a
source address pool with random source ip selection. I assume that NAPT
describes the rewriting of the source port in case of conflicts or in
any case (different sources indicate different behaviors).

The IPv4 pool in this case could be considered a prefix. On the other
hand, I consider it well known that a "masquerade" does not allow
configuring a source IP. Due to that, I consider the "masquerade-prefix"
something where the router should already know the possible source IPs.
In case of IPv4, I do not see anything in OpenWrt that could provide
these IPv4 prefixes.

While there is the possibility to extend this patch with a "randomize"
option to select the source IPs (for IPv6) randomly from the pool
instead of deterministically, I do not see a good use case for this.
While this could be a substitute for the IPv6 privacy extensions, the
regular masquerade for IPv6 would already solve this need.