Summary: | Add a mode for CLAT (RFC6145 as a part of RFC6877) | ||
---|---|---|---|
Product: | passt | Reporter: | Alexander E. Patrakov <patrakov> |
Component: | general | Assignee: | nobody |
Status: | CONFIRMED --- | ||
Severity: | feature | CC: | pbrobinson, sbrivio |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux |
Description
Alexander E. Patrakov
2023-02-24 17:26:14 UTC
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. |