On 07/03/2025 11:30, Fernando Gont wrote:
>
> In a lot of scenarios -- despite rather religious claims against that
> direction -- you may solve the problem as suggested doing NAT for IPv6.
> (particularly if this is one of the many problems you have on your table
> to solve, as is the case for many organizations)).
I think it is also worth mentioning that this is by no means a problem
with IPv6. Solving the same issue on IPv4 would be exactly as complex as
any solution on IPv6.
The only difference is that on IPv4 we generally don't care about
end-to-end principle, while in IPv6 we try to preserve it as much as
possible. Which is probably a good thing, but if this prevent us from
deploying IPv6, then I would say it is still better to have some
reachability to IPv6-only resources, be it via a proxy server (these
ancient protocols still exist!) or some sort of NAT than to have no IPv6
reachability at all.
I also agree with this, very good point. Multihoming is a layer 3 issue, not an IPv6 issue. And in a small/medium site, it is aggravated by the fact that the tools traditionally used to tackle the issue, such as BGP and PI addressing, are not available or it is not scalable to make them available for all.
IPv4 got NAT with the excuse of address scarcity, and then it was turned into a crude routing tool. IPv6 has the experimental NPTv6 which is simply NAT but with all the non-routing aspects removed -- it has the luxury of only changing the "locator" bits (if we ignore the checksum workaround) since there is no scarcity on either side of the translator and thus no need to overload.
Now... with a good stretch of the imagination you could see NPT as a way of "forcing" the return packet to be segment routed, albeit without a SRH and without encapsulation. The traffic path is anchored to the node performing the translation. But for some reason SRv6 is currently less controversial than NPTv6.
Paolo