RFC 4966

Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status

📅 published July 2007, from ietf

Reasons to Move NAT-PT to Historic Status 🦋

okay bestie, this one is a whole vibe 💅 It's RFC 4966, and it's basically the IETF saying "we need to talk about NAT-PT" 🫶

  • RFC number: 4966
  • Title: Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
  • Authors: C. Aoun (Energize Urnet) and E. Davies (Folly Consulting) 👑
  • Stream and working group: Network Working Group
  • Category: Informational 🎀
  • Date: July 2007 🌸
  • Obsoletes: RFC 2766 💔
  • Updates: nothing ✨

Status of This Memo ✨

so this part is kind of boring but it's important 🙈 This memo gives information to the Internet community. It is NOT an Internet standard of any kind. And distribution is unlimited, so share it with your whole group chat 💜

Copyright (C) The IETF Trust (2007). 🫶

Abstract 🔥

okay so here's the tea ☕ This document talks about problems with one specific IPv6-IPv4 protocol translation mechanism, the Network Address Translator - Protocol Translator (NAT-PT), which is defined in RFC 2766. These problems are serious enough that recommending RFC 2766 as a general purpose transition mechanism is no longer a good look 💀 So this document suggests that the IETF should move RFC 2766 from Proposed Standard to Historic status. Iconic reclassification arc 😭🍓

Table of Contents 🧚

Here's the whole roadmap so you can see where we're going 🗺️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . . .  7
    2.1.  Issues with Protocols Embedding IP Addresses . . . . . . .  7
    2.2.  NAPT-PT Redirection Issues . . . . . . . . . . . . . . . .  8
    2.3.  NAT-PT Binding State Decay . . . . . . . . . . . . . . . .  8
    2.4.  Loss of Information through Incompatible Semantics . . . .  9
    2.5.  NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . 10
    2.6.  NAT-PT Interaction with SCTP and Multihoming . . . . . . . 11
    2.7.  NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 12
    2.8.  NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 12
  3.  Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . . . 13
    3.1.  Network Topology Constraints Implied by NAT-PT . . . . . . 13
    3.2.  Scalability and Single Point of Failure Concerns . . . . . 14
    3.3.  Issues with Lack of Address Persistence  . . . . . . . . . 15
    3.4.  DoS Attacks on Memory and Address/Port Pools . . . . . . . 16
  4.  Issues Directly Related to Use of DNS-ALG  . . . . . . . . . . 16
    4.1.  Address Selection Issues when Communicating with
          Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16
    4.2.  Non-Global Validity of Translated RR Records . . . . . . . 18
    4.3.  Inappropriate Translation of Responses to A Queries  . . . 19
    4.4.  DNS-ALG and Multi-Addressed Nodes  . . . . . . . . . . . . 19
    4.5.  Limitations on Deployment of DNS Security Capabilities . . 19
  5.  Impact on IPv6 Application Development . . . . . . . . . . . . 20
  6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
  7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
  8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
  9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
    9.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
    9.2.  Informative References . . . . . . . . . . . . . . . . . . 23

1. Introduction ✨

okay so bestie, the Network Address Translator - Protocol Translator (NAT-PT) document [RFC2766] is all about network-layer translation. Its whole purpose is letting nodes that only speak IPv4 talk to nodes that only speak IPv6 🦋 while the internet is transitioning to IPv6.

[RFC2766] describes the basic NAT-PT, where only addresses get translated, and the Network Address Port Translator - Protocol Translator (NAPT-PT), which also translates transport identifiers 🌸 so you can stretch those precious scarce IPv4 addresses further. The actual translation is done with the Stateless IP/ICMP Translation Algorithm (SIIT) defined in [RFC2765]. When this doc just says "NAT-PT" with no qualifier, it means both basic NAT-PT and NAPT-PT. And if a point only applies to the address-only translator, it'll say "Basic NAT-PT" 💜

A bunch of earlier documents have already flagged issues with NAT-PT 😭. This one is going to recap those, call out a few problems carried over from regular IPv4 NATs, and add some new issues nobody has really talked about yet. Where there are proposed fixes, they get mentioned too, along with any changes the spec might need ✨

Here's the vibe check 💅: NAT is an ongoing thing we need because globally unique IPv4 addresses are limited. NAT-PT is different, though. It's only a transition mechanism for IPv6, so it shouldn't be allowed to box in IPv6 apps or limit what IPv6 can do in the future 🧚

So the conclusion is that these issues are a big deal. The technical and operational headaches, especially the possible future limits on IPv6 networks (see Section 5), make it undesirable to recommend NAT-PT as described in [RFC2766] as a general purpose transition mechanism for talking between IPv6 networks and IPv4 networks 🙈

Now, the packet translation in [RFC2766] isn't generally applicable, but we still need a translation mechanism. It's pretty likely that some IPv4-only node will need to talk to an IPv6-only node in certain situations 🫶 Honestly that might be better handled by an application-level proxy or a transport-layer translator. There could still be cases where a revised, possibly restricted version of NAT-PT works, so the document recommends that the IETF reclassify RFC 2766 from Proposed Standard to Historic status. That stops it from being used in the wrong scenarios while a replacement gets developed 🍓

Here are the documents relating directly to NAT-PT that were reviewed while drafting this:

  • Network Address Translation - Protocol Translation (NAT-PT) [RFC2766]
  • Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765]
  • NAT-PT Applicability Statement [NATP-APP]
  • Issues with NAT-PT DNS ALG (Application Layer Gateway) in RFC 2766 [DNS-ALG-ISSUES]
  • NAT-PT DNS ALG Solutions [DNS-ALG-SOL]
  • NAT-PT Security Considerations [NATPT-SEC]
  • Issues when Translating between IPv4 and IPv6 [TRANS-ISSUES]
  • IPv6-IPv4 Translation Mechanism for SIP-Based Services in Third Generation Partnership Project (3GPP) Networks [3GPP-TRANS]
  • Analysis on IPv6 Transition in 3GPP Networks [RFC4215]
  • Considerations for Mobile IP Support in NAT-PT [NATPT-MOB]
  • An IPv6-IPv4 Multicast Translator based on Internet Group Management Protocol / Multicast Listener Discovery (IGMP/MLD) Proxying (mtp) [MTP]
  • An IPv4-IPv6 Multicast Gateway [MCASTGW]
  • Scalable mNAT-PT Solution [MUL-NATPT]

Most of the docs that talk about these issues probably won't ever become RFCs 🥲, so the issues get summarized here instead. That way there's no need for normative references.

Some extra issues can be inferred from problems already known in "traditional" IPv4 NATs 👀. These are the relevant ones:

  • Protocol Complications with the IP Network Address Translator [RFC3027]
  • IP Network Address Translator (NAT) Terminology and Considerations [RFC2663]

There's some ambiguity in [RFC2766] about whether the Application Layer Gateway (ALG) for DNS (called DNS-ALG in this document) is an integral and mandatory part of the spec 🤔. The confusion mostly comes from the first section of the applicability section (Section 8), which seems to suggest that a 'simple' use of NAT-PT could skip the DNS-ALG.

This matters a LOT 😭 because a bunch of the major issues come from how DNS and NAT-PT interact. But when you look closely at [RFC2766], the 'simple' case was never actually worked out, and it's unclear how the address translation info would get passed to the hosts without the DNS-ALG. So this document assumes the DNS-ALG is an integral part of NAT-PT. That means DNS-ALG issues count as issues for the whole specification 🔥

Also, issues that aren't specifically about the DNS-ALG will apply to any network-layer translation scheme, including anything based on the SIIT algorithm [RFC2765]. If new translators get developed as alternatives to NAT-PT, the generic issues that apply to all IPv6-IPv4 translators should stay in mind 💖

Issues with IPv6-IPv4 translators in general, and NAT-PT in particular, get sorted like this 🌈:

  • Issues that are independent of the use of a DNS-ALG and are, therefore, applicable to any form of an IPv6-IPv4 translator:
    • Disruption of all protocols that embed IP addresses (and/or ports) in packet payloads or apply integrity mechanisms using IP addresses (and ports).
    • Inability to redirect traffic for protocols that lack demultiplexing capabilities or are not built on top of specific transport-layer protocols in situations where one NAPT-PT is translating for multiple IPv6 hosts.
    • Requirement for applications to use keepalive mechanisms to workaround connectivity issues caused by premature NAT-PT state timeout.
    • Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols.
    • Need for additional state and/or packet reconstruction in NAPT-PT translators dealing with packet fragmentation.
    • Interaction with SCTP and multihoming.
    • Need for NAT-PT to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility.
    • NAT-PT not being able to handle multicast traffic.
  • Issues that are exacerbated by the use of a DNS-ALG and are, therefore, also applicable to any form of an IPv6-IPv4 translator:
    • Constraints on network topology.
    • Scalability concerns together with introduction of a single point of failure and a security attack nexus.
    • Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be disrupted if a different mapping is used. The use of the DNS-ALG to create address mappings with limited lifetimes means that applications must start using the address shortly after the mapping is created, as well as keep it alive once they start using it.
    • Creation of a DoS (Denial of Service) threat relating to exhaustion of memory and address/port pool resources on the translator.
  • Issues that result from the use of a DNS-ALG and are, therefore, specific to NAT-PT as defined in [RFC2766]:
    • Address selection issues when either the internal or external hosts implement both IPv4 and IPv6.
    • Restricted validity of translated DNS records: a translated record may be forwarded to an application that cannot use it.
    • Inappropriate translation of responses to A queries from IPv6 nodes.
    • Address selection issues and resource consumption in a DNS-ALG with multi-addressed nodes.
    • Limitations on DNS security capabilities when using a DNS-ALG.

Section 2, Section 3 and Section 4 talk through these groups of issues. Section 5 looks at what deploying NAT-PT means for application developers, and the long-term effects of NAT-PT (or any generally deployed IPv6-IPv4 translator) on IPv6's future 🦋

The terminology in this document is defined in [RFC2663], [RFC2766], and [RFC3314].

2. Issues Unrelated to an DNS-ALG 🎀

2.1. Issues with Protocols Embedding IP Addresses 💅

It's well known from IPv4 NAT work (see Section 8 of [RFC2663] and [RFC3027]) 🧠 that the big class of protocols that stick numeric IP addresses inside their payloads either can't work through NATs, or they need special ALGs as helpers to translate the payloads to match the address and port translations. That same set of protocols can't pass through NAT-PT either 😭. It's worse with NAT-PT, because IPv6 and IPv4 addresses have different lengths, so the packet lengths and the packet contents both change. [RFC2766] describes these consequences as part of the FTP ALG description. Any protocol with embedded IP addresses that runs over TCP needs similar workarounds too 🍓

The issues in Sections 2 and 3 of [RFC2663], about authentication and encryption with NAT, also apply to NAT-PT 🔐.

Running a whole suite of ALGs means NAT-PT equipment needs the logic for every relevant protocol. Most of those protocols keep evolving, so the ALGs need continual, coordinated updates to stay in step 🌀.

Say the NAT-PT has a colocated ALG for one of these protocols. That ALG could replace the embedded IP addresses and ports. But this only works if no cryptographic integrity mechanism is in use and the protocol messages go out in the clear (i.e., not encrypted) 🙈.

There's a possible workaround where the NAT-PT is party to the security association used for authentication and/or encryption. Then NAT-PT would know the cryptographic algorithms and keys securing the traffic, and it could modify and re-secure the packets. This would definitely complicate network operations and create extra points of security vulnerability ⚠️.

Unless UDP encapsulation is used for IPsec [RFC3498], traffic using IPsec AH (Authentication Header), in both transport and tunnel mode, and IPsec ESP (Encapsulating Security Payload), in transport mode, can't be carried through NAT-PT without terminating the security associations on the NAT-PT. That's because of their use of cryptographic integrity protection 😭🔒.

A related issue with DNS security is discussed in Section 4.5. 💜

2.2. NAPT-PT Redirection Issues ✨

Okay, so Section 4.2 of [RFC3027] covers problems that are specific to RSVP and NATs 🧚, and one of them is actually a more general problem for all port translators. When several end-hosts share a single NAPT-PT box, protocols that don't have anything like transport-layer port numbers to tell flows apart can fail to work through NAPT-PT (or any other port translator). Why? Because NAPT-PT has nothing to use to figure out which binding is the right one 💀.

This hits IPsec encrypted packets where the transport port is hidden 🙈. (The Security Parameter Index (SPI) might work as an alternative demultiplexer, though.) It also hits protocols like RSVP, which ride directly inside IP datagrams instead of using a standard transport-layer protocol like TCP or UDP. With RSVP, packets going from the IPv4 domain to the IPv6 domain don't necessarily carry a usable demultiplexing field, because the port fields in the flow identifier and traffic specifications are optional 🦋.

There are several ad hoc workarounds for these demultiplexing issues, but honestly, in most cases they aren't documented anywhere 😭. That can lead to non-deterministic and undesirable behavior. For example, these workarounds often assume particular network topologies, etc., in order to function correctly. If those assumptions aren't met in a deployment, the workaround may not work as expected 🫠.

This issue is closely related to the fragmentation issue described in Section 2.5 💜.

2.3. NAT-PT Binding State Decay 🌸

NAT-PT will generally use dynamically created bindings to reduce the need for IPv4 addresses, for both basic NAT-PT and NAPT-PT 🍓. Both of them use soft state mechanisms to manage the address, and in the case of NAPT-PT, port pools are used for dynamically created address bindings. This lets all types of NAT-PT boxes operate autonomously, so clients don't have to signal, either implicitly or explicitly, that a binding is no longer required. Super convenient! ✨ But here's the catch: without soft state timeouts, network and application unreliability would inevitably lead to leaks, eventually causing address or port pool exhaustion 💥.

So for a dynamic binding to persist for longer than the soft state timeout, packets must be sent periodically from one side of the NAT-PT to the other. (The NAT-PT specification doesn't specify the direction 🤷‍♀️.) If no packets are sent in the proper direction, the NAT-PT binding won't be refreshed and the application connection will be broken. Hence, all applications need to maintain their NAT-PT bindings during long idle periods by incorporating a keepalive mechanism. Which may not be possible for legacy systems 😭.

Also, [RFC2766] does not specify how to choose timeouts for bindings. As discussed in [RFC2663] for traditional NATs, selecting suitable values is a matter of heuristics, and coordinating with application expectations may be impossible 🙃.

2.4. Loss of Information through Incompatible Semantics 👑

NAT-PT reuses the SIIT header and protocol translations defined in [RFC2765]. Mismatches in semantics between IPv4 and IPv6 can lead to loss of information when packets get translated. Three issues come out of this 💅:

  • There is no equivalent in IPv4 for the flow label field of the IPv6 header. So any special treatment of packets based on flow label patterns can't be propagated into the IPv4 domain.
  • IPv6 extension headers give us lots of flexibility for future improvements in the IP protocol suite, and new headers that don't have equivalents in IPv4 may be defined. In practice, some existing extensions, such as routing headers and mobility extensions, are not translatable 🥺.
  • As described in Section 2.2 of [NATP-APP], there are no equivalents in IPv6 for some ICMP(v4) messages. For others (notably the 'Parameter Problem' messages), the semantics are not equivalent. Translating such messages may lead to the loss of information. However, this issue may not be very severe, because the error messages relate to packets that have been translated by NAT-PT rather than to arbitrary packets. If the NAT-PT is functioning correctly, there is, for example, no reason why IPv6 packets with unusual extension headers or options should be generated 🧐.

Loss of information in any of these cases could be a constraint for certain applications 🚧.

A related matter is the propagation of the Differentiated Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP field when translating packets. Because of that, the IPv4 and IPv6 domains must have equivalent Per-Hop Behaviors for the same code point, or alternative means must be in place to translate the DSCP between domains 🎀.

2.5. NAT-PT and Fragmentation 🔥

As mentioned in [RFC3027], simple port translators can't translate packet fragments other than the first from a fragmented packet. The reason is that subsequent fragments don't contain the port number information 😩.

This means that, in general, fragmentation cannot be allowed for any traffic that traverses a NAPT-PT. One attempted workaround requires the NAPT-PT to maintain state information derived from the first fragment until all fragments of the packet have transited the NAPT-PT. But this isn't a complete solution, because fragment misordering could lead to the first fragment appearing at the NAPT-PT after later fragments. Consequently, the NAPT-PT wouldn't have the information it needs to translate the fragments received before the first one 🌀.

Although it wouldn't be expected in normal operation, NAPT-PT needs to be proofed against receiving short first fragments that don't contain the transport port numbers. Note that such packets are a problem for many forms of stateful packet inspection applied to IPv6 packets 🛡️. The current IPv6 specifications don't mandate (1) any minimum packet size beyond the need to carry the unfragmentable part (which doesn't include the transport port numbers), or (2) reassembly rules to minimize the effects of overlapping fragments. Thus, IPv6 is open to the sort of attacks described in [RFC1858] and [RFC3128] 🚨.

An additional concern arises when a fragmented IPv4 UDP packet, which doesn't have a transport-layer checksum, traverses any type of NAT-PT box. As described in [RFC2766], the NAT-PT has to reconstruct the whole packet so that it can calculate the checksum needed for the translated IPv6 packet. This can cause a significant delay to the packet, especially if it has to be re-fragmented before transmission on the IPv6 side 🐌.

If NAT-PT boxes reassembled all incoming fragmented packets (from both the IPv4 and IPv6 directions) the same way they have to for unchecksummed IPv4 UDP packets, that would solve the first problem. But the resource cost would be considerable, apart from the potential delay problem if the outgoing packet has to be re-fragmented. In any case, fragmentation would mean the NAT-PT consumes extra memory and CPU resources, making the NAT-PT even less scalable (see Section 3.2) 😵‍💫.

Packet reassembly in a NAT-PT box also opens the door to various fragment-related security attacks. Some of these are analogous to attacks identified for IPv4. The one that's of particular concern is a DoS attack based on sending large numbers of small fragments without a terminating last fragment. That could overload the reconstruction buffers and consume large amounts of CPU resources 💀🔥.

2.6. NAT-PT Interaction with SCTP and Multihoming 🦋

The Stream Control Transmission Protocol (SCTP) [RFC2960] is a transport protocol that was standardized after SIIT was specified. SIIT doesn't explicitly cover the translation of SCTP. But SCTP uses transport port numbers the same way UDP and TCP do, so similar techniques can be used when translating SCTP packets 🌈.

However, SCTP also supports multihoming, and that's where things get spicy 🌶️. During connection setup, SCTP control packets carry embedded addresses that would have to be translated. This would also require that the types of the options fields in the SCTP control packets be changed, with consequent changes to packet length. The transport checksum would also have to be recalculated 🧮. The ramifications of multihoming as it might interact with NAT-PT haven't been fully explored. Because of the 'chunked' nature of data transfer, it doesn't appear that state would have to be maintained to relate packets transmitted using the different IP addresses associated with the connection 🫶.

Even if these technical issues can be overcome, using SCTP in a NAT-PT environment may effectively nullify the multihoming advantages of SCTP if all the connections run through the same NAT-PT 😤. The consequences of running a multihomed network with separate NAT-PT boxes associated with each of the 'homes' haven't been fully explored either. One issue that will arise is described in Section 4.4. SCTP will need an associated "ALG" (actually a Transport Layer Gateway) to handle the packet payload modifications. If it turns out that state is required, that state would have to be distributed and synchronized across several NAT-PT boxes in a multihomed environment 🫠.

SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec, as described in Section 2.1 🙅‍♀️.

2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 👑

As discussed in [NATPT-MOB], it isn't possible to propagate Mobile IPv6 (MIPv6) control messages into the IPv4 domain. According to the IPv6 Node Requirements [RFC4294], IPv6 nodes should normally be prepared to support the route optimization mechanisms needed in a correspondent node. If communications from an IPv6 mobile node are traversing a NAT-PT, the destination IPv4 node will certainly not be able to support the correspondent node features needed for route optimization 😬.

This can be resolved in two ways 💖:

  • The NAT-PT can discard messages and headers relating to changes of care-of addresses, including reverse routing checks. Communications with the mobile node will continue through the home agent without route optimization. This is clearly sub-optimal, but communication should remain possible 🐢.
  • Additional functionality could be implemented in the NAT-PT to allow it to function as a proxy correspondent node for all IPv4 nodes for which it has bindings. This scheme adds considerably to the complexity of NAT-PT. Depending on the routability of the IPv6 PREFIX used for translated IPv4 addresses, it may also limit the extent of mobility of the mobile node: all communications to the IPv4 destination have to go through the same NAT-PT, even if the mobile node moves to a network that doesn't have direct IPv6 connectivity with the NAT-PT 🧳.

In both cases, the existing NAT-PT specification would need to be extended to deal with IPv6 mobile nodes, and neither one is a fully satisfactory solution 🥹✨.

2.8. NAT-PT and Multicast 📡

okay so multicast is a whole other vibe 🌈. SIIT [RFC2765] cannot handle translating multicast packets, and NAT-PT doesn't say how to map multicast addresses between IPv4 and IPv6 🙈. Some separate work has tried to fill that gap with a different approach. It uses a separate gateway that understands some or all of the relevant multicast control and routing protocols in each domain. It hasn't been carried through into standards yet 💅.

The basic version only involves IGMP on the IPv4 side and MLD on the IPv6 side, and it's described in 'An IPv6-IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)' [MTP]. The more comprehensive one, which includes proxying of the multicast routing protocols, is described in 'An IPv4 - IPv6 multicast gateway' [MCASTGW]. Both approaches have several of the issues described in this section, especially the ones with embedded addresses 🫶.

[NATPT-SEC] points out the possibility of a multiplicative reflection attack if the NAT-PT can be spoofed into creating a binding for a multicast address 😭. This attack would be super hard to pull off, because routers should not forward packets with multicast addresses in the source address field. Still, it shows that a naively implemented DNS-ALG could create such bindings from spoofed DNS responses, since [RFC2766] doesn't mention the need for checks on the types of addresses in these responses 💀.

The big takeaway for NAT-PT and multicast is that it reflects the fact that NAT-PT is at best a partial solution 🍓. Completing the translation solution to cater for multicast traffic is likely to carry a similar set of issues to the current unicast NAT-PT, and it may open up significant additional security risks 🚨.

3. Issues Exacerbated by the Use of DNS-ALG 🧨

3.1. Network Topology Constraints Implied by NAT-PT 🗺️

okay, so traffic flow initiators in a NAT-PT environment depend on the DNS-ALG in the NAT-PT to provide the mapped address they need to talk to the flow destination on the other side 🫠. Whether the flow starts in the IPv4 domain or the IPv6 domain, the NAT-PT has to be on the path taken by the DNS query sent by the flow initiator to the relevant DNS server. Otherwise, the DNS query won't be modified and the response type won't be appropriate 😤.

That means the NAT-PT box also has to be the default IPv6 router for the site, so the DNS-ALG can examine all DNS requests made over IPv6. On sites with both IPv6 and dual-stack nodes, this means all traffic ends up flowing through the NAT-PT, which brings serious scalability concerns 📉.

These constraints are described in more detail in [DNS-ALG-ISSUES] ✨.

[DNS-ALG-SOL] proposes a solution for flows initiated from the IPv6 domain, but it appears that this solution still has issues 🥲.

For IPv6-only clients, the solution requires a DNS server in the IPv4 domain, accessed via an IPv6 address that uses the NAT-PT PREFIX (see [RFC2766]). Queries to this server would necessarily pass through the NAT-PT. Dual-stack hosts would use a separate DNS server accessed through a normal IPv6 address. This removes the need for the NAT-PT box to be the default IPv6 gateway for the domain 🎀.

The primary proposal suggests that IPv6-only clients should use this DNS server for all queries. That's expensive on NAT-PT resources, because requests relating to hosts with native IPv6 addresses would also go through the NAT-PT DNS-ALG 💸.

The alternate suggestion to reduce this burden appears to be flawed 🙃. If IPv6-only clients are given a list of DNS servers that includes both the server accessed via NAT-PT and the server(s) accessed natively via IPv6, the proposal suggests the client could avoid using NAT-PT for hosts that have native IPv6 addresses.

The problem is that, for the alternate suggestion, there is no a priori way for the initiator to decide which DNS server to use for a particular query 😵. If the initiator makes the wrong choice, the DNS query returns an empty list rather than failing to respond. With standard DNS logic, the initiator won't try alternative DNS servers, because it has already received a response. So the solution would consist of always using DNS servers having the NAT-PT PREFIX, which imposes the burden of always requiring the DNS RR (Resource Record) [RFC1035] translation 🫠.

For flows initiated from the IPv4 network, the proposal recommends that the advertised DNS servers for the IPv6 network would have the IPv4 address of the NAT-PT. Again, there is no deterministic way to choose the correct DNS server for each query, which results in the same issues raised for flows initiated from the IPv6 domain 🌀.

Although the engineering workaround just described provides a partial solution to the topology constraints issue, it mandates that DNS queries and responses still go through a NAT-PT even when there would normally be no reason to do so 🚧. This mandatory passage through the NAT-PT for all DNS requests will exacerbate the other DNS-related issues discussed in Section 3.4 and Section 4.1 💅.

3.2. Scalability and Single Point of Failure Concerns 🧱

As with traditional NAT, NAT-PT is a bottleneck in the network with significant scalability concerns 😩. On top of that, anchoring flows to a particular NAT-PT makes the NAT-PT a potential single point of failure in the network. Adding the DNS-ALG to NAT-PT increases the scalability concerns even further 📈.

Solutions to both problems have been envisaged using collections of cooperating NAT-PT boxes. But those solutions require coordination and state synchronization, which hasn't been standardized yet, and they add to the functional and operational complexity of NAT-PT 🌪️. One such solution is described in [MUL-NATPT].

As with traditional NAT, the concentration of flows through NAT-PT, plus the legitimate modification of packets in the NAT-PT, makes NAT-PTs enticing targets for security attacks 👀.

3.3. Issues with Lack of Address Persistence 🫥

Using the DNS-ALG to create address bindings means the translated address returned by the DNS query has to be used for communications before the NAT-PT binding state times out (see Section 2.3). Applications won't normally be aware of this constraint, which may be different from the existing lifetime of DNS query responses. This could lead to "difficult to diagnose" problems with applications 🕵️‍♀️.

The DNS-ALG also needs to determine the initial lifetime of the bindings it creates. As noted in Section 2.3, this may need to be determined heuristically 🤔. The DNS-ALG doesn't know which protocol the mapping is going to be used for, so it needs another way to determine the initial lifetime. This could be tied to the DNS response lifetime, but that might open up additional DoS attack possibilities if very long binding lifetimes are allowed 🚩. Also, the lifetime should be adjusted once the NAT-PT determines which protocol is being used with the binding.

As with traditional NATs (see Section 2.5 of [RFC3027]), NAT-PT will most likely break applications that require address mapping to be retained across contiguous sessions 💔. These applications need the IPv4 to IPv6 address mapping to be kept between sessions, so the same mapped address can be reused for later session interactions. NAT-PT can't know this requirement, and it may reassign the previously used mapped address to different hosts between sessions 😬.

Keeping NAT-PT from discarding an address mapping would require either a NAT-PT extension protocol that lets the application ask the NAT-PT device to retain the mappings, or an extended ALG (which has all the issues discussed in Section 2.1). That extended ALG would interact with NAT-PT to keep the address mapping from being discarded after a session 🧩.

3.4. DoS Attacks on Memory and Address/Port Pools 🧨

As discussed in Section 2.3, a NAT-PT may create dynamic NAT bindings. Each one consumes memory resources, as well as an address (or a port if NAPT-PT is used) from an address (or port) pool 🧠. A number of documents, including [RFC2766] and [NATPT-SEC], discuss the possible denial of service (DoS) attacks on basic NAT-PT and NAPT-PT that would result in resource depletion of address and port pools. NAT-PT doesn't specify any authentication mechanisms, so an attacker may be able to create spurious bindings by spoofing addresses in packets sent through NAT-PT. The attack is more damaging if the attacker can spoof protocols with long binding timeouts (typically used for TCP) 😈.

The use of the DNS-ALG in NAT-PT introduces another vulnerability that can result in resource depletion 🚨. The attack identified in [DNS-ALG-ISSUES] exploits the use of DNS queries traversing NAT-PT to create dynamic bindings. Every time a DNS query is sent through the NAT-PT, the NAT-PT may create a new basic NAT-PT or NAPT-PT binding without any end-host authentication or authorization mechanisms. This behavior could lead to a serious DoS attack on both memory and address or port pools. Address spoofing isn't required for this attack to succeed 😭.

[DNS-ALG-SOL] proposes to mitigate the DoS attack by using Access Control Lists (ACLs) and static binds. That increases the operational cost and may not always be practical 🫤.

The ideal mitigation would be to disallow dynamically created binds until the end-host needing the protocol translation has been authenticated and authorized 🔐. This would require the proper security infrastructure to be in place to support the authentication and authorization, which increases the network operational complexity 🌋.

4.1. Address Selection Issues when Communicating with Dual-Stack End-Hosts ✨

Okay bestie, [DNS-ALG-ISSUES] spills the tea on NAT-PT DNS-ALG address selection drama 🙈. As [RFC2766] tells it, the DNS-ALG pulls AAAA RRs from two possible sources and hands them to the IPv6 host that sent the AAAA query.

If the query is for a dual-stack host, the answer comes back with both the native IPv6 address(es) and the translated IPv4 address(es) as AAAA RRs. Without any extra info, the IPv6 host's address selection might grab a translated IPv4 address instead of the more appropriate native IPv6 one 😤. In some situations, the address selection algorithms [RFC3484] will always prefer the translated address over the native IPv6 one. Obviously not it 💀.

[DNS-ALG-SOL] has a fix that changes the NAT-PT spec so only the most appropriate address(es) go back to an IPv6-capable host 💅:

  • When a DNS AAAA query goes through the NAT-PT DNS-ALG, NAT-PT forwards the query to the DNS server in the IPv4 domain unchanged, but using IPv4 transport. Two things can happen:
    • If the authoritative DNS server has one or more AAAA records, it returns them. The DNS-ALG forwards that response to the IPv6 host and does not send an A query like standard NAT-PT would do.
    • Otherwise, if the DNS server does not understand the AAAA query or has no AAAA entry for the host, it returns an error. The NAT-PT DNS-ALG intercepts the error or empty return and sends an A query for the same host. If this query returns an IPv4 address, the ALG creates a binding and synthesizes a corresponding AAAA record, which it sends back to the IPv6 host.
  • So NAT-PT forwards the result of the first successful DNS response back to the end-host, or an error if neither succeeds. That means only AAAA RRs from one source get provided instead of two like [RFC2766] specifies, and it contains the most appropriate address for a dual-stack or IPv6-only querier 🫶.
There is, however, still an issue with the proposed solution 😬: - The DNS client may time out the query if it doesn't get a response in time. This is more likely than for queries not passing through a DNS ALG, because the NAT-PT may have to make two separate, sequential queries that the client doesn't know about. It may be possible to reduce the response time by sending the two queries in parallel and ignoring the result of the A query if the AAAA returns one or more addresses. However, it is still necessary to delay after receiving the first response to figure out if a second one is coming, which may still trigger the DNS client timeout.

Unfortunately, the two queries cannot be combined into a single DNS request, because all known DNS servers only process a single DNS query per request message, due to difficulties expressing authoritativeness for arbitrary combinations of requests 🥲.

An alternative solution would be to let the IPv6 host use the NAT-PT PREFIX [RFC2766] within its address selection policies and give it a low selection priority 🧚. This solution needs automatic configuration of the NAT-PT PREFIX, plus its integration into the address selection policies. The simplest way to do that automatic configuration would be a configuration file download. This would be for when the host or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server doesn't support vendor options, and it also avoids a standardization effort on a NAT-PT PREFIX option. This solution does not require any modification to the NAT-PT specification 🌸.

Neither of these solutions fixes a second address selection issue identified in [DNS-ALG-ISSUES]. Applications have no way of knowing that the IPv6 address returned from the DNS-ALG is not a 'real' IPv6 address, but a translated IPv4 address. So the application may be led to believe it has end-to-end IPv6 connectivity with the destination. As a result, the application may use IPv6-specific options that NAT-PT doesn't support 😭. This issue is closely related to the issue described in Section 4.2 and the discussion in Section 5.

4.2. Non-Global Validity of Translated RR Records 🦋

Some applications pass information records they retrieved from DNS along to other applications. The published semantics of DNS imply that the results will be consistent for any user for the duration of the attached lifetime. RR records translated by NAT-PT break these semantics, because the retrieved addresses are only usable for communications through the translating NAT-PT 🙃.

Applications that pass on retrieved DNS records to other applications will generally assume they can rely on the passed-on addresses being usable by the receiving application. That may not be the case if the receiving application is on another node, especially if it isn't in the domain served by the NAT-PT that generated the translation 🥴.

4.3. Inappropriate Translation of Responses to A Queries 🔥

Some applications running on dual-stack nodes may want to query the IPv4 address of a destination. If that resulting A query passes through the NAT-PT DNS-ALG, the DNS-ALG will translate the response inappropriately into an AAAA record using a translated address 😵. This happens because the DNS-ALG specified in [RFC2766] operates statelessly, so it has no memory of the IPv6 query that caused the A request on the IPv4 side. The default action is to translate the response.

The NAT-PT specification could be modified to keep a minimal state about queries that pass through the DNS-ALG, so it can respond correctly to A queries as well as AAAA queries 🧠✨.

4.4. DNS-ALG and Multi-Addressed Nodes 💜

Lots of IPv6 nodes, especially in multihomed situations but also in single-homed deployments, can expect to have multiple global addresses. The same may be true for multihomed IPv4 nodes. Responses to DNS queries for these nodes will normally contain all of these addresses. Since the DNS-ALG in the NAT-PT has no knowledge of which of the addresses can or will be used by the application issuing the query, it is obliged to translate all of them 🫠.

This could be a significant drain on resources in both basic NAT-PT and NAPT-PT, since bindings will have to be created for each address 📉.

When using SCTP in a multihomed network, the problem gets worse if multiple NAT-PTs translate multiple addresses 😩. Also, it's not clear that SCTP will actually look up all the destination IP addresses via DNS, so bindings may not be in place when packets arrive 🙈.

4.5. Limitations on Deployment of DNS Security Capabilities 🔐

Secure DNS (DNSSEC) [RFC4033] uses public key cryptographic signing to authenticate DNS responses. The DNS-ALG modifies DNS query responses traveling through the NAT-PT in both directions. That would invalidate the signatures, as (partially) described in Section 7.5 of [RFC2766] 💔.

Workarounds have been proposed, such as making the DNS-ALG behave like a secure DNS server. This would need to be done separately for both the IPv6 and IPv4 domains. That's operationally very complex, and there's a risk the server could be mistaken for a conventional DNS server 😬. The NAT-PT specification would have to be altered to implement any such workaround.

So DNSSEC is not deployable in domains that use NAT-PT as currently specified. Widespread deployment of NAT-PT would become a serious obstacle to large-scale deployment of DNSSEC 🚧.

5. Impact on IPv6 Application Development 🌈

One of the major design goals for IPv6 is to restore the end-to-end transparency of the Internet 🦋. So because IPv6 may be expected to remove the need for NATs and similar impediments to transparency, developers building applications for IPv6 may be tempted to assume that the complex expedients that might have been needed to make an application work in a 'NATted' IPv4 environment aren't required 👀.

Consequently, some classes of applications (e.g., peer-to-peer) that would need special measures to manage NAT traversal, including special encapsulations, attention to binding lifetime, and provision of keepalives, may build in assumptions about whether IPv6 is being used or not. Developers would also like to exploit additional capabilities of IPv6 that aren't available in IPv4 💅.

NAT-PT as specified in [RFC2766] is intended to work autonomously and be transparent to applications. So there's no way for application developers to discover that a path contains a NAT-PT 🫥.

If NAT-PT is deployed, applications that have assumed a NAT-free IPv6 environment may break when their traffic passes through a NAT-PT 💀. That's bad enough, but requiring developers to include special capabilities to work around what is supposed to be a temporary transition 'aid' is even worse 😤. Finally, deployment of NAT-PT is likely to inhibit the development and use of additional IPv6 capabilities enabled by the flexible extension header system in IPv6 packets 🥀.

Some of these deleterious effects could possibly be eased if applications could discover the presence of NAT-PT boxes on the paths they use, letting them take steps to work around the problems 🔍. However, requiring applications to add extra code to work around problems with a transition aid still seems like a very bad idea: the behavior of the application in native IPv6 and NAT-PT environments would likely be significantly different 🙅‍♀️.

6. Security Considerations 🚨

This document summarizes security issues related to the NAT-PT [RFC2766] specification. Security issues are discussed in various sections 🔒:
  • Section 2.1 discusses how IPsec AH (transport and tunnel mode) and IPsec ESP transport mode are broken by NAT-PT (when IPsec UDP encapsulation is not used [RFC3498]), and how authentication and encryption are generally incompatible with NAT-PT 💥.
  • Section 2.5 discusses possible fragmentation-related security attacks on NAT-PT 🧨.
  • Section 2.8 discusses security issues related to multicast addresses and NAT-PT 📡.
  • Section 3.3 highlights that NAT-PT is an enticing nexus for security attacks 🍯.
  • Section 3.4 discusses possible NAT-PT DoS attacks on both memory and address/port pools 🫨.
  • Section 4.5 discusses why NAT-PT is incompatible with DNSSEC [RFC4033] and how deployment of NAT-PT may inhibit deployment of DNSSEC 🚫.

7. Conclusion ✨

Okay bestie, this doc has been spilling SO much tea on NAT-PT as defined in [RFC2766]. 🙈 From a deployment perspective, 3GPP networks are currently the only "standardised" scenario where NAT-PT is envisaged as a potential mechanism for an IPv6-only host to talk to an IPv4-only host, as discussed in the 3GPP IPv6 transition analysis [RFC4215]. But RFC 4215 says the generic form of NAT-PT should not be used, and that modified forms should only be used under strict conditions. 💀 It also documents a bunch of caveats and security issues that are specific to 3GPP. NAT-PT has also seen some limited usage for other purposes, fr fr.

Some of the issues with NAT-PT look like they have solutions, but a lot of those fixes need big changes to the existing specification and would likely make operations way more complicated. 😩 Even if those solutions got applied, we showed that NAT-PT still has serious, unresolvable issues and seems to have limited applicability. The potential constraints on IPv6 application development described in Section 5 are especially undesirable, no notes. 🥺 Alternatives to NAT-PT do exist for the situations where NAT-PT has been suggested, like using application proxies in 3GPP scenarios [RFC4215]

BUT, it's clear that in some circumstances an IPv6-IPv4 protocol translation solution can be a useful transitional fix, especially in more constrained situations where the translator doesn't have to handle traffic for a wide variety of protocols that aren't known in advance. ✨ So it's possible that a more limited form of NAT-PT could be defined for specific situations. 🦋

Accordingly, we recommend that:

  • the IETF no longer suggest its usage as a general IPv4-IPv6 transition mechanism in the Internet, and
  • RFC 2766 is moved to Historic status to limit the possibility of it being deployed inappropriately. 🫶

8. Acknowledgments 💜

This work builds on a huge pile of existing work looking at the issues and applicability of NAT-PT. The authors of the documents referred to in Section 1 were super helpful in making this doc happen. 🌸 Special thanks to Pekka Savola for his fast and thorough review, he's a whole legend. 👑

9. References 🎀

9.1. Normative References

[RFC2765]         Nordmark, E., "Stateless IP/ICMP Translation
                  Algorithm (SIIT)", RFC 2765, February 2000.

[RFC2766]         Tsirtsis, G. and P. Srisuresh, "Network Address
                  Translation - Protocol Translation (NAT-PT)",
                  RFC 2766, February 2000.

[RFC2663]         Srisuresh, P. and M. Holdrege, "IP Network Address
                  Translator (NAT) Terminology and Considerations",
                  RFC 2663, August 1999.

[RFC3027]         Holdrege, M. and P. Srisuresh, "Protocol
                  Complications with the IP Network Address
                  Translator", RFC 3027, January 2001.

[RFC3314]         Wasserman, M., "Recommendations for IPv6 in Third
                  Generation Partnership Project (3GPP) Standards",
                  RFC 3314, September 2002.

[RFC3484]         Draves, R., "Default Address Selection for Internet
                  Protocol version 6 (IPv6)", RFC 3484,
                  February 2003.

[RFC1035]         Mockapetris, P., "Domain names - implementation and
                  specification", STD 13, RFC 1035, November 1987.

[RFC4294]         Loughney, J., "IPv6 Node Requirements", RFC 4294,
                  April 2006.

[RFC4215]         Wiljakka, J., "Analysis on IPv6 Transition in Third
                  Generation Partnership Project (3GPP) Networks",
                  RFC 4215, October 2005.

[RFC4033]         Arends, R., Austein, R., Larson, M., Massey, D.,
                  and S. Rose, "DNS Security Introduction and
                  Requirements", RFC 4033, March 2005.

9.2. Informative References

[RFC1858]         Ziemba, G., Reed, D., and P. Traina, "Security
                  Considerations for IP Fragment Filtering",
                  RFC 1858, October 1995.

[RFC3128]         Miller, I., "Protection Against a Variant of the
                  Tiny Fragment Attack (RFC 1858)", RFC 3128,
                  June 2001.

[RFC2960]         Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
                  Schwarzbauer, H., Taylor, T., Rytina, I., Kalla,
                  M., Zhang, L., and V. Paxson, "Stream Control
                  Transmission Protocol", RFC 2960, October 2000.

[RFC3498]         Kuhfeld, J., Johnson, J., and M. Thatcher,
                  "Definitions of Managed Objects for Synchronous
                  Optical Network (SONET) Linear Automatic Protection
                  Switching (APS) Architectures", RFC 3498,
                  March 2003.

[NATP-APP]        Satapati, S., "NAT-PT Applicability", Work
                  in Progress, October 2003.

[DNS-ALG-ISSUES]  Durand, A., "Issues with NAT-PT DNS ALG in
                  RFC2766", Work in Progress, February 2002.

[DNS-ALG-SOL]     Hallingby, P. and S. Satapati, "NAT-PT DNS ALG
                  solutions", Work in Progress, July 2002.

[NATPT-MOB]       Shin, M. and J. Lee, "Considerations for Mobility
                  Support in NAT-PT", Work in Progress, July 2005.

[NATPT-SEC]       Okazaki, S. and A. Desai, "NAT-PT Security
                  Considerations", Work in Progress, June 2003.

[TRANS-ISSUES]    Pol, R., Satapati, S., and S. Sivakumar, "Issues
                  when translating between IPv4 and IPv6", Work
                  in Progress, January 2003.

[3GPP-TRANS]      Malki, K., "IPv6-IPv4 Translation mechanism for
                  SIP-based services in Third Generation Partnership
                  Project (3GPP) Networks", Work in Progress,
                  December 2003.

[MTP]             Tsuchiya, K., Higuchi, H., Sawada, S., and S.
                  Nozaki, "An IPv6/IPv4 Multicast Translator based on
                  IGMP/MLD Proxying (mtp)", Work in Progress,
                  February 2003.

[MCASTGW]         Venaas, S., "An IPv4 - IPv6 multicast gateway",
                  Work in Progress, February 2003.

[MUL-NATPT]       Park, S., "Scalable mNAT-PT Solution", Work
                  in Progress, May 2003.

Authors' Addresses 📮

Cedric Aoun
Energize Urnet
Paris
France

EMail: ietf@energizeurnet.com


Elwyn B. Davies
Folly Consulting
Soham, Cambs
UK

Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from