Hi all
First I would like to explain the scenario where this request come. My ISP has enabled IPv6, via 6rd tunnel, but no prefix delegation and most important they give only /64 subnet
There is no room for discussion with them on this topic, neither for me an alternative provider that gives better.
Hurricane or similar tunnels are not an option, due to different geolocalization, and because apparently my ISP is blocking IP proto 41 if originated from a device different than their own gateway
So I have decided to implement a NAT6 masquerade on my gateway running trunk.
I'm ok with the way of configure it as described in the wiki, but I would like to regain the flexibility of the public IPv6 address on my LAN devices, that is lost with the NAT6.
I know that I can use DNAT for standard port forwarding (first question: UCI/LUCI can handle DNAT for IPv6 in trunk?), but I have something different in mind.
My WAN6 in DHCPv6 mode gets a SLAAC IPv6 address from the ISP gateway. The idea is to add more IPv6 address in the same /64 subnet on this interface and set a symmetric SNAT/DNAT rule to map each internal IPv6 address running in LAN to a different public IPv6 address on WAN.
Doing so the assumption is that we can reach from internet the IPv6 address running in LAN from the IPv6 public address on the WAN via the DNAT rules and making the IPv6 address running in LAN appear on internet with their own public IPv6 address from the WAN via SNAT rule.
The goal is:

1) Have the LAN address management working with SLAAC and DHCPv6 with no caveat
2) Have the LAN device have their own public IPv6 address via SNAT/DNAT
3) Protect WAN to LAN access with normal iptables rules

The question: apart from the fact that I know it's way better not use NAT6 at all, does it make sense and is it feasable with modern iptables? Is there any kind of support, even if without LUCI, in UCI to do so, in particular assign more that one IPv6 address to WAN?
Thanks to everybody that would  contribute

I don't use 6rd and don't have experience with it, however I do use IPv6. My ISP only allocates a /64, but even with a /64, assigning my internal hosts a public IPv6 happens automagically.

Openwrt allocates my public IPv6 to the br-lan interface, while the PPPOE wan interface gets a link-local IPv6 assigned along with a default IPv6 route to a link local next-hop IPv6 address at my ISP.

Then odhcpd publishes a /64 prefix and my internal hosts pick this up via SLAAC or DHCPv6 (depending on the host - my servers use SLAAC and my clients use DHCPv6).

It all works perfectly smoothly. Ok, so with a /64 I can't subnet, but I don't really care much about that in my home network.

Hi Menion,

Is it possible to replace your ISP gateway device with your own OpenWrt router and run the 6rd tunnel on its WAN6 config ?

No it is not possible. However, I have also noticed that I have not underlined the main goal which is to overcome the limitation given by the /64 network.
In pratica I want to configure an internal /48 (or /32 or wathever) prefix with all the subnet I need and map the IPs, via NAT6, to the external /64 network IP range given by the ISP in upstream

Hi,

If this single /64 prefix could be "transferred" to your LAN, it would solve the problems, right ? This is why I asked if OpenWrt could manage the 6rd tunnel in place of the ISP modem/router device.

But since it is not possible to replace the ISP device and this device is advertising the /64 prefix with SLAAC, the best ways to configure the OpenWrt router are in this order:

1. NDP proxy/relay mode (try hard to make it work).
2. IPv6 BRouter (check https://github.com/cvmiller/v6brouter)
3. Write a script to add several ip -6 neigh proxy addresses to the WAN iface to create a pool of global IPv6 addresses. Distribute them to your LAN devices with DHCPv6. SLAAC won't be supported and I personally don't know how to configure a DHCPv6 server for this second step.
4. Use NAT6 as the last resort, only after trying really hard and failing the previous methods

I think you may be missing the point of IPv6. There is no such thing as a public IPv6 and then run it through NAT. If you have a public IPv6 (aka a Globally Unique Address, GUA) then you don't need NAT.

Does your 6RD gateway give you a separate IPv6 prefix for your LAN now? If so, then I would second what AndreL stated, try the odhcpd NDP/RA relay mode.

https://wiki.openwrt.org/doc/uci/networ … ent_dhcpv6

Or the v6brouter with firewall rather than NAT. NAT breaks the end-to-end connectivity that IPv4 used to have, and IPv6 offers again.

cvmiller: what you have written is clear, and believe me, clear also to me
But still, with all the IP assignment techinque I could deploy, still my ISP gives /64 prefix, so no room for, OpenVPN iPv6 tunneling (without splitting by hand the /64 in two /65 and goodby to SLACC) and NAT64, that requires a dedicated /64 prefix in a > /64 network.
This is why the NAT6 idea. If you have other better idea to implement the above two goals, please share it

So you actually want to share this global /64 prefix between two network segments ? One for LAN and another for a remote device/net connected through OpenVPN ?

If you have N OpenVPN tunnels where each one has a single client on the remote side and your public /64 prefix is static, then having N ip -6 proxy addresses is enough to serve the remote VPN endpoints. I do this myself for connecting my laptop or android phone remotely with openvpn. It is good to also know that a public ip6 address on the remote endpoint is in fact only needed if you wish to access the internet through the tunnel. It is not needed if the VPN tun is for reaching services inside your LAN (an ULA prefix can do this).

Yes, exactly this. I will look into the ipv6 proxy. What about NAT64?

Further suggestions:

Make the whole /64 available to the LAN network with the NDP proxy config case and pursuit solving the VPN needs secondly.

An option to do the VPN is to use TAP instead of TUN and bridge the TAP adapter to the LAN that will already have the /64 working through the NDP proxy settings. In the last resort, use NAT6 only for the VPN endpoint(s) (I also do this in a setup where the ISP prefix is dynamic) but let the LAN network where most of your devices will be have the native IPv6.

Are you quite sure your ISP will not give you anything but a /64? I ask because my ISP was only giving out /64, and I called them to complain, and they said it was possible to give out a /56, if my router didn't request an address. I  changed "request IPv6 address" to "disabled" and then a magically got a /56! Not sure why the ISP had set things up that way, but it worked.

And the other solution is to use an HE tunnel, where you can get a /48 and go nuts with subnetting off /64s. Of course, native is almost better than a tunnel, but if they won't give you more than a /64, then it isn't better.

There _will_ be things where some kind of NAT6 service is required, but it is my hope that we hold off using that NAT6 card until there are _no_ other ways to do it.

(Last edited by cvmiller on 6 Mar 2017, 21:40)

The answers to all your questions are in the opening post of this thread

(Last edited by Menion on 6 Mar 2017, 22:24)

Can you tell us who the bad-acting ISP is? Perhaps others will stay away knowing what poor IPv6 support they have.

It's not nice to do it. It's an italian ISP, one of the two that actually gives some sort of working IPv6
And in fact if you just use theu router, the IPV6 works, but you have a /64 network
We can argue on this, but it is not so strange, if you put yourself in the ISP shoes, to consider the requests for having a greater network not being a residential contract, rather than a commercial one.
In details the reason why we get the /64 is that they have allocated one /32 network from they ARPA pool, for 6rd, that as you know, append the 32 bit of your IPv4 address for composing the network managed by the border 6rd gateway, and the result of 32+32 is the /64....
Now, for sure they could have allocated a master network of /28 for the 6rd, but this is what we get.
In general, if the DHCPv6 relay mode worked, I could get a perfectly, working and standard /64 Ipv6 network deployed in my LAN. Yes no tunnel, not NAT, but this specific things are addressable by ipv6 proxy and NAT6.
But I read too much ideology on this topic, the real world is full of ISP assigning a /64, if you are lucky (some of them just DHCPv6 the address), and I think we must be more open mind

Hi Menion,

I know sometimes it is disappointing on a forum to read people telling how to do other things instead of what you actually asked. But they are suggestions and the information is available to the other users as well.

We came from the IPv4 era so used to NAT that we easily get tempted to think that NATting is the normal way of sharing internet connectivity with downstream devices or multiple LANs. But it is not. It was a hack done in IPv4 to save addresses. In IPv6, even a single /64 will have enough addresses to distribute with the methods I suggested in the previous posts.

Try to remember how many workarounds for NAT had to be implemented by programmers to be able to punch them in for P2P, VoIP and video calls without long delays because of a relay server, gaming, running personal servers for a simple tasks like putting an IP cam in your house accessible from outside, remote PC access... All these stuff had to be made and then reworked considering that address and port numbers are always faked by NAT (with several different implementations to detect) and that it is normal for ppl to buy internet service which has only outbound capability.

The opportunity to have plain two-way connectivity without all this hassle is back with IPv6 and I provided several options for the kind of need you are willing to fulfill. The NDP proxy and brouter methods are in use by other users and they work nicely to overcome the single subnet (/64) limitation without NAT.

I have two running OpenWrt setups with NDP proxy for sharing /64 and can't think that NATting would have been a better choice.

This is my personal opinion about the ISPs role:

If the customer network growth is to be somehow limited to prevent misuse of a residential plan, bandwidth limit (they advertise some speed on the plans they sell, right ?) and/or data quota restrictions are the way to do it.

Sabotaging the internet protocol is not the way to do it. Each country's telecom regulatory agencies should have enforced proper IPv6 implementation before all these single-/64-per-customer-setup spread out.