Previous Page
Next Page

Translation Mechanisms (NAT-PT)

Transition mechanisms reviewed so far enable end-to-end IPv6 connectivity. They are based on native IPv6 integration in a network, also called dual stack, or IPv6 encapsulation over IPv4 (manual or automatic tunnels). There is a potential scenario (third- and fourth-generation mobile phone networks, for instance) where IPv6-only devices need to communicate with IPv4-only nodes or resources. Such scenarios drive the need for translation mechanisms that enable communication between equipment that supports only one of the IP versions.

Even when hosts can be migrated to a dual stack at the networking layer, some applications will remain IPv4 only, just because their implementation relies too much on IPv4 addresses, or a recompilation cannot be implemented.

In such environments, you can use a different set of mechanisms, based on protocol translation rather than tunneling. These mechanisms include the following:

  • Bump-in-the-Stack (BIS), specified in RFC 2767

  • SOCKs-based gateway, specified in RFC 3089 and RFC 1928

  • TCP-UDP Relay, specified in RFC 3142

  • Network Address Translation-Protocol Translation (NAT-PT), specified in RFC 2765 and RFC 2766

These mechanisms fall into two categories: those that have an impact on hosts, generally only on one end of the communication; and those that do not. BIS and SOCKS-based gateways belong to the first category, whereas TCP-UDP Relay and NAT-PT belong to the second. Cisco IOS software implements only NAT-PT because the other translation mechanisms are either not relevant to Cisco IOS software or they are not really deployed. For these reasons, this section focuses only on NAT-PT.

NAT-PT enables IPv6-only hosts to communicate with IPv4-only hosts and applications. It is described in RFC 2766 and uses the IP translation mechanism referred as stateless IP/ICMP translation algorithm (SIIT), specified in RFC 2765.

Tables 3-4 and 3-5 present header translation rules, from IPv4 to IPv6 and in reverse.

Table 3-4. Header Translation IPv4 to IPv6

IPv6 Header Fields

Values

Version

6

Traffic Class

TOS

Flow Label

0

Payload Length

Total lengthheader length

Next Header

Protocol

Hop Limit

TTL

Source Address

NAT-PT

Destination Address

NAT-PT


Table 3-5. Header Translation IPv6 to IPv4

IPv4 Header Fields

Values

Version

4

IHL

5 (no options)

TOS

Traffic class

Total Length

Payload length + length of the IPv4 header

Identification

0

Flags

More Fragments Flag=0 Don't Fragment Flag=1

Fragment Offset

0

TTL

Hop limit

Protocol

Next Header field

Checksum

Computed

Source Address

NAT-PT

Destination Address

NAT-PT

Options

Not translated


Any IPv4 option is ignored during the protocol-translation process. IPv4 fragmented packets are translated using the IPv6 fragment header. Most ICMPv4 control messages are discarded during translation, except echo requests and replies which are mapped into IPv6 with the proper code (128, 129). Error messages are translated whenever possible. The reverse translation is done pretty much the same way. The IPv4 checksum computation is performed after the header has been translated.

The way addresses (source and destination) get translated is configuration controlled, or dynamic. In the simple case, explicit mapping is provided at the NAT-PT for both source and destination, in both directions.

Like for NAT, NAT-PT operates in various modes: static, where one IPv4 address is used to communicate with the IPv4-only host; and dynamic, where a pool of addresses is available, and dynamically bound to active flows; and PAT (Port Address Translation), where a single IPv4 address is used, and a TCP/UDP port number serves as a discriminator.

NAT-PT can also be used as the DNS application-level gateway (ALG) to translate the DNS transaction. The DNS query for an AAAA record gets translated into a query for an A record. Upon receiving a response with an IPv4 address, the NAT-PT builds an IPv6 address by prefixing it with the global NAT-PT prefix and sends the response to the IPv6 host. At the same time, it creates a dynamic entry for translating the destination.

For the destination, when communication is initiated from the IPv6 host, the IPv6 destination can embed the IPv4 address.

Figure 3-18 illustrates the case of dynamic NAT-PT using a pool of addresses.

Figure 3-18. NAT-PT


Example 3-31 presents the NAT-PT configuration of the router shown in Figure 3-18.

Example 3-31. NAT-PT Router Configuration

interface Ethernet0/0
 ipv6 address 3ffe:100:200:1::2/64
 ipv6 enable
 ipv6 nat
!
interface Ethernet1/0
 ip address 192.168.1.2 255.255.255.0
 ipv6 nat
!Entry for static mapping of v4 source->v6-
ipv6 nat v4v6 source 192.168.1.1 3ffe:b00:1::1
!Entry for mapping of v6 source->dynamic v4
ipv6 nat v6v4 source list pt1 pool v4pool
ipv6 nat v6v4 pool v4pool 10.50.10.1 10.50.10.10 prefix-length 24
ipv6 nat translation udp-timeout 600
ipv6 nat prefix 3ffe:b00:1::/96
!
ipv6 access-list pt1
 permit ipv6 3ffe:100:200:1::/64 any

NAT-PT involves many of the same issues as NAT, covered in depth in Chapter 1, "The Case for IPv6An Updated Perspective." These issues are also listed in draft-aoun-v6ops-natpt-deprecate (a work in progress in IETF). Whenever you have an alternative solution, you should favor it over NAT-PT. For instance, if there is any possibility to set up the hosts with dual-stack IPv4 and IPv6, other mechanisms (described in section "IPv6 Network Access") such as ISATAP or Teredo should be preferred. NAT-PT is not supported when an IPv6-only network is trying to communicate to another IPv6-only network via an IPv4 backbone or vice versa, because it would require a double translation. In such cases, tunneling mechanisms (described in the section "IPv6 over the Backbone") should be preferred.

However, a gap exists between a technical alternative and its operational feasibility. This gap may be filled by NAT-PT during the transitioning period. Consider, for example, the case of IPv6-only devices that should communicate with a node connected to an IPv6 unsupported data link layer (for example, Token Ring). For economical reasons, it may be valuable to run NAT-PT between devices, while waiting for the host to be upgraded to its next generation (thus ridding it of Token Ring).

You can integrate IPv6 into existing infrastructures in various ways. It is expected that dual-stack networks will become the standard approach, but various transition mechanisms are available today to lower the cost of the first steps toward IPv4 and IPv6 coexistence. This chapter has summarized those mechanisms to enable you to evaluate their use in different deployment scenarios as depicted in the second part of this book.


Previous Page
Next Page