ISPs start deploying customer-facing IPv6-only networks, and expect customer routers or operating systems to contain a CLAT component for accessing IPv4-only networks via translating this to a special IPv6 prefix. Oversimplifying, it is typically a NAT between 0.0.0.0/0 and 64:ff9b::/96. There are already some solutions for this on Linux, but they are not ideal. 1) https://github.com/toreanderson/clatd: uses Tayga and a TUN device under the hood. It is a pure userspace solution, but a bit too invasive in how it operates: instead of translating IPv4 traffic to the already assigned IPv6 address, it has to find a definitely-unused one in the same network (which is not possible in DHCPv6-only networks), and route it through the tun. 2) https://github.com/NICMx/Jool: a kernel module which does the needed protocol translation. Well, it is an external module and therefore taints the kernel. What passt already does looks like a suitable approach to solving the CLAT problem in userspace. I mean: * Create a "clat" tun or tap interface, assign 192.0.0.1 to it (see RFC6333), add a high-metric default IPv4 route. * Figure out the PLAT prefix via the procedure specified in RFC7050. * Translate between L2/L3 IPv4 TCP/UDP/ICMP packets on the "clat" interface and L4 socket-based operations on IPv6 connections towards the PLAT prefix - and this is something very close to what passt already does. Other translation mechanisms, such as MAP-T, might also be valid targets.
Hi Alexander, Thanks for proposing this feature and for sharing your research. I'm not familiar (yet) with RFC 6333, but I have a couple of questions meanwhile: - this would just apply to namespaces (pasta), correct? My understanding is that we need coordination with the tap interface, which we can't guarantee with a virtualised guest. Or is there a margin to force the configuration steps required by RFC 6333 via NDP or DHCPv6? - do you plan to contribute to this? - would it be possible to sketch this (at least temporarily as a reference) with a script that configures pasta (addresses and routes) according to what we need?
Hi, Regarding the first point: there is no namespace and no virtualized guest. Just a host with a single network namespace, in which there are the following interfaces: lo (the usual loopback interface, 127.0.0.1 and ::1) and eth0 (or whatever else, with the 2001:db8::1234 address, assigned by whatever means usually used for configuring this interface, and no IPv4). In the same namespace, one is supposed to run the third mode of the daemon (neither pasta nor passt, let's call it pclat). plcat will then create a tun or tap interface, pclat, and assign an address, 192.0.0.1, and add a default IPv4 route through the tap interface. Some random application wants to connect to 198.51.100.123 port 80. As such, a SYN packet goes through the pclat interface (because it is the only interface that has the default IPv4 route) and is then processed by the new pclat daemon. Assuming that the PLAT prefix discovery at the daemon startup has resulted in 64:ff9b::/96, the daemon would then create a socket that connects to 64:ff9b::198.51.100.123 port 80, and then copy data between the socket and the packets traveling over the pclat interface. Regarding the second point: right now I am busy with other things, but in the future - maybe. Regarding the third point: no, because now passt/pasta does not have code that translates between address families - that's the whole point of the ticket.
(In reply to Alexander E. Patrakov from comment #2) > Regarding the first point: there is no namespace and no virtualized guest. > Just a host with a single network namespace, in which there are the > following interfaces: lo (the usual loopback interface, 127.0.0.1 and ::1) > and eth0 (or whatever else, with the 2001:db8::1234 address, assigned by > whatever means usually used for configuring this interface, and no IPv4). In > the same namespace, one is supposed to run the third mode of the daemon > (neither pasta nor passt, let's call it pclat). plcat will then create a tun > or tap interface, pclat, and assign an address, 192.0.0.1, and add a default > IPv4 route through the tap interface. > > Some random application wants to connect to 198.51.100.123 port 80. As such, > a SYN packet goes through the pclat interface (because it is the only > interface that has the default IPv4 route) and is then processed by the new > pclat daemon. Assuming that the PLAT prefix discovery at the daemon startup > has resulted in 64:ff9b::/96, the daemon would then create a socket that > connects to 64:ff9b::198.51.100.123 port 80, and then copy data between the > socket and the packets traveling over the pclat interface. It makes sense, thanks for the practical application example. I was thinking there could still be a separate namespace with just the tap interface, in case you want to isolate the IPv4-only application on the IPv6-only host. But I see, it would be convenient to not require that, and probably it shouldn't be the default mode either for this case. The only problem I see is that we would require security capabilities on the init namespace ("host"): creating a non-namespaced tap device needs (at least) CAP_NET_ADMIN. It would be a different operational mode, without the security promises associated to passt and pasta, so I don't see it as a big issue, but that requires some extra care in terms of what possible isolation steps we can still carry out (see isolation.c). > Regarding the second point: right now I am busy with other things, but in > the future - maybe. Okay, great. I'll keep you posted in case somebody else is interested or finds the time for this meanwhile. > Regarding the third point: no, because now passt/pasta does not have code > that translates between address families - that's the whole point of the > ticket. Right, indeed.