White Paper IPv6 Network Address Translation and Protocol Translation (NAT-PT): What You Will Learn In an ongoing

Internet evolution, which is currently embracing IPv6 technology, there is an ongoing demand for communication between all sorts of devices. It is important that there is bidirectional communication possible between IPv6 and IPv4 based devices. This paper will discuss the NAT-PT (RFC2766) principle. This principle has been deprecated through RFC4966, nevertheless understanding the historical NAT-PT solution could be helpful in understanding the newly developed Address Family Translating (AFT) at the IETF standardization body. Initially SIIT (Stateless IP/ICMP Translation, RFC2765) will be explained, followed with the NAT-PT solution for the address translation. To conclude some Cisco IOS configuration syntax will be discussed. Stateless IP/ICMP Translation (SIIT) Any current Address Family Translation is based upon the SIIT principle. SIIT is the principle how an IPv4 packet is translated towards an IPv6 packet and vice-versa. SIIT on itself is not a sufficient migration mechanism because it is incapable of coordinating more than two unique addresses on either side of the translating device. This is where the newly developed IETF translation mechanisms and the historical NATPT technology plays a role.

Problem Presentation
IPv4/IPv6

IPv4/IPv6 IPv4

IPv4 IPv4/IPv6

IPv4+IPv6

IPv6
IPv6

IPv4
TECIPM-2010 2009 Cisco Systems, Inc. All rights reserved. Cisco Public

The usage of a translational technology is driven by a range of motivations: New Internet application (Microsoft Windows 7 Direct Access) Enterprises with IPv6 Only islands who would like to provide IPv4 content to these islands

Wireless mobile environments, because provisioning a single protocol to a handset is easier and more optimized then providing two protocol stacks on the same device

In the picture above the IPv6 clouds refer to a set of devices which ONLY have an IPv6 protocol stack, while the IPv4 clouds refer to devices with ONLY an IPv4 protocol stack. The combined IPv4/IPv6 clouds refer to devices with have both an IPv4 as an IPv6 protocol stack. How does SIIT technology operate? The key for SIIT is that in a stateless way the header fields between an IPv4 and IPv6 header are copied. The relevant IP header fields for this type of translation can be seen in the below picture.

SIIT
0 3 8 16 20 31

Vers.

H.L. TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

IPv4 IPv6
0 3 8 16 20 24 31

Vers. Tclass Payload Length

Flow Label Next Hdr

Hop Limit

Source Address

Destination Address
1

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

The fields between the IPv4 and the IPv6 headers are copied by using the following procedure and mechanism:
SIIT
0

SIIT
8 16 20 31
0 3

4 Vers.

H.L. TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

Vers.

H.L. TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

8 TOS

16

20

31

Simple copy

IPv4 IPv6
0 6 Vers. 3 8 16 20 24 31

IPv4 IPv6
0 3 8 Tclass 16 20 24 31

Tclass Payload Length

Flow Label Next Hdr

Hop Limit

Vers. Tclass Payload Length

Flow Label Next Hdr

Hop Limit

Source Address

Source Address

Destination Address
TECIPM-2010
TECIPM-2010 2009 Cisco Systems, Inc. All rights reserved. Cisco Public

Destination Address
13

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

12

SIIT
0 3 8 16 20 31

SIIT
0

Vers.

H.L. TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

Vers.

TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

3 H.L. H.L.

16

20 Total Length

31

Recalculate into Payload length

IPv4 IPv6
0 3 8 16 20 24 000000 Flow Label 31

IPv4 IPv6
0 3 8 16 20 24 31

Vers. Tclass Payload Length

Next Hdr

Hop Limit

Vers. Tclass Payload Length Payload Length

Flow Label Next Hdr

Hop Limit

Source Address

Source Address

Destination Address
14

Destination Address
15

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

SIIT
0 3 8 16 20 31
0

SIIT
3 8 16 20 31

Vers.

H.L. TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

Vers.

Protocol

H.L. TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

TTL

IPv4 IPv6
0 3 8 16 20 24 31

IPv4 IPv6
0 3 8 16 20 24 31

Vers. Tclass Payload Length

Flow Label Next Hdr Next Hdr

Hop Limit

Vers. Tclass Payload Length

Flow Label Next Hdr

Hop Limit Hop Limit

Source Address

Source Address

Destination Address
16
TECIPM-2010 2009 Cisco Systems, Inc. All rights reserved. Cisco Public

Destination Address
17

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

SIIT
0 3 8 16 20 31
0

SIIT
3 8 16 20 31

Vers.

H.L. TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

Vers.

H.L. TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

Header Checksum

IPv4 IPv6
Fragmented Packets generate fragmentation headers
0 3 8 16 20 24 31

IPv4 IPv6
0 3 8 16 20 24 31

Vers. Tclass Payload Length

Flow Label Next Hdr

Hop Limit

Vers. Tclass Payload Length

Flow Label Next Hdr

Hop Limit

Source Address

Source Address

Destination Address
18
TECIPM-2010 2009 Cisco Systems, Inc. All rights reserved. Cisco Public

Destination Address
19

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

Similar Stateless rules for translating IPv6 to IPv4 and ICMP exist. For ICMP translation

Header and type values are translated (note that when no counterpart is defined that the field is discarded) ICMP error packets have inside an IP information embedded, hence translation is required o Translation happens in similar fashion as for regular IP packets o The outermost IP header may change its length

There are some considerations to be taken into account when using SIIT based translation: There are situations where the IPv4 to IPv6 translation may cause fragmentation ESP encryption transport mode is supported by SIIT SIIT does not translate the following type of IPv6 headers: o Routing headers o Hop-by-hop options o Destination options o End-to-end AH headers

As demonstrated above the SIIT technology is a very deterministic translation. Unfortunately for the translation between the IPv6 address and the IPv4 address, the stateless deterministic characteristic not a given anymore and alternate means to automatically determine the correct translational IP addresses has to be used. NAT-PT provides such an infrastructure, based upon a DNS ALG (Application Layer Gateway).

SIIT
0 3 8 16 20 31

Vers.

H.L. TOS Total Length Flags Fragment Offset Identification Time to Live Protocol Header Checksum Source Address Destination Address

IPv4 IPv6
0 3 8 16 20 24 31

Vers. Tclass Payload Length

Flow Label Next Hdr

Hop Limit

Source Address

Destination Address
20

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

Network Address Translation Protocol Translation (NAT-PT) The technology of NAT-PT is strongly based upon SIIT translation mechanism. However NAT-PT adds a stateful component to the SIIT behavior to solve the association between the IPv4 and IPv6 addresses. This association is kept for a given time and is refreshed based upon session activity. A

side effect of this stateful behavior is that session traffic must traverse the same NAT-PT translator to used the correct set of IP address associations. Under some instances translation is also required at the application level, especially when there are IP addresses embedded within the data-field of the IP packet. For applications like DNS, FTP, etc there will be an Application Level Gateway (ALG) required for each of these application to perform a successful IPv4 <> IPv6 translation. When using NAT-PT the assumption is that there is an IPv6-ONLY system, who wants to speak with an IPv4-ONLY system, or vice versa. The NAT-PT device in middle, which connects to both the IPv4 and the IPv6 worlds, facilitates the translation.

NAT-PT: Overview

IPv6

Sees an IPv4 Network with few addresses

Sees an IPv6 network with an special PREFIX::/96

IPv4

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

24

In the figure above, the NAT-PT device is shown between the IPv6 and the IPv4 networks. When using NAT-PT as a translation mechanism, then any device within the IPv6 cloud will see the IPv4 world as [PREFIX::/961]. To represent a single IPv4 host within the IPv6 network, then the full IPv4 address is added to this 96 bit prefix, and then the full 128 bit address represents a single IPv4 host. The representation in the alternate direction is different, mainly because the IPv4 address space is much smaller compared with the IPv6 address space. Within the IPv4 cloud the IPv6 devices are represented by a few IPv4 addresses, which tends to be a single address for each IPv6 device communicating with IPv4 devices. The operation of NAT-PT is slightly different between an IPv6 initiated communication or an IPv4 initiated communication. Each of these scenarios will be discussed in the next paragraphs.

The PREFIX::/96 can be chosen by the NAT-PT operator

NAT-PT IPv6 Initiated Communication

NAT-PT: IPv6 Initiated Communication

2001:db8:babe::1

IPv6

(1) An application uses a name to start communication The DNS resolver sends a lookup request

(2) Local DNS Server Name not in cache. A DNS request is sent
TECIPM-2010 2009 Cisco Systems, Inc. All rights reserved. Cisco Public

IPv4
192.168.0.1 www.foo.com
25

The IPv6 host has an IP address of 2001:db8:babe::1 and would like to start a session with a remote host found at www.foo.com. As a first step (1) the host will check through his DNS resolver to find the IP address related to the URL www.foo.com. The first step the resolver will take is to check with the local host DNS cache. If no matching entry is found then a (2) DNS request is sent out.

NAT-PT: IPv6 Initiated Communication

DNS-ALG translates query NAT-PT translates addresses

IPv6

IPv4

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

26

When the DNS query is sent from the host to the DNS server, it will be needed to translate the DNS request from an IPv6 request into an IPv4 request. The NAT-PTs DNS-ALG function will be responsible for translating the IPv6 into IPv4 addresses as shown in the above figure. When the IPv4 DNS server responds to the DNS request as shown then translation will occur again, but now from IPv4 to IPv6

NAT-PT: IPv6 Initiated Communication

NAT-PT processes DNS Response DNS-ALG changes type and IPv4 address for PREFIX::IPv4

IPv6

IPv4

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

27

As can seen above the NAT-PT will process the DNS response and the DNS-ALG function will change type and the IPv4 address into an IPv6 address based upon [PREFIX::/96] + [IPv4 address]. The NAT-PT will remember the association between the just made IPv4 and IPv6 addresses. Once the IPv6 device received a valid IPv6 address it can initiate a session with its remote destination as shown in the figure below. The session will be initiated from the IPv6 address of the IPv6 device, and will have as destination address PREFIX::IPv4 (in the example the IPv4 address is 192.168.0.1).

NAT-PT: IPv6 Initiated Communication

IPv6

Source: 2001:db8:babe::1 Destination: PREFIX::192.168.0.1

IPv4

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

28

This session will have to be translated by the NAT-PT device from an IPv6 session into an IPv4 session. The NAT-PT device will need to create a translation slot.

NAT-PT: IPv6 Initiated Communication

1.
2001:db8:babe::1

2. 3.

IPv6

Looks for PREFIX::192.168.0.1 in its table, but does not find it Looks for a free IPv4 address (e.g. 100.1.1.1), and associates to 2001:db8:babe::1 Generates packet: New destination address 192.168.0.1 (obtained from PREFIX::192.168.0.1) New source address 100.1.1.1

IPv4
192.168.0.1 www.foo.com
TECIPM-2010 2009 Cisco Systems, Inc. All rights reserved. Cisco Public

29

The translation slot is created and used by the NAT-PT device by going through the following process steps: 1. First the NAT-PT device looks in its translation table with aspiration to find an existing translation slot.

2. If a free translation slot is not found, then the NAT-PT device will look for an available IPv4 address and associates that with the sessions source IPv6 address (in the example above this would be 100.1.1.1 and that is associated with 2001:db8:babe::1) 3. Once the translation association slot has been created it can be used for ongoing address and protocol translation. Each packet passing through the NAT-PT device will be translated, and both the source as destination IP addresses will be modified by usage of SIIT. In the example the source IPv6 address (2001:db8:babe::1) will be translated in the available IPv4 address (100.1.1.1), and the IPv6 destination address (PREFIX::192.168.0.1) is translated into 192.168.0.1 The above is the translation in a single direction and returning packets must be translated also. This is demonstrated by the below procedure.

NAT-PT: IPv6 Initiated Communication

2001:db8:babe::1

IPv6

Response Source: 192.168.0.1 Destination: 100.1.1.1

Identifies address in table, and translates it Also translates source address Performs ALG if necessary Executes SIIT translation
TECIPM-2010 2009 Cisco Systems, Inc. All rights reserved. Cisco Public

IPv4
192.168.0.1 www.foo.com
30

The IPv4 device truly believes it is communicating with another IPv4 device. The packets it sends out have both IPv4 source and destination addresses. Once the reply packets of the IPv4 host flow through the NATPT device, then the translation slot is used to execute upon the SIIT based translation, potentially complemented with a application ALG translation (FTP for example). NAT-PT IPv4 Initiated Communication In many cases the IP session is not initiated by the IPv6 host, but by the IPv4 host. The NAT-PT operational principle is very similar; however there is a slight difference on how the translation slot is created.

NAT-PT: IPv4 Initiated Communication

2001:db8:babe::1 www.foo6.com

Application uses hostname (www.foo6.com) DNS Request

IPv6

Local DNS Server sends request

IPv4
192.168.0.1 www.foo.com

TECIPM-2010

2009 Cisco Systems, Inc. All rights reserved.

Cisco Public

31

In the example used the IPv4 host would like to communicate with www.foo6.com. As a first step to create a session with a remote party the IPv4 host will most likely make a DNS lookup. The goal is to figure out the IPv4 destination address if the actual IPv4 destination address is not known locally.

NAT-PT: IPv4 Initiated Communication

2001:db8:babe::1 www.foo6.com

NAT-PT translates address and DNS request type

IPv6

IPv4
192.168.0.1 www.foo.com
TECIPM-2010 2009 Cisco Systems, Inc. All rights reserved. Cisco Public

32

The translator device can translate through an DNS Application Level Gateway function translate the DNS query and forward it towards the IPv6 DNS server. When the NAT-PT device receives the DNS-reply as shown below, then it will look for an available IP4 address to associate with the real IPv6 address received from the DNS server. This address is flagged as a non-cacheable address within the association table.

NAT-PT: IPv4 Initiated Communication

2001:db8:babe::1 www.foo6.com

DNS-ALG detects address in DNS message (2001:db8:babe::1)

IPv6

Looks for free IPv4 address and associates it to IPv6 address DNS response marked as noncacheable

Rest of the process is the same

TECIPM-2010 2009 Cisco Systems, Inc. All rights reserved. Cisco Public

IPv4
192.168.0.1 www.foo.com
33

The remainder operations for an IPv4 initiated session is the same as an IPv6 initiated session. NAT-PT conclusion NAT-PT allows communication between IPv4/IPv6 domains by translating addresses and protocols. When the communication starts at the IPv6 domain, then state is created when the first data-packet traverses the NAT-PT device. If communication starts at the IPv4 domain, then state must be established when the first DNS response traverses the NAT-PT device. NAT-PT is a rather heavy mechanism requiring a stateful address association table, and protocol translation is needed for every single packet. A NAT-PT translator is due to its important placement a potential single point of failure. The SIIT protocol translation may result in information loss (e.g. IPv6 extension headers) due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols. NAT-PT does not have Multicast support. Configuration of NAT-PT The configuration described in this document has been tested at various industry conferences and is working correctly in process switched mode as referenced at http://www.civiltongue.net/6and4/wiki/Cisco%20IOS%20NAT-PT%20Configuration. As documented previously the functionality of NAT-PT exists out two main functions very closely tight to eachother: Translation between IPv4 and IPv6 DNS-ALG to translate the A to AAAA records and vice versa

Cisco NAT-PT has the capability to separate these functions and run them on two different devices. During these industry conferences the protocol translation between IPv4 and IPv6 was achieved using a standard Cisco router, while the DNS-ALG functionality was achieved by using the DNS Trick Or Treat Deamon (TOTD) ((http://www.vermicelli.pasta.cs.uit.no/software/totd.html). Separating these two functionalities from each other will need special considerations within the Cisco NATPT configuration. Prior to configuring NAT-PT it is desired that the addressing details are clear and available: On the IPv6 facing interface of the NAT-PT, there is need to have a /64 IPv6 interface address. For this purpose 2001:db8::/64 is utilized On the IPv4 facing interface a minimum of a /30, for this purpose we will use 10.20.0.0/30. The IPV4 address of the DNS server located on the IPv4 only side of the NAT-PT, in this document we will use 10.10.0.1/32 for this purpose A minimum of a /96 to use as the NAT-PT IPv6 prefix, for these purposes 2001:0DB8:1::/96 is used A contiguous block of IPv4 address space to be used for IPv4 addres pool, in this document we will use 10.20.0.0/24 for this purpose. As a rule of thumb the size of this block should be roughly 1020% larger than the highest number of simultaneous IPv6 only clients you expect to have transiting the NAT-PT. When planning for N:1 translation, known as port translation or overload mode, then a smaller pool of addresses is needed.
NATPTPrefix:2001:db8:1::/96

DNSALG IPv4Internet
DefaultIPv4Route DefaultIPv6Route

IPv6ONLYNetwork

NATPT IPv4ONLY IPv6ONLY

IPv4addressPoolsrcpool1 10.20.0.0 10.20.0.255

The configuration described below focuses upon IPv6 initiated sessions, thus from an IPv6 ONLY host towards an IPv4 ONLY host, hence unsolicited connections from IPv4 to IPv6 are out of scope for this configuration. The example below represents a working example of a NAT-PT device using an independent DNS-ALG. Full details on each of the commands can be found in the Cisco configuration guide found at: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6nat_trnsln_ps6350_TSD_Products_Configuration_Guide_Chapter.html
ipv6 unicast-routing By default IPv6 unicast-routing is not enabled, so it has to be enabled by manual command ! interface GigabitEthernet0/1 description NAT-PT inside IPv6-only interface no ip address There is no need for an IPv6 address as this is IPv6 only side of the NAT-PT device ipv6 address 2001:0DB8::2/64 The IPv6 address of the NAT-PT router at the IPv6 only side ipv6 nat Enable NAT-PT on this interface ! interface GigabitEthernet0/2 description NAT-PT outside IPv4-only interface ip address 10.20.0.1 255.255.255.252 This is the NAT-PTs IPv4 only network side. There is no IPv6 address configured on this side of the NAT-PT device ipv6 nat Enable NAT-PT on this interface ! ip route 0.0.0.0 0.0.0.0 10.10.0.2 Configuration of the IPv4 default route out from the NAT-PT. It is also possible to configure a routing protocol, but to keep the example simple a static route entry is used ! ipv6 route ::/0 2001:0DB8::1

Configuration of the IPv6 default route. Also for IPv6 a routing protocol could be used, however for keeping the configuration example simple static routing is selected ! ipv6 nat translation timeout 3600 Translationslot time-out in seconds which apply to dynamic translations. This is a global translationslot time-out. The default time is 86400 seconds (24 hours). This suggested value worked well in some environments, however your environment may need different tuning. ipv6 nat translation tcp-timeout 3000 Translationslot time-out for the TCP specific translations in seconds. The default time is 86400 seconds (24 hours). This suggested value worked well in some environments, however your environment may need different tuning. ipv6 nat v4v6 source 10.10.0.1 2001:0DB8:1:0:A0A:1 Optional: This line of configuration is *not* needed when an external DNS-ALG is used. When the DNS-ALG of the Cisco router is utilized, and the DNS server for the IPv6 ONLY hosts resides at the IPv4 ONLY side, then this static translation is needed. The basic syntax is ipv6 nat v4v6 source <real ipv4 address of DNS server> <translated IPv6 address of DNS server>. The translation from IPv4 -> IPv6 is done by using the NAT-PT /96 prefix complemented with the IPv4 address in HEX. How does the mapping work? 10.10.0.1 would be written in hex as 0A0A:0001, which results in [2001:0db8:1::/96 + 0A0A:0001] = 2001:0db8:1::0A0A:0001 address. For this working example when an EXTERNAL DNS-ALG is used, this line is obsolete, because the DNS server for the IPv6 ONLY hosts will reside at the IPv6 only side of the NAT-PT. ipv6 nat v6v4 source list v6_natpt_list pool srcpool1 From this line onwards the configuration of the NAT-PT starts to take place. v6_natpt_list is the list of IPv6 addresses which should be translated by the NATPT device. An IPv6 host outside this list will not be dynamically translated. srcpool1 is the IPv4 address pool used to translate the IPv6 addresses. Thus if the NAT-PT receives an IPv6 packet at its IPv6 ONLY interface, then it will translate the IPv6 source address to an address from the srcpool1 available IPv4 addresses. ipv6 nat v6v4 pool srcpool1 10.20.0.1 10.20.0.254 prefix-length 24 This line defines the IPv4 address pool used to translate the IPv6 ONLY hosts IPv6 addresses. scrpool1 is a random name which makes sense for the person configuring the router. Next is the address range available, starting with the first address available in the pool followed by the last address available in the pool, followed by the prefix length. ipv6 nat prefix 2001:0DB8:1::/96 v4-mapped v6_natpt_list By this command the NAT-PT prefix is configured. This prefix is used to represent IPv4 ONLY hosts within the IPv6 ONLY environment. This representation exists out of adding to the 96 bits of the NAT-PT prefix the 32 bits of the IPv4 address and by that means compose a valid unique 128 bit IPv6 address.

When using an external DNS-ALG, the v4-mapped keyword is needed. This keyword influences the moment when a translation slot is created. With traditional NAT-PT the translation slot is created when the DNS request passes through the DNS-ALG of the NAT-PT, however when using an external DNS-ALG, it is impossible to create this translation slot because the NAT-PT does not run the DNS-ALG function anymore. In that case the translation slot must be created when the actual IP packet traverses the NAT-PT router. The command v4-mapped command makes that functionality happen. The v6_natpt_list is used to provide some additional control about which incoming IPv6 traffic is mapped to this prefix. ! ! ipv6 access-list v6_natpt_list permit ipv6 any 2001:0DB8:1::/96 Access list to control the IPv6 mapped traffic as referenced in the previous NAT-PT configuration syntax !

The above configuration goes from the assumption that there is a 1:1 mapping between IPv6 and IPv4 addresses. It is also possible to have N:1, where multiple IPv6 only hosts share the same IPv4 address. This is known as NAPT-PT where the IPv4 address is overloaded with IPv6 addresses. To enable this then the overload keyword must be used when defining the available IPv4 address pool as shown in following example: ipv6 nat v6v4 source list natpt-list interface Loopback0 overload In the above example a single IPv4 address is used instead of the previously defined IPv4 address-pool (10.20.0.0 10.20.0.255)

More information on the configuration of NAT-PT can be found in the Cisco IPv6 configuration guide at: http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6nat_trnsln_ps6441_TSD_Products_Configuration_Guide_Chapter.html Deprecation of NAT-PT The deprecation of NAT-PT is documented in RFC4966 (July 2007) Reasons to move network address translator protocol translator (NAT-PT) to historic status. The goal of this is to have IPv6 technology o take benefit of its full capabilities without restrictions and lost information due to using translational techniques. Within the recommendation for deprecation of NAT-PT at the IETF there are a number of general translational motivations mentioned: Protocols that embed IP addresses provide complications Inability to redirect traffic for protocols that lack de-multiplexing capabilities (i.e. IPsec, RSVP, etc) keepalive mechanisms for state-maintenance Loss of information due to IPv4 vs IPv6 header semantics (next-headers, flow-label)

Fragmentation Multicast Scalability

In addition to this list also there are also some NAT-PT specific issues documented: Address selection issues when either the internal or external hosts implement both IPv4 and IPv6 (when destination host has both A and AAAA record for example) Non-Global Validity of Translated RR Records (a translated record may be forwarded to an application that cannot use it) Address selection issues and resource consumption in a DNS-ALG with multi-addressed nodes Limitations on DNS security capabilities when using a DNS-ALG Inappropriate translation of responses to A queries from IPv6 nodes

The IETF is working upon alternative solutions to replace NAT-PT within the Behave working group. These solutions decouple the Translation function from the DNS-ALG functionality. Within this IETF working group the replacement solution for NAT-PT to provide IPv6 users access to the IPv4 internet is named NAT64. This paper has been written in such a way, that once NAT64 becomes a formal standard and products are available, that this can replace the NAT-PT device without impacting the network design heavily and to keep the implementation cycle to as short as possible.

For More Information Cisco NAT-PT configuration reference http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-nat_trnsln.pdf NAT-PT RFC http://www.ietf.org/rfc/rfc2766.txt DNS-ALG http://www.ietf.org/rfc/rfc2694.txt