v6ops
Internet Engineering Task Force                                  G. Chen
Internet-Draft                                                    Z. Cao
Intended status: Informational                              China Mobile
Expires: August 4, 2013                                         C. Byrne
                                                            T-Mobile USA January 10, 2014                                         C. Xie
                                                           China Telecom
                                                                D. Binet
                                                   France Telecom
                                                        January 31, Telecom-Orange
                                                           July 09, 2013

                     NAT64 Deployment Considerations
                  draft-ietf-v6ops-nat64-experience-01 Operational Experiences
                  draft-ietf-v6ops-nat64-experience-02

Abstract

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

Status of this 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 August 4, 2013. January 10, 2014.

Copyright Notice

   Copyright (c) 2013 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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  5   3
   3.  NAT64-CGN Deployment  NAT64 Networking Experiences  . . . . . . . . . . . . . . .  5 .   4
     3.1.  NAT64-CGN Networking . . Consideration . . . . . . . . . . . . . . . . .  5   4
     3.2.  High Availability Considerations . . . . . .  NAT64-FE Consideration  . . . . . . .  6
     3.3.  Traceability . . . . . . . . . .   5
   4.  High Availability . . . . . . . . . . . . .  6
     3.4.  Quality of Experience . . . . . . . . .   6
     4.1.  Redundancy Design . . . . . . . . .  7
     3.5.  NAT64-CGN Load Balancer . . . . . . . . . . .   6
     4.2.  Load Balancing  . . . . . .  8
     3.6.  MTU Consideration . . . . . . . . . . . . . . .   8
   5.  Source Address Transparency . . . . .  8
   4.  NAT64-FE Deployment Experiences . . . . . . . . . . . .   9
     5.1.  Traceability  . . .  9
     4.1.  NAT64-FE Networking . . . . . . . . . . . . . . . . . . .   9
     4.2.  Source Address Traceability
     5.2.  Geo-location  . . . . . . . . . . . . . . . 10
     4.3.  DNS Resolving . . . . . . .  10
   6.  Quality of Experience . . . . . . . . . . . . . . . . 10
     4.4.  Load Balancer . . . .  11
     6.1.  Service Reachability  . . . . . . . . . . . . . . . . . .  11
     4.5.  MTU Consideration
     6.2.  Resource Reservation  . . . . . . . . . . . . . . . . . .  11
   7.  MTU Considerations  . . 11
     4.6.  Anti-DDoS/SYN Flood . . . . . . . . . . . . . . . . . . . 11
   5.  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . 11
   6.  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
   7.  13
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  13
   11. Additional Author List  . . . . . . . . . . . . . . . . . . . . 12
   9.  14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  14
     12.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  14
     12.2.  Informative References . . . . . . . . . . . . . . . . . . 13  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 15  18

1.  Introduction

   With

   Now that IANA's global IPv4 address pool was has been exhausted, IPv6 is
   the only sustainable solution for numbering nodes on the Internet.
   Network operators have to deploy IPv6-only networks in order to meet
   the
   numbering needs of the expanding internet without available IPv4 addresses.

   As IPv6 deployment continues, IPv6 networks and hosts will need to
   coexist with IPv4 numbered resources.  The Internet will include
   nodes that are dual-stack, nodes that remain IPv4-only, and nodes
   that can be deployed as IPv6-only nodes.

   Single stack IPv6 network deployment can simplify the network
   provisioning.  Some justifications have been described in
   [I-D.ietf-v6ops-464xlat]. 464xlat
   [RFC6877].  As an example, IPv6-only networks confer connectivity confers some
   benefits to mobile operators employing them. operators.  In the such mobile context, it enables the
   use of a single IPv6 PDP(Packet Data Protocol), Protocol) context or EPS
   (Evolved Packet System) bearer if Long Term Evolution (LTE) network
   is considered, which eliminates significant network cost costs caused by
   doubling the number of PDP count on a mass contexts in some cases and the need of legacy mobile terminals.
   IPv4 addresses to be assigned to customers.  In broadband networks
   overall, it can allow for the scaling of edge-network growth
   decoupled from IPv4 numbering limitations.

   In a transition scenario, an some existing network may rely on the IPv4
   stack networks are likely to be
   IPv4-only configured for quite a long time.  There is also the troublesome trend of access
   network providers squatting on IPv4 address space that they do not
   own.  Allowing for
   interconnection between IPv4-only nodes and IPv6-
   only IPv6-only nodes is a
   critical capability. capability for service continuity.  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.  A translation mechanism based on a
   NAT64[RFC6146] function will [RFC6145]function is likely to be a key element of the internet
   infrastructure supporting such legacy networks.
   Internet for IPv6-IPv4 interoperability.

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

2.  Terminology

   In regards to IPv4/IPv6 translation, [RFC6144] has described a
   framework of enabling networks to make interworking possible between
   IPv4-only
   IPv4 and IPv6-only IPv6 networks.  This document has further categorized
   different NAT64 location function locations and use case. cases.  The principle
   distinction of location is if the NAT64 is located in a NAT64-CGN
   (Carrier Grade NATs) or NAT64-FE (server Front End).

2.  Terminology  The terms of
   NAT-CGN/FE are understood to be a topological distinction indicating
   different features employed in a NAT64 deployment.

   NAT64-CGN:  A NAT64-CGN (Carrier Grade NATs) is placed in an ISP
      network.  IPv6 only subscribers leverage the NAT64-CGN to access
      existing IPv4 internet services.  The ISP as an administrative
      entity takes full control on the IPv6 side, but has limited or no
      control on the IPv4 side.  ISP's should attempt  NAT64-CGN may have to accommodate consider the
      behavior of IPv4 networks
      Internet environment and services. services to make appropriate
      configurations.

   NAT64-FE:  A NAT64-FE (server Front End) is generally a traffic load
      balancer device with
      NAT64 functionalities in a ICP content provider or data center
      network.

3.  NAT64-CGN Deployment Experiences

   A NAT64-CGN deployment scenario is depicted in Figure 1

                                   -----------
                 ----------       //          \\
               //          \\    /             \
              /             +----+              \
             |              |XLAT|               |
             |  An IPv6     +----+  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     +----+  Internet     |  XLAT: IPv6/IPv4
             |              |DNS |               |        Translator
              \             +----+               /  DNS:  DNS64
               \\         //      \             /
                 ---------         \\         //
                                    -----------
                            ====>

        Figure 1: NAT64-CGN Scenario: network within the data center, but only limited influence or
      control over the external IPv6 Network to IPv4 Internet

3.1.  NAT64-CGN network.

3.  NAT64 Networking

   The Experiences

3.1.  NAT64-CGN use case is employed Consideration

   Fixed network operators and mobile operators may locate NAT64 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-only IPv6 users to the IPv4 Internet.  The NAT64 gateway performs protocol translation from
   an IPv6 packet header  With regard to an IPv4 packet header the numbers
   of users and vice versa
   according to the shortage of public IPv4 addresses, stateful NAT64 [RFC6146].  Address translation maps
   IPv6 addresses
   NAT64[RFC6146] is more adapted to perform some maximal sharing of
   public IPv4 addresses and vice versa for return traffic.

   All connections addresses.  The usage of stateless NAT64 can be seen with
   better transparency features
   [I-D.ietf-softwire-stateless-4v6-motivation], while it has to the be
   coordinated with A+P[RFC6346] processes as specified in
   [I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope
   with IPv4 Internet from shortage.

   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.  And, it will help 464xlat
   to automatically discover NAT64 prefix through
   [I-D.ietf-behave-nat64-discovery-heuristic].  Berkeley Internet Name
   Daemon(BIND) software supports the function.  It's important to note
   that DNS64 generates the synthetic AAAA reply when services only
   register A records.  Operators should not expect to access IPv4 parts
   of a dual-stack server using NAT64/DNS64.  NAT64 would forwards all
   the traffic on IPv6 paths if dual-stack servers are targeted.  In
   some sense, it encourages IPv6 transmission and restrains NAT uses
   compared to NAT44(if used), on which all traffic flows have to
   traverse.  Therefore, NAT64 may serve double roles in some cases,
   i.e. a translator and IPv6 forwarder.  Some failure cases may occur
   once NAT64 serves a IPv6 gateway but is configured only with IPv4 on
   WAN links.  We tested on Top100 websites (referring to [Alexa]
   statistics) in such condition. 43% of websites are failed to be
   connected since those websites have both AAAA and A records.  To be
   reliable, it's recommended to enable NAT64 WAN links with dual-stack
   connections in the deployment.

   All connections to IPv4 services from IPv6-only clients must traverse
   the NAT64-CGN.  It is 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
   translates
   translate packets only at or near the network egress.  In many service
   provider networks,  NAT64 is can be
   considered as a feature of the AS boarder.
   This allows consistent attribution and traceability within the
   service provider network.  Meaning, within one network, the packet
   only has one source.  As the packet leaves the network destine for
   another network, the packet source may be translated as needed.

   In mobile networks, various possibilities can be envisaged to deploy
   the NAT64 function.  Whichever option (Autonomous System) border in fixed
   networks.  And, it is selected, the NAT64 function
   will likely to be deployed in an IP node beyond the
   GGSN (Gateway GPRS Support Node) or PDN-GW (Public Data Network-Gateway), i.e. first IP node Network-
   Gateway) in currently
   deployed mobile architectures.

   In a given implementation, NAT64 functionality can be provided by
   either a dedicated device networks or an multifunction directly in the gateway with integrated
   NAT64 functionality.  If NAT64 is integrated into an existing node,
   capacities of existing nods can be potentially limited by itself in some
   situations.  This allows consistent attribution and traceability
   within the new
   functionality, e.g. maximum concurrent connections.  In a mobile
   context, service provider network.  It has been observed that the NAT64 function likely be implemented in a firewall,
   which
   process of correlating log information is the first hop routed problematic from GGSN/PGW.

3.2.  High Availability Considerations

   High Availability (HA) is a major requirement for every service.

   Two mechanisms are typically used to achieve high availability, i.e.
   cold-standby and hot-standby.  Cold-standby systems have synchronized
   configuration and mechanism multiple-
   vendor's equipments due to failover traffic between the hot and
   cold systems such as VRRP [RFC5798] .  Unlike hot-standby, cold-
   standby does not synchronize inconsistent formats of log records.
   Placing NAT64 session state.  This makes cold-
   standby less resource intensive and generally simpler, but it
   requires clients to re-establish sessions when in a fail-over occurs.
   Hot-standby has all the features centralized location may reduce diversity of cold-standby but must also
   synchronize log
   format and simplify the binding information base (BIB).  Given that short
   lived sessions account for most of network provisioning.  Moreover, since NAT64
   is only targeted at serving traffic flows from IPv6 to IPv4-only
   services, the bindings, hot-standby does not
   offer much benefit for those sessions.  Consideration user traffic volume should not be given
   to as high as in a NAT44
   scenario, and therefore, the importance (or lack thereof) of maintaining bindings for long
   lived sessions across failovers.

3.3.  Traceability

   Traceablility is required gateway's capacity in many cases such location may
   not be as identifying malicious
   attacks sources and accounting requirements.  NAT64 devices are
   required to log events like creation and deletion much of translations and
   information about the occupied resources.  There are two different
   demands for traceability,i.e. online a concern or offline.

   o  Regarding the Online requirements, XFF (X-Forwarded-For)
      [I-D.ietf-appsawg-http-forwarded]would be a candidate, it appends
      IPv6 address of subscribers to HTTP headers which is passed on hurdle to
      WEB servers, and deployment.  On the querier server can lookup radius servers for other
   hand, the target subscribers placement in a centralized way would require more strict
   high availability (HA) design.  It would also make geo-location based
   on IPv6 IPv4 addresses included in XFF
      HTTP headers.  X-Forwarded-For rather inaccurate as it is specific to HTTP, requires currently the
      use of an application aware gateway, cannot case for
   NAT44 CGN already deployed in general be applied
      to requests made over HTTPs ISP networks.  More considerations or
   workarounds on HA and cannot be assumed to be preserved
      end-to-end as it may be overwritten by other application-aware
      proxies such as load balancers.

   o  Some potential solutions to online traceability are explore in
      [I-D.ietf-intarea-nat-reveal-analysis].

   o  A NAT64-CGN could also deliver NAT64 sessions (BIB be found at Section4 and STE) to
   Section5 .

   NAT64 could likely co-exist with NAT44 in a
      Radius server by extension of the radius protocol.  Such an
      extension is an alternative solution for online traceability,
      particularly high performance would be required on Radius servers dual-stack network mostly
   because IPv4 private addresses are allocated to customers.  The
   coexistence has already appeared in order mobile networks, in which dual
   stack mobile phones normally initiate some dual-stack PDN/PDP
   Type[RFC6459] to achieve this.

   o  For off-line traceability, syslog might be a good choice.
      [RFC6269] indicates query both IPv4/IPv6 address sharing solutions generally need to
      record and store information for specific periods IPv4 allocated
   addresses are very often private ones.  [RFC6724] always prioritizes
   IPv6 connections regardless of time.  A
      stateful NAT64 whether the end-to-end path is supposed native
   IPv6 or IPv6 translated to manage one mapping per session.  A
      large volume IPv4 via NAT64/DNS64.  Conversely, Happy
   Eyeballs[RFC6555] will direct some IP flows across IPv4 paths.  The
   selection of logs poses a challenge for storage and processing.
      In order to mitigate the issue,
      [I-D.donley-behave-deterministic-cgn]is proposed to pre-allocated IPv4/IPv6 paths may depend on particular implementation
   choices or settings on a group of ports for each specific IPv6 host.  A trade-off among
      address multiplexing efficiency, port randomization
      security[RFC6056] host-by-host basis, and logging storage compression should be
      considered during the planning.  A hybrid mode combining may differ from an
   operator's deterministic scheme.  Our tests verified that hosts may
   find themselves switching between IPv4 and dynamic port assignment was recommended
      regarding IPv6 paths as they access
   identical service, but at different times
   [I-D.kaliwoda-sunset4-dual-ipv6-coexist].  Since the uncertainty of topology on each
   path is different, it may cause unstable user traffic.

3.4. experiences and some
   degradation of Quality of Experience

   NAT64 is providing a translation capability between IPv6 and IPv4
   end-nodes.  In order (QoE) when fallback to provide the reachability between two IP
   address families, NAT64-CGN has to implement appropriate ALGs where
   address translation other
   protocol is not itself sufficient powerful enough for example.  It's also difficult for
   operators to debug the issue and security mechanisms
   do make optimal resource usages on both
   NAT44 and NAT64.  It's desirable to find the solutions that will
   allow introducing IPv6/IPv4 translation service to IPv6-only hosts
   while keeping dual-stack hosts unaffected and IPv4 service unchanged.

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 load
   balancing function.  Load balancers are employed to connect different
   IP family domains, meanwhile distribute workloads across multiple
   domains or internal servers actually.  In some cases, IPv4 addresses
   exhaustion may not be a problem in some IDC's 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.

   o  Some ICPs who already have satisfactory operational experiences
      would adopt single stack IPv6 operations to build up their data
      center network, servers and applications since it allows new
      services delivery without having to integrate consideration of
      IPv4 NAT and address limitations of IPv4 networks.  Stateless
      NAT64[RFC6145]is used to provide services for IPv4-only
      subscribers.  [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 some proxies,
      which are configured to handle incoming IPv6 flows and proxy them
      to IPv4 back-end systems.  Many load balancers have already
      integrated some proxy functionalities.  IPv4 addresses configured
      in the proxy can be multiplexed like a stateful NAT64 performs.  A
      similar challenge exists once increasingly numerous users in IPv6
      Internet access an IPv4 network.  High loads on 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 learn from the experiences and move on to dual-stack or
      IPv6 single stack in a further stage, since the native IPv6 is
      always more desirable than transition solutions.

   [RFC6144] recommends that AAAA records of load-balancers or
   application servers can be directly registered in the authoritative
   DNS servers requiring to populate these servers with corresponding
   AAAA records.  In this case, there is no need to deploy DNS64
   servers.  Those AAAA records can be some native IPv6 addresses or
   some IPv4-converted IPv6 addresses[RFC6052].  The type of IPv6
   address does not give the possibility to nodes to get any information
   about NAT64 presence on communication path and the possibility to
   prefer IPv4 path or the IPv6 path in dual-stack networks.  Using an
   independent sub domain e.g. ipv6exp.xxx.xxx may help 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 mechanism is an
   essential approach to avoid single-point failure and significantly
   increase the network reliability.  It's not render only useful to stateful
   NAT64 cases, but also to stateless NAT64 gateways.

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

   o  Cold standby can't replicate the NAT64 states from the primary
      equipment to the backup.  Administrators switch on the backup
      NAT64 only if the primary NAT64 fails.  As the results, all the
      existing established sessions will be disconnected.  The internal
      hosts are required to re-establish sessions to the external hosts.
      Since the backup NAT64 is manually configured to switch over to
      active NAT64, it may have unpredictable impacts to the ongoing
      services.  Normally, the handover would take several minutes so as
      to wait for the whole process of NAT64 bootstrap loader.

   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 Base (BIB) for 30 million sessions.  In
      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.  Thanks to Bidirectional
      Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay
      of only 35ms for 30 million sessions handover was observed during
      testing.  In some sense, it could guarantee the session continuity
      for every service.  In order to timely transmit states
      information, operators may have to deploy extra transport links
      between primary NAT64 and distant backup.

   In general, cold-standby and warm-standby is simpler and less
   resource intensive, but it infeasible. e.g.  FTP-ALG[RFC6384], RSTP-ALG, H.323-
   ALG,etc.  It requires clients to re-establish sessions
   when a fail-over occurs.  Hot standby doubles resource's consumption
   to synchronize the states, but it achieve seamless handover.  The
   consideration of redundancy mode for stateless NAT64 is simple,
   because it doesn't have to consider time consuming for states
   maintenance.  The warm standby is sufficient for stateless NAT64.  In
   regards to stateful NAT64, it maybe useful to investigate performance
   tolerance of applications and the traffic characteristics in a
   particular network.  The following table is trying to evaluate user
   experience from a lab testing.

                  Table 1: 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            | 10~16s                 |  Yes                    |
   +----------------+------------------------+-------------------------+
   |Instant Message |1 minute                |  Yes                    |
   +----------------+------------------------+-------------------------+
   |Mail            |30 seconds              |  No                     |
   +----------------+------------------------+-------------------------+
   |Downloading     |1 minutes               |  No                     |
   +----------------+------------------------+-------------------------+

   Our statistics in a mobile network shown that almost 91.21% of amount
   of traffic is accounted by browsing services.  Those services don't
   require session continuity.  The handover time of warm standby is
   qualified to the delay tolerance.  Hot-standby does not offer much
   benefit for those sessions on this point.  In a fixed network, HTTP
   streaming, p2p and online games would be the major
   traffic[Cisco-VNI].  Consideration should be noted that ALGs may impact given to the importance
   of maintaining bindings for those sessions across failovers.
   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 with different
   synthetic responses for limited traffic.  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 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 equipments don't implement load balancer functions on a
      board card.  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.  With the performance absence of DNS64, internal
      hosts could learn multiple IPv6 prefixes through the approaches
      defined in[I-D.ietf-behave-nat64-discovery-heuristic] 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 box instance.  Stateful NAT64s require a
      deterministic pattern to some extent.  ISPs as well 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 content providers might
   choose identifying malicious
   attacks sources and accounting requirements.  Operators are asked to avoid situations where
   record the imposition NAT64 log information for specific periods of an ALG might be
   required.  At time.  In
   our lab testing, the same time, it is also important log information from 200,000 subscribers have
   been collected from a stateful NAT64 gateway for 60 days.
   Syslog[RFC5424] has been adopted to remind customers transmit log message from NAT64
   to a log station.  Each log message contains transport protocol,
   source IPv6 address:port, translated IPv4 address: port and application developers
   timestamp.  It takes almost 125 bytes long in ASCII format.  It has
   been verified that IPv6 end-to-end usage does not
   require ALG imposition the volume of recorded information reach up to
   42.5 terabytes in the raw format and therefore results 29.07 terabytes in a better overall user
   experience.

   Session status normally is managed by a static life-cycle.  In some
   cases, NAT resource maybe significantly consumed by largely inactive
   users.  The NAT translator compact
   format.  Operators have to build up dedicated transport links,
   storage system and other customers would suffer from
   service degradation due servers for the purpose.  There are also several
   implementations to port consummation by other subscribers
   using mitigate the same issue.  For example, stateful NAT64 device.  A flexible NAT session control
   could dynamically assign a port range to each subscriber or perform
   static port-range allocations as
   [I-D.donley-behave-deterministic-cgn] proposed.  Those methods can
   change log granularity from per-session to per-customer.  The
   recorded log volume can be reduced to 40.6 gigabytes accordingly.
   However, the IPv4 multiplexing efficiency is
   desirable also decreased regarding
   to resolve those methods.  For example, the issues.  PCP[I-D.ietf-pcp-base] utilization ratio of public IPv4
   address is dropped approximately to 75% when sized 400 ports range
   allocated to each device according to our statistics.  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].Basically, the decision
   depends on usable IPv4 resource and investments of log systems.

5.2.  Geo-location

   IP addresses are usually used as inputs to geo-location services.
   The use of address sharing will prevent these systems from resolving
   the location of a
   candidate 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 such capability.  A NAT64-CGN should integrate
   with a PCP server, to allocate available IPv4 address/Port resources.
   Resources could be assigned sub-optimal
   substitution to PCP clients solve the problem of host identification, in
   particular it may not today solve problems with source identification
   through PCP MAP/PEER mode.
   Such an ability should also be considered translation.  The following lists current practices to upgrade user
   experiences,
   mitigate the issue.

   o  Operators who adopt NAT64-FE may leverage the application layer
      proxies, e.g. assigning different sizes of port ranges XFF (X-Forwarded-For)
      [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 queried server can lookup Radius servers for
   different subscribers.  Such a mechanism the
      target subscribers based on IPv6 addresses included in XFF HTTP
      headers.  XFF is also helpful to minimize
   terminal battery consumption and reduce the number of keepalive
   messages to be sent by terminal devices.

3.5.  NAT64-CGN Load Balancer de facto standard which has been integrated
      in most Load balancers are an essential tool Balancers.  Therefore, it may be superior to avoid use in a
      NAT-FE environment.  In the issue of single
   points of failure and add additional scale.  It downsides, XFF is potentially
   important specific to employ load-balancing considering HTTP.
      It restricts the usages so that deployment of
   multiple NAT64 devices.  Load balancers are required the solution can't be applied to achieve some
   service continuity and scale
      requests made over HTTPs.  This makes geo-location problematic for customers.
   [I-D.zhang-behave-nat64-load-balancing] discusses several ways of
   achieving NAT64 load balancing, including anycast
      HTTPs based policy and
   prefix64 selection services.

   o  The NAT64-CGN equipments may not implement XFF.  Geo-location
      based policy, either implemented via
   DNS64[RFC6147] or Prefix64 assignments.  Since DNS64 on shared IPv4 address is normally co-
   located with NAT64 rather inaccurate in some scenarios, it could be leveraged that case.
      It's desirable to
   perform offer geo-location system more information, for
      example port number to retrieve the load balance.  For traffic which does not require a DNS
   resolution, prefix64 assignment based
   on[I-D.ietf-behave-nat64-learn-analysis] could be adopted.

3.6.  MTU Consideration internal IPv6 requires that every link address, which
      has meaning in the internet global scale.  We have an 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 message, reporting a Next-Hop MTU less than
   1280.  The result would be that IPv6 allows packets to contain a
   fragmentation header, without the packet being fragmented into
   multiple pieces.  [I-D.ietf-6man-ipv6-atomic-fragments] discusses how
   this situation could be exploited by an attacker investigated to perform
   fragmentation-based attacks, deliver
      NAT64 BIBs and also proposes an improved handling
   of such packets.  It required enhancements on protocol level, which
   might imply potential upgrade/modifications Session Table Entrys (STEs) to a Radius
      server[I-D.chen-behave-nat64-radius-extension], since current geo-
      location systems rely on behaviors a Radius database to deployed
   nodes. inspect location
      information, for example the information provided in [RFC5580].
      Those methods could convey original source address through same
      message bus.  Another approach that potentially avoids this issue is to
   configure IPv4 MTU>=1260.  It would forbid the occurrence of
   PTB<1280.  However, such an operational consideration is hard to
   universally apply ask NAT64-CGN providing
      application aware gateway to the legacy "IPv4 Internet".

4.  NAT64-FE Deployment Experiences

   The NAT64-FE Scenario is depicted in Figure 2
                  --------
                //        \\        ----------
               /            \     //          \\
              /             +----+              \
             |              |XLAT|               |
             |  The IPv6    +----+  An IPv4      |
             |  Internet    +----+  Network      |  XLAT: IPv4/IPv6
             |  /Network    |DNS |               |        Translator
              \             +----+              /   DNS:  DNS64
               \            /     \\          //
                \\        //        ----------
                  --------
                             ====>

    Figure 2: NAT64-FE Scenario: insert IPv6 Internet/Network to IPv4 Network

4.1.  NAT64-FE Networking

   There are plenty source addresses.
      However, that may introduce complexity and performance
      degradation.

6.  Quality of practices to equip load balancer with Experience

6.1.  Service Reachability

   NAT64 at
   front of servers.  Two different cases appeared in the NAT64-FE
   networking.

   o  Some content providers who has is providing a wealth of translation capability between IPv6 experiences
      consider IPv6-only strategy to serve customers since it allows new
      services delivery without having to integrate consideration of
      IPv4 NAT and address limitations of IPv4 networks.  Whereas they
      have
   end-nodes.  In order to provide some IPv4 service continuity to their customers,
      stateless IP/ICMP Translation (SIIT) [RFC6145]has been used the reachability between two IP
   address families, NAT64-CGN has to
      continue 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 services FTP-
   ALG[RFC6384].  NAT64-FEs may have functional richness on Load
   Balancer, for IPv4 subscribers.

   o  ICPs who example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have insufficient IPv6 incentive likely prefer short-term
      alternatives to provide IPv6 connectivity due to the widespread
   been supported.  It should be noted that ALGs may impact of supporting IPv6 within the
   performance on a ICP environment.  A stateful NAT64 has been located at front of servers.  It could
      simultaneously facilitate box to some extent.  ISPs as well as content
   providers might choose to avoid situations where the IPv6 accessibility and conservation imposition of IPv4 servers.  [I-D.ietf-v6ops-icp-guidance]has described the
      cases, in which an HTTP proxy can readily
   ALG might be configured required.  At the same time, it is also important to handle
      incoming connections over
   remind customers and application developers that IPv6 end-to-end
   usage does not require ALG imposition and to proxy them to therefore results in a server over
      IPv4.

   For first case, [I-D.anderson-siit-dc]has provided further
   descriptions and guidelines.  This document
   better overall user experience.

6.2.  Resource Reservation

   Session status normally is addressed to second
   case.  An administrator managed by a static timer.  For example,
   the value of the IPv4 network needs to "established connection idle-timeout" for TCP
   sessions must not be cautious less than 2 hours 4 minutes[RFC5382] and
   aware of the operational issues in the case since 5
   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 native IPv6 same NAT64 device.  A
   flexible NAT session control is
   always more desirable than transition solutions.

   One potential challenge is stateful NAT64-FE facing IPv6 Internet, in
   which to resolve the issues.
   PCP[RFC6887] could be a significant number of IPv6 users may initiate connections.
   When increasingly numerous users in IPv6 Internet access an IPv4
   network, scalability concerns(e.g. additional latency, candidate to provide such capability.  A
   NAT64-CGN should integrate with a single point
   of failure, PCP server, to allocate available
   IPv4 pool exhaustion, etc) 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 apt also
   helpful to minimize terminal battery consumption and reduce the
   number of keep-alive messages to be applied. 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
   given off-the-shelf NAT64-FE, those challenges should relatively large distance.
   Additional maintenance has to be seriously
   assessed.  Potential issues should spent to ensure the connectivity
   quality.  However, that may be properly identified.

   Following subsections described several considerations necessary to stateful
   NAT64-FE case.  For operators who some applications, which
   are delay-sensitive and seek a clear precedent session continuity, for
   operating reliable IPv6-only services, it should example on-line
   games and live-streaming.  Operators may be well noted that
   the usage is problematic.

4.2.  Source Address Traceability

   IP addresses are usually used as input able to geo-location services.  The
   use of address sharing will prevent these systems get added-values
   from resolving those services by offering first-class services.  It can be pre-
   configured on the
   location of a host based gateway to hot-standby modes depending on IP address alone.  Applications that
   assume such geographic information may not work as intended.
   subscriber's profile.  The
   possible solutions listed at section 3.3 intended to bridge rest of other sessions can be covered by
   cold/warm standby.

7.  MTU Considerations

   IPv6 requires that every link in the gap. internet have an Maximum
   Transmission Unit (MTU) of 1280 octets or greater[RFC2460].  However, the analysis reveals those solutions can't
   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 optimal
   substitution Next-Hop MTU less than 1280 bytes.  The result would be
   that IPv6 allows packets to solve the problem of host identification, in
   particular it does not today mitigate problems with source
   identification through translation.  That makes NAT64-FE usage
   becoming contain a unappealing approach, if customers require source address
   tracking.

   For fragmentation header, without
   the operators, who 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 deployed NAT64-FE approach, queued with the source
   address same set of {IPv6
   Source Address, IPv6 Destination Address, Fragment Identification}.
   If the request is obscured without the source address mapping
   information previously obtained.  It's superior to present mapping
   information directly to applications.  Some application layer proxies
   e.g.  XFF (X-Forwarded-For) , can convey this information in-band.
   Another approach NAT64 box is to ask application coordinating the information compliant with NAT logging.  But that [RFC5722], there is not sufficient, since risk that all
   the applications
   itself wants fragments have to know the original source address from an application
   message bus.  The logging information may be used dropped.

   [RFC6946] discusses how this situation could be exploited by administrators
   offline an
   attacker to inspect use behavior and preference analysis, perform fragmentation-based attacks, and accurate
   advertisement delivery.

4.3.  DNS Resolving

   In the case also proposes an
   improved handling of NAT64-FE, it is recommended such packets.  It required enhancements on NAT64
   gateway implementations to isolate packet's processing.  NAT64 should
   follow the
   recommendations in [RFC6144].  There is no need for the DNS to
   synthesize AAAA from A records, since static AAAA records can be
   registered in the authoritative DNS for a given domain to represent
   these IPv4-only hosts.  How recommendation and take steps to design the FQDN for prevent the IPv6 service
   is out-of-scope risks of
   fragmentation.

   Another approach that potentially avoids this document.

4.4.  Load Balancer

   Load balancing on NAT64-FE has a couple of considerations.  If
   dictated by scale or availability requirements traffic should be
   balanced among multiple NAT64-CE devices.  One point to be noted issue is
   that synthetic AAAA records may be added directly in authoritative
   DNS. load balancing based on DNS64 synthetic resource records may not
   work in those cases.  Secondly, NAT64-FE could also serve as the load
   balancer for to configure
   IPv4 backend servers.  There are also some ways of load
   balance for MTU more than 1260 bytes.  It would forbid the cases, where load balancer is placed in front occurrence of
   NAT64-FE.

4.5.  MTU Consideration

   As compared PTB
   smaller than 1280 bytes.  Such an operational consideration is hard
   to universally apply to the MTU consideration legacy "IPv4 Internet" NAT64-CGN bridged.
   However, it's a feasible approach in NAT64-CGN, 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.  Since a
   IPv4 network is normally operated by a particular administrative
   entity, it should take steps to prevent 1260
   bytes.

8.  Security Considerations

   This document presents the risk deployment experiences of fragmentation
   discussed NAT64 in [I-D.ietf-6man-ipv6-atomic-fragments].

4.6.  Anti-DDoS/SYN Flood

   For every incoming new connection 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 Internet, the 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 DDoS limitation mechanism, the
   NAT64-FE is exposed to attacks.  With service provisioning, attacks
   have the potential could also deteriorate service quality.  One
   consideration in internet content providers is place a L3 load
   balancer with capable of line rate DDOS defense, such as the
   employment of SYN PROXY-COOKIE.  Security domain division is
   necessary in this case.  Load Balancers could not only serve for
   optimization of traffic distribution, but also serve as a DOS
   mitigation device.

5.  Security Considerations

   This document presents the deployment experiences of NAT64 in CGN and
   FE scenario, some security considerations are described in detail
   regarding to specific NAT64 mode in section 3 and 4.  In general, RFC
   6146[RFC6146] provides TCP-tracking, address-dependent filtering
   mechanisms to protect NAT64 from DDOS.  In NAT64-CGN cases, ISP also
   could adopt uRPF and black/white-list the
   NAT64-FE is exposed to enhance attacks.  Load Balancer is recommended to
   enable the security by
   specifying access policies.  For example, NAT64-CGN should forbid
   establish NAT64 BIB for incoming IPv6 packets if URPF (Strict or
   Loose mode) check does not pass or whose source IPv6 address capabilities of line rate DDOS defense, such as the
   employment of SYN PROXY-COOKIE.  Security domain division is
   associated
   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 black-lists.

6. security attacks.

9.  IANA Considerations

   This memo includes no request to IANA.

7.

10.  Acknowledgements

   The authors would like to thank Jari Arkko, Dan Wing, Remi Despres,
   Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum and Beijnum, Philip
   Matthews and Randy Bush for their helpful comments.

   Many thanks to Wesley George and Satoru Matsushima for their 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.

8.

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

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

9.

12.  References
9.1.

12.1.  Normative References

   [I-D.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R.,

   [I-D.ietf-appsawg-http-forwarded]
              Petersson, A. and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-29 M. Nilsson, "Forwarded HTTP Extension",
              draft-ietf-appsawg-http-forwarded-10 (work in progress), November
              October 2012.

   [I-D.ietf-behave-nat64-discovery-heuristic]
              Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
              the IPv6 Prefix Used for IPv6 Address Synthesis", draft-
              ietf-behave-nat64-discovery-heuristic-17 (work in
              progress), April 2013.

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

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

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

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

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

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

   [I-D.chen-sunset4-cgn-port-allocation]
              Chen, G., "Analysis of NAT64 Port Allocation Method",
              draft-chen-sunset4-cgn-port-allocation-01 (work in
              progress), February 2013.

   [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-05 draft-donley-
              behave-deterministic-cgn-05 (work in progress), January
              2013.

   [I-D.ietf-6man-ipv6-atomic-fragments]
              Gont, F., "Processing of IPv6 "atomic" fragments",
              draft-ietf-6man-ipv6-atomic-fragments-03 (work in
              progress), December 2012.

   [I-D.ietf-appsawg-http-forwarded]
              Petersson, A.

   [I-D.ietf-softwire-4rd]
              Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
              M. Nilsson, "Forwarded HTTP Extension",
              draft-ietf-appsawg-http-forwarded-10 (work in progress),
              October 2012.

   [I-D.ietf-behave-nat64-learn-analysis]
              Korhonen, J. and T. Savolainen, "Analysis of solution
              proposals for hosts to learn NAT64 prefix",
              draft-ietf-behave-nat64-learn-analysis-03 Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
              Solution (4rd)", draft-ietf-softwire-4rd-05 (work in
              progress), March 2012.

   [I-D.ietf-intarea-nat-reveal-analysis]
              Boucadair, April 2013.

   [I-D.ietf-softwire-map-deployment]
              Sun, Q., Chen, M., Touch, J., Levis, P., Chen, G., Tsou, T., and R. Penno,
              "Analysis S. Perreault,
              "Mapping of Solution Candidates to Reveal a Host
              Identifier (HOST_ID) in Shared Address Deployments",
              draft-ietf-intarea-nat-reveal-analysis-04 and Port (MAP) - Deployment
              Considerations", draft-ietf-softwire-map-deployment-01
              (work in progress), August 2012.

   [I-D.ietf-v6ops-464xlat]
              Mawatari, M., Kawashima, M., February 2013.

   [I-D.ietf-softwire-map-t]
              Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and C. Byrne, "464XLAT:
              Combination
              T. Murakami, "Mapping of Stateful Address and Stateless Translation",
              draft-ietf-v6ops-464xlat-09 Port using
              Translation (MAP-T)", draft-ietf-softwire-map-t-02 (work
              in progress),
              January July 2013.

   [I-D.ietf-v6ops-icp-guidance]
              Carpenter, B.

   [I-D.ietf-softwire-stateless-4v6-motivation]
              Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
              Borges, I., and S. Jiang, "IPv6 Guidance G. Chen, "Motivations for Internet
              Content and Application Service Providers",
              draft-ietf-v6ops-icp-guidance-05 Carrier-side
              Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-
              softwire-stateless-4v6-motivation-05 (work in progress),
              January 2013.

   [I-D.zhang-behave-nat64-load-balancing]
              Zhang, D., Xu, X.,
              November 2012.

   [I-D.kaliwoda-sunset4-dual-ipv6-coexist]
              Kaliwoda, A. and M. Boucadair, "Considerations on
              NAT64 Load-Balancing",
              draft-zhang-behave-nat64-load-balancing-03 D. Binet, "Co-existence of both dual-
              stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual-
              ipv6-coexist-01 (work in progress), July 2011. October 2012.

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

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

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269, June
              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.

Authors' Addresses

   Gang Chen
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: phdgang@gmail.com

   Zhen Cao
   China Mobile
   53A,Xibianmennei Ave.,
   Xuanwu District,
   Beijing  100053
   China

   Email: caozhen@chinamobile.com

   Cameron Byrne
   T-Mobile USA
   Bellevue
   Washington  98105
   USA

   Email: cameron.byrne@t-mobile.com

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

   Email: xiechf@ctbri.com.cn
   David Binet
   France Telecom Telecom-Orange
   Rennes
   35000
   France

   Email: david.binet@orange.com