Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)

[Hans Dedecker]

On Fri, Oct 6, 2017 at 9:25 PM, JORDI PALET MARTINEZ
 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 
> Responder a: 
> Fecha: domingo, 10 de septiembre de 2017, 22:19
> Para: Jordi Palet Martinez 
> CC: LEDE Development List 
> Asunto: Re: using 464XLAT in LEDE (or OpenWRT)
>
> On Sat, Sep 9, 2017 at 1:20 PM, JORDI PALET MARTINEZ
>  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 
> > Responder a: 
> > Fecha: sábado, 9 de septiembre de 2017, 15:36
> > Para: Jordi Palet Martinez 
> > CC: LEDE Development List 
> > Asunto: Re: using 464XLAT in LEDE (or OpenWRT)
> >
> > On Sat, Sep 9, 2017 at 3:45 AM, JORDI PALET MARTINEZ
> >  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 
> > > Responder a: 
> > > Fecha: martes, 14 de marzo de 2017, 1:47
> > > Para: Jordi Palet Martinez 
> > > CC: LEDE Development List 
> > > Asunto: Re: using 464XLAT in LEDE (or OpenWRT)
> > >
> > > On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ
> > >  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, 

Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)

[JORDI PALET MARTINEZ]

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 
Responder a: 
Fecha: domingo, 10 de septiembre de 2017, 22:19
Para: Jordi Palet Martinez 
CC: LEDE Development List 
Asunto: Re: using 464XLAT in LEDE (or OpenWRT)

On Sat, Sep 9, 2017 at 1:20 PM, JORDI PALET MARTINEZ
 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 
> Responder a: 
> Fecha: sábado, 9 de septiembre de 2017, 15:36
> Para: Jordi Palet Martinez 
> CC: LEDE Development List 
> Asunto: Re: using 464XLAT in LEDE (or OpenWRT)
>
> On Sat, Sep 9, 2017 at 3:45 AM, JORDI PALET MARTINEZ
>  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 
> > Responder a: 
> > Fecha: martes, 14 de marzo de 2017, 1:47
> > Para: Jordi Palet Martinez 
> > CC: LEDE Development List 
> > Asunto: Re: using 464XLAT in LEDE (or OpenWRT)
> >
> > On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ
> >  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, 

Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)

[Hans Dedecker]

On Sat, Sep 9, 2017 at 1:20 PM, JORDI PALET MARTINEZ
 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 
> Responder a: 
> Fecha: sábado, 9 de septiembre de 2017, 15:36
> Para: Jordi Palet Martinez 
> CC: LEDE Development List 
> Asunto: Re: using 464XLAT in LEDE (or OpenWRT)
>
> On Sat, Sep 9, 2017 at 3:45 AM, JORDI PALET MARTINEZ
>  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 
> > Responder a: 
> > Fecha: martes, 14 de marzo de 2017, 1:47
> > Para: Jordi Palet Martinez 
> > CC: LEDE Development List 
> > Asunto: Re: using 464XLAT in LEDE (or OpenWRT)
> >
> > On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ
> >  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
> >
> 

Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)

[JORDI PALET MARTINEZ]

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 
Responder a: 
Fecha: sábado, 9 de septiembre de 2017, 15:36
Para: Jordi Palet Martinez 
CC: LEDE Development List 
Asunto: Re: using 464XLAT in LEDE (or OpenWRT)

On Sat, Sep 9, 2017 at 3:45 AM, JORDI PALET MARTINEZ
 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 
> Responder a: 
> Fecha: martes, 14 de marzo de 2017, 1:47
> Para: Jordi Palet Martinez 
> CC: LEDE Development List 
> Asunto: Re: using 464XLAT in LEDE (or OpenWRT)
>
> On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ
>  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, 

Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)

[JORDI PALET MARTINEZ]

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!

Regards,
Jordi
 

-Mensaje original-
De: Hans Dedecker 
Responder a: 
Fecha: martes, 14 de marzo de 2017, 1:47
Para: Jordi Palet Martinez 
CC: LEDE Development List 
Asunto: Re: using 464XLAT in LEDE (or OpenWRT)

On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ
 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, 

Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)

[Hans Dedecker]

On Sun, Mar 12, 2017 at 12:24 AM, JORDI PALET MARTINEZ
 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:
> 

Re: [LEDE-DEV] using 464XLAT in LEDE (or OpenWRT)

[Hans Dedecker]

Hi,

On Wed, Mar 8, 2017 at 10:23 PM, JORDI PALET MARTINEZ
 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.
>
>
>

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev