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 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
