IPv6 NPTv6 (Network Prefix Translation)

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Why did I use a loopback with a prefix instead of prefix 2001:DB8:0:23::/64 (the link between NPTv6 and H3)? I tried this the first time but it doesn’t work because H3 will do a neighbor solicitation for 2001:DB8:0:23::1/64 (the translated address). Since nobody responds to that address, the ping fails.

I guess the question is - what if you changed the IP of H1 to 2001:DB8:0:12::2/64 (and swapped G2 to ::1)

Then the translated address for H1 would be 2001:DB8:0:23::2/64 - so NPTV6 should respond to the neighbour solicitation :wink:

3

Hello Chris.

Yes that makes sense. You might want to try to lab it for confirmation and let us know of your results…

Laz

4

I don’t understand the use of this prefix
If the prefix is give by a ISP it do not belong to the Customer and if you are the owner of the prefix you can use BGP to still make it available
Is there a pratical scenario where the is an advantage of using NPTv6

Cordially

5

Hello Fabrice

IPv4 and IPv6 are similar in that they separate their respective addresses into two sections. The terminology used is somewhat different however. Where an IPv4 address is separated into the network portion and the host portion using a subnet mask, an IPv6 address is separated into a prefix and a host identifier using the prefix length.

So for an IP address of 2001:DB8:0:12::1/64 as in the lesson, the prefix is 2001:DB8:0:12, the host identifier is ::1 and the prefix length is 64. 64 indicates what part of the address is the prefix, that is, the first 64 bits.

So, when we say that we are applying network prefix translation, what we’re doing is taking the 2001:DB8:0:12 part of the address and replacing it with another prefix, and in this lesson, this other prefix is 2001:DB8:0:23.

So for every packet that comes in to a destination IP address of 2001:DB8:0:12::1, the NPTv6 router will replace the 2001:DB8:0:12 with 2001:DB8:0:23. The resulting mapping will be as follows:

2001:DB8:0:12::1 will map to 2001:DB8:0:23::1
2001:DB8:0:12::2 will map to 2001:DB8:0:23::2
2001:DB8:0:12::3 will map to 2001:DB8:0:23::3
2001:DB8:0:12::4 will map to 2001:DB8:0:23::4
2001:DB8:0:12::5 will map to 2001:DB8:0:23::5
etc…

So this is indeed a one to one mapping.

Now the prefix may be owned by you, or it may be the prefix that the ISP is giving you as part of your connectivity package. The NPT need not be applied at the edge of your network, it may even be applied inside your network.

Some practical scenarios where this can be useful are included in the lesson. Specifically:

  • Address independence: you don’t have to change your IPv6 prefixes on your local network when your global IPv6 prefix changes. On the other hand, IPv6 renumbering is not so bad compared to IPv4.
  • ULAs (Unique Local Addresses): NPTv6 translates the prefix in your ULAs to a global prefix that is routable on the Internet.
  • Access-lists: Your host has two IPv6 addresses and only one of them is permitted through some firewall. Your host won’t know which source address is permitted through the firewall so by using NPTv6, you can translate the address to a prefix that is permitted through the firewall.

The IETF stipulates that NPTv6 provides what they call “address independence.” More about this can be found here:

I hope this has been helpful!

Laz

2 Likes
6

Hello

I don’t understand discussions of question “What are limitations in use of NPTv6 for IPv6 vs IPv6 address translation?”. Some people suppose that one of limitation is “1-to-1 prefix rewrite”. But other suppose that limitation is “mismatched prefix allocations”.

It seems both versions are true. Anybody clarify me?

Thanks

7

Hello Boris

Limitations to any technology can be a subjective matter. For one person, one aspect may be limiting while another may not. Compared to NAT, the fact that NPTv6 can only provide a one-to-one translation may be a limitation for someone that wants this functionality, however, NPTv6 was not developed for this purpose. For others, the fact that you can’t have mismatched prefix allocation sizes is a limit.

NPTv6 was developed in order to provide a very simple functionality: rewrite the IPv6 prefix. That’s it. Now for some this is a limitation, for others, this is exactly what they want it to do.

Some things that are limitations, regardless of how it functions or what it’s purpose is, is the fact that IPsec cannot be used across an NPTv6 translation, and a more complex DNS setup is required, specifically, split-horizon DNS must be applied.

I hope this has been helpful!

Laz

2 Likes
8

Hello Laz,

Thanks a lot. The explanation has been helpful!

9

Hey Laz and Rene,

Why there isn’t any show command like show nat66 translations?

I know that the conversion is 1:1 but sometimes you want to see which ip address was translated and which wasn’t , and you can’t verify this with the other show commands.
(For example - port forwarding in NPTv6 for servers environment with public services)

Another question that I wanna ask: if there is any method like NAT ALG in the NPTv6 version?

Thanks you very much

1 Like
10

Hello Nitay

As far as I can see there is no way to see the actual translations of the specific IP addresses. But there is a reason for this. NAT66 does not keep track of each individual translation like NAT for IPv4 does. It simply translates the prefixes. In this sense, it is stateless as far as the specific addresses are concerned, that’s why you can’t see a record of the translations. The only way to see and verify specific translations is to do a wireshark capture and see what addresses appear in the IPv6 header.

ALG does exist for NAT66 in much the same way as it does for IPv4 NAT. This is emphasized in RFC 6296 describing IPv6 to IPv6 Network Prefix Translation where it states that:

NPTv6 may interfere with the use of application
protocols that transmit IP addresses in the application-specific
portion of the IP datagram. These applications currently require
Application Layer Gateways (ALGs) to work correctly through NAPT44
devices, and similar ALGs may be required for these applications to
work through NPTv6 Translators.

However, from my research, I find that most Cisco devices that support NAT66 don’t simultaneously support ALG. For example, this Cisco documentation on NPTv6 states that:

Application Level Gateways (ALG) is not supported by NPTv6 support on ASR1k/CSR1k/ISR4k feature. Payload address or port translation is not supported.

I have been unable to find documentation indicating a Cisco device supporting ALG on NAT66 translations.

I hope this has been helpful!

Laz

2 Likes
11

I think the usefulness of NAT for IPv6 is hardly a matter of question anymore - while original intention of NAT in ipv4 was to save IPs, in reality it does a lot more. Which still remains true for IPv6 where it no longer needed to save IPs. The typical scenario would involve many multihomed networks where it is necessary to somehow ‘tag’ the clients IPs. Like having client located in site A which is connected to site B, with both sites providing Internet connectivity. If internal networks are advertised to ISP as summary (which is normally the case) then both A and B would end up advertising same summary for client to have any redundancy. Then even in case both sites up (not to mention something is wrong within site A routing) the client would send traffic out from either of the sites but return traffic may end up in a different site and dropped on firewalls. NPT solves this making traffic from the same client unique to particular site its coming from, so Internet ‘knows’ which site traffic came from and will return it to the same site.

But that was a statement. My question though is what is needed to use nptv6 on cisco? That is I tried it and on several routers there is simply no nat66 command. Either global or interface. There is ipv6 nat and nat64 but no nat66. What might be the problem? I have ipv6 routing enabled and ipv6 addresses set on several interfaces.
And the main reason I tried was to check if I can translate the prefixes using arbitrary prefix which is not associated with any interface on the router, physical or loopback. I understand why using …23::/64 would not work but not why we need to have loopback to assign translated prefix to it.

12

Hello Vadim

Concerning your statement, I understand the logic behind it. However, we must also take into account the many problems that NAT causes. Some of the most notable are:

  • A degradation of performance
  • difficulty of applying QoS
  • causes problems with some applications, including VoIP, IPSec, FTP etc which require further configuration to resolve
  • increased complexity

Now the solutions that you describe above are indeed solutions that NPT delivers, however, the question is, do you want to have those solutions at the expense of the above mentioned problems? Most would probably say no. Redudnancy can be achieved in other ways so you wouldn’t typically see the use of NAT in IPv6 for this purpose. It really comes down to what each administrator chooses to deploy of course, but what you describe would not be that common. Actually I’m interested, do you have any examples of a production network that has such a setup?

There is no nat66 command on Cisco IOS. You would use the ipv6 nat command to implement NAT66. Here is an example configuration:

! Enable IPv6 unicast routing
ipv6 unicast-routing

! Configure the inside and outside interfaces
interface GigabitEthernet0/0
 description Inside Interface
 ipv6 address 2001:db8:1::1/64
 ipv6 enable
 ipv6 nat inside
 no shutdown
!
interface GigabitEthernet0/1
 description Outside Interface
 ipv6 address 2001:db8:2::1/64
 ipv6 enable
 ipv6 nat outside
 no shutdown

! Configure the static NAT66 translation
ipv6 nat translation static 2001:db8:1::10 2001:db8:2::10

I hope this has been helpful!

Laz

13

Thanks, Laz, and sorry for delayed response (was overwhelmed with work load, no time at all, what with all the layoffs causing those who dodged the bullet picking up more projects). That clarifies the config - indeed confusing with cisco implementing same features by different ways depending on platform.
As to NAT usage - indeed it is what was decided to use on our network (I did not spend yet enough time on ipv6 so don’t have all the details leading to this architectural decision). The main reason is as I mentioned - there are several sites (say A and B) which are Internet POPs for particular region. Im in site C, which is accessing Internet through either site A or B. Usually it is through A because Im closer to it, but there is no 100% guarantee - the most obvious case is my access to site A is interrupted due to some issues. Then my default gateway is getting redirected to site B by BGP. I cant advertise individual IPs to Internet, need summaries. Cant advertise the same summary from both sites A and B, either. If I do, I will eventually get asymmetric routing issue, with my traffic coming out of site A and coming back to site B (where it will be blocked by firewalls, not having stateful session pointing that source was inside the network). Can’t advertise it from only site A as then losing connection to site A will stop my Internet access. Can’t rely on BGP activating summary advertising from B only when site A is down (range are large and there could be all sorts of issues where only part of member of particular range cant get to site A, so BGP likely will have summary active in both site A and B, meaning they will be advertised from both sites in all likelihood, if redundancy to exist at all. Cant really control what is happening on carriers’ networks, so manipulating communities and path values could get tricky. So from that perspective at least, NAT is the simplest solution - my IP, within summary, is advertised to both internet gateways, in site A and B and there translated, with Internet getting different source for my traffic when coming from site A or B. So return traffic will always get back to where it came from. Thats in a nutshell. The options were analyzed and this design was accepted as simplest. Particular cases, like ipv6 VPN, will get separate considerations. There might have been other considerations, as well, but as I mentioned, that was designed without my participation and I still did not have enough time to look into it deeper.
I hope that provides some picture, though.
On a side note - with all the discussion one question I asked got lost. Its about the translation address as was configured in the lesson. The question was - " Can I translate the prefixes using arbitrary prefix which is not associated with any interface on the router, physical or loopback? I understand why using …23::/64 would not work but not why we need to have loopback to assign translated prefix to it. Is it a requirement?".

Thanks

14

Hello Vadim

Thanks for sharing the details of your production network where NAT is employed in this way for redundancy. Although it is difficult to get a clear picture of the topology just from text, it was enough to understand the logic behind the design.

Concerning your last question, you can translate the prefixes using an arbitrary prefix that is not associated with any interface on the router, physical or loopback. There is no restriction there.
However, there are some advantages to associating the translated prefix with a loopback interface. These include:

  • Stability - Loopback interfaces are virtual and don’t depend upon the physical status of hardware interfaces. This means that even if a physical interface goes down, the loopback interface remains up, ensuring that the translated prefix remains reachable.
  • Troubleshooting: When you associate the translated prefix with a loopback interface, it can be easier to monitor and troubleshoot connectivity issues related to the NAT configuration. You can use common troubleshooting tools like ping and traceroute to verify reachability to the loopback address.

I hope this has been helpful!

Laz

15

Thanks a lot. Appreciated, as always.

1 Like