CCIE Blog

IPv6 NAT-PT is to be used with IPv4 to IPv6 migration scenarios and it’s purpose is to provide bi-directional connectivity between IPv4 and IPv6 domains. A dual-stack router with interfaces in both IPv4 and IPv6 networks is capable of performing this task. The difference from classic IPv4 NAT is that translations should be done both ways: IPv6 packets routed towards IPv4 hosts should have their src/dst addresses changed to some IPv4 equivalents and vice versa: IPv4 packets sent toward IPv6 hosts should get both src and dst addresses replaced with IPv6 addresses.

The first question that arises is how in the world IPv6 domain learns about IPv4 hosts and v4 domain knows about existence of v6. Well, the first idea that comes in mind to resolve this, is it to provide static bi-directional mappings. For example, we can manually program router to rewrite destination addresses in IPv6 packets sent to IPv6 address 2000::960B:0202 (a sample address, but note that 960B is 150.11 in decimal) to 150.11.2.2. What about the source address? To translate the source address (e.g. 3001:11:0:1::1) we set up another mapping, that tells to rewrite IPv4 packets (opposite direction) sent to 150.11.1.1 to 3001:11:0:1::1. Since the mapping is bi-directional, IPv6 packets with src/dst address pair [3001:11:0:1::1, 2000::960B:0202] would get rewritten to IPv4 packets with address pair [150.11.1.1, 150.11.2.2] and vice versa – IPv4 packet src/dst [150.11.2.2, 150.11.1.1] will be rewritten to [2000::960B:0202, 3001:11:0:1::1].

Here is how it would look like in IOS configuration. First, note that IPv6 stack classifies packets for NAT-PT via a special IPv6 NAT prefix. This prefix represents the whole IPv4 address space (2^32) embedded within IPv6 super-space, and always has length of 96 bits (128-32=96). Every IPv6 packet sent to this prefix is inspected by NAT-PT engine.

Next, using the configuration depicted on the diagram, we aim to provide connectivity between IPv6 Loopback100 of R1 and IPv4 Loopback0 of R2. In the most simple case of static v6v4 mapping, the configuration would look like the following:

R3:
!
! Enable NAT-PT on the interfaces
!
interface FastEthernet 0/0
 ipv6 nat
!
interface FastEthernet 0/1
 ipv6 nat

!
! Static translation for R1 Loopback0
!
ipv6 nat v6v4 source 3001:11:0:1::1 150.11.3.1

!
! Static translation for R2 Loopback0 
!
ipv6 nat v4v6 source static 150.11.2.2 2000::960b:0202

!
! IPv6 NAT prefix, needed to enable NAT-PT classification
!
ipv6 nat prefix 2000::/96

However, more flexible solutions are available for other deployment models. Suppose we want to provide access to an IPv4 server for a large group of IPv6 hosts. We may set up access to the IPv4 server using static IPv4 to IPv6 mapping, and translate the IPv6 hosts’ source addresses into IPv4 address pool. This way, only the IPv6 hosts will be able to initiate sessions to the IPv4 server, using dynamically allocated IPv4 addresses, but not vice-versa – the IPv6 hosts will not have any persistent mappings to IPv4 address space.

R3:
!
! Enable NAT-PT on the interfaces
!
interface FastEthernet 0/0
 ipv6 nat
!
interface FastEthernet 0/1
 ipv6 nat

!
! Dynamic NAT for IPv6 to IPv4 traffic (the hosts) 
!
ipv6 nat v6v4 source list NAT_TRAFFIC pool IPV6_TO_IPV4

!
! Static translation for R2 Loopback0 (the server)
!
ipv6 nat v4v6 source static 150.11.2.2 2000::960b:0202

!
! Dynamic NAT IPv4 pool
!
ipv6 nat v6v4 pool IPV6_TO_IPV4 150.11.3.128 150.11.3.254 prefix-length 24

!
! IPv6 NAT prefix
!
ipv6 nat prefix 2000::/96 

!
!
!
ipv6 access-list NAT_TRAFFIC
   permit ipv6 any 2000::/96

All right. But what if we want to allow the IPv6 domain to access ANY arbitrary IPv4 host? We will need some automated translation logic to do that, mapping every host under IPv4 address space to a host under our IPv6 NAT prefix, since we can’t provide manual mapping to each and every IPv4 host. The most obvious way to achieve this is to take the last 32 bits of IPv6 destination address and use them as the corresponding IPv4 address. For example, the IPv6 address 2000::960b:0202 corresponds to 150.11.2.2 under this interpretation (960b:0202 = 150.11.2.2). Using this approach, we fully utilize the IPv6 /96 NAT prefix address space. However, we need to make sure all IPv6 hosts are aware of that logic using some mechanism external to IPv6. Here is a configuration example:

R3:
!
! Enable NAT-PT on the interfaces
!
interface FastEthernet 0/0
 ipv6 nat
!
interface FastEthernet 0/1
 ipv6 nat

!
! Dynamic NAT for IPv6 to IPv4 traffic
!
ipv6 nat v6v4 source list NAT_TRAFFIC pool IPV6_TO_IPV4

!
! Dynamic NAT IPv4 pool
!
ipv6 nat v6v4 pool IPV6_TO_IPV4 150.11.3.128 150.11.3.254 prefix-length 24

!
! IPv6 NAT prefix with v4-mapped flag
! the access-list specifies IPv6 traffic eligible to
! access the IPv4 mapped addresses
!
ipv6 nat prefix 2000::/96 v4-mapped NAT_TRAFFIC
!
ipv6 access-list NAT_TRAFFIC
   permit ipv6 any 2000::/96

Verification

Rack11R1#ping 2000::960B:202 source loopback 100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2000::960B:202, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
Rack11R1#

Rack11R3#debug ipv6 nat detailed
IPv6           more_flags = 0
IPv6 NAT: icmp src (3001:11:0:1::1) -> (150.11.3.128), dst (2000::960B:202) -> (150.11.2.2)
IPv6 NAT: ipv6nat_find_entry_v4tov6:
	 ref_count = 1,
                                usecount = 0, flags = 2, rt_flags = 0,
                                more_flags = 0

Note that a proper NAT-PT implementation requires a number of specific ALG (application level gateways) to be used along with NAT. The purpose of ALGs is to resolve application-level issues that arise from IP address change (e.g. fix up FTP PORT command, etc). Currently Cisco IOS supports only a limited number of ALGs, compared to IPv4 NAT implementation.

To summarize:

- IPv6 NAT-PT translates addresses both ways
- IPv6 NAT-PT requires IPv6 NAT /96 prefix
- IPv6 NAT-PT could be configured using static bi-directional entries
- IPv6 NAT-PT dynamic translations use IPv4 address pool to map many IPv6 addresses to a small group of IPv4 addresses
- IPv6 NAT-PT allows IPv4 address mapping inside IPv6 NAT prefix

Hi Brians,

Just a quick question about the “include-connected” command when redistributing IPv6 protocols (especially RIPng and OSPFv3). From the DocCD it says that it allows the quote “target protocol to redistribute routes learned by the source protocol and connected prefixes on those interfaces over which the source protocol is running”. Is there any reason why this is now necessary to do with IPv6 routing protocols, whereas IPv4 routing protocols would automatically advertise the networks of the connected interfaces if the source protocol is running on them. By the way, this blog is a fantastic idea/revison tool. Keep up the excellent work.

Kind Regards,

Colin

Hi Colin,

In current IOS versions for IPv4 redistribution is a two step process. Let’s suppose that we are trying to redistribute RIPv2 into OSPFv2 by issuing the “redistribute rip subnets” command under the OSPF process. The first thing the router does is to look at the “show ip route rip” output. All of these prefixes are candidate to be redistributed into OSPF. Next the router looks at the “show ip route connected” output. The routes for any connected interfaces from this output running RIPv2 are also candidate to be redistributed into OSPF. In other words, we don’t have to issue the “redistribute connected subnets” to get connected interfaces that run RIP to be sent into the OSPF process.

In previous IOS versions this was not always the case however. In many network designs, especially in service provider environments, transit links themselves are not advertised into the routing domain. Based on this design traffic cannot be sent *to* the network itself, only *through* the network. Over the course of IOS releases however this behavior was mostly updated, and now we see that IPv4 protocols, with the exception of IS-IS, do automatically redistribute their connected interfaces.

For IPv6 whether or not connected links are included in redistribution is up to you at the time of configuration. If we take the previous case for IPv4 and translate it to IPv6 we’ll see that the behavior is not the same. By this I mean that if we issue the “redistribute rip 1” command under the OSPFv3 process, the router will only look at the output of the routes from the “show ipv6 route rip” command, and not the output from the “show ipv6 route connected”. To get connected interfaces to be included in this redistribution we can either issue a separate “redistribute connected” command under OSPFv3, which will take all connected IPv6 interfaces by default, not those just running RIPng, or we can issue the “redistribute rip 1 include-connected” command. This is the preferred design as it gives us more flexibility as to which particular networks we choose to advertise.