Analysis of Stateful 64
Translation
Cisco Systems, Inc.
170 West Tasman Drive
San Jose
95134
California
USA
repenno@cisco.com
Cisco Systems
Cessna Business Park
Bangalore
India
560103
tasaxena@cisco.com
France Telecom
Rennes
35000
France
mohamed.boucadair@orange.com
Cisco Systems
7100-8 Kit Creek Road
Research Triangle Park
27709
North Carolina
USA
ssenthil@cisco.com
Transport Area
Behavior Engineering for Hindrance Avoidance
NAT64
DNS64
NAT-PT
ALG (Application Layer Gateway)
NAT traversal
IPv4-IPv6 interconnection
IPv4-IPv6 translation
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.
This document uses stateful 64 (or 64 for short) to refer to the
mechanisms defined in the following documents:
IP/ICMP Translation Algorithm
Stateful NAT64: Network Address and
Protocol Translation from IPv6 Clients to IPv4 Servers
DNS64: DNS Extensions for Network
Address Translation from IPv6 Clients to IPv4 Servers
IPv6 Addressing of IPv4/IPv6
Translators
Framework for IPv4/IPv6
Translation
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 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
), 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 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.
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) address the issues raised
in .
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 .
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., ) are configured on the stateful
NAT64.
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.
Of the set of problems pointed out in ,
the stateful 64 addresses some of them, whereas it leaves others
unaddressed.
Some issues mentioned in were solved
by , , and
. 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
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 into three categories:
Problems impossible to solve.
Problems that can be solved.
Problems solved.
Problems discussed in that are
impossible to solve:
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
(Section 2.2 of ).
Analysis: This issue is not specific to 64 but to all
NAT-based solutions.
Loss of information due to incompatible semantics between IPv4
and IPv6 versions of headers and protocols (Section 2.4 of).
Analysis: This issue is not specific to 64 but is due to the
design of IPv4 and IPv6.
Need for the NAT64-capable device to act as proxy for
correspondent node when IPv6 node is mobile, with consequent
restrictions on mobility (Section 2.7
of).
Analysis: This is not specific to NAT64 but to all NAT
flavors. Refer to for an
early analysis on mobility complications encountered when
NAT64 is involved.
Problems discussed in that can be
solved:
Disruption of all protocols that embed IP addresses (and/or
ports) in packet payloads or apply integrity mechanisms using IP
addresses (and ports) (Section 2.1
of).
Analysis: In the case of FTP,
this problem can be mitigated in several ways (e.g., use a
FTP64 Application Layer Gateway (ALG) or in the FTP client
(e.g., )).
In the case of SIP , 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) , maintain
SIP-related NAT bindings as per Section 3.4 of , media latching ,
embedded SIP ALGs, etc.).
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.
Interaction with Stream Control Transmission Protocol (SCTP) and
multihoming (Section 2.6 of).
Analysis: Only TCP and UDP transport protocols are within
the scope of NAT64 . SCTP is out
of scope of this document.
Inability to handle multicast traffic (Section 2.8 of).
Analysis: This problem is not addressed by the current 64
specifications.
Scalability concerns together with introduction of a single
point of failure and a security attack nexus (Section 3.2 of).
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.
Restricted validity of translated DNS records: a translated
record may be forwarded to an application that cannot use it
(Section 4.2 of).
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 for more
discussion about issues related to reachability scope).
IPsec traffic using AH (Authentication Header) 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
(Section 2.1
of). In addition, IPsec traffic using ESP (Encapsulating
Security Payload) in transport mode
generally uses UDP encapsulation
for NAT traversal (including NAT-PT traversal) in order to avoid
the problems described in (Section 2.1 of).
Analysis: This is not specific to NAT64 but to all NAT
flavors.
Address selection issues when either the internal or external
hosts implement both IPv4 and IPv6 (Section
4.1 of).
Analysis: This is out of scope of 64 since Scenarios 1 and
5 of assume IPv6-only
hosts.
Therefore, this issue is not resolved and mitigation
techniques outside the 64 need to be used (e.g., ). 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
.
Problems identified in that have been
solved:
Constraints on network topology (as it relates to DNS-ALG; see
Section 3.1 of ).
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.
Need for additional state and/or packet reconstruction in
dealing with packet fragmentation. Otherwise, implement no support
for fragments (Section 2.5 of).
Analysis: This issue is not specific to 64 but to all
NAT-based solutions. 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).
Inappropriate translation of responses to A queries from IPv6
nodes (Section 4.3 of).
Analysis: DNS64 does not
alter A queries.
Address selection issues and resource consumption in a DNS-ALG
with multi-addressed nodes (Section 4.4
of).
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
Section 3 of ) are
required to allow for communications initiated from an
IPv4-only client to an IPv6-only server.
Limitations on DNS security capabilities when using a DNS-ALG
(Section 2.5 of).
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
Section 3 of for more
details.
Creation of a DoS threat relating to
exhaustion of memory and address/port pool resources on the
translator (Section 3.4 of ).
Analysis: This specific DoS concern on Page 6 of 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 (Section 3.4
of ), 64 must enforce a port
limit similar to the one defined in .
Thus, this concern can be fully eliminated in 64.
Requirement for applications to use keepalive mechanisms to
work around connectivity issues caused by premature timeout for
session table and Binding Information Base entries (Section 2.3 of
).
Analysis: Since NAT64 follows some of the , , and
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.
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 , , and .
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.
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 (Section 3.3 of).
Analysis: In the following, address persistence is used to
refer to the support of "IP address pooling" behavior of
"Paired" .
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 and ).
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.
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.
Some of the issues, as pointed out in ,
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 Specific
Exists in NAT64
DNS ALG Specific
Generic NAT
Can be solved?
Protocols embedding addresses
No
Yes
No
Yes
Yes
Protocols without demux capability
No
Yes
No
Yes
No
Binding state decay
No
Yes
No
Yes
Yes
Loss of information
No
Yes
No
No
No
Fragmentation
No
No
No
Yes
Yes
SCTP and Multihoming interaction
No
Yes
No
Yes
Yes
Proxy correspondent node for MIPv6
No
Yes
No
No
No
Multicast
No
Yes
No
Yes
Yes
IPSec tunnel mode
No
Yes
No
Yes
Yes
Topology constraints with DNS-ALG
Yes
No
Yes
No
Yes
Scale and Single point of failure
No
Yes
No
Yes
Yes
Lack of address persistence
No
Yes
No
Yes
Yes
DoS attacks
No
Yes
No
Yes
Yes
Address selection issues with Dual stack hosts
Yes
No
Yes
No
Yes
Non-global validity of Translated RR records
Yes
No
Yes
No
Yes
Incorrect translation of A responses
Yes
No
Yes
No
Yes
DNS-ALG and Multi- addressed nodes
No
Yes
No
Yes
Yes
DNSSEC limitations
No
Yes
No
Yes
Yes
This document does not specify any new protocol or architecture. It
only analyzes how BEHAVE WG 64 documents mitigate concerns raised in
and which ones are still unaddressed.
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.
Port Control Protocol (PCP)
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.
IPv6-only and Dual Stack Hosts on the Same Network with DNS64
Some networks are expected to support IPv4-only, dual-stack, and IPv6-only hosts at the same time. Such networks also want to IPv6/ IPv4 translation for the IPv6-only host so it can access servers on the IPv4 Internet. On such a network, the synthesized AAAA responses from a DNS64 can cause traffic to be translated. This document describes a solution to avoid that translation when the application uses DNS.
FTP consideration for IPv4/IPv6 transition
The File transfer protocol(FTP) has a long histroy,, but still being widely used. The first concept of FTP was described RFC 114, and then was specified in RFC 354. FTP can work in IPv4 environment and then was extended to IPv6. RFC 2428 defines IPv6 extensions of FTP. In the IPv6-IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. This document discusses the details for FTP to work in IPv4-IPv6 transitiion scenario. This document gives recommendation regarding how IPv6 FTP client should behave in 6to4 scenario.
Distributing Address Selection Policy using DHCPv6
RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site.
Common Requirements for Carrier-Grade NATs (CGNs)
This document defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787.
A Note on NAT64 Interaction with Mobile IPv6
This memo discusses potential NAT64 technology repercussions for mobile nodes using Mobile IPv6. An ambiguity is identified related to the use of DNS during bootstrapping, which is likely to inhibit proper signaling between mobile node and home agent.
Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path
Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively.
A Generic Referral Object for Internet Entities
The purpose of a referral is to enable a given entity in a multiparty application to pass information to another party. This memo specifies a Generic Referral Object (GRO) to be used in the context of referrals. The proposed object is compact and is application- independent. Both IPv4 and IPv6 schemes are supported, as well as upper layer identifiers. Additional information to characterise an enclosed reference is also described. To allow proper interpretation of referrals, a new notion of scope identifiers is introduced.