Ah even better, I thought 17.01.2 was not including the right CLAT (NAT46) stuff.
So, I will try that then: http://downloads.lede-project.org/releases/17.01.2/targets/ramips/mt7621/lede-17.01.2-ramips-mt7621-sk-wb8-squashfs-sysupgrade.bin Right? Or do you mean I use the snapshot and then opkg install all the relevant packages? I will confirm if it works well, thanks a lot! Regard, Jordi -----Mensaje original----- De: Hans Dedecker <dedec...@gmail.com> Responder a: <dedec...@gmail.com> Fecha: sábado, 9 de septiembre de 2017, 15:36 Para: Jordi Palet Martinez <jordi.pa...@consulintel.es> CC: LEDE Development List <lede-dev@lists.infradead.org> Asunto: Re: using 464XLAT in LEDE (or OpenWRT) On Sat, Sep 9, 2017 at 3:45 AM, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> wrote: > Hi all, > > I just saw in github that 464xlat.sh has been modified on June 2. > > I’m not sure if that means that 464XLAT is already working if I use a snapshot, for example: > > http://downloads.lede-project.org/snapshots/targets/ramips/mt7621/lede-ramips-mt7621-sk-wb8-squashfs-sysupgrade.bin > > I’m doing a workshop this week and have one of those routers which I can reflash to demo it. There is no OpenWRT 15.05 support for this box, and 15.05.1 has 464XLAT broken as well as I can remember. > > Or alternatively maybe an OpenWRT snapshot has it working? > > Thanks in advance! Hi, The 464xlat package is working in Lede trunk; however the 464xlat package is not enabled by default and as such won't be present in a snapshot build Hans > > Regards, > Jordi > > > -----Mensaje original----- > De: Hans Dedecker <dedec...@gmail.com> > Responder a: <dedec...@gmail.com> > Fecha: martes, 14 de marzo de 2017, 1:47 > Para: Jordi Palet Martinez <jordi.pa...@consulintel.es> > CC: LEDE Development List <lede-dev@lists.infradead.org> > Asunto: Re: using 464XLAT in LEDE (or OpenWRT) > > 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. > > > > > > > > > > > > ********************************************** > 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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > ********************************************** 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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
