On Fri, Oct 6, 2017 at 9:25 PM, JORDI PALET MARTINEZ <jordi.pa...@consulintel.es> wrote: > Hi Hans, > > Sorry, missed confirming that it works perfectly. > > I just tested today with the recent LEDE 17.01.3, and it works perfectly as > well. Thanks for the feedback
Hans > > Thanks a lot! > > Regards, > Jordi > > > -----Mensaje original----- > De: Hans Dedecker <dedec...@gmail.com> > Responder a: <dedec...@gmail.com> > Fecha: domingo, 10 de septiembre de 2017, 22:19 > 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 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. > > > > > > > > > > > ********************************************** > 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
