Post AdRKCo8a3sIDc7Jn7o by tschaefer@ipv6.social
 (DIR) More posts by tschaefer@ipv6.social
 (DIR) Post #AbbwiXGERTO1wqrs2K by Oskar456@mastodon.social
       2023-11-07T08:20:34Z
       
       0 likes, 1 repeats
       
       My effort during IETF 118 hackathon got merged. Now you can use clatd by @tore  not only with TAYGA user-space translator but also with nat46 kernel-space translator: https://github.com/toreanderson/clatd/commit/6d2ad96c2f89c86d6d93e1dfc83fd03045754e54We are still far from the universal availability of CLAT on Linux, but at least we started to move.
       
 (DIR) Post #AbbyIpbBq56DCZXelM by tore@snabelen.no
       2023-11-07T08:28:58Z
       
       0 likes, 0 repeats
       
       Thank you very much for your contribution, @Oskar456 ! 👌 It would have been much better if the functionality of clatd was included in the standard network management components like NetworkManager and systemd-networkd (honestly clatd is meant mostly as a proof of concept), but I doubt that will happen before there's a decent SIIT/NAT46 translation engine included in the upstream kernel.
       
 (DIR) Post #AbbyIrTSrm6l1BwW00 by Oskar456@mastodon.social
       2023-11-07T08:44:42Z
       
       0 likes, 1 repeats
       
       @tore definitely, that's the ultimate goal. But it still needs to be figured out what is going to do the actual packet translation.During the hackathon, I also received a tip on how to make the clat least intrusive to the host OS - that means no forwarding enabled and no fiddling with firewall.I have made a PoC and it seems to work quite well:https://gist.github.com/oskar456/d898bf2e11b642757800a5ccdc2415aaI would like to try to write a daemon to automate such a setup and eventually integrate to NM and similar.
       
 (DIR) Post #AbbzE1BFS3Jrcyg0dU by litchralee_v6@ipv6.social
       2023-11-07T18:51:46Z
       
       0 likes, 0 repeats
       
       @Oskar456 @tore Very nice! I've done something similar for a #k8s cluster that needed #NAT64 translation for its containers. One thing I did have to add was filtering within the namespace, since Jool was unexpectedly translating RFC1918 addresses when using the well-known prefix.It was unclear to me why Jool was doing that, but all was easily fixed with some reject rules for each of the rfc1918 address subnets.
       
 (DIR) Post #AbbzEIwJQK4EhrpKr2 by tschaefer@ipv6.social
       2023-11-08T23:20:43Z
       
       0 likes, 0 repeats
       
       @litchralee_v6 @Oskar456 @tore If I remember correctly android clat translates rfc1918 addresses too.(with the well known prefix)
       
 (DIR) Post #AbcANQbfO0GyaTitkG by litchralee_v6@ipv6.social
       2023-11-09T01:25:43Z
       
       0 likes, 0 repeats
       
       @tschaefer @Oskar456 @tore What I had in mind was the restriction from RFC6053 section 3.1, where the well known prefix is supposed to reject non-global legacy IP addresses.I suppose it's not a big issue if Android's CLAT tries to initiate traffic with such a destination, but the #NAT64 gateway is supposed to decline to translate that destination within the well known prefix, if I understand the RFC correctly.
       
 (DIR) Post #AdRKCo8a3sIDc7Jn7o by tschaefer@ipv6.social
       2024-01-02T15:38:12Z
       
       0 likes, 0 repeats
       
       @alexhaydock Embedded devices can already use nat46 (kmod-nat46 openwrt).You are right, I would also prefer the nf solution.