On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> wrote: > Hi Hans, > > Thanks for your response. > > I’m now a bit more confused with your comment that it doesn’t work in LEDE, > because this afternoon, finally I got it working. > > Let me explain all the history. > > About a year ago, using OpenWRT 15.05, I tested 464XLAT and it worked fine. > > Last weekend, I was trying to replicate it again directly with LEDE … no > success. > > Then I tried again with OpenWRT 15.05.1 and didn’t worked, but this may be > related to the platform I was using. > > I reverted back to 15.05 and it worked. > > This has been a very slow process because I expected that simply adding at > network: > config interface 'clat' > option proto '464xlat' > will make it, but, I didn’t realize that it requires a reboot, for some > reason, just ifdown/ifup, is not enough. > > I could ping/traceroute to both IPv4/IPv6, browse, use skype, etc., and only > having in the WAN IPv6, which is for what is meant 464XLAT of course. > > Once I got it stable, tried again with LEDE (17.01.0 stable), and even having > the same configuration didn't worked, or at least I was assuming that … > > In the packages info, it shows a dependency with libssp, so that confused me > … I also saw that the out rule was removed from 15.05, so I even edited the > 464xlat.sh to include that rule again, but no difference. > > Now … by chance instead of trying ping, which is the FIRST thing that you do > (specially because it worked in 15.05) … my previous browsing window was > still open and tried to reload it … and it worked! > > I tried it also with the trunk version from today, and also works. > > I tried with both a hardware router and also a VM under VirtualBox. > > So, I’m not sure to understand in which LEDE release is broken … > > What definitively is broken is the capability to issue a ping (IPv4). 464xlat is definitely broken on LEDE as you need an ip rule which checks the prelocal table before the local table is checked
ip rule list 0: from all lookup prelocal 1: from all lookup local The rule to the prelocal table is required in order to route the 464xlat traffic to the nat46 module via the xlat interface > > Also, there are other, probably simple to sort out (I’m not a programmer so > I’m not able to contribute myself on this), issues that may be enhanced to > have a good 464XLAT support: > 1) option ipv4addr '192.168.0.1' seems to not work, I see 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. You cannot specify an IPv4 address in the 464xlat config; all IPv4 traffic is indeed source nated to 192.0.0.1. Large scale deployment of 464xlat in an enterprise was not considered by Steven Barth as an initial development target > 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) Last, 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. > > Let me explain 3). 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. I did not hit this issue in my setups before but again this could be related to 464xlat being broken on LEDE; the fact you have to configure manually routes is not normal as routing rules are put into place by the 464xlat script (https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat.sh#L47 and https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat.sh#L48) > > Of course this can be done in the BRAS devices, or the access infrastructure, > but I think is also possible that this part of the network is layer 2, so > you’ve no way to do it there and the CPE should support it. > > This is my config at network: > config interface 'clat' > option proto '464xlat' > option ifname 'eth0.6' > option ip6prefix '64:ff9b::/96' > option ip6addr '2001:470:68ee:30::1' > option ipv4addr '192.168.0.1' In principle this config is not required if you use DHCPv6 on the wan interface as it will automatically setup a 464xlat interface (https://git.lede-project.org/?p=source.git;a=blob;f=package/network/ipv6/odhcp6c/files/dhcpv6.script;h=1bb5e771b6dc80c1f5bceef88508d92cc69b1d3a;hb=HEAD#l170) on the condition that ipv4only.arpa is translated to a correct IPv6 prefix (https://github.com/openwrt-routing/packages/blob/master/nat46/src/464xlatcfg.c#L64) by dns. > > This is my routing table: > ip -6 route > 64:ff9b::/96 via 2001:470:68ee:20::20 dev eth0.6 proto static metric 1024 > 2001:470:68ee:20::/64 dev eth0.6 proto kernel metric 256 > 2001:470:68ee:40::/64 dev br-lan proto kernel metric 256 > unreachable 2001:470:68ee:40::/64 dev lo proto static metric 2147483647 > error -128 > fe80::/64 dev eth0 proto kernel metric 256 > fe80::/64 dev br-lan proto kernel metric 256 > fe80::/64 dev wlan0 proto kernel metric 256 > fe80::/64 dev eth0.6 proto kernel metric 256 > default via fe80::1 dev eth0.6 proto static metric 1024 > > > Do you think I need to open a bug report/feature request for all those issues > or having copied the development list is enough? You can open a bug report 464xlat is currently broken and unfortunately there's no simple solution to fix it at the moment .. You can revert netifd commit https://git.lede-project.org/?p=project/netifd.git;a=commit;h=39d9ceeb96162a83a3f5fa63e6aaa1ccb38caa62 and based on this netifd version do further 464xlat tests. Other bug reports/feature requests need to be opened in github openwrt routing as an issue; but this should be based on a working solution of 464xlat which is currently not the case. Hans > > By the way, in case you’re interested, I’m working in a DHCPv6 option for > configuring all the NAT64 prefixes: > https://datatracker.ietf.org/doc/draft-li-intarea-nat64-prefix-dhcp-option/ > > Regards, > Jordi > > > -----Mensaje original----- > De: Hans Dedecker <dedec...@gmail.com> > Responder a: <dedec...@gmail.com> > Fecha: sábado, 11 de marzo de 2017, 21:04 > Para: <jordi.pa...@consulintel.es> > CC: LEDE Development List <lede-dev@lists.infradead.org> > Asunto: Re: using 464XLAT in LEDE (or OpenWRT) > > Hi, > > On Wed, Mar 8, 2017 at 10:23 PM, JORDI PALET MARTINEZ > <jordi.pa...@consulintel.es> wrote: > > Hi Hans, > > > > I believe you’re the maintainer of 464XLAT. I want to do demonstrations > of OpenWRT/LEDE in scenarios where you run out of IPv4 addresses for the WAN > links. > > > > Sorry to write you directly, but I’ve been trying for many hours to > find more info as I’m not succeeding to configure a CLAT to work in a very > simple scenario. > I've added LEDE development mailing list in CC as the info could be > usefull for other persons who're trying to use 464xlat > > > > The main problem is that I don’t know what are the parameters needed in > the network file. > The 464xlat feature is currently broken on LEDE as the 464xlat netifd > logic have been reverted > > (https://git.lede-project.org/?p=project/netifd.git;a=commit;h=39d9ceeb96162a83a3f5fa63e6aaa1ccb38caa62) > as it changed the default behavior of user ip rules in unexpected > ways. This can easily be checked by the ip rule list cmd as it should > contain a rule to the prelocal table. > > > > My scenario is quite simple. I’ve a virtual machine with Ubuntu running > a DNS64 with bind9 and NAT64 with Jool. This has been tested and is working. > > > > In the router where I want to run CLAT, I’ve: > > > > 1) WAN interface configured only with an IPv6 address (and of course > I’ve checked that I can ping from here to the DNS/NAT64 and Internet with > IPv6). > > 2) LAN interface with an IPv6 prefix /64, an IPv4 /24 (private), and > DHCP and SLAAC running. I can ping with both IPv4 and IPv6 to the router. > > > > I tried both with Luci and editing the network file. > > > > I don’t understand what it means tunlink (is it the WAN with only IPv6 > interface?). Should I configure additional addresses for the CLAT? According > the 464XLAT RFC I need 3 IPv6/prefixes (WAN/LAN/translation). > tunlink is indeed the logical interface on which the 464xlat interface > depends; in this case it's the IPv6 wan interface > > > > By the way, for the NAT64, I’m using the standard prefix 64:ff9b::/96. > > > > Do I need to do any special configuration in the rest of the interfaces > or the firewall to make it work? > You need to specify to which firewall zone the 464xlat interface > belongs via the zone UCI parameter; usually this is the wan zone > > > > I hope you have a sample configuration for the network and firewall > files that I can understand what I’m doing wrong or missing. It may be > something really silly but I’m unable to see it. > > > First you need to verify if you're using a build which still supports > 464xlat otherwise even with a correct config it won't work ... > > Hans > > Thanks a lot! > > > > By the way, we just submitted a new IETF draft to allow configuring the > CLAT (and other protocols related to NAT64 usage) by DHCPv6 options: > > > > https://www.ietf.org/id/draft-li-intarea-nat64-prefix-dhcp-option-00.txt > > > > Regards, > > Jordi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > > > > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > > _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
