[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-chen-v6ops-nat64-experience) 00 01 02 03 04 05 06 07 08 09 10 RFC 7269

Internet Engineering Task Force                                  G. Chen
Internet-Draft                                                    Z. Cao
Intended status: Informational                              China Mobile
Expires: September 11, 2014                                       C. Xie
                                                           China Telecom
                                                                D. Binet
                                                   France Telecom-Orange
                                                          March 10, 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 NAT (NAT64-CGN) and
   NAT64 server Front End (NAT64-FE) are considered in this document.

Status of This Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents 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.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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



Chen, et al.           Expires September 11, 2014               [Page 1]

Internet-Draft              NAT64 Experience                  March 2014


   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 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 Transparency . . . . . . . . . . . . . . . . .   9
     5.1.  Traceability  . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Geo-location  . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Quality of Experience . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Service Reachability  . . . . . . . . . . . . . . . . . .  11
     6.2.  Resource Reservation  . . . . . . . . . . . . . . . . . .  12
   7.  MTU Considerations  . . . . . . . . . . . . . . . . . . . . .  13
   8.  ULA Usages  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   12. Additional Author List  . . . . . . . . . . . . . . . . . . .  16
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     13.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Appendix A.  Testing Results of Application Behavior  . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

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

   Single-stack IPv6 network deployment can simplify networks
   provisioning, some justification was provided in 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) context or Evolved Packet
   System (EPS) bearer on Long Term Evolution (LTE) networks.  This



Chen, et al.           Expires September 11, 2014               [Page 2]

Internet-Draft              NAT64 Experience                  March 2014


   eliminates significant network costs caused by employing two PDP
   contexts in some 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 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, nodes that remain IPv4-only, and nodes
   that can be deployed as IPv6-only nodes.  A translation mechanism
   based on a NAT64[RFC6146] [RFC6145]function 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 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.  This document has further categorized different NAT64
   functions, locations and use-cases.  The principle distinction of
   location is whether the NAT64 is located in a Carrier Grade NAT or
   server Front End. The terms of NAT-CGN/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 subscribers leverage the NAT64-CGN to
      access existing IPv4 internet services.  The ISP as an
      administrative entity takes full control of the IPv6 side, but has
      limited or no control on the IPv4 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 for 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, but only limited influence or
      control over the external Internet IPv6 network.



Chen, et al.           Expires September 11, 2014               [Page 3]

Internet-Draft              NAT64 Experience                  March 2014


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 can be
   built into various devices, including routers, gateways or 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] 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],
   but has to be coordinated with A+P[RFC6346] processes as specified in
   [I-D.ietf-softwire-map-t] in order to address an IPv4 address
   shortage.

3.1.2.  DNS64 Deployment

   DNS64[RFC6147] is recommended for use in combination with stateful
   NAT64, and will likely be an essential part of an IPv6 single-stack
   network that couples to the IPv4 Internet. 464xlat[RFC6877] can
   enable access of IPv4 only applications or applications that call
   IPv4 literal addresses.  Using DNS64 will help 464xlat to
   automatically discover NAT64 prefix through [RFC7050].  Berkeley
   Internet Name Daemon (BIND) software supports the 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 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. 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 interfaces of NAT64.
   We tested on Top100 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-
   important over time.  It should be noted the DNS64-DNSSEC
   Interaction[RFC6147] may impact validation of Resource Records
   retrieved from the the DNS64 process.  In particular, DNSSEC



Chen, et al.           Expires September 11, 2014               [Page 4]

Internet-Draft              NAT64 Experience                  March 2014


   validation will fail when DNS64 synthesizes AAAA records where there
   is a DNS query with the "DNSSEC OK" (DO) bit set and the "Checking
   Disabled" (CD) bit set received.

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 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 Data 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
   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 location may be less of
   a concern or a hurdle to deployment.  On the other-hand, placement in
   a centralized fashion would require more strict high availability
   (HA) design.  It would also make geo-location based on IPv4 addresses
   rather inaccurate as is currently the case for NAT44 CGN already
   deployed in ISP networks.  More considerations or workarounds on HA
   and traceability could be found at Section 4 and Section 5.

3.1.4.  Co-existence of NAT64 and NAT44

   NAT64 will likely co-exist 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
   mobile phones normally initiate some dual-stack PDN/PDP Type[RFC6459]
   to query both IPv4/IPv6 address and IPv4 allocated addresses are very
   often private 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] 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 basis, and 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, but at different times
   [I-D.kaliwoda-sunset4-dual-ipv6-coexist].  Since the topology on each



Chen, et al.           Expires September 11, 2014               [Page 5]

Internet-Draft              NAT64 Experience                  March 2014


   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 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.  There are
   ongoing efforts to detect host connectivity and propose a new DHCPv6
   option[I-D.wing-dhc-dns-reconfigure] 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 co-located with a load
   -balancing function.  Load-balancers are employed to connect
   different IP family domains, and distribute workloads across multiple
   domains or internal servers.  In some cases, IPv4 addresses
   exhaustion may not be a problem in some IDC's internal networks.
   IPv6 support for some applications may require some investments and
   workloads so IPv6 support may not be a priority.  The use of NAT64
   may be served to support widespread IPv6 adoption on the Internet
   while maintaining IPv4-only applications access.

   Different strategy has been described in [RFC6883] 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 IPv6 operation in building data-center
      networks, servers and applications, as it allows new services
      delivery without having to integrate consideration of IPv4 NAT and
      address limitations of IPv4 networks.  Stateless NAT64[RFC6145]
      can used to provide services for IPv4-only enabled customers.
      [I-D.anderson-siit-dc] has provided further descriptions and
      guidelines.

   o  ICPs who attempt to offer customers IPv6 support in their
      application farms at an early stage may likely run proxies load-
      balancers or translators, which 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
      users in IPv6 Internet access an IPv4 network.  High loads on



Chen, et al.           Expires September 11, 2014               [Page 6]

Internet-Draft              NAT64 Experience                  March 2014


      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 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 or
   application servers can be directly registered in the authoritative
   DNS servers.  In this case, there is no need to deploy DNS64 name-
   servers.  Those AAAA records can point to natively assigned IPv6
   addresses or IPv4-converted IPv6 addresses[RFC6052].  Hosts are not
   aware of the NAT64 translator on communication path.  For the testing
   purpose, operators could employ an independent sub domain e.g.
   ipv6exp.example.com to identify experimental ipv6 services to users.
   How to design the FQDN for the IPv6 service is out-of-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 redundancy mechanisms is an
   essential approach to avoid failure and significantly increase the
   network reliability.  It's not only useful to stateful NAT64 cases,
   but also to stateless NAT64 gateways.

   Three redundancy modes are mainly used: cold standby, warm standby
   and hot standby.

   o  Cold 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.  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 is a flavor of the cold standby mode.  Backup NAT64
      would keep running once the primary NAT64 is working.  This makes
      warm standby less time consuming during the traffic failover.
      Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a
      solution to enable automatic handover in the warm standby.  It was
      tested that the handover takes as maximum as 1 minute if the
      backup NAT64 needs to take over routing and re-construct the
      Binding Information Bases (BIBs) for 30 million sessions.  In




Chen, et al.           Expires September 11, 2014               [Page 7]

Internet-Draft              NAT64 Experience                  March 2014


      deployment phase, operators could balance loads on distinct NAT64s
      devices.  Those NAT64s make a warm backup of each other.

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

   In general, cold-standby and warm-standby is simpler and less
   resource intensive, but it requires clients to re-establish sessions
   when a fail-over occurs.  Hot standby increases resource consumption
   in order to synchronize state, but potentially achieves seamless
   handover.  For stateless NAT64 considerations are simple, because
   state synchronization is unnecessary.  Regarding stateful NAT64, it
   may be useful to investigate performance tolerance of applications
   and the traffic characteristics in a particular network.  Some
   testing 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 services.  These services
   generally don't require session continuity.  Hot-standby does not
   offer much benefit for those sessions on this point.  In fixed
   networks, HTTP streaming, p2p and online games would be the major
   traffic beneficiaries of 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
   suitable redundancy mode.  Warm standby may still be adopted to cover
   most services while hot standby could be used to upgrade Quality of
   Experience (QoE) using DNS64 to generate different synthetic
   responses for limited traffic or destinations.  Further
   considerations are discussed at Section 6.





Chen, et al.           Expires September 11, 2014               [Page 8]

Internet-Draft              NAT64 Experience                  March 2014


4.2.  Load Balancing

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

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

   o  A dedicated Load Balancer could be deployed at front of a NAT64-FE
      farm.  Load Balancer uses 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, is preferred.  A dynamic algorithm, for example Round-
      Robin, may have impacts on applications seeking session
      continuity, which described in the Table 1.

5.  Source Address Transparency

5.1.  Traceability

   Traceability is required in many cases such as identifying malicious
   attacks sources and accounting requirements.  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 collected from a stateful NAT64 gateway for 60 days.
   Syslog[RFC5424] has been adopted to transmit log message from NAT64
   to a log station.  Each log message contains transport protocol,
   source IPv6 address:port, translated IPv4 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 flows
   per 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 and servers for the purpose of
   managing such logging.



Chen, et al.           Expires September 11, 2014               [Page 9]

Internet-Draft              NAT64 Experience                  March 2014


   There are also several improvements that can be made to mitigate the
   issue.  For example, stateful NAT64 could configure with 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 and hence does not require logging.
   The log volume in this case may be only one thousandth of dynamic
   port allocation.  Some implementations may adopt static port-range
   allocations [I-D.donley-behave-deterministic-cgn] which eliminates
   the need for per-subscriber logging.  As a side effect, the IPv4
   multiplexing efficiency is decreased regarding to those methods.  For
   example, the utilization ratio of public IPv4 address is dropped
   approximately to 75% when NAT64 gateway is configured with bulk port
   allocation (The lab testing allocates each subscriber with 400
   ports).  In addition, port-range based allocation should also
   consider port randomization described in [RFC6056] . A trade-off
   among address multiplexing efficiency, logging storage compression
   and port allocation complexity should be considered.  More
   discussions could be found in [I-D.chen-sunset4-cgn-port-allocation].
   The decision can balance usable IPv4 resources against investments in
   log systems.

5.2.  Geo-location

   IP addresses are usually used as inputs to geo-location 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
   substitution to solve the problem of host identification, in
   particular it may not today solve 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
      proxies, e.g. X-Forwarded-For (XFF)
      [I-D.ietf-appsawg-http-forwarded], to convey the IPv6 source
      address in HTTP headers.  Those messages would be passed on to
      web-servers.  The log parsing tools are required to be able to
      support IPv6 and may lookup Radius servers for the target
      subscribers based on IPv6 addresses included in XFF HTTP headers.
      XFF is the de facto standard which has been integrated in most
      Load Balancers.  Therefore, it may be superior to use in a NAT-FE
      environment.  In the downsides, XFF is specific to HTTP.  It
      restricts the usages so that the solution can't be applied to
      requests made over HTTPs.  This makes geo-location problematic for
      HTTPs based services.



Chen, et al.           Expires September 11, 2014              [Page 10]

Internet-Draft              NAT64 Experience                  March 2014


   o  The NAT64-CGN equipment may not implement XFF.  Geo-location based
      on shared IPv4 address is rather inaccurate in that case.
      Operators could subdivide the outside IPv4 address pool so an IPv6
      address can be translated depending on their geographical
      locations.  As 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 specific usage.  For the geo-location systems
      relying on a Radius database[RFC5580], we have investigated to
      deliver NAT64 BIBs and Session Table Entries (STEs) to a Radius
      server[I-D.chen-behave-nat64-radius-extension].  This method could
      provide geo-location system with an internal IPv6 address to
      identify each user.  It can get along with [RFC5580] to convey
      original source address through same message bus.

6.  Quality of Experience

6.1.  Service Reachability

   NAT64 is providing a translation capability between IPv6 and IPv4
   end-nodes.  In order to provide the reachability between two IP
   address families, NAT64-CGN has to implement appropriate application
   aware functions, i.e. Application Layer Gateway (ALG), where address
   translation is not itself sufficient and security mechanisms do not
   render it infeasible.  Most NAT64-CGNs mainly provide FTP-
   ALG[RFC6384].  NAT64-FEs may have functional richness on Load
   Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have
   been supported.  Those application protocols exchange IP address and
   port parameters within control session, for example the "Via" filed
   in a HTTP header, "Transport" field in a RTSP SETUP message and
   "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.  The experiences of some
   applications are still align with [RFC6586].  For example, we have
   tested P2P file sharing and streaming applications including eMule
   v0.50a, Thunder v7.9 and PPS TV v3.2.0.  It has been found there are
   some software issues to support IPv6 at this time.  The application
   software would benefit from 464xlat[RFC6877] until the software adds
   IPv6 support.. A SIP based voice call has been tested in LTE mobile



Chen, et al.           Expires September 11, 2014              [Page 11]

Internet-Draft              NAT64 Experience                  March 2014


   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) described in [RFC5245]
   is recommended to be supported for the SIP IPv6 transition.
   [RFC6157] describes both signaling and media layer process, which
   should be followed.  In addition, it may be worth to notice that ICE
   is not only useful for NAT traversal, but also firewall[RFC6092]
   traversal in native IPv6 deployment.

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

                   Table 1: The tested applications
+----------------+----------------------------------------------------+
|     APPs       |            Results and Found Issues                |.
+----------------+----------------------------------------------------+
| Webservice     |Mostly pass, some failure cases due to IPv4 Literals|
+----------------+----------------------------------------------------+
|Instant Message |Mostly fail, software can't support IPv6            |
+----------------+----------------------------------------------------+
|     Games      |Mostly pass for web-based games; mostly fail for    |
|                |standalone games due to the lack of IPv6 support in |
|                |software                                            |
+----------------+----------------------------------------------------+
|  SIP-VoIP      |Fail, due to the lack of NAT64 traversal            |
+----------------+----------------------------------------------------+
|  IPsec-VPN     |Fail, the translated IPsec packets are invalidated  |
+----------------+----------------------------------------------------+
|P2P file sharing|Mostly fail, software can't support IPv6, e.g. eMule|
|and streaming   |Thunder and PPS TV                                  |
+----------------+----------------------------------------------------+
|      FTP       |Pass                                                |
+----------------+----------------------------------------------------+
|     Email      |Pass                                                |
+----------------+----------------------------------------------------+

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] and 5



Chen, et al.           Expires September 11, 2014              [Page 12]

Internet-Draft              NAT64 Experience                  March 2014


   minutes for UDP sessions[RFC4787].  In some cases, NAT resource maybe
   significantly consumed by largely inactive users.  The NAT translator
   and other customers would suffer from service degradation due to port
   consummation by other subscribers using the same NAT64 device.  A
   flexible NAT session control is desirable to resolve the issues.
   PCP[RFC6887] could be a candidate to provide such capability.  A
   NAT64-CGN should integrate with a PCP 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 user experiences, for example 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 offers satisfactory experience once outage
   of primary NAT64 is occurred.  Operators may rightly be concerned
   about the considerable investment required for NAT64 equipment
   relative to low ARPU income.  For example, transport links may cost
   much, because primary NAT64 and backup are normally located at
   different locations, separated by a relatively large distance.
   Additional cost has to be assumed to ensure the connectivity quality.
   However, that may be necessary to some applications, which are delay-
   sensitive and seek session continuity, for example on-line games and
   live-streaming.  Operators may be able to get added-values from those
   services by offering first-class services.  It can be pre-configured
   on the gateway to hot-standby modes depending on subscriber's
   profile.  The rest of other sessions can be covered by cold/warm
   standby.

7.  MTU Considerations

   IPv6 requires that every link in the internet have an Maximum
   Transmission Unit (MTU) of 1280 octets or greater[RFC2460].  However,
   in case of NAT64 translation deployment, some IPv4 MTU constrained
   link will be used in some communication path and 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 fragmentation header in which "M" flag
   equal to 0 and "Fragment Offset" equal 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 risk that all
   the fragments have to be dropped.





Chen, et al.           Expires September 11, 2014              [Page 13]

Internet-Draft              NAT64 Experience                  March 2014


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

   Another approach that potentially avoids this issue is to configure
   IPv4 MTU more than 1260 bytes.  It would forbid the occurrence of PTB
   smaller than 1280 bytes.  Such an operational consideration is hard
   to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged.
   However, it's a feasible approach in NAT64-FE cases, since a IPv4
   network NAT64-FE connected is rather well-organized and operated by a
   IDC operator or content provider.  Therefore, the MTU of IPv4 network
   in NAT64-FE case are strongly recommended to 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
   to the IPv4 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] provides further
   guidance for the ULAs usages.

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

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




Chen, et al.           Expires September 11, 2014              [Page 14]

Internet-Draft              NAT64 Experience                  March 2014


9.  Security Considerations

   This document presents the deployment experiences of NAT64 in CGN and
   FE scenarios.  In general, RFC 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 adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and
   black/white-list to enhance the security by specifying access
   policies.  For example, NAT64-CGN should forbid establish NAT64 BIB
   for incoming IPv6 packets if uRPF in Strict or Loose mode check does
   not pass or whose source IPv6 address is associated to black-lists.

   The stateful NAT64-FE creates state and maps that connection to an
   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 is recommended to
   enable the capabilities of line rate DDOS defense, such as the
   employment of SYN PROXY-COOKIE.  Security domain division is
   necessary as well in this case.  Therefore, Load Balancers could not
   only serve for optimization of traffic distribution, but also prevent
   service from quality deterioration due to security attacks.

   The DNS64 process will potentially interfere with the DNSSEC
   functions[RFC4035], since 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 and Simon Perreault for their helpful
   comments.

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

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





Chen, et al.           Expires September 11, 2014              [Page 15]

Internet-Draft              NAT64 Experience                  March 2014


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

12.  Additional Author List

   The following are extended authors who contributed to the effort:

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

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

13.  References

13.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.






Chen, et al.           Expires September 11, 2014              [Page 16]

Internet-Draft              NAT64 Experience                  March 2014


   [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.






Chen, et al.           Expires September 11, 2014              [Page 17]

Internet-Draft              NAT64 Experience                  March 2014


   [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.  Informative References

   [Alexa]    Alexa, "http://www.alexa.com/topsites", 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. and D. Binet, "Radius Attributes for Stateful
              NAT64", draft-chen-behave-nat64-radius-extension-00 (work
              in progress), July 2013.



Chen, et al.           Expires September 11, 2014              [Page 18]

Internet-Draft              NAT64 Experience                  March 2014


   [I-D.chen-sunset4-cgn-port-allocation]
              Chen, G., Tsou, T., Donley, C., and T. Taylor, "Analysis
              of NAT64 Port Allocation Method", draft-chen-sunset4-cgn-
              port-allocation-03 (work in progress), February 2014.

   [I-D.donley-behave-deterministic-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 in progress), January
              2014.

   [I-D.ietf-softwire-map-deployment]
              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 in progress), October 2013.

   [I-D.ietf-softwire-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
              in progress), February 2014.

   [I-D.ietf-softwire-stateless-4v6-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 in 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. and D. Binet, "Co-existence of both dual-
              stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual-
              ipv6-coexist-01 (work in progress), October 2012.

   [I-D.wing-dhc-dns-reconfigure]
              Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6
              Dynamic Reconfiguration", draft-wing-dhc-dns-
              reconfigure-02 (work in progress), September 2013.






Chen, et al.           Expires September 11, 2014              [Page 19]

Internet-Draft              NAT64 Experience                  March 2014


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

   [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.

Appendix A.  Testing Results of Application Behavior

   We test several application behaviors in a lab environment to
   evaluate the impact when a primary NAT64 is out of service.  In this
   testing, participants are asked to connect a IPv6-only WiFi network



Chen, et al.           Expires September 11, 2014              [Page 20]

Internet-Draft              NAT64 Experience                  March 2014


   using laptops, tablets or mobile phones.  NAT64 is deployed as the
   gateway to connect Internet service.  The tested applications are
   shown in the below table.  Cold standby, warm standby and hot standby
   are taken turn to be tested.  The participants may experience service
   interruption due to the NAT64 handover.  Different interruption
   intervals are tested to gauge application behaviors.  The results are
   illuminated as below.

                  Table 2: The acceptable delay of applications
   +----------------+------------------------+-------------------------+
   |     APPs       | Acceptable Interrupt   |   Session Continuity    |
   |                |        Recovery        |                         |
   +----------------+------------------------+-------------------------+
   | Web Browse     |As maximum as 6s        |  No                     |
   +----------------+------------------------+-------------------------+
   |Http streaming  |As maximum as 10s(cache)|  Yes                    |
   +----------------+------------------------+-------------------------+
   | Gaming         | 200ms~400ms            |  Yes                    |
   +----------------+------------------------+-------------------------+
   |P2P streaming,  | 10~16s                 |  Yes                    |
   |file sharing    |                        |                         |
   +----------------+------------------------+-------------------------+
   |Instant Message |1 minute                |  Yes                    |
   +----------------+------------------------+-------------------------+
   |Mail            |30 seconds              |  No                     |
   +----------------+------------------------+-------------------------+
   |Downloading     |1 minutes               |  No                     |
   +----------------+------------------------+-------------------------+

Authors' Addresses

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

   Email: phdgang@gmail.com












Chen, et al.           Expires September 11, 2014              [Page 21]

Internet-Draft              NAT64 Experience                  March 2014


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

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


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

   Email: xiechf@ctbri.com.cn


   David Binet
   France Telecom-Orange
   Rennes
   35000
   France

   Email: david.binet@orange.com

























Chen, et al.           Expires September 11, 2014              [Page 22]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/