On Sat, Sep 9, 2017 at 1:20 PM, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> wrote: > 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? Indeed I meant use a snapshot build and install the relevant 464xlat package on top
Hans > > 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
