6889
INFORMATIONAL
Analysis of Stateful 64 Translation
Authors: R. Penno, T. Saxena, M. Boucadair, S. Sivakumar
Date: April 2013
Area: tsv
Working Group: behave
Stream: IETF
Abstract
Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.
RFC 6889
INFORMATIONAL
Internet Engineering Task Force (IETF) R. Penno
Request for Comments: 6889 Cisco Systems, Inc.
Category: Informational T. Saxena
ISSN: 2070-1721 Cisco Systems
M. Boucadair
France Telecom
S. Sivakumar
Cisco Systems
April 2013
<span class="h1">Analysis of Stateful 64 Translation</span>
Abstract
Due to specific problems, Network Address Translation - Protocol
Translation (NAT-PT) was deprecated by the IETF as a mechanism to
perform IPv6-IPv4 translation. Since then, new efforts have been
undertaken within IETF to standardize alternative mechanisms to
perform IPv6-IPv4 translation. This document analyzes to what extent
the new stateful translation mechanisms avoid the problems that
caused the IETF to deprecate NAT-PT.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc6889">http://www.rfc-editor.org/info/rfc6889</a>.
<span class="grey">Penno, et al. Informational [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Definition . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.2">1.2</a>. Context . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Analysis of 64 Translation against Concerns of <a href="./rfc4966">RFC 4966</a> . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Problems Impossible to Solve . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Problems That Can Be Solved . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Problems Solved . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5">5</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.1">6.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.2">6.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Definition</span>
This document uses stateful 64 (or 64 for short) to refer to the
mechanisms defined in the following documents:
o IP/ICMP Translation Algorithm [<a href="./rfc6145" title=""IP/ICMP Translation Algorithm"">RFC6145</a>]
o Stateful NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers [<a href="./rfc6146" title=""Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"">RFC6146</a>]
o DNS64: DNS Extensions for Network Address Translation from IPv6
Clients to IPv4 Servers [<a href="./rfc6147" title=""DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers"">RFC6147</a>]
<span class="grey">Penno, et al. Informational [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
o IPv6 Addressing of IPv4/IPv6 Translators [<a href="./rfc6052" title=""IPv6 Addressing of IPv4/IPv6 Translators"">RFC6052</a>]
o Framework for IPv4/IPv6 Translation [<a href="./rfc6144" title=""Framework for IPv4/IPv6 Translation"">RFC6144</a>]
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Context</span>
Stateful 64 is widely seen as a major interconnection technique
designed to enable communications between IPv6-only and IPv4-only
networks. One of the building blocks of the stateful 64 is
decoupling the DNS functionality from the protocol translation
itself.
This approach is pragmatic in the sense that there is no dependency
on DNS implementation for the successful NAT handling. As long as
there is a function (e.g., DNS64 [<a href="./rfc6147" title=""DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers"">RFC6147</a>] or other means) that can
construct an IPv6-embedded IPv4 address with a pre-configured IPv6
prefix, an IPv4 address and a suffix (refer to [<a href="./rfc6052" title=""IPv6 Addressing of IPv4/IPv6 Translators"">RFC6052</a>]), NAT64 will
work just fine.
The focus of the stateful 64 is on the deployment and not the
implementation details. As long as a NAT64 implementation conforms
to the expected behavior, as desired in the deployment scenario, the
details are not very important as mentioned in this excerpt from
[<a href="./rfc6146" title=""Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"">RFC6146</a>]:
A NAT64 MAY perform the steps in a different order, or MAY perform
different steps, but the externally visible outcome MUST be the
same as the one described in this document.
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Scope</span>
This document provides an analysis of how the proposed set of
documents that specify stateful IPv6-only to IPv4-only translation
and replace Network Address Translation - Protocol Translation
(NAT-PT) [<a href="./rfc2766" title=""Network Address Translation - Protocol Translation (NAT-PT)"">RFC2766</a>] address the issues raised in [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>].
As a reminder, it is worth mentioning the analysis is limited in the
sense that hosts from IPv6 networks can initiate a communication to
IPv4 network/Internet, but not vice versa. This corresponds to
Scenarios 1 and 5 described in [<a href="./rfc6144" title=""Framework for IPv4/IPv6 Translation"">RFC6144</a>]. Hence, the scenario of
servers moving to IPv6 while clients remaining IPv4 remains
unaddressed. Of course, IPv6-to-IPv4 communications can also be
supported if static or explicit bindings (e.g., [<a href="./rfc6887" title=""Port Control Protocol (PCP)"">RFC6887</a>]) are
configured on the stateful NAT64.
<span class="grey">Penno, et al. Informational [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
Stateful 64, just like any other technique under development, has
some positives and some drawbacks. The ups and downs of the proposal
must be clearly understood while going forward with its future
development.
The scope of this document does not include stateless translation.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Analysis of 64 Translation against Concerns of <a href="./rfc4966">RFC 4966</a></span>
Of the set of problems pointed out in [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>], the stateful 64
addresses some of them, whereas it leaves others unaddressed.
Some issues mentioned in [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>] were solved by [<a href="./rfc4787" title=""Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"">RFC4787</a>],
[<a href="./rfc5382" title=""NAT Behavioral Requirements for TCP"">RFC5382</a>], and [<a href="./rfc5508" title=""NAT Behavioral Requirements for ICMP"">RFC5508</a>]. At the time when NAT-PT was published,
these recommendations were not in place but they are orthogonal to
the translation algorithm per se; therefore, they could be
implemented with NAT-PT. On the other hand, NAT64 [<a href="./rfc6146" title=""Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"">RFC6146</a>]
explicitly mentions that these recommendations need to be followed
and thus should be seen as a complete specification.
It is also worth pointing out that the scope of the stateful 64 is
reduced when compared to NAT-PT. Following is a point-by-point
analysis of the problems. This document classifies the issues listed
in [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>] into three categories:
1. Problems impossible to solve.
2. Problems that can be solved.
3. Problems solved.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Problems Impossible to Solve</span>
Problems discussed in [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>] that are impossible to solve:
1. Inability to redirect traffic for protocols that lack de-
multiplexing capabilities or are not built on top of specific
transport-layer protocols for transport address translations
(<a href="./rfc4966#section-2.2">Section 2.2 of [RFC4966]</a>).
Analysis: This issue is not specific to 64 but to all NAT-
based solutions.
<span class="grey">Penno, et al. Informational [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
2. Loss of information due to incompatible semantics between IPv4
and IPv6 versions of headers and protocols (<a href="./rfc4966#section-2.4">Section 2.4 of
[RFC4966]</a>).
Analysis: This issue is not specific to 64 but is due to the
design of IPv4 and IPv6.
3. Need for the NAT64-capable device to act as proxy for
correspondent node when IPv6 node is mobile, with consequent
restrictions on mobility (<a href="./rfc4966#section-2.7">Section 2.7 of [RFC4966]</a>).
Analysis: This is not specific to NAT64 but to all NAT
flavors. Refer to [<a href="#ref-NAT64-HARMFUL">NAT64-HARMFUL</a>] for an early analysis on
mobility complications encountered when NAT64 is involved.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Problems That Can Be Solved</span>
Problems discussed in [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>] that can be solved:
1. Disruption of all protocols that embed IP addresses (and/or
ports) in packet payloads or apply integrity mechanisms using IP
addresses (and ports) (<a href="./rfc4966#section-2.1">Section 2.1 of [RFC4966]</a>).
Analysis: In the case of FTP [<a href="./rfc0959" title=""File Transfer Protocol"">RFC0959</a>], this problem can be
mitigated in several ways (e.g., use a FTP64 Application Layer
Gateway (ALG) [<a href="./rfc6384" title=""An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation"">RFC6384</a>] or in the FTP client (e.g., [<a href="#ref-FTP64" title=""FTP consideration for IPv4/IPv6 transition"">FTP64</a>])).
In the case of SIP [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>], no specific issue is induced by
64; the same techniques for NAT traversal can be used when a
NAT64 is involved in the path (e.g., Interactive Connectivity
Establishment (ICE) [<a href="./rfc5245" title=""Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols"">RFC5245</a>], maintain SIP-related NAT
bindings as per <a href="./rfc5853#section-3.4">Section 3.4 of [RFC5853]</a>, media latching
[<a href="#ref-MIDDLEBOXES">MIDDLEBOXES</a>], embedded SIP ALGs, etc.). [<a href="./rfc6157" title=""IPv6 Transition in the Session Initiation Protocol (SIP)"">RFC6157</a>] provides
more discussion on how to establish SIP sessions between IPv4
and IPv6 SIP user agents.
The functioning of other protocols is left for future study.
Note that the traversal of NAT64 by application embedding IP
address literal is not specific to NAT64 but generic to all
NAT-based solutions.
2. Interaction with Stream Control Transmission Protocol (SCTP)
[<a href="./rfc4960" title=""Stream Control Transmission Protocol"">RFC4960</a>] and multihoming (<a href="./rfc4966#section-2.6">Section 2.6 of [RFC4966]</a>).
Analysis: Only TCP and UDP transport protocols are within the
scope of NAT64 [<a href="./rfc6146" title=""Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"">RFC6146</a>]. SCTP is out of scope of this
document.
<span class="grey">Penno, et al. Informational [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
3. Inability to handle multicast traffic (<a href="./rfc4966#section-2.8">Section 2.8 of [RFC4966]</a>).
Analysis: This problem is not addressed by the current 64
specifications.
4. Scalability concerns together with introduction of a single point
of failure and a security attack nexus (<a href="./rfc4966#section-3.2">Section 3.2 of
[RFC4966]</a>).
Analysis: This is not specific to NAT64 but to all stateful
NAT flavors. The presence of a single point of failure is
deployment-specific; some service providers may deploy state
synchronization means while others may only rely on a
distributed NAT64 model.
5. Restricted validity of translated DNS records: a translated
record may be forwarded to an application that cannot use it
(<a href="./rfc4966#section-4.2">Section 4.2 of [RFC4966]</a>).
Analysis: If a node on the IPv4 side forwards the address of
the other endpoint to a node that cannot reach the NAT box or
is not covered under the endpoint-independent constraint of
NAT, then the new node will not be able to initiate a
successful session.
Actually, this is not a limitation of 64 (or even NAT-PT) but
a deployment context where IPv4 addresses managed by the NAT64
are not globally reachable. The same limitation can be
encountered when referrals (even without any NAT in the path)
include reachability information with limited reachability
scope (see [<a href="#ref-REFERRAL" title=""A Generic Referral Object for Internet Entities"">REFERRAL</a>] for more discussion about issues related
to reachability scope).
6. IPsec traffic using AH (Authentication Header) [<a href="./rfc4302" title=""IP Authentication Header"">RFC4302</a>] in both
transport and tunnel modes cannot be carried through NAT-PT
without terminating the security associations on the NAT-PT, due
to the inclusion of IP header fields in the scope of AH's
cryptographic integrity protection [<a href="./rfc3715" title=""IPsec-Network Address Translation (NAT) Compatibility Requirements"">RFC3715</a>] (<a href="./rfc4966#section-2.1">Section 2.1 of
[RFC4966]</a>). In addition, IPsec traffic using ESP (Encapsulating
Security Payload) [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>] in transport mode generally uses UDP
encapsulation [<a href="./rfc3948" title=""UDP Encapsulation of IPsec ESP Packets"">RFC3948</a>] for NAT traversal (including NAT-PT
traversal) in order to avoid the problems described in [<a href="./rfc3715" title=""IPsec-Network Address Translation (NAT) Compatibility Requirements"">RFC3715</a>]
(<a href="./rfc4966#section-2.1">Section 2.1 of [RFC4966]</a>).
Analysis: This is not specific to NAT64 but to all NAT
flavors.
<span class="grey">Penno, et al. Informational [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
7. Address selection issues when either the internal or external
hosts implement both IPv4 and IPv6 (<a href="./rfc4966#section-4.1">Section 4.1 of [RFC4966]</a>).
Analysis: This is out of scope of 64 since Scenarios 1 and 5
of [<a href="./rfc6144" title=""Framework for IPv4/IPv6 Translation"">RFC6144</a>] assume IPv6-only hosts.
Therefore, this issue is not resolved and mitigation
techniques outside the 64 need to be used (e.g.,
[<a href="#ref-ADDR-SELECT">ADDR-SELECT</a>]). These techniques may allow one to offload
NAT64 resources and prefer native communications that do not
involve address family translation. Avoiding NAT devices in
the path is encouraged for mobile nodes in order to save power
consumption due to keepalive messages that are required to
maintain NAT states ("always-on" services). An in-depth
discussion can be found in [<a href="#ref-DNS64" title=""IPv6-only and Dual Stack Hosts on the Same Network with DNS64"">DNS64</a>].
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Problems Solved</span>
Problems identified in [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>] that have been solved:
1. Constraints on network topology (as it relates to DNS-ALG; see
<a href="./rfc4966#section-3.1">Section 3.1 of [RFC4966]</a>).
Analysis: The severity of this issue has been mitigated by the
separation of the DNS from the NAT functionality.
Nevertheless, a minimal coordination may be required to ensure
that the NAT64 to be crossed (the one to which the IPv4-
Converted IPv6 address returned to a requesting host) must be
in the path and has also sufficient resources to handle
received traffic.
2. Need for additional state and/or packet reconstruction in dealing
with packet fragmentation. Otherwise, implement no support for
fragments (<a href="./rfc4966#section-2.5">Section 2.5 of [RFC4966]</a>).
Analysis: This issue is not specific to 64 but to all NAT-
based solutions. [<a href="./rfc6146" title=""Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"">RFC6146</a>] specifies how to handle
fragmentation; appropriate recommendations to avoid
fragmentation-related DoS (Denial-of-Service) attacks are
proposed (e.g., limit resources to be dedicated to out-of-
order fragments).
3. Inappropriate translation of responses to A queries from IPv6
nodes (<a href="./rfc4966#section-4.3">Section 4.3 of [RFC4966]</a>).
Analysis: DNS64 [<a href="./rfc6147" title=""DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers"">RFC6147</a>] does not alter A queries.
<span class="grey">Penno, et al. Informational [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
4. Address selection issues and resource consumption in a DNS-ALG
with multi-addressed nodes (<a href="./rfc4966#section-4.4">Section 4.4 of [RFC4966]</a>).
Analysis: Since no DNS-ALG is required to be co-located with
NAT64, there is no need to maintain temporary states in
anticipation of connections. Note that explicit bindings (see
<a href="./rfc6887#section-3">Section 3 of [RFC6887]</a>) are required to allow for
communications initiated from an IPv4-only client to an IPv6-
only server.
5. Limitations on DNS security capabilities when using a DNS-ALG
(<a href="./rfc4966#section-2.5">Section 2.5 of [RFC4966]</a>).
Analysis: A DNSSEC validating stub resolver behind a DNS64 in
server mode is not supported. Therefore, if a host wants to
do its own DNSSEC validation, and it wants to use a NAT64, the
host has to also perform its own DNS64 synthesis. Refer to
<a href="./rfc6147#section-3">Section 3 of [RFC6147]</a> for more details.
6. Creation of a DoS threat relating to exhaustion of memory and
address/port pool resources on the translator (<a href="./rfc4966#section-3.4">Section 3.4 of
[RFC4966]</a>).
Analysis: This specific DoS concern on Page 6 of [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>] is
under a DNS-ALG heading in that document, and refers to NAT-
PT's creation of NAT mapping state when a DNS query occurred.
With the new IPv6-IPv4 translation mechanisms, DNS queries do
not create any mapping state in the NAT64.
To mitigate the exhaustion of port pool issue (<a href="./rfc4966#section-3.4">Section 3.4 of
[RFC4966]</a>), 64 must enforce a port limit similar to the one
defined in [<a href="./rfc6888" title=""Common Requirements for Carrier-Grade NATs (CGNs)"">RFC6888</a>].
Thus, this concern can be fully eliminated in 64.
7. Requirement for applications to use keepalive mechanisms to work
around connectivity issues caused by premature timeout for
session table and Binding Information Base entries (<a href="./rfc4966#section-2.3">Section 2.3
of [RFC4966]</a>).
Analysis: Since NAT64 follows some of the [<a href="./rfc4787" title=""Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"">RFC4787</a>],
[<a href="./rfc5382" title=""NAT Behavioral Requirements for TCP"">RFC5382</a>], and [<a href="./rfc5508" title=""NAT Behavioral Requirements for ICMP"">RFC5508</a>] requirements, there is a high lower
bound for the lifetime of sessions. In NAT-PT, this was
unknown and applications needed to assume the worst case. For
instance, in NAT64, the lifetime for a TCP session is
approximately two hours, so not much keepalive signaling
overhead is needed.
<span class="grey">Penno, et al. Informational [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
Application clients (e.g., VPN clients) are not aware of the
timer configured in the NAT device. For unmanaged services, a
conservative approach would be adopted by applications that
issue frequent keepalive messages to be sure that an active
mapping is still maintained by any involved NAT64 device even
if the NAT64 complies with [<a href="./rfc4787" title=""Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"">RFC4787</a>], [<a href="./rfc5382" title=""NAT Behavioral Requirements for TCP"">RFC5382</a>], and
[<a href="./rfc5508" title=""NAT Behavioral Requirements for ICMP"">RFC5508</a>].
Note that keepalive messages may be issued by applications to
ensure that an active entry is maintained by a firewall, with
or without a NAT in the path, which is located in the
boundaries of a local domain.
8. 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 (<a href="./rfc4966#section-3.3">Section 3.3 of [RFC4966]</a>).
Analysis: In the following, address persistence is used to
refer to the support of "IP address pooling" behavior of
"Paired" [<a href="./rfc4787" title=""Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"">RFC4787</a>].
In the context of 64, the external IPv4 address (representing
the IPv6 host in the IPv4 network) is assigned by the NAT64
machinery and not the DNS64 function. Therefore, address
persistence can be easily ensured by the NAT64 function (which
complies with NAT recommendations [<a href="./rfc4787" title=""Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"">RFC4787</a>] and [<a href="./rfc5382" title=""NAT Behavioral Requirements for TCP"">RFC5382</a>]).
Address persistence should be guaranteed for both dynamic and
static bindings.
In the IPv6 side of the NAT64, the same IPv6 address is used
to represent an IPv4 host; no issue about address persistence
is raised in an IPv6 network.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Conclusions</span>
The above analysis of the solutions provided by the stateful 64 shows
that the majority of the problems that are not directly related to
the decoupling of NAT and DNS remain unaddressed. Some of these
problems are not specific to 64 but are generic to all NAT-based
solutions.
This points to several shortcomings of stateful 64 that must be
addressed if the future network deployments have to move reliably
towards 64 as a solution to IPv6-IPv4 interconnection.
<span class="grey">Penno, et al. Informational [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
Some of the issues, as pointed out in [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>], have possible
solutions. However these solutions will require significant updates
to the stateful 64, increasing its complexity.
The following table summarizes the conclusions based on the analysis
of stateful 64.
+---------------+----------+---------+----------+---------+---------+
| Issue | NAT-PT | Exists | DNS ALG | Generic | Can be |
| | Specific | in | Specific | NAT | solved? |
| | | NAT64 | | | |
+---------------+----------+---------+----------+---------+---------+
| Protocols | No | Yes | No | Yes | Yes |
| embedding | | | | | |
| addresses | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Protocols | No | Yes | No | Yes | No |
| without demux | | | | | |
| capability | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Binding state | No | Yes | No | Yes | Yes |
| decay | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Loss of | No | Yes | No | No | No |
| information | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Fragmentation | No | No | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| SCTP and | No | Yes | No | Yes | Yes |
| Multihoming | | | | | |
| interaction | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Proxy | No | Yes | No | No | No |
| correspondent | | | | | |
| node for | | | | | |
| MIPv6 | | | | | |
| Multicast | No | Yes | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| IPsec tunnel | No | Yes | No | Yes | Yes |
| mode | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Topology | Yes | No | Yes | No | Yes |
| constraints | | | | | |
| with DNS-ALG | | | | | |
<span class="grey">Penno, et al. Informational [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
+---------------+----------+---------+----------+---------+---------+
| Scale and | No | Yes | No | Yes | Yes |
| Single point | | | | | |
| of failure | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Lack of | No | Yes | No | Yes | Yes |
| address | | | | | |
| persistence | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DoS attacks | No | Yes | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| Address | Yes | No | Yes | No | Yes |
| selection | | | | | |
| issues with | | | | | |
| Dual stack | | | | | |
| hosts | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Non-global | Yes | No | Yes | No | Yes |
| validity of | | | | | |
| Translated RR | | | | | |
| records | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Incorrect | Yes | No | Yes | No | Yes |
| translation | | | | | |
| of A | | | | | |
| responses | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DNS-ALG and | No | Yes | No | Yes | Yes |
| Multi- | | | | | |
| addressed | | | | | |
| nodes | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DNSSEC | No | Yes | No | Yes | Yes |
| limitations | | | | | |
+---------------+----------+---------+----------+---------+---------+
Table 1: Summary of NAT64 analysis
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document does not specify any new protocol or architecture. It
only analyzes how BEHAVE WG 64 documents mitigate concerns raised in
[<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>] and which ones are still unaddressed.
<span class="grey">Penno, et al. Informational [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgements</span>
Many thanks to M. Bagnulo, D. Wing, X. Li, D. Anipko, and S.
Moonesamy for their review and comments.
D. Black provided the IPsec text.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC0959">RFC0959</a>] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, <a href="./rfc959">RFC 959</a>, October 1985.
[<a id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
June 2002.
[<a id="ref-RFC3948">RFC3948</a>] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
<a href="./rfc3948">RFC 3948</a>, January 2005.
[<a id="ref-RFC4302">RFC4302</a>] Kent, S., "IP Authentication Header", <a href="./rfc4302">RFC 4302</a>,
December 2005.
[<a id="ref-RFC4303">RFC4303</a>] Kent, S., "IP Encapsulating Security Payload (ESP)",
<a href="./rfc4303">RFC 4303</a>, December 2005.
[<a id="ref-RFC4787">RFC4787</a>] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", <a href="https://www.rfc-editor.org/bcp/bcp127">BCP 127</a>,
<a href="./rfc4787">RFC 4787</a>, January 2007.
[<a id="ref-RFC4960">RFC4960</a>] Stewart, R., "Stream Control Transmission Protocol",
<a href="./rfc4960">RFC 4960</a>, September 2007.
[<a id="ref-RFC4966">RFC4966</a>] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", <a href="./rfc4966">RFC 4966</a>, July 2007.
[<a id="ref-RFC5382">RFC5382</a>] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", <a href="https://www.rfc-editor.org/bcp/bcp142">BCP 142</a>,
<a href="./rfc5382">RFC 5382</a>, October 2008.
[<a id="ref-RFC5508">RFC5508</a>] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", <a href="https://www.rfc-editor.org/bcp/bcp148">BCP 148</a>, <a href="./rfc5508">RFC 5508</a>,
April 2009.
<span class="grey">Penno, et al. Informational [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
[<a id="ref-RFC6052">RFC6052</a>] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", <a href="./rfc6052">RFC 6052</a>,
October 2010.
[<a id="ref-RFC6144">RFC6144</a>] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", <a href="./rfc6144">RFC 6144</a>, April 2011.
[<a id="ref-RFC6145">RFC6145</a>] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", <a href="./rfc6145">RFC 6145</a>, April 2011.
[<a id="ref-RFC6146">RFC6146</a>] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", <a href="./rfc6146">RFC 6146</a>, April 2011.
[<a id="ref-RFC6147">RFC6147</a>] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", <a href="./rfc6147">RFC 6147</a>,
April 2011.
[<a id="ref-RFC6887">RFC6887</a>] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", <a href="./rfc6887">RFC 6887</a>,
April 2013.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-ADDR-SELECT">ADDR-SELECT</a>]
Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy using DHCPv6", Work in Progress,
April 2013.
[<a id="ref-DNS64">DNS64</a>] Wing, D., "IPv6-only and Dual Stack Hosts on the Same
Network with DNS64", Work in Progress, February 2011.
[<a id="ref-FTP64">FTP64</a>] Liu, D., Beijnum, I., and Z. Cao, "FTP consideration for
IPv4/IPv6 transition", Work in Progress, January 2012.
[<a id="ref-MIDDLEBOXES">MIDDLEBOXES</a>]
Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis
of Middlebox Interactions for Signaling Protocol
Communication along the Media Path", Work in Progress,
January 2013.
[<a id="ref-NAT64-HARMFUL">NAT64-HARMFUL</a>]
Haddad, W. and C. Perkins, "A Note on NAT64 Interaction
with Mobile IPv6", Work in Progress, March 2011.
<span class="grey">Penno, et al. Informational [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
[<a id="ref-REFERRAL">REFERRAL</a>] Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and
K. Moore, "A Generic Referral Object for Internet
Entities", Work in Progress, October 2009.
[<a id="ref-RFC2766">RFC2766</a>] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", <a href="./rfc2766">RFC 2766</a>,
February 2000.
[<a id="ref-RFC3715">RFC3715</a>] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", <a href="./rfc3715">RFC 3715</a>, March 2004.
[<a id="ref-RFC5245">RFC5245</a>] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", <a href="./rfc5245">RFC 5245</a>,
April 2010.
[<a id="ref-RFC5853">RFC5853</a>] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
A., and M. Bhatia, "Requirements from Session Initiation
Protocol (SIP) Session Border Control (SBC) Deployments",
<a href="./rfc5853">RFC 5853</a>, April 2010.
[<a id="ref-RFC6157">RFC6157</a>] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
Transition in the Session Initiation Protocol (SIP)",
<a href="./rfc6157">RFC 6157</a>, April 2011.
[<a id="ref-RFC6384">RFC6384</a>] van Beijnum, I., "An FTP Application Layer Gateway (ALG)
for IPv6-to-IPv4 Translation", <a href="./rfc6384">RFC 6384</a>, October 2011.
[<a id="ref-RFC6888">RFC6888</a>] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
A., and H. Ashida, "Common Requirements for Carrier-Grade
NATs (CGNs)", <a href="https://www.rfc-editor.org/bcp/bcp127">BCP 127</a>, <a href="./rfc6888">RFC 6888</a>, April 2013.
<span class="grey">Penno, et al. Informational [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc6889">RFC 6889</a> Analysis of 64 Translation April 2013</span>
Authors' Addresses
Reinaldo Penno
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134
USA
EMail: [email protected]
Tarun Saxena
Cisco Systems
Cessna Business Park
Bangalore 560103
India
EMail: [email protected]
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: [email protected]
Senthil Sivakumar
Cisco Systems
7100-8 Kit Creek Road
Research Triangle Park, North Carolina 27709
USA
EMail: [email protected]
Penno, et al. Informational [Page 15]
Annotations
Select text to annotate