Re: [v6ops] Are we competitive?

Hi Soni,
I do not understand how your comment is relevant to NAT66.

If the source traffic is private IPv4 then indeed we need stateful translation somewhere.
lw4o6 and MAP-E/T prefer to do the stateful translation on the client.
DS-Lite, 464XLAT, and DS-Lite prefer to do the stateful translation on the CGNAT.
NAT66 requirement is not visible in any translation RFC.

Sorry, I am not familiar with TAYGA implementation.
And could not guess which one RFC it breaks.
Eduard
-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Soni "They/Them" L.
Sent: Wednesday, August 10, 2022 12:49 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] Are we competitive?

On 2022-08-09 18:16, Clark Gaylord wrote:
>
> That there are commercial NAT66 offerings is less compelling. Vendors 
> frequently want you to do bad things. NAT66 suffers from the same 
> problem as NAT44 -- there is no exit strategy. NAT64 is specifically a
> *transition* technology and over time there is less and less NAT.
>

how do you make it so e.g. TAYGA uses the same client IP(v4) for all CLATs without NAT66, i.e. without mapping IPv6 addresses to a single canonical, internal IPv6 address (maybe [::1]) for TAYGA to use?

since TAYGA is stateless, it wants to map single IPv6 to single IPv4.
"true" NAT64 using the DS-Lite range requires the use of NAT66 + TAYGA, otherwise you have to use 1918 (or, alternatively, CGNAT addresses) +
NAT44 + TAYGA.

(still trying to see if this works, haven't had the time to play with it... still annoyed at the lack of out-of-box linux distro 464XLAT support also.)

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops