jordipalet:

This is a CRITICAL BUG, because we have run out of IPv4 addresses, and the ISPs need to deploy IPv6-only access, but the CPE inside the customer network need to be able to use IPv4 for old apps/devices. 464XLAT is the easier and cheaper way to do that for ISPs, as it is proven by millions of cellular devices using IPv6-only access and 464XLAT.

Following email exchange with Hans Dedecker and the developers list, I can confirm that the CLAT (464XLAT client) is broken, I believe since OpenWRT 15.05.1. I'm able to get it working only in the 15.05.

It seems to be related to netifd logic have been reverted (https://git.lede-project.org/?p=project/netifd.git;a=commit;h=39d9ceeb96162a83a3f5fa63e6aaa1ccb38caa62).

Also, there are some needed improvements, which I believe will be easy to implement.

1. option ipv4addr '192.168.0.1' doesn't work. in the 464xlat.sh is fixed to 192.0.0.1, but according to my reading of RFC6877/7915 (and all the related ones), it should be possible to select what address and not just one address but a prefix for the translation. I believe that using just one address, if there is a lot of flows, you can run out of “ports” for that number of ports. This may not happen in a small residential network but if you have a LEDE router in an enterprise is a different history.

2. Same with option ip6addr '2001:470:68ee:30::1', it should be possible to use instead of just one address, a pool of them (a prefix).

3. I believe the default route is not being installed. In fact, in my case, I’ve a default route for in the WAN interphase to my primary router. This default route is still there after installing 464XLAT. My default route is: default via fe80::1 dev eth0.6. So I’ve added ip -6 route add 64:ff9b::/96 via 2001:470:68ee:20::20 dev eth0.6 (later I’ve made a static route with this at network, so it is keep across reboots). I think we need to have two choices here. If there is already a default route, keep it and add a route for the NAT64 prefix, otherwise have a default route to the NAT64 prefix. If you’re an ISP, you don’t want to have all the IPv6 traffic to go via the NAT64, as this means extra overload in that box. So you will prefer to have ONLY the IPv4/IPv6 translated traffic going there (the specific route for 64:ff9b::/96 in my case) and keep the rest going thru the upstream infrastructure.