wdiff rfc7269.original rfc7269.txt

Internet Engineering Task Force (IETF) G. Chen
Internet-Draft
Request for Comments: 7269 Z. Cao
Intended status:
Category: Informational China Mobile
Expires: September 11, 2014
ISSN: 2070-1721 C. Xie
China Telecom
D. Binet
France Telecom-Orange
March 10,
June 2014

NAT64 Deployment Options and Experience
draft-ietf-v6ops-nat64-experience-10

Abstract

This document summarizes NAT64 function deployment scenarios and
operational experience. Both NAT64 Carrier Grade Carrier-Grade NAT (NAT64-CGN) and
NAT64 server Front End (NAT64-FE) are considered in this document.

Status of This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid 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 maximum candidate for any level of Internet
Standard; see Section 2 of RFC 5741.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 11, 2014.
http://www.rfc-editor.org/info/rfc7269.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NAT64 Networking Experience . . . . . . . . . . . . . . . . . 4
3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4
3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4
3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4
3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5
3.1.4. Co-existence Coexistence of NAT64 and NAT44 . . . . . . . . . . . 5
3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9
5. Source Address Source-Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geo-location Geolocation . . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 13
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . Contributors . . . . . . . . . . . . 15
12. Additional Author List . . . . . . . . . . . . . . . . . . . 16
13.
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1.
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2.
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Testing Test Results of for Application Behavior . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21

1. Introduction

IPv6 is the only sustainable solution for numbering nodes on the
Internet due to the IPv4 depletion. Network operators have to deploy
IPv6-only networks in order to meet the needs of the expanding
internet
Internet without available IPv4 addresses.

Single-stack IPv6 network deployment can simplify networks
provisioning, network
provisioning; some justification was provided in 464xlat 464XLAT [RFC6877].
IPv6-only connectivity confers some benefits to mobile operators as
an example. In the mobile context, IPv6-only usage enables the use
of a single IPv6 Packet Data Protocol(PDP) Protocol (PDP) context or Evolved Packet
System (EPS) bearer on Long Term Evolution (LTE) networks. This
eliminates significant network costs caused (caused by employing two PDP
contexts in some cases, cases) and the need for IPv4 addresses to be
assigned to customers. In broadband networks overall, it can allow
for the scaling of edge-network growth to be decoupled from IPv4
numbering limitations.

In transition scenarios, some existing networks are likely to be
IPv4-only IPv4
only for quite a long time. IPv6 networks and hosts IPv6-only hosts will
need to coexist with IPv4 numbered resources. Widespread dual-stack
deployments have not materialized at the anticipated rate over the
last 10 years, one possible conclusion being that legacy networks
will not make the jump quickly. The Internet will include nodes that
are dual-stack, dual stack, nodes that remain IPv4-only, IPv4 only, and nodes that can be
deployed as IPv6-only nodes. A translation mechanism based on a NAT64[RFC6146] [RFC6145]function
NAT64 function [RFC6145] [RFC6146] is likely to be a key element of
Internet connectivity for IPv6-IPv4 interoperability.

[RFC6036] reports at least 30% of operators plan to run some kind of
translator (presumably NAT64/DNS64). Advice on NAT64 deployment and
operations are therefore of some importance. [RFC6586] documents the
implications for IPv6 only IPv6-only networks. This document intends to be
specific to NAT64 network planning.

2. Terminology

Regarding IPv4/IPv6 translation, [RFC6144] has described a framework
for enabling networks to make interworking possible between IPv4 and
IPv6 networks. Two operation modes (i.e., stateful translation and
stateless translation) have been described in Section 3.2 of
[RFC6144]. This document describes the usage of those two operation
modes and has further categorized different NAT64 functions, locations
locations, and use-cases. use cases. The principle principal distinction of location is
whether the NAT64 is located in a Carrier Grade Carrier-Grade NAT or server Front
End. The terms of NAT-CGN/FE "NAT-CGN" and "NAT-FE" are understood to be a
topological distinction indicating different features employed in a
NAT64 deployment.

NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP
network. IPv6 enabled IPv6-enabled subscribers leverage the NAT64-CGN to
access existing IPv4 internet Internet services. The ISP as an
administrative entity takes full control of the IPv6 side, but it
has limited or no control on the IPv4 internet Internet side. NAT64-CGN
deployments may have to consider the IPv4 Internet environment and
services, and make appropriate configuration choices accordingly.

NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device
with NAT64 functionality in a content provider or data center
network. It could be be, for example example, a traffic load balancer or a
firewall. The operator of the NAT64-FE has full control over the
IPv4 network within the data center, center but only limited influence or
control over the external Internet IPv6 network.

3. NAT64 Networking Experience

3.1. NAT64-CGN Consideration

3.1.1. NAT64-CGN Usages

Fixed network operators and mobile operators may locate NAT64
translators in access networks or in mobile core networks. It NAT64 can
be built into various devices, including routers, gateways gateways, or firewalls
firewalls, in order to connect IPv6 users to the IPv4 Internet. With
regard to the numbers of users and the shortage of public IPv4
addresses, stateful NAT64[RFC6146] NAT64 [RFC6146] is more suited to maximize
sharing of public IPv4 addresses. The usage of stateless NAT64 can
provide better transparency features [I-D.ietf-softwire-stateless-4v6-motivation], [MOTIVATION], but it has to be
coordinated with A+P[RFC6346] Address plus Port (A+P) processes [RFC6346] as
specified in
[I-D.ietf-softwire-map-t] [MAP-T] in order to address deal with an IPv4 address shortage.

3.1.2. DNS64 Deployment

DNS64[RFC6147]

DNS64 [RFC6147] is recommended for use in combination with stateful
NAT64, and it will likely be an essential part of an IPv6 single-stack single-
stack network that couples to the IPv4 Internet. 464xlat[RFC6877] 464XLAT [RFC6877]
can enable access of IPv4 only IPv4-only applications or applications that call
IPv4 literal addresses. Using DNS64 will help 464xlat 464XLAT to
automatically discover NAT64 prefix prefixes through [RFC7050]. Berkeley
Internet Name Daemon (BIND) software supports the that function. It's
important to note that DNS64 generates the synthetic AAAA reply when
services only provide A records. Operators should not expect to
access IPv4 parts of a dual-stack server using NAT64/DNS64. The
traffic is forwarded on IPv6 paths if dual-stack servers are
targeted. IPv6 traffic may be routed around rather than going
through NAT64. Only the traffic going to IPv4-only service services would
traverse the NAT64 translator. In some sense, it encourages IPv6
usage and limits NAT translation compared to employing NAT44, where
all traffic flows have to be translated. In some cases, NAT64-CGNs
may serve double roles, i.e. i.e., as a translator and IPv6 forwarder. In
mobile networks, NAT64 may be deployed as the default gateway serving
all the IPv6 traffic. The traffic heading to a dual-stack server is
only forwarded on the NAT64. Therefore, both IPv6 and IPv4 are
suggested to be configured on the Internet faced Internet-facing interfaces of
NAT64. We tested on Top100 the top 100 websites (referring to [Alexa]
statistics). 43% of websites are connected and forwarded on the NAT64
since those websites have both AAAA and A records. With expansion of
IPv6 support, the translation process on NAT64 will likely become less-
less important over time. It should be noted that the DNS64-DNSSEC
Interaction[RFC6147]
interaction [RFC6147] may impact validation of Resource Records
retrieved from the the DNS64 process. In particular, DNSSEC validation
will fail when DNS64 synthesizes AAAA records where there is a DNS
query received with the "DNSSEC OK" (DO) bit set and the "Checking
Disabled" (CD) bit set received. set.

3.1.3. NAT64 Placement

All connections to IPv4 services from IPv6-only clients must traverse
the NAT64-CGN. It can be advantageous from the vantage-point viewpoint of
troubleshooting and traffic engineering to carry the IPv6 traffic
natively for as long as possible within an access network and
translate packets only at or near the network egress. NAT64 may be a
feature of the Autonomous System (AS) border in fixed networks. It
may be deployed in an IP node beyond the Gateway GPRS Support Node
(GGSN) or Public Packet Data Network- Network Gateway (PDN-GW) in mobile networks or
directly as part of the gateway itself in some situations. This
allows consistent attribution and traceability within the service
provider network. It has been observed that the process of
correlating log information is problematic from multiple-vendor's multiple vendors'
equipment due to inconsistent formats of log records. Placing NAT64
in a centralized location may reduce diversity of log format and
simplify the network provisioning. Moreover, since NAT64 is only
targeted at serving traffic flows from IPv6 to IPv4-only services,
the user traffic volume should not be as high as in a NAT44 scenario,
and therefore, the gateway's capacity in such a location may be less
of a concern or a hurdle to deployment. On the other-hand, other hand, placement
in a centralized fashion would require more strict high availability high-availability
(HA) design. It would also make geo-location geolocation based on IPv4 addresses
rather inaccurate as is currently the case for NAT44 CGN CGNs already
deployed in ISP networks. More considerations or workarounds on HA
and traceability could can be found at Section in Sections 4 and Section 5.

3.1.4. Co-existence Coexistence of NAT64 and NAT44

NAT64 will likely co-exist coexist with NAT44 in a dual-stack network where
IPv4 private addresses are allocated to customers. The coexistence
has already been observed in mobile networks, in which dual stack dual-stack
mobile phones normally initiate some dual-stack PDN/PDP Type[RFC6459] Type
[RFC6459] to query both IPv4/IPv6 address addresses and IPv4 allocated IPv4-allocated
addresses (which are very often private ones. ones). [RFC6724] always
prioritizes IPv6 connections regardless of whether the end-to-end
path is native IPv6 or IPv6 translated to IPv4 via NAT64/DNS64.
Conversely, Happy
Eyeballs[RFC6555] a "Happy Eyeballs" [RFC6555] algorithm will direct some
IP flows across IPv4 paths. The selection of IPv4/IPv6 paths may
depend on particular implementation choices or settings on a host-by-host host-by-
host basis, and it may differ from an operator's deterministic
scheme. Our tests verified that hosts may find themselves switching
between IPv4 and IPv6 paths as they access identical service, services, but at
different times
[I-D.kaliwoda-sunset4-dual-ipv6-coexist]. [COEXIST]. Since the topology on each path is
potentially different, it may cause unstable user experience and some
degradation of Quality of Experience (QoE) when falling back to the
other protocol. It's also difficult for operators to find a solution
to make a stable network with optimal resource utilization. In
general, it's desirable to figure out the solution that will
introduce IPv6/IPv4 translation service to IPv6-only hosts connecting
to IPv4 servers servers, while making sure dual-stack hosts to have at least one
address family accessible via native service if possible. With the
end-to-end native IPv6 environment available, hosts should be
upgraded aggressively to migrate in favor of IPv6-only. IPv6 only. There are
ongoing efforts to detect host connectivity and propose a new DHCPv6
option[I-D.wing-dhc-dns-reconfigure]
option [CONN-STATUS] to convey appropriate configuration information
to the hosts.

3.2. NAT64-FE Consideration

Some Internet Content Providers (ICPs) may locate NAT64 in front of
an Internet Data Center (IDC), for example example, co-located with a load
-balancing load-
balancing function. Load-balancers Load balancers are employed to connect different
IP family domains, domains and distribute workloads across multiple domains or
internal servers. In some cases, IPv4 addresses address exhaustion may not be
a problem in some an IDC's internal networks. network. IPv6 support for some
applications may require some investments increased investment and
workloads workload, so IPv6
support may not be a priority. The use of NAT64
may can be served used to support
widespread IPv6 adoption on the Internet while maintaining access to
IPv4-only applications access. applications.

Different strategy has strategies have been described in [RFC6883] [RFC6883]; they are
referred to as "inside out" and "outside in". An IDC operator may
implement the following practices in the NAT64-FE networking
scenario.

o Some ICPs who already have satisfactory operational experience
might adopt single stack single-stack IPv6 operation in building data-center data center
networks, servers servers, and applications, as it allows new services
delivery to
be delivered without having to integrate consideration of consider IPv4 NAT and or the address
limitations of IPv4 networks. Stateless NAT64[RFC6145] NAT64 [RFC6145] can used
to provide services for IPv4-only enabled customers.
[I-D.anderson-siit-dc] [SIIT] has provided
further descriptions and guidelines.

o ICPs who attempt to offer customers IPv6 support in their
application farms at an early stage may will likely run proxies load-
balancers proxies, load
balancers, or translators, which translators that are configured to handle incoming
IPv6 flows and proxy them to IPv4 back-end systems. Many load
balancers integrate proxy functionality. IPv4 addresses
configured in the proxy may be multiplexed like a stateful NAT64
translator. A similar challenge exists once increasingly numerous as more users in with IPv6 Internet
connectivity access an IPv4 network. networks. High loads on
load-balancers load balancers
may be apt to cause additional latency, IPv4 pool exhaustion, etc.
Therefore, this approach is only reasonable at an early stage.
ICPs may employ dual-stack dual stack or IPv6 single stack in a further
stage, since the native IPv6 is frequently more desirable than any of
the transition solutions.

[RFC6144] recommends that AAAA records of load-balancers load balancers or
application servers can be directly registered in the authoritative
DNS servers. In this case, there is no need to deploy DNS64 name- name
servers. Those AAAA records can point to natively assigned IPv6
addresses or IPv4-converted IPv6 addresses[RFC6052]. addresses [RFC6052]. Hosts are not
aware of the NAT64 translator on the communication path. For the testing
purpose,
purposes, operators could employ an independent sub domain e.g.
ipv6exp.example.com subdomain, e.g.,
ipv6exp.example.com, to identify experimental ipv6 IPv6 services to users.
How to design the FQDN Fully Qualified Domain Name (FQDN) for the IPv6
service is out-of-scope outside the scope of this document.

4. High Availability

4.1. Redundancy Design

High Availability (HA) is a major requirement for every service and
network services. The deployment of service. Deploying redundancy mechanisms is an essential approach to avoid
avoiding failure and significantly increase increasing the network
reliability. It's useful not only useful to stateful NAT64 cases, cases but also
to stateless NAT64 gateways.

Three redundancy modes are mainly used: cold standby, warm standby Cold Standby, Warm Standby,
and hot standby. Hot Standby.

o Cold standby Standby HA devices do not replicate the NAT64 states from the
primary equipment to the backup. Administrators switch on the
backup NAT64 only if the primary NAT64 fails. As a result, all
existing established sessions through a failed translator will be
disconnected. The translated flows will need to be recreated by
end-systems.
end systems. Since the backup NAT64 is manually configured to
switch over to active NAT64, it may have unpredictable impacts to
the ongoing services.

o Warm standby Standby is a flavor of the cold standby Cold Standby mode. Backup NAT64
would keep running once the primary NAT64 is working. This makes
warm standby
Warm Standby less time consuming time-consuming during the traffic failover. The
Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a
solution to enable automatic handover in the warm standby. It was
tested that during Warm Standby. During
testing, the handover takes as took a maximum as of 1 minute if the backup
NAT64 needs had to take over routing and re-construct reconstruct the Binding
Information Bases (BIBs) for 30 million sessions. In the
deployment phase, operators could balance loads on distinct NAT64s NAT64
devices. Those NAT64s NAT64 devices make a warm backup of each other.

o Hot standby Standby must synchronize the BIBs between the primary NAT64
and backup. When the primary NAT64 fails, the backup NAT64 would take takes
over and maintain maintains the state of all existing sessions. The
internal hosts don't have to re-connect reconnect the external hosts. The
handover time has been is extremely reduced. Employing During testing that employed
Bidirectional Forwarding Detection (BFD) [RFC5880] combined with
VRRP, a delay handover time of only 35ms 35 ms for 30 million sessions handover was observed during
testing.
observed. Under ideal conditions hotstandby conditions, Hot Standby deployments could
guarantee the session continuity for every service. In order to
timely
transmit session states, states in a timely manner, operators may have to
deploy extra transport links between the primary NAT64 and the
distant backup. The scale of synchronization of the data instance is depending
depends on the particular deployment. For example, If if a NAT64-CGN is served for
serves 200,000 users, the an average amount of 800, 000 800,000 sessions per
second is roughly estimated for new a rough estimate of the newly created and expired
sessions. A physical 10Gbps 10 Gbit/s transport link may have to be
deployed for the sync data transmission considering the amount of
sync sessions at the peak and the capacity redundancy redundancy.

In general, cold-standby Cold Standby and warm-standby is Warm Standby are simpler and less
resource intensive, but it requires they require clients to re-establish sessions
when a fail-over failover occurs. Hot standby Standby increases resource consumption
in order to synchronize state, but it potentially achieves seamless
handover. For stateless NAT64 NAT64, considerations are simple, simple because
state synchronization is unnecessary. Regarding stateful NAT64, it
may be useful to investigate the performance tolerance of
applications and the traffic characteristics in a particular network.
Some
testing test results are shown in the Appendix A.

Our statistics in a mobile network shown that almost 91.21% of of
traffic is accounted by http/https HTTP/HTTPS services. These services
generally don't require session continuity. Hot-standby Hot Standby does not
offer much benefit for those sessions on this point. In fixed
networks, HTTP streaming, p2p P2P, and online games would be the major
traffic beneficiaries of hot-standby replication[Cisco-VNI]. Hot Standby replication [Cisco-VNI].
Consideration should be given to the importance of maintaining
bindings for those sessions across failover. Operators may also
consider the Average Revenue Per User (ARPU) factors to deploy when deploying a
suitable redundancy mode. Warm standby Standby may still be adopted to cover
most services services, while hot standby Hot Standby could be used to upgrade the Quality
of Experience (QoE) and using DNS64 to generate different synthetic
responses for limited traffic or destinations. Further
considerations are discussed at Section 6.

4.2. Load Balancing

Load balancing is used to accompany redundancy design so that better
scalability and resiliency could can be achieved. Stateless NAT64s allow
asymmetric routing routing, while anycast-based solutions are recommended in
[I-D.ietf-softwire-map-deployment].
[MAP-DEPLOY]. The deployment of load balancing may make more sense
to stateful NAT64s for the sake of avoiding single-point
failure avoidance. failures.
Since the NAT64-CGN and NAT64-FE have distinct facilities, the
following lists the considerations for each case.

o NAT64-CGN equipment normally doesn't typically implement load-balancing
functions onboard. functions;
they may be implemented in other dedicated equipment. Therefore,
the gateways have to resort to DNS64 or an internal host's
behavior. Once DNS64 is deployed, the load balancing can be
performed by synthesizing the AAAA response with different IPv6
prefixes. For the applications not requiring a DNS resolver,
internal hosts could learn multiple IPv6 prefixes through the
approaches defined in[RFC7050] in [RFC7050] and then select one based on a
given prefix selection policy.

o A dedicated Load Balancer load balancer could be deployed at the front of a
NAT64-FE farm. Load Balancer uses The load balancer could use proxy mode to redirect
the flows to the appropriate NAT64 instance. Stateful NAT64s
require a deterministic pattern to arrange the traffic in order to
ensure outbound/inbound flows traverse the identical NAT64.
Therefore, static scheduling algorithms, for example source-address based
policy, example, a source-
address-based policy, is preferred. A dynamic algorithm, for example Round-
Robin,
example, Round-Robin, may have impacts on applications seeking
session continuity, which are described in the Table 1.

5. Source Address Source-Address Transparency

5.1. Traceability

Traceability is required in many cases cases, such as meeting accounting
requirements and identifying malicious
attacks the sources and accounting requirements. of malicious attacks.
Operators are asked to record the NAT64 log information for specific
periods of time. In our lab testing, the log information from
200,000 subscribers have
been was collected from a stateful NAT64 gateway for
60 days.
Syslog[RFC5424] Syslog [RFC5424] has been adopted to transmit log message messages
from NAT64 to a log station. Each log message contains the transport
protocol, source IPv6 address:port, translated IPv4 address: port address:port, and
timestamp. It takes almost 125 bytes in ASCII format. It has been
verified that the rate of traffic flow is around 72 thousand 72,000 flows per second
second, and the volume of recorded information reaches up to 42.5
terabytes in the raw format. The volume is 29.07 terabytes in a
compact format. At scale, operators have to build up dedicated
transport links, storage system systems, and servers for the purpose of
managing such logging.

There are also several improvements that can be made to mitigate the
issue. For example, stateful NAT64 could configure be configured with the bulk
port allocation method. Once a subscriber creates the first session,
a number of ports are pre-allocated. A bulk allocation message is
logged indicating this allocation. Subsequent session creations will
use one of the pre-allocated port ports and hence does do not require logging.
The log volume in this case may be only one thousandth of that of
dynamic port allocation. Some implementations may adopt static port-range port-
range allocations [I-D.donley-behave-deterministic-cgn] which eliminates [DET-CGN] that eliminate the need for per-subscriber per-
subscriber logging. As a side effect, effect of those methods, the IPv4
multiplexing efficiency is decreased regarding to those methods. decreased. For example, the utilization
ratio of public IPv4 address is dropped
approximately addresses drops to approximately 75% when the
NAT64 gateway is configured with bulk port
allocation allocation. (The lab
testing allocates each subscriber with 400
ports). ports.) In addition, port-range based
port-range-based allocation should also consider port randomization as
described in [RFC6056] . A [RFC6056]. The trade-off among address multiplexing
efficiency, logging storage compression compression, and port allocation
complexity should be considered. More discussions could can be found in [I-D.chen-sunset4-cgn-port-allocation].
[PORT-ALLOC]. The decision can balance usable IPv4 resources against
investments in log systems.

5.2. Geo-location Geolocation

IP addresses are usually used as inputs to geo-location geolocation services. The
use of address sharing prevents these systems from resolving the
location of a host based on IP address alone. Applications that
assume such geographic information may not work as intended. The
possible solutions listed in [RFC6967] are intended to bridge the
gap. However, those solutions can only provide a sub-optimal suboptimal
substitution to solve the problem of host identification, identification; in
particular
particular, it may not today solve today's problems with source
identification through translation. The following lists current
practices to mitigate the issue.

o Operators who adopt NAT64-FE may leverage the application layer application-layer
proxies, e.g. e.g., X-Forwarded-For (XFF)
[I-D.ietf-appsawg-http-forwarded], [RFC7239], to convey the IPv6
source address in HTTP headers. Those messages would be passed on
to
web-servers. web servers. The log parsing tools are required to be able to
support IPv6 and may lookup Radius RADIUS servers for the target
subscribers based on IPv6 addresses included in XFF HTTP headers.
XFF is the de facto standard which that has been integrated in most
Load Balancers. load
balancers. Therefore, it may be superior to use in a NAT-FE
environment. In On the downsides, downside, XFF is specific to HTTP. It
restricts the usages usage so that the solution can't be applied to requests
made over HTTPs. HTTPS. This makes geo-location geolocation problematic for
HTTPs HTTPS-
based services.

o The NAT64-CGN equipment may not implement XFF. Geo-location Geolocation based
on shared IPv4 address addresses is rather inaccurate in that case.
Operators could subdivide the outside IPv4 address pool so an IPv6
address can be translated depending on their the IPv6 subscriber's
geographical locations. As a consequence, location information
can be identified from a certain IPv4 address range. [RFC6967]
also enumerates several options to reveal the host identifier.
Each solution likely has their-own its own specific usage. For the geo-location
geolocation systems relying on a Radius database[RFC5580], RADIUS database [RFC5580], we
have investigated to
deliver delivering NAT64 BIBs and Session Table Entries
(STEs) to a Radius
server[I-D.chen-behave-nat64-radius-extension]. RADIUS server [NAT64-RADIUS]. This method could
provide geo-location a geolocation system with an internal IPv6 address to
identify each user. It can get along be paired with [RFC5580] to convey the
original source address through the same message bus.

6. Quality of Experience

6.1. Service Reachability

NAT64 is providing a translation capability between IPv6 and IPv4
end-nodes. end
nodes. In order to provide the reachability between two IP address
families, NAT64-CGN has to implement appropriate application
aware application-aware
functions, i.e. i.e., Application Layer Gateway (ALG), Gateways (ALGs), where address
translation is not itself sufficient and security mechanisms do not render it
the functions infeasible. Most NAT64-CGNs mainly provide FTP-
ALG[RFC6384]. FTP-ALG
[RFC6384]. NAT64-FEs may have functional richness on Load
Balancer, the load
balancer; for example example, HTTP-ALG, HTTPs-ALG, RTSP-ALG HTTPS-ALG, RTSP-ALG, and SMTP-ALG
have been supported. Those application protocols exchange IP address
and port parameters within a control session, for example example, using the
"Via" filed field in a HTTP header, "Transport" field in a an RTSP SETUP message and
"Received: "
message, or "Received:" header in a SMTP message. ALG functions will
detect those fields and make IP address translations. It should be
noted that ALGs may impact the performance on a NAT64 box to some
extent. ISPs as well as content providers might choose to avoid
situations where the imposition of an ALG might be required. At the
same time, it is also important to remind customers and application
developers that IPv6 end-to-end usage does not require ALG imposition
and therefore results in a better overall user experience.

The service reachability is also subject to the IPv6 support in the
client side. We tested several kinds of applications as shown in the
below table to verify the IPv6 supports. support. The experiences of some
applications are still align aligned with [RFC6586]. For example, we have
tested P2P file sharing and streaming applications including eMule
v0.50a, Thunder v7.9 v7.9, and PPS TV v3.2.0. It has been found there are
some software issues to with the support of IPv6 at this time. The
application software would benefit from 464xlat[RFC6877] 464XLAT [RFC6877] until the
software adds IPv6 support.. support. A SIP based SIP-based voice call has been tested
in the LTE mobile environment as specified in [IR.92]. The voice
call is failed due to the lack of NAT64 traversal when an IPv6 SIP user
agent communicates with an IPv4 SIP user agent. In order to address
the failure, Interactive Connectivity Establishment (ICE) as
described in [RFC5245] is recommended to be supported for the SIP
IPv6 transition. [RFC6157] describes both signaling and media the media-
layer process, which should be followed. In addition, it may be is worth to notice
noting that ICE is not only useful for NAT traversal, but also firewall[RFC6092] for
firewall [RFC6092] traversal in a native IPv6 deployment.

Different IPsec modes for VPN services have been tested, including
IPsec-AH
IPsec Authentication Header (AH) and IPsec-ESP. IPsec Encapsulating Security
Payload (ESP). It has been testified IPsec-AH can't survive
since shown that IPsec AH fails because the
destination host detects the IP header changes and
invalidate invalidates the
packets. IPsec-ESP IPsec ESP failed in our testing because the NAT64 does not
translate IPsec ESP (i.e. (i.e., protocol 50) packets. It has been
suggested that IPsec ESP should would succeed if the IPSec IPsec client supports NAT-Traversal
NAT traversal in the IKE[RFC3947] Internet Key Exchange Protocol (IKE) [RFC3947]
and uses IPsec ESP over
UDP[RFC3948]. UDP [RFC3948].

Table 1: The tested applications Tested Applications

6.2. Resource Reservation

Session status normally is managed by a static timer. For example,
the value of the "established connection idle-timeout" for TCP
sessions must not be
less than 2 hours 4 minutes[RFC5382] minutes [RFC5382] for TCP sessions and 5 minutes
for UDP sessions[RFC4787]. sessions [RFC4787]. In some cases, NAT resource maybe resources may be
significantly consumed by largely inactive users. The NAT translator and other
customers would suffer from service degradation due to port
consummation
consumption by other subscribers using the same NAT64 device. A
flexible NAT session control is desirable to resolve the these issues.
PCP[RFC6887]
The Port Control Protocol (PCP) [RFC6887] could be a candidate to
provide such capability. A NAT64-CGN should integrate with a PCP server,
server to allocate available IPv4 address/port resources. Resources
could be assigned to PCP clients through PCP MAP/PEER mode. Such ability can be considered to
upgrade Doing so
might improve user experiences, for example example, by assigning different
sizes of port ranges for different subscribers. Those mechanisms are
also helpful to minimize terminal battery consumption and reduce the
number of keep-alive messages to be sent by mobile terminal devices.

Subscribers can also benefit from network reliability. It has been
discussed that hot-standby Hot Standby offers a satisfactory experience once after
outage of the primary NAT64 is has occurred. Operators may rightly be
concerned about the considerable investment required for NAT64
equipment relative to low ARPU income. ARPU. For example, transport links may cost
much, be
expensive, because the primary NAT64 and the backup are normally
located at different locations, separated by a relatively large
distance. Additional cost has to would be assumed incurred to ensure the
connectivity quality. However, that may be necessary to some applications, which applications
that are delay-
sensitive delay-sensitive and seek session continuity, for example on-line example,
online games and
live-streaming. live streaming. Operators may be able to get added-values added
value from those services by offering first-class services. It The
service sessions can be pre-configured on the gateway to hot-standby modes Hot Standby
mode depending on the subscriber's profile. The rest of other the sessions
can be covered by cold/warm
standby. Cold or Warm Standby.

7. MTU Considerations

IPv6 requires that every link in the internet Internet have an a Maximum
Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. greater [RFC2460].
However,
in case of if NAT64 translation deployment, is deployed, some IPv4 MTU constrained
link will be used in some a communication path and the originating IPv6
nodes may therefore receive an ICMP Packet Too Big (PTB) message,
reporting a Next-Hop MTU less than 1280 bytes. The result would be
that IPv6 allows packets to contain a fragmentation header, without
the packet being fragmented into multiple pieces. A NAT64 would
receive IPv6 packets with a fragmentation header in which the "M"
flag
equal is set to 0 and the "Fragment Offset" equal is set to 0. Those
packets likely impact other fragments already queued with the same
set of {IPv6 Source Address, IPv6 Destination Address, Fragment
Identification}. If the NAT64 box is compliant with [RFC5722], there
is a risk that all the fragments will have to be dropped.

[RFC6946] discusses how this situation could be exploited by an
attacker to perform fragmentation-based attacks, attacks and also proposes an
improved handling of such packets. It required requires enhancements on NAT64
gateway implementations to isolate packet's processing. the processing of packets. NAT64
devices should follow the recommendation recommendations and take steps to prevent
the risks of fragmentation.

Another approach that potentially avoids this issue is to configure
the IPv4 MTU to more than 1260 bytes. It This would forbid the occurrence of prevent getting a
PTB message for an MTU smaller than 1280 bytes. Such an operational
consideration is hard to universally apply to the legacy "IPv4
Internet" NAT64-CGN bridged. that is bridged by NAT64-CGNs. However, it's a feasible
approach in NAT64-FE cases, since a an IPv4 network NAT64-FE connected is rather
well-organized and operated by a an IDC operator or content provider.
Therefore, the MTU of an IPv4 network in NAT64-FE case are is strongly
recommended to be set to more than 1260 bytes.

8. ULA Usages

Unique Local Addresses (ULAs) are defined in [RFC4193] to be
renumbered within a network site for local communications. Operators
may use ULAs as NAT64 prefixes to provide site-local IPv6
connectivity. Those ULA prefixes are stripped when the packets going go to
the IPv4 Internet, therefore Internet; therefore, ULAs are only valid in the IPv6 site.
The use of ULAs could help in identifying the translation
traffic.[I-D.ietf-v6ops-ula-usage-recommendations] traffic.
[ULA-USAGE] provides further guidance for the ULAs usages. on using ULAs.

We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is
only
assigned with only an IPv6 address and connected to a NAT64-CGN, when
connect
it connects to an IPv4 service, it would receive a AAAA record
generated by the DNS64 with the ULA prefix. A Global Unicast Address
(GUA) will be selected as the source address to the ULA destination
address. When the host has both IPv4 and IPv6 address, addresses, it would
initiate both A and AAAA record lookup, then both the original A
record and DNS64-generated AAAA record would be received. A host, which host
that is compliant with [RFC6724], [RFC6724] will never prefer a ULA over IPv4. an IPv4
address. An IPv4 path will be always be selected. It may be
undesirable because the NAT64-CGN will never be used. Operators may
consider to add adding additional site-specific rows into the default policy
table for host address selection in order to steer traffic flows going
through the NAT64-CGN. However, it involves significant costs to
change a terminal's behavior. Therefore, operators are it is not suggested to that
operators configure ULAs on a NAT64-CGN.

ULAs can't work when hosts transit the Internet to connect with
NAT64. Therefore, ULAs are inapplicable not applicable to the case of NAT64-FE.

9. Security Considerations

This document presents the deployment experiences of NAT64 in CGN and
FE scenarios. In general, RFC 6146[RFC6146] 6146 [RFC6146] provides TCP-tracking,
address-dependent filtering mechanisms to protect NAT64 from
Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators
also
could also adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] (uRPF) [RFC3704] and
black/white-list
blacklisting and whitelisting to enhance the security by specifying
access policies. For example, NAT64-CGN should forbid establish establishing
NAT64 BIB for incoming IPv6 packets if they do not pass the uRPF
check in Strict or Loose mode check does
not pass or whose if their source IPv6 address is associated to black-lists.

The stateful
blacklisted.

Stateful NAT64-FE creates state and maps that connection to an
internally-facing
internally facing IPv4 address and port. An attacker can consume the
resources of the NAT64-FE device by sending an excessive number of
connection attempts. Without a DDoS limitation mechanism, the
NAT64-FE is exposed to attacks. Load Balancer The load balancer is recommended to
enable the capabilities of line rate for line-rate DDOS defense, such as the
employment of SYN PROXY-COOKIE. Security domain proxy/cookie. In this case, division of the
security domain is necessary as well in this case. well. Therefore, Load Balancers load balancers
could not only serve for optimization of optimize the traffic distribution, distribution but also prevent
service from quality deterioration due to security attacks.

The DNS64 process will potentially interfere with the DNSSEC
functions[RFC4035],
functions [RFC4035], since the DNS response is modified and DNSSEC
intends to prevent such changes. More detailed discussions can be
found in [RFC6147].

10. IANA Considerations

This memo includes no request to IANA.

11. Acknowledgements

The authors would like to thank Jari Arkko, Dan Wing, Remi Despres,
Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy
Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley,
Tim Chown, Gert Doering Doering, and Simon Perreault for their helpful
comments.

Many thanks to Wesley George, Lee Howard Howard, and Satoru Matsushima for
their detailed reviews.

The authors especially thank Joel Jaeggli and Ray Hunter for his their
efforts and contributions on editing editing, which substantially improves improved
the
legibility readability of the document.

Thanks to Cameron Byrne who was an active co-author coauthor of some earlier
draft versions of this draft.

12. Additional Author List document.

11. Contributors

The following are extended authors who individuals contributed extensively to the effort:

Qiong Sun
China Telecom
Room 708, No.118, No. 118, Xizhimennei Street
Beijing 100035
P.R.China
P.R. China
Phone: +86-10-58552936
Email:
EMail: sunqiong@ctbri.com.cn

QiBo Niu
ZTE
50,RuanJian Road.
50 RuanJian Road
YuHua District,
Nan Jing 210012
P.R.China
Email:
P.R. China
EMail: niu.qibo@zte.com.cn

13.

12. References

13.1.

12.1. Normative References

[I-D.ietf-appsawg-http-forwarded]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 2012.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.

[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.

[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.

[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.

[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.

[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.

[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.

[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.

[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
Aboba, "Carrying Location Objects in RADIUS and Diameter",
RFC 5580, August 2009.

[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009.

[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, March 2010.

[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.

[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.

[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.

[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.

[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6
Transition in the Session Initiation Protocol (SIP)", RFC
6157, April 2011.

[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG)
for IPv6-to-IPv4 Translation", RFC 6384, October 2011.

[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.

[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.

[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.

[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
6946, May 2013.

[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
7050, November 2013.

13.2.

[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, May 2014.

12.2. Informative References

[Alexa] Alexa, "http://www.alexa.com/topsites", "Top 500 Global Sites", April 2013.

[Cisco-VNI]
Cisco, "Cisco Visual Networking Index: Forecast and
Methodology, 2012-2017,
http://ciscovni.com/forecast-widget/index.html", May 2013.

[I-D.anderson-siit-dc]
Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data
Centre Environments", draft-anderson-siit-dc-00 (work in
progress), November 2012.

[I-D.chen-behave-nat64-radius-extension]
Chen, G. 2013,
<http://www.alexa.com/topsites>.

[COEXIST] Kaliwoda, A. and D. Binet, "Radius Attributes for Stateful
NAT64", draft-chen-behave-nat64-radius-extension-00 (work "Co-existence of both dual-
stack and IPv6-only hosts", Work in progress), July 2013.

[I-D.chen-sunset4-cgn-port-allocation]
Chen, G., Tsou, T., Donley, C., Progress, October
2012.

[CONN-STATUS]
Patil, P., Boucadair, M., Wing, D., and T. Taylor, "Analysis
of NAT64 Port Allocation Method", draft-chen-sunset4-cgn-
port-allocation-03 (work Reddy, "IP
Connectivity Status Notifications for DHCPv6", Work in progress),
Progress, February 2014.

[I-D.donley-behave-deterministic-cgn]

[Cisco-VNI]
Cisco, "Cisco VNI Global Mobile Data Traffic Forecast,
2012-2018", February 2014,
<http://ciscovni.com/forecast-widget/index.html>.

[DET-CGN] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments", draft-donley-
behave-deterministic-cgn-07 (work Work in progress),
Progress, January 2014.

[I-D.ietf-softwire-map-deployment]

[IR.92] Global System for Mobile Communications Association
(GSMA), "IMS Profile for Voice and SMS Version 7.0", March
2013.

[MAP-DEPLOY]
Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault,
"Mapping of Address and Port (MAP) - Deployment
Considerations", draft-ietf-softwire-map-deployment-03
(work Work in progress), October 2013.

[I-D.ietf-softwire-map-t] Progress, April 2014.

[MAP-T] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work Work in progress), Progress, February 2014.

[I-D.ietf-softwire-stateless-4v6-motivation]

[MOTIVATION]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Carrier-side
Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-
softwire-stateless-4v6-motivation-05 (work Work in progress),
Progress, November 2012.

[I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B. and S. Jiang, "Recommendations of Using Unique
Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-02 (work in progress), February 2014.

[I-D.kaliwoda-sunset4-dual-ipv6-coexist]
Kaliwoda, A.

[NAT64-RADIUS]
Chen, G. and D. Binet, "Co-existence of both dual-
stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual-
ipv6-coexist-01 (work "Radius Attributes for Stateful
NAT64", Work in progress), October 2012.

[I-D.wing-dhc-dns-reconfigure]
Patil, P., Boucadair, M., Wing, D., Progress, July 2013.

[PORT-ALLOC]
Chen, G., Tsou, T., Donley, C., and T. Reddy, "DHCPv6
Dynamic Reconfiguration", draft-wing-dhc-dns-
reconfigure-02 (work in progress), September 2013.

[IR.92] Global System for Mobile Communications Association
(GSMA), , "IMS Profile Taylor, "Analysis
of NAT64 Port Allocation Methods for Voice and SMS Version 7.0",
March 2013. Shared IPv4
Addresses", Work in Progress, April 2014.

[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider
Scenarios for IPv6 Deployment", RFC 6036, October 2010.

[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, January
2011.

[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, January
2011.

[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.

[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011.

[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012.

[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012.

[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.

[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers", RFC
6883, March 2013.

[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Potential Solutions for Revealing a Host
Identifier (HOST_ID) in Shared Address Deployments", RFC
6967, June 2013.

[SIIT] Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data
Centre Environments", Work in Progress, November 2012.

[ULA-USAGE]
Liu, B. and S. Jiang, "Recommendations of Using Unique
Local Addresses", Work in Progress, February 2014.

Appendix A. Testing Test Results of for Application Behavior

We test tested several application behaviors in a lab environment to
evaluate the impact when a primary NAT64 is out of service. In this
testing, participants are were asked to connect a an IPv6-only WiFi network
using laptops, tablets tablets, or mobile phones. NAT64 is was deployed as the
gateway to connect provide Internet service. The tested applications are
shown in the below table. table below. Cold standby, warm standby Standby, Warm Standby, and hot standby
are taken turn to be Hot
Standby were each tested. The participants may experience have experienced
service interruption due to the NAT64 handover. Different
interruption intervals are were tested to gauge application behaviors.
The results are
illuminated as shown below.

Table 2: The acceptable delay Acceptable Delay of applications Applications

+----------------+------------------------+-------------------------+
| APPs Application | Acceptable Interrupt | Session Continuity |
| | Recovery | |
+----------------+------------------------+-------------------------+
| Web Browse |As maximum as 6s browsing | Maximum of 6 s | No |
+----------------+------------------------+-------------------------+
|Http
| HTTP streaming |As maximum as 10s(cache)| | Maximum of 10 s (cache)| Yes |
+----------------+------------------------+-------------------------+
| Gaming Games | 200ms~400ms 200-400 ms | Yes |
+----------------+------------------------+-------------------------+
|P2P streaming, | 10~16s file sharing| 10-16 s | Yes |
|file sharing
|and streaming | | |
+----------------+------------------------+-------------------------+
|Instant Message |1
| Instant Message| 1 minute | Yes |
+----------------+------------------------+-------------------------+
|Mail |30 seconds
| Email | 30 s | No |
+----------------+------------------------+-------------------------+
|Downloading |1 minutes
| Downloading | 1 minute | No |
+----------------+------------------------+-------------------------+

Authors' Addresses

Gang Chen
China Mobile
Xuanwumenxi Ave. No.32, No. 32
Xuanwu District, District
Beijing 100053
P.R. China

Email:

EMail: chengang@chinamobile.com, phdgang@gmail.com

Zhen Cao
China Mobile
Xuanwumenxi Ave. No.32, No. 32
Xuanwu District, District
Beijing 100053
P.R. China

Email:

EMail: caozhen@chinamobile.com, zehn.cao@gmail.com

Chongfeng Xie
China Telecom
Room 708 No.118, Xizhimenneidajie 708, No. 118, Xizhimennei Street
Beijing 100035
P.R.China

Email:
P.R. China

EMail: xiechf@ctbri.com.cn

David Binet
France Telecom-Orange
Rennes
35000
France

Email:

EMail: david.binet@orange.com