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. Cisco points out that many other transition techniques are possible, and NAT-PT (Network Address Translation – Protocol Translation) should not be used when other, more “native” options exist, such as having dual stack hosts communicate directly through dual stack routers. Another example provided of when NAT-PT is not needed is when two islands of IPv6 want to communicate over an IPv4-only backbone. We know that many different tunnels exist for this purpose. For more information about these tunnel techniques, see the Transition Technique series in this blog category.
For the job of NAT-PT, 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, while IPv4 packets sent toward IPv6 hosts should get both src and dst addresses replaced with IPv6 addresses.
The first question that arises when exploring NAT-PT is: how in the world does the IPv6 domain learn about IPv4 hosts? And for that matter, how does the IPv4 domain know about the existence of the IPv6 domain?
Well, the first idea that comes to mind to resolve this is it to provide static, bi-directional mappings. For example, we can manually program the router to rewrite destination addresses in IPv6 packets sent to an IPv6 address, for example 2000::960B:0202. Note that in this sample address 960B:0202 is 150.11.2.2 in dotted decimal. What about the source address? To translate the source address (e.g. 3001:11:0:1::1) we set up another mapping that tells the router 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 the src/dst address pair [3001:11:0:1::1, 2000::960B:0202] would get rewritten to IPv4 packets with the address pair [150.11.1.1, 150.11.2.2] and vice versa – an IPv4 packet src/dst [150.11.2.2, 150.11.1.1] would be rewritten to [2000::960B:0202, 3001:11:0:1::1].
Let us examine what this would look like in the IOS configuration. First, note that the 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 an IPv6 super-space. This prefix always has a length of 96 bits (128-32=96). Every IPv6 packet sent to this prefix is inspected by the NAT-PT engine.
Next, using the configuration depicted in the diagram, we aim to provide connectivity between the IPv6 Loopback100 of R1 and the IPv4 Loopback0 of R2. In the most simple case of static IPv6 to IPv4 mappings, the configuration would be:
For the job of NAT-PT, 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, while IPv4 packets sent toward IPv6 hosts should get both src and dst addresses replaced with IPv6 addresses.
The first question that arises when exploring NAT-PT is: how in the world does the IPv6 domain learn about IPv4 hosts? And for that matter, how does the IPv4 domain know about the existence of the IPv6 domain?
Well, the first idea that comes to mind to resolve this is it to provide static, bi-directional mappings. For example, we can manually program the router to rewrite destination addresses in IPv6 packets sent to an IPv6 address, for example 2000::960B:0202. Note that in this sample address 960B:0202 is 150.11.2.2 in dotted decimal. What about the source address? To translate the source address (e.g. 3001:11:0:1::1) we set up another mapping that tells the router 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 the src/dst address pair [3001:11:0:1::1, 2000::960B:0202] would get rewritten to IPv4 packets with the address pair [150.11.1.1, 150.11.2.2] and vice versa – an IPv4 packet src/dst [150.11.2.2, 150.11.1.1] would be rewritten to [2000::960B:0202, 3001:11:0:1::1].
Let us examine what this would look like in the IOS configuration. First, note that the 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 an IPv6 super-space. This prefix always has a length of 96 bits (128-32=96). Every IPv6 packet sent to this prefix is inspected by the NAT-PT engine.
Next, using the configuration depicted in the diagram, we aim to provide connectivity between the IPv6 Loopback100 of R1 and the IPv4 Loopback0 of R2. In the most simple case of static IPv6 to IPv4 mappings, the configuration would be:
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::/96The great news is 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 a static IPv4 to IPv6 mapping, and translate the IPv6 hosts’ source addresses into an 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 the 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 ! ! The traffic eligible for NAT-PT ! ipv6 access-list NAT_TRAFFIC permit ipv6 any 2000::/96All 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. We need to map every host under the 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 the 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::/96Verification
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 = 0Note 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 the IP address change (e.g. fix up FTP PORT command, etc). Currently, the Cisco IOS supports only a limited number of ALGs, compared to an IPv4 NAT implementation.
0 comments:
Post a Comment