[v6ops] Re: CLAT-in-libc and possible interactions with draft-ietf-v6ops-claton?

[Brian Candler <[e-mail]>]

On 27/07/2024 20:03, Soni "It/Its" L. wrote:
>
> say you have an ipv4 listen socket, you accept on it, and a connection 
> comes in.
>
> accept is generally expected to fill in a struct sockaddr with the 
> peer address.  since the OS doesn't have ipv4, "CLAT-in-libc" has to 
> fetch the NAT64 prefix and translate the IPv6 NAT64 address of the 
> peer to its IPv4 representation.
>
> "Fetching the NAT64 prefix", for practical purposes, involves reading 
> /etc/clat.conf.  It's not particularly expensive, but it isn't free 
> either.

I'd say it's insignificant in the bigger picture of what an application 
already has to do on each incoming connection.

I don't think you can avoid this functionality though. Although accept() 
takes a pointer to a generic struct sockaddr, any application which 
opened a v4 socket is likely to be hard-coded to pass in a sockaddr_in, 
and parse it as such.  You can't return a sockaddr_in6 and expect it to 
work in the general case.

You might be thinking of a server application accepting thousands of 
connections per second. If the reading of clat.conf on each connection 
were a problem, I guess it could cache the contents of /etc/clat.conf in 
RAM as a small optimisation (remembering that the NAT64 prefix *could* 
change over time)

But would you really expect a high-performance server to be sitting on a 
v6-only network, configured to accept v4 connections, as an important 
use case?

The "translating the IPv6 NAT64 address of the peer" only applies if the 
PLAT were accepting IPv4 connections and forwarding them - which in turn 
means configuration of port forwarding on the PLAT. Maybe you'd do that 
in a home network, but I'd be surprised if much of that happens much in 
a provider network. I guess with PCP/uPNP etc it would be possible in 
principle.

I think in the main reason to map listening sockets as just a matter of 
completeness, and to allow applications which choose to open a (v4) 
listening socket to run without crashing on a v6-only network.


>
> If instead you have an IPv6 listen socket, why go through all that 
> effort just to convert NAT64 addresses into v4mapped addresses?

Obviously, an application which natively opens an IPv6 listen socket 
will see IPv6 source addresses.  Or IPv4-mapped ones (under certain OSes 
and with dual stack).  Or it will see IPv4 addresses with a NAT64 
prefix, but only if the PLAT does inbound port forwarding.  I don't see 
a need to mess with any of those.

But if the application opened an IPv4 socket, but the libc shim actually 
gave them an IPv6 socket, then it would have to do the translation - 
because if the application calls getpeername() or accept() etc it will 
expect to see an AF_INET address.


>
>> I also don't get what situation you're referring to which requires 
>> "the traditional thing of opening two connect sockets", unless you're 
>> talking about Happy Eyeballs? Or do you mean that the client would 
>> open *either* an IPv4 *or* and IPv6 socket? That's fine.
>>
>
> That's the latter, yeah, the application would just use IPv4 sockets 
> when connecting to IPv4 addresses, and IPv6 sockets when connecting to 
> IPv6 addresses.  As it generally does today.

I see no issue with that behaviour an IPv6-only host with this libc 
shim. The natural behaviour would be if the application:

- open an IPv6 socket: it just passes through
- open an IPv4 socket: the shim converts it to an IPv6 socket and 
adds/removes the NAT64 prefix as necessary on connect(), accept(), 
getpeername() etc.

However, if an IPv6 socket is given an IPv4-mapped address to connect 
to, I think it would be easy enough to convert this to NAT64 prefix+IP 
address as well. Then both types of application are handled equally well.

Regards,

Brian.