IPv6 and NAT / NPTv6

I need to be able to use NAT66 and I need some help configuring it. I have successfully enabled ipv6 on both my WAN and LAN connection but I can't enable NAT. The Lite is default. I thought that the following configuration enabled both IPv4 and IPv6:

Re: IPv6 and NAT / NPTv6

There are only a few cases where NAT for IPv6 provides a benefit. Also, there are several types of NAT for IPv6, with the most common one being NPTv6 (Network Prefix Translation).

NTPv6 is different from IPv4 NAT in that only the network prefix is changed, leaving the host segment of the IPv6 address (as well as any port numbers used) unmodified. This is a much more acceptable form of NAT than the traditional "NAT overload" or "PAT" typically associated with IPv4 where many hosts make use of one source address because it does not break end-to-end connectivity (in other words, you don't need to manually configure port-forwarding or run a servcie like NAT-PMP to allow incomming traffic).

The biggest use case for NPTv6 is for SMB networking where you want to have multiple providers but maintain a "one host, one address" model for your internal network, or you simply want to use a predictable network prefix for internal addressing for things like static address configuration that is independent of what prefix you get from your provider.

With NAT for IPv4 we make use of RCF1918 "private" address space. For IPv6, the equivilant is called ULA, or RFC4193 Unique Local Addressing. ULA addressing is a bit different from 1918 address space in that to be compliant with the standard you're supposed to follow a protocol for coming up with a RANDOM prefix to use internally rather than simply deciding to use something like FD00::/48 (all zeros).

There are a few websites online that you can use to generate a random ULA prefix to use within your organization:

The big reason for using a randomly generated internal prefix, even though it's non-routed, is that it effectively eliminates the chance that you and another organization will be using the same ULA prefix. This is to get around the problem introduced when companies merge togeather and are using the same address space. In IPv4 it's usually a big mess and means having to re-address everything before you can talk to each other directly; but with ULA there is a very small chance that two companies will be using the same randomly generated network prefix for their internal network.

PLEASE respect the RCF and don't "randomly" select something cute like FD00::/48 or FD12:3456::/48, or FD00EAD:BEEF::/48 etc, that goes against the whole point of ULA addressing.

On a side note the short-lived "Site-Local" address scope in IPv6 was thrown out because of the "merging networks" problem just described, and the answer to that was ULA addressing.

Anyway, back to NPTv6:

In the case of NPTv6, assume that we have two ISPs. Since we're a small business or residential customer, we don't participate in BGP and don't have PI (provider independent) address space for our network. For IPv4, this wasn't really a problem because we just would NAT internall addressing with our magic Dual WAN, Load-Balancing, Firewall. For IPv6, there isn't really NAT in that sense. Instead we have NPTv6.

Let's say ISP A provides you a prefix of 2001B8:AAAA:AA00::/56 (00-FF).

ISP B provides you with a prefix of 2001B8:BBBB:BB00::/56 (00-FF).

Because IPv6 supports multiple prefixes on a single network, you COULD just connect ISP A and ISP B directly into your LAN, and each host would get an IPv6 address from both ISPs. For example, you might have a PC with the MAC address 00:53:00:AA:BB:CC. If State-Less Address Auto-Configuration (SLAAC) is enabled for each prefix (common), and IPv6 privacy extensions are disabled (uncommon, but easier for sake of example), then the host segment of the IPv6 address for that PC would be 0053:00FF:FEAA:BBCC (SLAAC works by using the EUI-64 form of the MAC address which means inserting FFFE in the middle to expand 48-bit to 64-bit).

In this case, the PC would end up with two global IPv6 addresses; each valid:

ISP A: 2001:0DB8:AAAA:AA00:0053:00FF:FEAA:BBCC

ISP B: 2001:0DB8:BBBB:BB00:0053:00FF:FEAA:BBCC

For very small networks this may be acceptable. But for business networks, the need for predictable addressing for servers and a "one host, one address" model that matches existing IPv4 practices more closely is usually desired. Typically DHCPv6 also enters the picture in favor of SLAAC for addressing.

Using the website above, I got FD0C:2E75:F7D0::/48 as a random ULA prefix. I'll extend this to be a 56-bit prefix to match ISP A and B: FD0C:2E75:F7D0:00::/56.

Now with NPTv6, I will NAT the prefix only for ISP A and B so that traffic coming in is re-written to have a destination using my ULA prefix, while traffic going out is re-written to use the prefix of which ever interface is used (ISP A or ISP B) for its source address.

The result is that my PC now has an internal IPv6 address of only FD0C:2E75:F7D0:0000:0053:00FF:FEAA:BBCC, but externally can be reach by either 2001:0DB8:AAAA:AA00:0053:00FF:FEAA:BBCC or 2001:0DB8:BBBB:BB00:0053:00FF:FEAA:BBCC.

In theory, dynamic DNS would come into play as well so that a DNS record could point to each public IPv6 address in use; and if an ISP becomes unavilable, the DNS record could be updated to remove the address that is unreachable. There isn't actually a service to do this yet that I'm aware of, though.

Load-Balancing with NPTv6 is also still a challenege. I haven't looked into it yet, but I don't think NPTv6 + Load-Balancing is something you can configure Linux-based systems to do just yet.

Basically, NPTv6 is something that is JUST starting to become available and most of the use cases are theory rather than practice right now. I suspect over time, as hardware is up to the task, the model described here will become VERY popular though.

For now, using ULA space with a single ISP is possible, and the advantage there is that if your ISP changes or your prefix changes you don't need to worry about updating internal DNS records or staticly configured IPv6 addresses.

Re: IPv6 and NAT / NPTv6

I'm interested in your last paragraph where you say translating from ULA for a single ISP works now. Did you mean on Edgerouters? If so, what mechanism? This seems like a reasonable way to avoid reconfiguring firewall rules among internal subnets when the ISP-supplied external IPV6 prefix changes.

Re: IPv6 and NAT / NPTv6

VyOS has some kind of support for NPTv6 here with some examples of iptables rules.

I dont change ISP that often but still having to reconfigure your internal network is still pain in the ass. NPTv6 would be a nice addition to edgeos feature list especially bigger networks (business users) in mind

Re: IPv6 and NAT / NPTv6

Thank you very much for your posting on the use of NPT, ULAs, etc. - I guess I'll point customers raising such questions to it in the future rather than elaborating on these issues myself :-)

There are, however, a few additional uses for NAT66, which -at present- cannot be covered by "simple" NPT, among which my current most important one: Your provider fails to delegate a prefix for one reason or another and you still need/want to use IPv6.

Zooming in on EdgeOS:

The following command does pretty much exactly what I want/need on other debian based systems, like, for instance, current Ubuntu realeases:

ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

However, as noted by previous posters in this thread, on EdgeOS (v1.7.0, like in previous releases) it does exactly nothing. No complaints (error messages, etc.) either and a thorough examination of loaded kernel modules even revealed all required modules present an loaded. I even compared this list with the modules loaded on Ubuntu - just the same set of modules and "uses" on both systems. In fact EdgeOS loads even more modules, but this doesn't seem to have anything to do with this issue.

But I noted a quite unusual emptiness of the conntrack table for IPv6, as revealed by

conntrack -f ipv6 -L

So if connection tracking is somehow "disabled", proper NAT cannot happen. Further digging then revealed, that connection tracking for IPv6 is effectively turned off by EdgeOS (after invoking it's own "hooks") in the raw table:

These "NOTRACK" entries apparently originate from the file /opt/vyatta/etc/ipv6_restore, which, I guess, defines the default environment, Vyatta creates before filling ip6tables with it's own stuff?!

@ubntWhether it's old Vyatta cruft left over or you put it in - or even an IPv6-Anti-NAT-Zeolot left it there, I don't know. Can you please look into this? If the lines in ipv6_restore serve no purpose (any more?) can you please remove them? Also: Can you please hint on effects of NAT66 in combination with the offloading function? Will it blenderr break? And finally: If nobody else works on this/is interested I'd volunteer to provide a patch for the (Vyatta) CLI environment to allow proper configuration of NAT66 under service nat6 (or similar) - please advise.

(No, I won't touch the GUI under any circumstance; partly because it's the first thing I disable and/or erase from the router when I install it. I don't hate it, but I have no use for it and besides: I want the memory! :-)

PS: Anyone interested in NAT64 - I played a bit with Tayga and it seems to work nicely. You'll need a DNS64 implementation, though. I used bind on a different system, but it can be integrated onto the EdgeRouters as well, I believe.

Clemens

Note to all zeolots:I implore you: Please refrain from lecturing me on the evilness of NAT. I know all those arguments by heart (I use IPv6 in production since 2003) and, being an IETF member too, I've heard them all. Statements, like "if you need NAT you are doing it all wrong" are also not helpful in this context. Yes, I have notified router vendors and ISPs in those case where they are "doing things wrong" (i.e. not providing [proper] prefix delegation) and they have all either been completely ignorant or assuringly apologetic, yet unhelpful so far. Some may even see the light and come through with a solution some day, but -as of now- I have to live with dreadful NAT66 "solutions"instead. Please forgive me, if you can.

Now: if you still want to have those discussions with me, please send me direct messages or open another thread and I'll happily(?) enter that arena with you. But please keep this thread purely technical! Thank you very much!

Re: IPv6 and NAT / NPTv6

csch: Good catch! Yeah those were from "upstream". The original design was that the NOTRACK would take effect by default (for better performance) unless something else is configured that requires connection tracking. In this example, note the FW_CONNTRACK chain which by default just RETURN (so NOTRACK would take effect). However, when firewall is configured with some rules that require connection tracking (e.g., state match), then the action in FW_CONNTRACK is changed to stop traversing in the PREROUTING/OUTPUT chains, which in effect enables connection tracking.

In the context of this particular thread, since the ip6tables NAT rules are added "outside the configuration", the system does not know to enable conntrack, which is why it needs to be manually enabled as you described. Of course if/when we do add IPv6 NAT support in the system configuration, we'll need to add the same mechanism to automatically enable contrack when NAT rules are configured. Thanks for taking the time to look into this!

Re: IPv6 and NAT / NPTv6

Update: For those who would like to be hung, poisoned, set-on-fire, drowned and quartered justa little less by the IPv6-Inquisition because you "only" want to use Prefix Translation ("NPT"), i.e., in order to translate internal ULAs (see way above) to global unicast addresses, you can do this as well - all required modules are there already (at least in v1.7.0 and V1.6.0).

PS: The "NETMAP" mechanism also works well with legacy (IPv4) adresses. I use this in cases where I need to distinguish between multiple networks of overlapping (RFC1918) address-ranges, i.e. multiple sites utilizing the very popular 192.168.178.0/24 space. I "map" those with NETMAP into other RFC1918 space - or better even into space taken from RFC6598 (just to be safely out of other potential collisions ...)

Re: IPv6 and NAT / NPTv6

It appears the one piece missing to insulate the firewall and internal network configuration from changes to an external DHCPv6 assigned address is the need to netmap to a network instead of an interface.