Re: [v6ops] IPREF as a transitioning tool

["Soni \"They/Them\" L." <[e-mail]>]

(Apologies for possible double-send, SMTP broke)

On 2023-11-12 07:36, Gert Doering wrote:
> Hi,
>
> On Sun, Nov 12, 2023 at 07:20:17AM -0300, Soni "They/Them" L. wrote:
> > On *that* note, it would be nice if we could extend 464XLAT to servers. The
> > main issue is how to give the server a global IPv4 for 464XLAT purposes, as
> > the way we understand it the host uses its own global IPv6 for the source
> > address, and the NAT64 prefix for the destination. (Granted you could just
> > require static IPv4 address config...) There is also something to be said
> > about moving the CLAT into the system's libc, as opposed to having it in the
> > kernel or something.
>
> For server setups, SIIT-DC seems to work well (and server applications
> are usually better controlled and can be taught to use v6 sockets).
>
> What scenarios do you have in mind where a 464xlat on the server itself
> would be beneficial, as compared to a v6-only datacenter with SIIT-DC in
> front?

SIIT-DC appears to use the same packet translation building blocks as 
464XLAT/NAT64...? (From skimming, it looks like the same thing, just 
with different names for the various components! And the addition of a 
"reverse" mode of operation, where it accepts connections from v4 hosts.)

So what makes 464XLAT (on *top* of SIIT-DC, as opposed to replacing it) 
better is the ability to let the server know about it. As well as being 
able to standardize on a protocol already supported by (some) operating 
systems (systemd is slowly working on adding a CLAT, and FreeBSD 
allegedly already has one).

>
> Gert Doering
>          -- NetMaster