Re: [v6ops] Our IPv6-only home network and future experiments

[Brian Candler <[e-mail]>]

On 12/04/2024 15:04, Soni "They/Them" L. wrote:
> If we get CLAT in libc working, then we'll move on to enabling the use 
> of this OS on IPv4-only and dual-stack networks, but again without 
> introducing an IPv4 stack. This can be done by taking IPv4 packets 
> from the wire, without passing through any functionality associated 
> with an IPv4 stack (routing, packet filtering, or connection 
> tracking), and turning them into IPv6 packets, which then go on to get 
> processed by the IPv6 stack. The combination of CLAT in libc and this 
> non-traditional SIIT would allow the OS to be deployed on existing 
> IPv4-only and dual-stack networks, fully implemented without an IPv4 
> stack.

Since you say "CLAT in libc", presumably this is in the context Linux or 
other Unix-like systems. I expect you're already aware of the 
"IPv6-mostly" mechanisms to signal to a client that it should use a CLAT 
(RFC8925 for DHCP option 108, RFC8781 for PREF64 in router advertisements).

If you're thinking about doing this in libc, I presume the plan is to 
map a call to open an IPv4 socket into a call for opening an IPv6 socket 
instead. This isn't an approach I've seen attempted before, and it'll be 
really interesting to see how it pans out. Normally, CLAT requires its 
own IPv6 address to use as the source (to distinguish incoming 464XLAT 
traffic from regular IPv6 traffic). But since each socket effectively 
will have its own CLAT then that may not be necessary, since the kernel 
already keeps track of which ports belong to which sockets.

Potential issues I can see:

1. libc needs to decide whether to use the CLAT in preference to regular 
IPv4 sockets, e.g. by detecting the presence of an active IPv4 stack or 
default route, and/or the presence of DHCP option 108.

2. Every process would have to do discovery of the NAT64 prefix for 
itself, unless this information is published in a system-wide location 
that can be queried (which should include RFC8781 so that no DNS64 is 
required, or spoofing of ipv4only.arpa). It might get tricky if there 
are multiple NAT64 prefixes learned from different interfaces; there is 
a choice to be made.

3. There are some cases where you might want to map IPv6 addresses back 
to IPv4 addresses, e.g. the source address on recvfrom(). That sounds 
doable.

4. What do you do if an application binds a socket to an explicit IPv4 
address like 127.0.0.1? What about an IPv4 wildcard address 0.0.0.0? Do 
you map to ::1 and ::, or do you just fail them?

I note that there are several ways an application which listens for 
incoming connections or binds source address for outgoing connections 
might work:

a. it could open a single socket bound to 0.0.0.0 (legacy IPv4-only 
application)
b. it could open two sockets, one bound to 0.0.0.0 and the other to :: 
(with IPV6_V6ONLY for the latter)
c. it could open a single socket bound to :: with IPV6_V6ONLY disabled

If you fail case (a) then the application may not work at all; but if 
you allow case (a) then case (b) may fail due to conflicting ports.  And 
the default for IPV6_V6ONLY is set system-wide in 
/proc/sys/net/ipv6/bindv6only.

Having said that, accepting incoming traffic for an application that 
opens an IPv4-only socket is probably not a big concern. I'd just wonder 
about an app that binds to 0.0.0.0 before making an outbound connection.

Regards,

Brian.