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

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

On 2024-04-12 12:00, Brian Candler wrote:
> 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.

The idea is to not have regular IPv4 sockets, it'll always use the CLAT. 
However,

>
> 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.

Yeah we're just gonna stuff things into an /etc/clat.conf just like we 
have /etc/resolv.conf but uh anyway.

>
> 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.

Yeah this is doable, we can reject IPv6 source addresses (and thus IPv6 
connections/packets) in libc too.

>
>
> 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?

0.0.0.0 is mapped to ::, we're still deciding how to best handle 
127.0.0.0/8, or broadcast/multicast... The latter will be necessary for 
DHCPv4 at the least.

>
> 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.

We're pretty excited about this part because, without an IPv4 stack, we 
don't have to worry about IPV6_V6ONLY. This is NAT64/SIIT, and not 
IPv4-mapped, thus it is not affected by IPV6_V6ONLY. In fact, we don't 
even need to support IPV6_V6ONLY, attempting to use it (either setting 
it on or off) can simply return an error.

If the same app binds on both sockets, it'll likely be using the same 
libc for both, and with any luck we can manage that at the libc level. 
We do not plan to support split deployments with a separate IPv4-only 
app and an IPv6-only app on the same port - a significant departure from 
classic IPv4-mapped, which does attempt to support this use-case, often 
to the pain of everyone involved. In fact, we'd even argue this approach 
solves a significant hurdle with traditional IPv4-mapped, because 
ultimately this is one of the reasons FreeBSD and some other BSDs don't 
ship IPv4-mapped support by default (or at all, as the case may be).

>
> 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.

Those are surprisingly easier to support, since they generally use a 
random port.

>
> Regards,
>
> Brian.
>