Internet Engineering Task Force                                  G. Chen
Internet-Draft                                                    Z. Cao
Intended status: Informational                              China Mobile
Expires: September 13, 2012                                     C. Byrne
                                                            T-Mobile USA
                                                                  Q. Niu
                                                          March 12, 2012

                     NAT64 Operational Experiences


   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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 13, 2012.

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
   ( 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

Chen, et al.           Expires September 13, 2012               [Page 1]

Internet-Draft              NAT64 Experience                  March 2012

   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.  NAT64-CGN Deployment Experiences . . . . . . . . . . . . . . .  3
     2.1.  NAT64-CGN Networking . . . . . . . . . . . . . . . . . . .  4
     2.2.  High Availability Consideration  . . . . . . . . . . . . .  5
     2.3.  Traceability and Lawful Interception . . . . . . . . . . .  5
     2.4.  Quality of Experience  . . . . . . . . . . . . . . . . . .  6
     2.5.  Load Balance . . . . . . . . . . . . . . . . . . . . . . .  6
     2.6.  MTU Consideration  . . . . . . . . . . . . . . . . . . . .  6
   3.  NAT64-CE Deployment Experiences  . . . . . . . . . . . . . . .  7
     3.1.  NAT64-CE Networking  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Anti-DDoS/SYN Flood  . . . . . . . . . . . . . . . . . . .  8
     3.3.  User Behavior Analysis . . . . . . . . . . . . . . . . . .  8
     3.4.  DNS Resolving  . . . . . . . . . . . . . . . . . . . . . .  8
     3.5.  Load Balance . . . . . . . . . . . . . . . . . . . . . . .  9
     3.6.  MTU Consideration  . . . . . . . . . . . . . . . . . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

Chen, et al.           Expires September 13, 2012               [Page 2]

Internet-Draft              NAT64 Experience                  March 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 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.  The interconnection between
   IPv4-only nodes and IPv6-only nodes is a critical capability.  Given
   that widespread dual-stack deployments have not materialized over the
   last 10 years for which the approach has been prescribed prior to
   IPv4 exhaust, it is obvious that NAT64[RFC6146] will be a key element
   of the going-forward internet infrastructure.

   Regarding the IPv4/IPv6 translation, RFC6144[RFC6144] has described a
   framework enabling networks to have IPv4 and IPv6 coexist.  There are
   three common NAT64 deployment scenarios "An IPv6 Network to the IPv4
   Internet", "The IPv6 Internet to an IPv4 Network" and "An IPv6
   Network to an IPv4 Network".  Since the scenario of "The IPv6
   Internet to the IPv4 Internet" seems the ideal case for in-network
   translation technology, this document has focused on the three cases
   and categorized different NAT64 usages as NAT64-CGN and NAT64-CE.
   Therein, NAT64-CGN are 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
   server 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.  NAT64-CGN Deployment Experiences

   The NAT64-CGN Scenario is depicted in Figure 1

Chen, et al.           Expires September 13, 2012               [Page 3]

Internet-Draft              NAT64 Experience                  March 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

2.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 the Stateful NAT64 [RFC6146].  Address translation maps IPv6
   addresses to IPv4 addresses and vice versa.

   Given that all IPv4 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

   Coming to a real practice in broadband access network, NAT64
   functionalities could be located on BNG or core router depending on
   scale of IPv6-enable network.  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 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.

   The different deployment modes would correspond to specific use
   cases, in which ISP should consider different perspectives, e.g.

Chen, et al.           Expires September 13, 2012               [Page 4]

Internet-Draft              NAT64 Experience                  March 2012

   traffic model, investment, network evolution, etc.

2.2.  High Availability Consideration

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

   In general, there are two mechanisms 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

2.3.  Traceability and Lawful Interception

   Traceability and Lawful Interception(LI) are required in many cases
   to identify an attacker or a host that was used to launch malicious
   attacks and/or for various other purposes of accounting.

   In order to facilitate traceability, 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.  Regarding the Online
   requierements, 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
   target subscribers based on IPv6 addresses included in XFF HTTP
   headers.  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 .  For off-line traceability, syslog
   might be a good choice.

   Lawful intercept[RFC3924] is normally part of the access network, in
   which an optical splitter is used to bypass all traffic for
   subsequent filtering process.  It's not the requirement for NAT64.
   However, operators may expect to serve as interception access point
   (IAP) avoiding installation of additional LI system.  It's low-cost
   and fast-deployed.  It's an alternative solution for LI even if that
   may not a major case in current practices.

Chen, et al.           Expires September 13, 2012               [Page 5]

Internet-Draft              NAT64 Experience                  March 2012

2.4.  Quality of Experience

   While NAT64 is bridge between the IPv6 and IPv4, it is important that
   the NAT64-CGN have the appropriet ALGs to support customers, e.g.
   FTP-ALG[RFC6384], RSTP-ALG, H.323-ALG,etc.  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 in context of
   stateful NAT64, which has some common issues regarding 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.  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.

2.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.  When
   there are multiple NAT64 CGN deployed, it is important to achieve
   load balancing between these different devices.
   [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.

2.6.  MTU Consideration

   IPv6 requires that every link in the internet have an MTU of 1280
   octets or greater[RFC2460].  However, the coexistence with IPv4 link
   may let originating IPv6 node to 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.gont-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 upgrations/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 "IPv4 Internet".  In this case, these issues

Chen, et al.           Expires September 13, 2012               [Page 6]

Internet-Draft              NAT64 Experience                  March 2012

   are eliminated from operational aspects.

3.  NAT64-CE Deployment Experiences

   The NAT64-CE Scenario is depicted in Figure 2
                //        \\        ----------
               /            \     //          \\
              /             +----+              \
             |              |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

3.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.  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.  On the other side, residential facilities
   is always going out of ISP control.  It's hard to guarantee
   positioned network device or installed applications are IPv6-capable.
   Thereby, NAT64 on CPE could easily help homenet become IPv6-
   reachable.  This scenario appears in ISP network quite popular.  As
   the instances, visitors go through distant network to take care of
   family affairs, like monitoring house security via residential
   camera, manipulating household appliances remotely prior to comeback

   One big challenge for NAT64-CE is IPv6 space always much bigger than
   IPv4 space.  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.

Chen, et al.           Expires September 13, 2012               [Page 7]

Internet-Draft              NAT64 Experience                  March 2012

   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.

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

3.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
   delicated address mapping rules on the CE so that the orginal address
   information could be kept.

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

Chen, et al.           Expires September 13, 2012               [Page 8]

Internet-Draft              NAT64 Experience                  March 2012

3.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 that cases.
   Secondly, NAT64-CE could also serve traffic distribution for IPv4
   backend servers.  There are also some ways of load balance for the
   cases , where the user placed NAT66 before the NAT64 so that the load
   balancer can be implemented at the NAT66 for any user preference

3.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.gont-6man-ipv6-atomic-fragments].

4.  Security Considerations

   This document only presents the deployment experiences of NAT64 in
   CGN and CE scenario, some security considerations have been
   considerated 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.

5.  IANA Considerations

   This memo includes no request to IANA.

6.  Acknowledgements

   The authors would like to thank Dan Wing, Remi Despres, Jari Arkko
   and Fred Baker for their helpful comments.

7.  References

Chen, et al.           Expires September 13, 2012               [Page 9]

Internet-Draft              NAT64 Experience                  March 2012

7.1.  Normative References

              Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R.
              Penno, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-23 (work in progress), February 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.

7.2.  Informative References

              Gont, F., "Processing of IPv6 "atomic" fragments",
              draft-gont-6man-ipv6-atomic-fragments-00 (work in
              progress), December 2011.

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

              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.

Chen, et al.           Expires September 13, 2012              [Page 10]

Internet-Draft              NAT64 Experience                  March 2012

Authors' Addresses

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


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


   Cameron Byrne
   T-Mobile USA
   Washington  98105


   QiBo Niu
   50,RuanJian Road.
   YuHua District,
   Nan Jing  210012


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