Re: [v6ops] Are we competitive?

[Vasilenko Eduard <[e-mail]>]

Gábor, Soni,
Thanks for your comments.
It still looks like NAT66 is not a requirement for translational technology.
Ed/
From: v6ops [mailto:[e-mail]] On Behalf Of Soni "They/Them" L.
Sent: Wednesday, August 10, 2022 11:21 PM
To: Gábor LENCSE <[e-mail]>
Cc: IPv6 Operations <[e-mail]>
Subject: Re: [v6ops] Are we competitive?

(attempting to re-send this because something seems to have gone wrong...)

On Wed, Aug 10, 2022, 08:01 Gábor LENCSE <[e-mail]<mailto:[e-mail]>> wrote:
Dear Eduard,

TAYGA is a stateless NAT64 implementation. We use it for educational
purposes: we demonstrate stateful NAT64 using TAYGA (stateless NAT64) +
iptables (stateful NAT44). We use it because it is easy to configure and
everything can be easily observed and debugged (unlike with the much
more powerful Jool stateful NAT64 solution).

1. why with NAT44 instead of NAT66?
2. can jool really use the same 192.0.0.2 on all clients? it seemed to use 1918 and 100.64.0.0/10<http://100.64.0.0/10>?


However, I would not recommend TAYGA for ISP-s due to performance
issues. (It works in userspace and it is not able to utilize more than a
single CPU core.)

ohh. but it's fine for hotspot software? why isn't hotspot software using 464 instead of 1918? it's gonna be NAT either way but one of them at least stress tests IPv6 in the wild.


Best regards,

Gábor


8/10/2022 12:12 PM keltezéssel, Vasilenko Eduard írta:
> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Soni "They/Them" L.
> Sent: Wednesday, August 10, 2022 12:49 AM
> To: [e-mail]<mailto:[e-mail]>
> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops