There are use cases that might require the ability to translate or proxy between IPv4 and IPv6. For example, translation in the data center is necessary to enable communication between IPv6-enabled hosts in the campus/branch and legacy IPv4-only servers in the data center access layer.
An intermediate device or node (for example, router, firewall, or load balancer) can translate from IPv4 to IPv6 and vice versa. Or the operating system can perform translation at each endpoint.
Some examples of mechanisms that perform translation of IPv4/IPv6 include
■ Network Address Translation – Protocol Translation (NAT-PT)
■ NAT64
■ TCP-UDP Relay
■ Bump in the stack (BIS)
■ SOCKS-based IPv6/IPv4 gateway
NAT-PT and NAT64 are discussed because they are the most commonly used mechanisms. The other mechanisms listed previously (TCP-UDP Relay, BIS, and SOCKS-based IPv6/IPv4 gateway) are mentioned only for completeness and are not discussed in the topic.
Note NAT-PT has been officially moved to "historic" status via RFC 4966 and is, by most vendors, not a recommended way of performing translation.
NAT-PT
NAT-PT performs translation of the network layer addresses (Layer 3) between IPv4 and IPv6. In this mechanism, end nodes in the IPv6 network are trying to communicate with the nodes in the IPv4 network. This method is primarily used for communication between the hosts that are IPv6-only to the ones that are IPv4-only.
NAT-PT uses a pool of IPv4 addresses and assigns them to IPv6 end nodes/hosts at the IPv4-IPv6 boundaries. This mechanism is similar to today’s NAT mechanisms in IPv4 networks.
NAT-PT is based on the Stateless IP/ICMP Translation (SIIT) algorithm, as described in RFC 2765. This algorithm translates between the IPv4 and IPv6 packet headers without requiring any per-connection state.
Similar to NAT with IPv4, NAT-PT enables both static translations and dynamic (pools). In the case of static, one IPv6 address is mapped to one IPv4 address. Using the mapped IPv6 address of the IPv4 address on the NAT-PT router, the IPv6 nodes are able to communicate. Dynamic NAT-PT allocates addresses from the pool to allow multiple NAT-PT mappings.
Figure 3-15 shows the NAT-PT router with the translation table for the addresses.
|
Before Translation |
After Translation |
||
|
Source Address |
Destination Address |
Source Address |
Destination Address |
|
2002:10:20:1:1 |
2002:CAFO:1:1 |
192.168.1.1 |
10.12.1.1 |
|
2002:10:20:1:2 |
2M2:CAFO:1:2 |
192.168.1.2 |
10.12.1.2 |
Figure 3-15 NAT-PT Example
The restrictions of this solution are similar to the IPv4 NAT mechanisms, including the following:
■ No support of asymmetrical routing because the traffic for the sessions needs to pass through the same NAT-PT device.
■ Any embedded address translation needs the knowledge of the underlying application/protocol.
NAT64
As the name suggests, the NAT64 transition mechanism refers to the translation of the IPv6 packet to an IPv4 packet. In case of NAT64, the initiator of the packet is always on the IPv6 side. Although NAT64 shares some of the same issues as other NAT mechanisms, it is the best option because it is built upon the years of experience with IPv4 NAT and overcomes some of the issues related to the other mechanisms like NAT-PT. NAT64 provides additional features like NAT mapping, filtering, and TCP simultaneous-open, which are required for the peer-to-peer environment.
NAT64 also provides features such as hair pinning, which enable the IPv6 hosts behind the NAT64 device to communicate with each other. Figure 3-16 shows the network design with the NAT64 device, DNS64, IPv6 clients, and IPv4 servers.
Figure 3-16 NAT64
Summary
This topic dealt with the overview of different transition mechanisms for IPv6, which could be used to prepare a customer to transition from IPv4 to IPv6, depending upon the size and the availability of today’s underlying IPv4 infrastructure.
