IPv6 Essentials
10.3. Network Address and Protocol Translation
Address and protocol translation techniques are described in RFCs 2765 and 2766. They offer transition mechanisms in addition to dual-stack and tunneling techniques. The goal is to provide transparent routing for nodes in IPv6 networks to communicate with nodes in IPv4 networks and vice versa. The Stateless IP/ICMP Translation Algorithm (SIIT; see RFC 2765) specifies algorithms that translate between IPv4 and IPv6 packet headers. It does not specify a mechanism for the assignment of IPv4 addresses. Network Address TranslationProtocol Translation (NAT-PT; see RFC 2766) uses a pool of public IPv4 addresses for assignment to IPv6 nodes on a dynamic basis as sessions are initiated across protocol boundaries. 10.3.1. Stateless IP/ICMP Translation
For the case in which IPv4-only hosts want to communicate with IPv6-only hosts or vice versa, RFC 2765 defines how a protocol translator has to translate the IP and ICMP headers for both parties to understand each other. For example, you might have a new network segment and want to roll out native IPv6 hosts. With the implementation of a protocol translator, it is possible to set up the new IPv6-only network internally and have those IPv6-only clients access the standard IPv4 Internet or any other IPv4-only node. For this purpose, a new address type has been introduced: the IPv4-translatable address. The format of the prefix for this address is 0::ffff:0:0:0/96. The host identifier is an IPv4 address that has to be taken from a special pool and assigned to the IPv6 node that wants to communicate with IPv4 nodes. TCP and UDP headers generally do not need to be modified by the translator. One exception is UDP headers that need a checksum for IPv6 because a pseudoheader checksum is required for IPv6. The same is true for ICMPv4 messages that need a pseudoheader checksum for ICMPv6. In addition to the checksum, ICMP error messages contain the IP header of the original packet in the payload that needs to be modified by the translator; otherwise, the receiving node cannot understand it. IPv4 options and IPv6 Routing headers, Hop-by-Hop Options headers, and Destination Option headers are not translated. Also, the translation techniques cannot be used for multicast traffic, because IPv4 multicast addresses cannot be mapped into IPv6 multicast addresses and vice versa. Just as with dual-stack nodes, applications running on nodes that use IP/ICMP translation need a mechanism to determine which protocol version to use for communication with their peers. 10.3.1.1. Translating IPv4 to IPv6
An IPv4-to-IPv6 translator receives an IPv4 datagram. Because it has been configured to know the pool of IPv4 addresses that represent the internal IPv6 nodes, the translator knows that the packet needs translation. It removes the IPv4 header and replaces it with an IPv6 header by translating all the information from the IPv4 header into the IPv6 header. Path MTU discovery is optional in IPv4 but mandatory in IPv6. If an IPv4 host does Path MTU discovery by setting the Don't Fragment bit in the header, Path MTU discovery works even through the translator. The sender may receive Packet Too Big messages from both IPv4 and IPv6 routers. If the Don't Fragment bit is not set in the IPv4 packet, an IPv6 translator has to ensure that the packet can safely travel through the IPv6 network. It does this by fragmenting the IPv4 packet if necessary, using the minimum MTU for IPv6, 1280 bytes. IPv6 guarantees that 1280-byte packets will be delivered without a need for further fragmentation. In this case, the translator always includes a fragment header to indicate that the sender allows fragmentation. Should this packet travel through an IPv6-to-IPv4 translator, the translator knows it can fragment the packet. For a UDP packet with a zero checksum, the translator must calculate a valid checksum for IPv6. If a translator receives the first fragment of a fragmented UDP packet with a zero checksum, it should drop the packet and generate a system message specifying the IP address and port number. Further fragments should be silently discarded. 10.3.1.2. Translating ICMPv4 to ICMPv6 and vice versa
For all ICMPv4 messages, the translator has to compute a valid checksum because it is required with ICMPv6. In addition to this, the type values have to be translated and, for error messages, the included IP header also needs to be translated. Internet Group Management Protocol (IGMP) messages are single-hop messages and should not be forwarded over routers. Therefore, they do not require translation and are silently discarded. The same translation rules apply to the translation of ICMPv6 messages to ICMPv4 messages, only in reverse order. 10.3.1.3. Translating IPv6 to IPv4
This process is not much different from the translation discussed previously. In this case, the translator knows that it has to translate from IPv6 to IPv4 based on the IPv4-mapped Destination address. It removes the IPv6 header and replaces it with an IPv4 header. The minimum MTU for IPv4 is 68 bytes; the minimum MTU for IPv6 is 1280 bytes. If a translator receives a packet for an IPv4 network with a smaller MTU, it creates 1280-byte packets and fragments them after translation. 10.3.2. NAT-PT
Network Address TranslationProtocol Translation (NAT-PT) is an implementation of SIIT. The NAT gateway uses a pool of globally unique IPv4 addresses and binds them to IPv6 addresses. No changes to the end nodes are necessary. NAT-PT has been set to experimental and is not to be seen as a preferred transition mechanism, but it is implemented and used, as you will see in the case study section. The following abbreviations are used in RFC 2766 and throughout this section:
These concepts are explained in the following sections. NAT has widely been used, especially to overcome the limitations of the IPv4 address space. Corporate networks use IPv4 addresses from the private range and a NAT router at the border of the corporate network translates the private addresses to a single or a limited number of public addresses. NAT, as described here, provides routing between an IPv6 network and an IPv4 network. With basic NAT, a block of IPv4 addresses is set aside and the fields for IP Source addresses, IP, TCP, UDP, and ICMP header checksums are translated. With NAPT, further transport identifiers such as TCP and UDP port numbers and ICMP message types are translated. This allows a set of IPv6 hosts to share a single IPv4 address. NAT can be unidirectional (only IPv6 hosts can initiate a session) or bidirectional (the session can be initiated from both sides). Hosts in the IPv4 network use DNS to resolve names. Therefore, a DNS Application Layer Gateway (ALG) must be capable of translating IPv6 addresses into their IPv4 NAT address bindings and vice versa. To understand how packets are translated, we'll follow a packet being sent from an IPv6 host through a NAPT gateway to an IPv4 host and back. Figure 10-14 illustrates the translation process. Figure 10-14. Communication flow over NAPT
In this example, Ford, the IPv6 host, has an IPv6 address of ABCD:BEEF::2228:7001. Marvin, on the other side of the NAPT router, has an IPv4 address of 120.140.160.101. The NAPT gateway has been assigned a pool of 120.10.40/24. Ford initializes a session with Marvin by sending a packet to the Destination address prefix::120.140.160.101, port 23. The prefix ::/96 is advertised by NAPT into the IPv6 network, and whenever a packet is sent to that prefix, it will be routed through NAPT. As Source address, Ford uses its IPv6 address with a port number of 3056 (step 1). The NAPT gateway now assigns an IPv4 address and a port number out of its pool. Let's say it uses the address 120.10.40.10. The new IPv4 packet going out from NAPT to Marvin has a Source address of 120.10.40.10, port 1025, and a Destination address of 120.140.160.101, port 23 (step 2). When Marvin replies, it sends the packet with a Source address of 120.140.160.101, port 23, to Destination address 120.10.40.10, port 1025 (step 3). NAPT translates the packet according to the parameters it has stored in its cache for the duration of the session and sends it from Source address prefix::120.140.160.101, port 23, to Destination address ABCD:BEEF::2228:7001, port 3056 (step 4). 10.3.3. Limitations
The NAT-PT translation mechanisms described in RFC 2766 should be used only if no other transition mechanism is possible, and dual-stack operation should be avoided for certain reasons. This mechanism has a number of disadvantages. For instance, it does not take full advantage of the advanced capabilities that IPv6 offers, and it is difficult to maintain the number of Application Level Gateways (ALG) required in NAT to keep all applications working correctly through the gateway. NAT-PT has therefore been moved to experimental status. For an explanation of the issues that led to this decision, refer to draft-ietf-v6ops-natpt-to-exprmntl-03.txt. There are other transition techniques, such as DSTM, to support IPv4 applications in IPv6 networks. The same topology restrictions apply that also apply to IPv4 NATs. The inbound and outbound datagrams pertaining to one session have to traverse the same NAT router. There are applications that use IP addresses in the payload of IP datagrams. NAT is not aware of the application layer and does not look into the payload to detect IP addresses. In this case, NAT would have to be combined with an ALG to support such applications in this type of environment. RFC 2766 describes how a DNS ALG or FTP ALG would have to translate to support these applications over NAT. For instance, if a DNS request goes out from the IPv4 network to a DNS server through a NAT-PT device in the IPv6 network (or vice versa), a mechanism must be provided that translates IPv4 resource records types (A type) to IPv6 resource record types (AAAA). FTP control sessions carry IP address information in the payload, and the format of the command allows only for 32-bit addresses. RFC 2428 defines two new extensions to FTP commands to replace the PORT and PASV commands. The new commands are designed not only to allow long addresses, but also to carry additional information about the protocol to be used. These new extensions can also be used for FTP over IPv4. An FTP ALG would have to be able to translate these commands for FTP to work over NAT.
End-to-end security cannot be provided when using any form of NAT. Two end nodes that need IPsec-level security must use either IPv4 or IPv6 natively. This is a well-known limitation of NAT in general and will be one of the driving reasons to move away from NAT and start to use IPv6 natively. Because the DNS ALG translates DNS requests, the mechanisms of DNSSEC will not work either. 10.3.4. Other Translation Techniques
There are additional translation mechanisms, which I describe in this section. 10.3.4.1. Bump-in-the-Stack
Bump-in-the-Stack (BIS) is specified in RFC 2767. It basically corresponds to the NAT-PT mechanism described in the previous section with the difference that the translator sits within the operating system of the host. BIS is a translation interface between IPv4 applications and the underlying IPv6 network, and its goal is to support IPv4 applications within an IPv6 dominant network. The BIS interface is between the IPv4 application and the network interface driver, and translates IPv4 to IPv6 for outgoing data and IPv6 to IPv4 for incoming data. The difference from using a dual-stack node is that when using BIS, such a node does not need an IPv4 address; IPv6 packets go over the network. The BIS driver has a pool of IPv4 addresses for internal communication with the IPv4 applications, but these addresses never leave the node. From outside, the node looks like an IPv6-only node. This mechanism is not designed to be a long-term solution, but to allow a migration to an IPv6 dominant network while still supporting IPv4 applications. 10.3.4.2. Bump-in-the-API
Bump-in-the-API (BIA) is specified in RFC 3338. It is the same mechanism as in BIS, only in this case, the translation happens internally between the IPv4 APIs and the IPv6 APIs. When an IPv4 application wants to communicate with an IPv6 node, the API translator intercepts the socket API functions and calls the corresponding IPv6 socket APIs. It also uses a pool of internal IPv4 addresses. Again, this mechanism is not designed to be a long-term solution. The goal is the same as with BIS and DSTM: to prevent the necessity to support IPv4 applications from delaying a migration to an IPv6-dominant network. 10.3.4.3. Transport Relay Translator
The Transport Relay Translator (TRT; see RFC 3142) is a translation mechanism to be used in an IPv6-only network on the transport layer. It sits in the IPv6 network and allows the communication between IPv6 nodes and IPv4 nodes. Every communication of an IPv6 client with an IPv4 application needs to go through the Relay Translator. In case of a TCP connection, the relay terminates the connection to the client and makes a new TCP connection on the other side to the IPv4 application. Internally, the translator translates between the two sessions. In case of a UDP connection, the translator simply translates and forwards the packet. All translation techniques should be used only if there is no other choice. The overview in this chapter aims to give an idea of the variety of mechanisms to enable coexistence and smooth transition. The most important goal the developers had in mind was to provide mechanisms to give customers the possibility to move to an IPv6 network as soon as possible. The sooner you have an IPv6-dominant network, the better, because maintaining one protocol is always less costly than maintaining two. |