NAT-PT & DNS-ALG (Deprecated)

NAT-PT and DNS-ALG were the first attempt to produce a viable IPv4-IPv6 layer 3 (L3) translator.

NAT-PT was specified in RFC 2766, "Network address Translation - Protocol Translation (NAT-PT)", February 2000.

A closely related mechanism was also described in RFC 2766, in addition to "basic NAT-PT", called NAPT-PT, "Network Address Port Translation + Protocol Translation". Basic NAT-PT required a lot of IPv4 addresses, so it is not applicable to a post-IPv4 world, such as we find ourselves in now. NAPT-PT was a variant that would allow up to 63K TCP and 63K UDP sessiones per IPv4 address.

From the RFC:

This document specifies an IPv4-to-IPv6 transition mechanism, in
addition to those already specified in RFC 1933. This solution
attempts to provide transparent routing, as defined in RFC 2663, to
end-nodes in V6 realm trying to communicate with end-nodes in V4
realm and vice versa. This is achieved using a combination of Network
Address Translation and Protocol Translation. The scheme described
does not mandate dual-stacks (i.e., IPv4 as well as V6 protocol
support) or special purpose routing requirements (such as requiring
tunneling support) on end nodes. This scheme is based on a
combination of address translation theme as described in RFC 2663
and V6/V4 protocol translation theme as described in RFC 2765 (SIIT).

SIIT (RFC 2765) is the Stateless IP/ICMP Translation Algorithm.

The goal of NAT-PT was to create a stateless, bidirectional gateway that could translate IPv4 to IPv6 and IPv6 to IPv4. You would be able to insert it between a region of IPv4-only and a region of IPv6-only, and nodes on either side would be able to transparently connect to and exchange data with nodes on the other side. This would have been very useful in the deployment of IPv6.

Another technology, called DNS-ALG was referred to in RFC 2766. It was supposed to translate the DNS query originating on the IPv4 side, going to a DNS server on the IPv6 side, asking for an A record into one asking for a AAAA record. It also needed to translate a DNS query orginating on the IPv6 side, going to a DNS server on the IPv4 side, asking for a AAAA record into one asking for an A record. Unfortunately not enough details were included to actually build one. This actually broke the "stateless" design goal. Some Internet Drafts were issued trying to clarify DNS-ALG, but none reached RFC status.

A lot of very smart people tried to make this work for several years. Defeat was finally admitted after seven years with RFC 4966, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", July 2007.

This document discusses issues with the specific form of IPv6-IPv4
protocol translation mechanism implemented by the Network Address
Translator - Protocol Translator (NAT-PT) defined in RFC 2766.  These
issues are sufficiently serious that recommending RFC 2766 as a
general purpose transition mechanism is no longer desirable, and this
document recommends that the IETF should reclassify RFC 2766 from
Proposed Standard to Historic status.

The deprecation of RFC 2766 included NAT-PT, NAPT-PT, and DNS-ALG. It is interesting to read the problems listed with these technologies in RFC 4966. They tried to leave the door open for other technologies that might be able to achieve the goal of IPv4<->IPv6 translation, but the problems were pretty serious.

One interesting comment concerned the role of DNS-ALG:

There is some ambiguity in RFC 2766 about whether the Application
Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this document)
is an integral and mandatory part of the specification.  The
ambiguity arises mainly from the first section of the applicability
section (Section 8), which appears to imply that 'simple' use of
NAT-PT could avoid the use of the DNS-ALG.
This is important because a number of the major issues arise from the
interactions between DNS and NAT-PT.  However, detailed inspection of
RFC 2766 shows that the 'simple' case has not been worked out and it
is unclear how information about the address translation could be
passed to the hosts in the absence of the DNS-ALG.  Therefore, this
document assumes that the DNS-ALG is an integral part of NAT-PT;
accordingly, issues with the DNS-ALG must be considered as issues for
the whole specification.

This leads one to believe that RFC 2766 really had not been thought through thoroughly, and nobody had actually tried to make it work.

Other problems were:

  • Disruption of protocols that embed IP addresses (and/or ports) in packet payloads.
  • Inability to redirect traffic for protocols that lack demultiplexing capabilities (where one NAPT-PT gateway is translating for multiple IPv6 hosts).
  • Requirement for applications to use keepalive mechanisms to address problems from premature NAT-PT state timeout.
  • Loss of information due to incompatible semantics between IPv4 and IPv6 versions of packet headers and protocols.
  • Need for additional state and/or packet reconstruction in NAPT-PT translators dealing with packet fragmentation.
  • Interaction with SCTP and multi-homing.
  • Need for NAT-PT to act as a proxy for correspondent node when the IPv6 node is mobile, with consequent restrictions on mobility.
  • NAT-PT could not handle multicast traffic.
  • Address selection issues when either  the internal or external hosts implement both IPv4 and IPv6 (dual stack nodes didn't work right).
  • Restricted validity of translated DNS records - it was possible for a node to get a DNS record it could not use.
  • Inappropriate translation of responses to DNS A record queries from IPv6 nodes.
  • Address selection issues and resource consumption in a DNS-ALG with multi-addressesed nodes.
  • DNS-ALG broke DNS-Sec.

RFC 4966 goes into detail on each of these problems, but the bottom line is that NAT-PT, NAPT-PT and DNS-ALG were total failures. Interestingly enough there are commercial products being sold today based on NAT-PT. You should avoid these. The IETF basically said "these mechanisms just don't work, we blew it - don't use them".