Skip to main content

NAT64 Operational Experiences
draft-chen-v6ops-nat64-experience-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Gang Chen , Zhen Cao , Cameron Byrne , Chongfeng Xie , David Binet
Last updated 2012-07-04
Replaces draft-chen-v6ops-nat64-cpe
Replaced by draft-ietf-v6ops-nat64-experience, draft-ietf-v6ops-nat64-experience, draft-ietf-v6ops-nat64-experience, draft-ietf-v6ops-nat64-experience, RFC 7269
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chen-v6ops-nat64-experience-02
Internet Engineering Task Force                                  G. Chen
Internet-Draft                                                    Z. Cao
Intended status: Informational                              China Mobile
Expires: January 5, 2013                                        C. Byrne
                                                            T-Mobile USA
                                                                  C. Xie
                                                           China Telecom
                                                                D. Binet
                                                          France Telecom
                                                           July 04, 2012

                     NAT64 Operational Experiences
                  draft-chen-v6ops-nat64-experience-02

Abstract

   This document summarizes some stateful NAT64 deployment scenarios and
   operational experiences for NAT64-CGN and NAT64-CE.

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 January 5, 2013.

Copyright Notice

   Copyright (c) 2012 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

Chen, et al.             Expires January 5, 2013                [Page 1]
Internet-Draft              NAT64 Experience                   July 2012

   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  NAT64-CGN Deployment Experiences . . . . . . . . . . . . . . .  4
     3.1.  NAT64-CGN Networking . . . . . . . . . . . . . . . . . . .  5
     3.2.  High Availability Consideration  . . . . . . . . . . . . .  6
     3.3.  Traceability . . . . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Quality of Experience  . . . . . . . . . . . . . . . . . .  7
     3.5.  Load Balance . . . . . . . . . . . . . . . . . . . . . . .  8
     3.6.  MTU Consideration  . . . . . . . . . . . . . . . . . . . .  8
   4.  NAT64-CE Deployment Experiences  . . . . . . . . . . . . . . .  8
     4.1.  NAT64-CE Networking  . . . . . . . . . . . . . . . . . . .  9
     4.2.  Anti-DDoS/SYN Flood  . . . . . . . . . . . . . . . . . . . 10
     4.3.  User Behavior Analysis . . . . . . . . . . . . . . . . . . 10
     4.4.  DNS Resolving  . . . . . . . . . . . . . . . . . . . . . . 10
     4.5.  Load Balance . . . . . . . . . . . . . . . . . . . . . . . 10
     4.6.  MTU Consideration  . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  Additional Author List . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Chen, et al.             Expires January 5, 2013                [Page 2]
Internet-Draft              NAT64 Experience                   July 2012

1.  Introduction

   With fast developments of global Internet, the demands for IP
   addresses are rapidly increasing.  IANA announced that the global
   IPv4 address pool has been exhausted on February 3, 2011.  IPv6 is
   the only sustainable and perennial solution for numbering nodes on
   the Internet.  Network operators have to accelerate the process of
   deploying IPv6 networks in order to meet the numbering needs of
   expanding internet without available IPv4 addresses.

   As IPv6 deployments progress, IPv6 will coexist with IPv4.  The
   Internet will include nodes that are IPv4-only, IPv6-only, and nodes
   that are dual-stack with IPv4 and IPv6.  As IPv6 deployment
   progresses it may be simpler for operators to employ a single-version
   network, since deploying both IPv4 and IPv6 protocol in parallel
   would costs more than managing IPv6-only network.  In a dual stack
   architecture, operators have to maintain double management interfaces
   and operational support system .  Moreover, some additional efforts
   should be paid for troubleshooting.

   On the other hand, IPv6 could simplify the network provisioning.
   Some justification has described in [I-D.ietf-v6ops-464xlat], IPv6-
   only network is likely superior for operators to employ.  In mobile
   contexts, it could enable single IPv6 PDP, which eliminates
   significant network cost caused by doubling the PDP count on a mass
   of legacy mobile terminals.  In broadband network, it could help to
   scale edge network growth decoupled with IPv4 limitation.

   With network transition, a significant part of network rely on IPv4
   stack for a long time.  The interconnection between IPv4-only nodes
   and IPv6-only nodes is a critical capability.  Given that widespread
   dual-stack deployments have not been materialized over the last 10
   years, it is translation mechanism based on obvious that
   NAT64[RFC6146] function will be a key element of the going-forward
   internet infrastructure.

   [RFC6036] reported at least 30% operators plan to run some kind of
   translator (presumably NAT64/DNS64).  Operators would expect to get
   more NAT64 deployment experiences.  A very good example as [RFC6586]
   documented show the benefits for operational communities.  Compared
   to it, this document is more specific on NAT64 network planning.

   Regarding the IPv4/IPv6 translation, [RFC6144] has described a
   framework enabling networks make interworking possible between IPv4-
   only and IPv6-only networks.  There are three scenarios "An IPv6
   Network to the IPv4 Internet", "The IPv6 Internet to an IPv4 Network"
   and "An IPv6 Network to an IPv4 Network" where NAT64 function is
   relevant.  Since the scenario of "The IPv6 Internet to the IPv4

Chen, et al.             Expires January 5, 2013                [Page 3]
Internet-Draft              NAT64 Experience                   July 2012

   Internet" seems the ideal case for inter-network translation
   technology, this document has focused on the three cases and
   categorized different NAT64 location and usages, depending if the
   NAT64 is located in a NAT64-CGN and NAT64-CE.  Therein, NAT64-CGN is
   corresponding to the scenario "IPv6 Network to IPv4 Internet".
   NAT64-CE is for "IPv6 Internet to IPv4 Network" and "IPv6 Network to
   IPv4 Network" respectively.  Based on different NAT64 modes,
   different considerations have been elaborated for ISPs to facilitate
   NAT64 deployments.

   The purpose of this document is to summarize deployment experience of
   several operators and content providers regarding NAT64.  The reader
   of this document can get the information for their possible
   deployment of NAT64 in future.  Whether the audiences take the
   experience as their deployment guidance is up to them, not the
   purpose of this document.

2.  Terminology

   The terms of NAT-CGN/CE is to be understood as a topological
   qualifier to indicate different features for NAT64 deployment.

   NAT64-CGN:  A NAT64-CGN is placed in ISP network and managed by an
      administrative entity, e.g. operators.  From an administrator
      view, NAT64-CGN usually forwards outbound traffic heading to IPv4
      realm.  IPv4 services in large scale could leverage the NAT64- CGN
      node to serves ISP's subscribers with IPv6-enable services.  ISP
      as an administrative entity takes full control on IPv6 sides but
      has limited or no control on IPv4 sides.  Therefore, ISP should
      accommodate the predominant IPv4 networks and guarantee
      compatibilities for IPv4 services in wild.

   NAT64-CE:  A NAT64-CE is placed at the edge of customer network, e.g.
      a network operated by an enterprise or Internet data center.
      NAT64-CE makes IPv4 services in small/medium scale accessible for
      the IPv6 only users.  An administrative entity usually operates a
      IPv4 network and take IPv6 access as a common infrastructure.
      Since the services have been run at customer network scale,
      NAT64-CE should only take care of particular types.

3.  NAT64-CGN Deployment Experiences

   The NAT64-CGN Scenario is depicted in Figure 1

Chen, et al.             Expires January 5, 2013                [Page 4]
Internet-Draft              NAT64 Experience                   July 2012

                                   -----------
                 ----------       //          \\
               //          \\    /             \
              /             +----+              \
             |              |XLAT|               |
             |  An IPv6     +----+  The IPv4     |
             |  Network     +----+  Internet     |  XLAT: IPv6/IPv4
             |              |DNS |               |        Translator
              \             +----+               /  DNS:  DNS64
               \\         //      \             /
                 ---------         \\         //
                                    -----------
                            ====>

        Figure 1: NAT64-CGN Scenario: IPv6 Network to IPv4 Internet

3.1.  NAT64-CGN Networking

   NAT64-CGN case is focusing on connecting IPv6-only users with IPv4
   Internet.  NAT64 performs protocol translation from an IPv6 packet
   header to an IPv4 packet header and vice versa is performed according
   to the Stateful NAT64 [RFC6146].  Address translation maps IPv6
   addresses to IPv4 addresses and vice versa.

   Given that all connections to the IPv4 Internet from IPv6-only
   clients must traverse the NAT64, the NAT64 should be located close to
   the IPv4 peering points to reduce unnecessary backhaul costs and
   latency.  It is advantageous for troubleshooting and traffic
   engineering to maintain the IPv6 traffic native for as long as
   possible within an access network and only translate at the network
   border.Traffic patterns as well as techno-economics studies have to
   be carried out in order to define the optimized location for the
   NAT64 function.  Technical considerations, as detailed in this
   section have also to be considered for location selection.

   Coming to a real practice in broadband access network, NAT64
   functionalities could be located on BNG(Broadband Network Gateway) or
   Core Router depending on scale of IPv6-enable network.  Considering
   mobile networks, various possibilities can be envisaged to deploy
   some NAT64 functions.  Whatever the retained option, the NAT64
   function will be deployed beyond the GGSN(Gateway GPRS Support Node)
   or PDN-GW(Public Data Network-Gateway), i.e. first IP nodes in
   current mobile architectures.

   From implementation views, NAT64 functionalities could be served by
   either a dedicated GW or an existing GW integrated with NAT64
   functionality.  In standalone NAT64, NAT64-CGN is placed in a side of

Chen, et al.             Expires January 5, 2013                [Page 5]
Internet-Draft              NAT64 Experience                   July 2012

   BNG or CR.  The deployment has few impacts to a given network, which
   results in a low OPEX.  On the other side, an embedded NAT64 is
   integrated with existing GW, it requires relative lower investment,
   i.e. lower CAPEX.  However, capacities of existing GW would be
   restricted by the inserted functionality.  It likely requires a new
   round of network planning, which would cause high OPEX.  In a mobile
   context, NAT64 function can be co-located with GGSN/PDN-GW or it can
   be embedded in existing FW/NAT44 already deployed or the function can
   be collocated in existing routers.  Whatever the solution retained
   for the co-location option, impacts on existing services and legal
   obligations have to be assessed.  More discussion can be found at
   following sub-sections.

   The different deployment modes would correspond to specific use
   cases, in which ISP should consider different perspectives, e.g.
   traffic model, investment, network evolution, etc.

3.2.  High Availability Consideration

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

   Two mechanisms are likely to be used to achieve high reliability,
   i.e. cold-standby and hot-standby.  Cold-standby has synchronized
   configuration and mechanism to failover traffic between the hot and
   cold systems such as VRRP [RFC5798] .  Unlike hot-standby, cold-
   standby does not synchronize NAT64 session state.  This makes cold-
   stanby less resource intensive and generally simpler, but it requires
   clients to re-establish sessions when a fail-over occurs.  Hot-stanby
   has all the features of cold-standby but must also synchronize the
   binding information base (BIB).  Considering the most common Internet
   traffic type is short lived sessions, hot-standby does not offer much
   benefit unless long lived sessions are common and the cost is
   justified.

3.3.  Traceability

   Traceablility is required in many cases to identify an attacker or a
   host that launchs malicious attacks and/or for various other
   purposes, such as accounting requirements.  NAT64 devices are
   required to log events like creation and deletion of translations and
   information about the occupied resources.  There are two different
   demands for traceability,i.e. online or offline.

   o  Regarding the Online requirements, XFF (X-Forwarded-For)
      [I-D.petersson-forwarded-for]would be a candidate, it appends IPv6
      address of subscribers to HTTP headers which is passed on to WEB
      servers, and the querier server can lookup radius servers for the

Chen, et al.             Expires January 5, 2013                [Page 6]
Internet-Draft              NAT64 Experience                   July 2012

      target subscribers based on IPv6 addresses included in XFF HTTP
      headers.  Some other solutions, as described in
      [I-D.ietf-intarea-nat-reveal-analysis].NAT64-CGN could also
      deliver NAT64 session (BIB and STE) to Radius server by some
      extent of radius protocol extension.  That is an alternative
      solution for online traceability, but high performance is required
      on Radius servers .

   o  For off-line traceability, syslog might be a good choice.
      [RFC6269] indicates address sharing solutions must record and
      store information for specific period.  Stateful NAT64 is supposed
      to manage one mapping per session.  That would raise a challenge
      for storage and data processing.  In order to mitigate the issue,
      [I-D.donley-behave-deterministic-cgn]proposed to pre-allocated a
      group of ports for each specific IPv6 host.  A trade-off among
      address multiplexing efficiency, port randomization
      security[RFC6056] and logging storage compression should be
      considered during the planning.  A hybrid mode combining
      deterministic and dynamic port assignment was recommended
      regarding the uncertainty of user traffic mode.

3.4.  Quality of Experience

   NAT64 is providing some translation capability between IPv6 and IPv4
   end-nodes.  In order to provide the reachability between two IP
   address families, NAT64-CGN has to implement the appropriate ALGs,
   e.g.  FTP-ALG[RFC6384], RSTP-ALG, H.323-ALG,etc.  It should be noted
   that such ALG implementation may impact the performance on a NAT64
   box in some extent.  Therefore, ISPs as well as content providers
   should avoid ALG requisition, when they design behaviors of the
   client and server.  They have to make sure that contents are
   reachable thanks to native IPv6 connectivity.  At the same time, it
   is also important to remind customers that IPv6 end-to-end does not
   required ALGs and therefore that provides the best experience.

   The service experiences also should be optimized regarding stateful
   NAT process.  To be specific, session status normally is managed by a
   static lifetime cycle.  In some cases, NAT resource maybe suffered
   from significant inactive users.  NAT and beyond customers can also
   suffer from service degradation because of number of ports
   consummation by other subscribers using the same NAT64 device.  A
   flexible NAT session control is desirable to resolve the issues.
   PCP[I-D.ietf-pcp-base] could be a candidate to provide such
   capability.  In the case, NAT64-CGN should integrate with PCP server,
   depending on which available IPv4 address/Port could be assigned to
   PCP client through PCP MAP/PEER mode.  Such abilities should also be
   considered to upgrade user experiences, e.g. assigning different
   sizes of port ranges for different subscribers.Such mechanism is also

Chen, et al.             Expires January 5, 2013                [Page 7]
Internet-Draft              NAT64 Experience                   July 2012

   helpful to minimize terminal battery consumption reducing the number
   of keepalive messages to be sent by terminal devices.

3.5.  Load Balance

   Load balance is an essential ability to avoid the issue of single
   point of failure and add the feature of linear scalability.  It is
   important to achieve load balancing between these different devices
   considering that deployment of multiple NAT64 devices is required to
   achieve some service continuity and some QoE for the customers.
   [I-D.zhang-behave-nat64-load-balancing] discusses several ways of
   achieving NAT64 load balancing, including anycast based policy and
   prefix64 selection based policy, either implemented via DNS64 or
   Prefix64 assignments.

3.6.  MTU Consideration

   IPv6 requires that every link in the internet have an MTU of 1280
   octets or greater[RFC2460].  However, in case of NAT64 function
   deployment some IPv4 link will be used on communication path and
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  That would result the IPv6
   allows packets to contain a fragment header, without the packet being
   actually fragmented into multiple pieces.
   [I-D.ietf-6man-ipv6-atomic-fragments] discusses how this could
   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 protocol level, which might
   imply potential upgrade/modifications on behaviors to deployed nodes.
   Another candidate approach avoding this issue is to configure IPv4
   MTU>=1260 from operational perspectives.  It would forbid the
   occurrence of PTB<1280.  However, such operational consideration is
   hardly applied to a wild and legacy "IPv4 Internet".  In this case,
   these issues are eliminated thanks to some specific operational
   actions

4.  NAT64-CE Deployment Experiences

   The NAT64-CE Scenario is depicted in Figure 2

Chen, et al.             Expires January 5, 2013                [Page 8]
Internet-Draft              NAT64 Experience                   July 2012

                  --------
                //        \\        ----------
               /            \     //          \\
              /             +----+              \
             |              |XLAT|               |
             |  The IPv6    +----+  An IPv4      |
             |  Internet    +----+  Network      |  XLAT: IPv4/IPv6
             |  /Network    |DNS |               |        Translator
              \             +----+              /   DNS:  DNS64
               \            /     \\          //
                \\        //        ----------
                  --------
                             ====>

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

4.1.  NAT64-CE Networking

   More and more contents providers would like to use IPv6 to serve
   customers since it allows for the definition of new services without
   having to backward integrate into the NATs and address limitations of
   IPv4 networks, but they have to provide some IPv4 service continuity
   to their customers and that militates for NAT64 design.  Cloud
   computing is growing, which requires millions of public addresses.
   IPv6 could provide a good opportunity to meet the deployment
   requirements by subsiding the location to a customer edge, e.g.
   Enterprise-GW and Data Center.  On the other side, residential
   facilities is always going out of ISP control as far as devices
   connected to home networks are not under ISP responsibility.  It's
   hard to guarantee positioned network device or installed applications
   are IPv6-capable and it is not possible to consider that all devices
   are IPv6 compliant.  Thereby, NAT64 on CPE could easily help networks
   deployment and to rely on some IPv6-only connectivity from the ISP.

   One big challenge is NAT64-CE facing IPv6 Internet, on which a
   significant IPv6 users may connect to.  When increasingly numerous
   users in IPv6 Internet access an IPv4 network, there will be not
   enough IPv4 addresses and/or ports to serve the mapping.  One
   potential solution is to distribute NAT64-CE at separated CE domain.
   Each domain could reuse the IPv4 address defined in RFC1918
   [RFC1918], which would expand IPv4 spaces by increasing reuse ratio
   of IPv4 address.

   Note: considering this challenge of NAT64, it is suggested that
   NAT64-CE is only deployed and used in the scenario for small scale
   content providers and residential network where the incoming
   connections from the IPv6 Internet is not too many to destroy the
   NAT64 functionalities.

Chen, et al.             Expires January 5, 2013                [Page 9]
Internet-Draft              NAT64 Experience                   July 2012

4.2.  Anti-DDoS/SYN Flood

   For every incoming new connection from the IPv6 Internet, the
   NAT64-CE creates state and maps that connection to an internally-
   facing IPv4 address and port.  An attacker can consume the resources
   of the NAT64-CE device by sending an excessive number of connection
   attempts.  Without Anti-DDoS mechanism, the NAT64 is exposed to
   attacks from the IPv6 Internet which will greatly influence the user
   experience.  Essentially, there are strong demands to have thorough
   security mechanism to prevent malicious invasion in NAT64-CE
   scenario.  With service provisioning, potential safety hazard could
   also deteriorate service quality.  For example, DDoS will severely
   degrade web performance.  Security domain division is necessary in
   this case, especially for NAT64-CE in enterprise network.  One
   practices in some ICP is place a L3 load balancer with capable of 10G
   line rate DDoS defense, like SYN Flood with SYN PROXY-COOKIE.  Load
   Balancer could not only serve for optimization of traffic
   distribution, but also take filtering helping enhanment of security.

4.3.  User Behavior Analysis

   The mapping information on the NAT64-CE is valuable for those who
   deploy it.  Owners or operators of NAT64-CE could use the mapping and
   logging information for use behavior and preference analysis, and
   acurate advertisement delivery.  Different ways of achieving user
   analysis may be applied.  The NAT64-CE owner can either synchronize
   the mapping information with its local analysis engine or deploy
   dedicated address mapping rules on the CE so that the orginal address
   information could be kept.

4.4.  DNS Resolving

   In the case of NAT64-CE, it is recommended to 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 regular DNS to represent these IPv4-only hosts.
   How to design the FQDN for the IPv6 service is out-of-scope of this
   document.

4.5.  Load Balance

   Load balance on NAT64-CE was twofold.  First off, traffic should be
   balanced among multiple NAT64-CE devices, which has identical
   requirement with NAT64-CGN.  One point should be noticed that a
   synthetic AAAA records may be added directly in authoritative DNS.
   The load balance based on DNS64 may not work in those cases.
   Secondly, NAT64-CE could also serve traffic distribution for IPv4
   backend servers.  There are also some ways of load balance for the

Chen, et al.             Expires January 5, 2013               [Page 10]
Internet-Draft              NAT64 Experience                   July 2012

   cases , where the user placed load balancer with NAT66
   functionalities before the NAT64.

4.6.  MTU Consideration

   As compared to the MTU consideration in NAT64-CGN, MTU of IPv4
   network are strongly recommeded to set more than 1260.  Since a IPv4
   network normally operated by a particular entity, it could take
   advantages of administrative ways to easily get rid of fragmentation
   risks discussed in [I-D.ietf-6man-ipv6-atomic-fragments].

5.  Security Considerations

   This document presents the deployment experiences of NAT64 in CGN and
   CE scenario, some security considerations have been considered
   regarding to specific NAT64 mode in section 2 and 3.  In general, RFC
   6146[RFC6146] provides TCP-tracking, Endpoint-dependent filtering
   mechanisms to protect NAT64 from DDOS.  In NAT64-CGN cases, ISP also
   could adopt uRPF 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 (Strict or
   Loose mode) check does not pass or whose source IPv6 address is
   associated to black-lists.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Acknowledgements

   The authors would like to thank Jari Arkko, Dan Wing, Remi Despres,
   Fred Baker, Joel Jaeggli, Lee Howard and Iljitsch van Beijnum for
   their helpful comments.  Many thanks to Wesley George and Satoru
   Matsushima for their reviews.

8.  Additional Author List

   The following are extended authors who contributed to the effort:

Chen, et al.             Expires January 5, 2013               [Page 11]
Internet-Draft              NAT64 Experience                   July 2012

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

9.1.  Normative References

   [I-D.ietf-pcp-base]
              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-26 (work in progress), June 2012.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

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

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

   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation", RFC 6144, 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.

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

Chen, et al.             Expires January 5, 2013               [Page 12]
Internet-Draft              NAT64 Experience                   July 2012

9.2.  Informative References

   [I-D.donley-behave-deterministic-cgn]
              Donley, C., Grundemann, C., Sarawat, V., and K.
              Sundaresan, "Deterministic Address Mapping to Reduce
              Logging in Carrier Grade NAT Deployments",
              draft-donley-behave-deterministic-cgn-03 (work in
              progress), June 2012.

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

   [I-D.ietf-intarea-nat-reveal-analysis]
              Boucadair, M., Touch, J., Levis, P., and R. Penno,
              "Analysis of Solution Candidates to Reveal a Host
              Identifier (HOST_ID) in Shared Address Deployments",
              draft-ietf-intarea-nat-reveal-analysis-02 (work in
              progress), April 2012.

   [I-D.ietf-v6ops-464xlat]
              Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              draft-ietf-v6ops-464xlat-05 (work in progress), July 2012.

   [I-D.petersson-forwarded-for]
              Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
              draft-petersson-forwarded-for-02 (work in progress),
              November 2011.

   [I-D.zhang-behave-nat64-load-balancing]
              Zhang, D., Xu, X., and M. Boucadair, "Considerations on
              NAT64 Load-Balancing",
              draft-zhang-behave-nat64-load-balancing-03 (work in
              progress), July 2011.

   [RFC3924]  Baker, F., Foster, B., and C. Sharp, "Cisco Architecture
              for Lawful Intercept in IP Networks", RFC 3924,
              October 2004.

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

Chen, et al.             Expires January 5, 2013               [Page 13]
Internet-Draft              NAT64 Experience                   July 2012

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,
              June 2011.

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

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

Chen, et al.             Expires January 5, 2013               [Page 14]
Internet-Draft              NAT64 Experience                   July 2012

   David Binet
   France Telecom
   Rennes
   35000
   France

   Email: david.binet@orange.com

Chen, et al.             Expires January 5, 2013               [Page 15]