IPv6 to IPv6 Network Prefix Translation or NPTv6

I was reading through some comments on reddit about NAT66 or RFC 6296 which is really NPTv6 and I realized that universally there seems to be a misunderstanding of why NPTv6 is needed, when you would use it and that it was intended to only address the needs of those use cases and not to emulate what is happening in IPv4 today.

Credit should be given to far smarter folks than I on this topic, specifically Dan Wing with Cisco who first explained NAT66 to a lot of folks (notice he is presenting on how to avoid having to do NAT66) and who also authored the Happy Eyeballs draft RFC which should pop out of draft here shortly. Dan is soft spoken but I'll call out that he is the co-chair of the IETF Behave (Behavior Engineering for Hindrance Avoidance) working group along with Dave Thaler from Microsoft. Obviously Fred Baker and Margaret Wasserman for authoring the RFC though I haven't been lucky enough to chat with either of them about it, though I hope to do so, opportunity permitting.

Okay, on to NPTv6.

So what is NPTv6? NPTv6 is simply rewriting IPv6 prefixes. If your current IPv6 prefix is 2001:db8:cafe::/48 then using NPTv6 it would allow you to change it to 2001:db8:fea7::/48 - that is it. It is a one for one prefix rewrite - you can't overload it, have mismatching prefix allocations sizes, re-write ports or anything else. Importantly, it doesn't touch anything other than the prefix. Your network/host portion remains intact with no changes.

So what is NPTv6 not? It is not for sharing IPv6 addresses, it is not for port overloading and it is not stateful.

Now that we have the ground rules set lets talk about the use cases that NPTv6 was brought about to address. Fundamentally NPTv6 addresses deficiencies in current host behavior and the lack of support for source address selection, next-hop route selection and split-zone DNS. The most common use case condition will be to fix source address selection issues for home and SMB's that have two providers (for whatever reason, redundancy, walled garden services like VOIP or IPTV, etc.) For almost all Enterprises this is not an issue as they will obtain Provider Independent (PI) IPv6 space and dual home properly. They might have to deal with split-zone DNS but I will address that in another post.

What happens when you have two Global Unicast Addresses (GUA) on the same interface? To clarify, not two interfaces each with a GUA. The host has to make a decision about which interface to use yet it knows nothing about how routing works within the network and therefore likely uses RFC 3484 to determine what to do. There are already many issues with host behavior outlined in RFC 5220 so go read that to get a good idea of some of the challenges.

Lets go over a sample practical use case to show where NPTv6 might help your home dual provider situation. This is an example - the prefixes are unnaturally large for an SMB or home user and I will update the diagrams later to properly reflect potential prefixes you would get in a real world situation. Regardless, it is sufficient to show the issue.

Source Address Selection Diagram - the problem:

The solution for the home user or SMB is to remove the multiple IPv6 GUA configuration and use a single IPv6 GUA address on the interface. Once this is done then you end up with proper traffic flow.

Source Address Selection Diagram - the fix case 1:

In the above diagram the host only has a single GUA to source traffic from and therefore selects it to send a request to a server, in this case 2001:db8:f000::1. Notice that the host forwards the traffic to RTR A which is it's default gateway. RTR A then forwards the traffic outbound and everything works as expected.

Source Address Selection Diagram - the fix case 2:

In the above diagram the host only has a single GUA to source traffic from and therefore selects it to send a request to a server, in this case 2001:db8:ff00::b. Notice that the host forwards the traffic to RTR A which is it's default gateway. RTR A then forwards the traffic to RTR B because a static route assignment has been entered for a longer specific prefix in this case. RTR B receives the traffic and because it has NPTv6 set up it realizes it has a prefix match and must do a prefix replacement prior to forwarding the traffic upstream. RTR B then forwards the traffic outbound and everything works as expected.

So realistically, how do we avoid all this in the first place? The only way is for the host to gain more intelligence in making decisions about what source interface address to select. Some sort of policy control would have to happen on the host OS. Alternatively, all hosts could participate in some sort of routing to determine proper paths and hold a route forwarding table. I don't really see that as a viable alternative in many environments today.

In other words, there is little a network engineers can do to fix this problem. It really is an OS host issue and if network engineers really want NAT to go away fully in IPv6 then we have to beg and plead to get a fix done in all the major OS platforms. It also brings to light one of the biggest changes between IPv4 and IPv6, a host can have multiple IPv6 addresses per interface. Somehow we need to get routing information onto the host.

So, is NPTv6 desirable from an IPv6 perspective? I would argue no, I would prefer that my host selected the correct source address and everything just worked. The problem is that it doesn't work that way today and for the foreseeable future it doesn't look promising. So NPTv6 is a necessary evil to address some of these corner case condition of getting IPv6 deployed widely on the Internet today.
- Ed