NAT64 Deployment Considerations
draft-ietf-v6ops-nat64-experience-01

gt;

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

4.1.  NAT64-FE Networking

   There are plenty of practices to equip load balancer with NAT64 at
   front of servers.  Two different cases appeared in the NAT64-FE
   networking.

   o  Some content providers who has a wealth of 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 to provide some IPv4 service continuity to their customers,
      stateless IP/ICMP Translation (SIIT) [RFC6145]has been used to
      continue provide services for IPv4 subscribers.

   o  ICPs who have insufficient IPv6 incentive likely prefer short-term
      alternatives to provide IPv6 connectivity due to the widespread
      impact of supporting IPv6 within a ICP environment.  A stateful
      NAT64 has been located at front of servers.  It could
      simultaneously facilitate the IPv6 accessibility and conservation
      of IPv4 servers.  [I-D.ietf-v6ops-icp-guidance]has described the
      cases, in which an HTTP proxy can readily be configured to handle
      incoming connections over IPv6 and to proxy them to a server over
      IPv4.

   For first case, [I-D.anderson-siit-dc]has provided further
   descriptions and guidelines.  This document is addressed to second

Chen, et al.             Expires August 4, 2013                 [Page 9]
Internet-Draft              NAT64 Deployment                January 2013

   case.  An administrator of the IPv4 network needs to be cautious and
   aware of the operational issues in the case since the native IPv6 is
   always more desirable than transition solutions.

   One potential challenge is stateful NAT64-FE facing IPv6 Internet, in
   which 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, a single point
   of failure, IPv4 pool exhaustion, etc) are apt to be applied.  For a
   given off-the-shelf NAT64-FE, those challenges should be seriously
   assessed.  Potential issues should be properly identified.

   Following subsections described several considerations to stateful
   NAT64-FE case.  For operators who seek a clear precedent for
   operating reliable IPv6-only services, it should be well noted that
   the usage is problematic.

4.2.  Source Address Traceability

   IP addresses are usually used as input to geo-location services.  The
   use of address sharing will prevent these systems from resolving the
   location of a host based on IP address alone.  Applications that
   assume such geographic information may not work as intended.  The
   possible solutions listed at section 3.3 intended to bridge the gap.
   However, the analysis reveals those solutions can't be a optimal
   substitution 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 a unappealing approach, if customers require source address
   tracking.

   For the operators, who already deployed NAT64-FE approach, the source
   address of 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 is to ask application coordinating the information
   with NAT logging.  But that is not sufficient, since the applications
   itself wants to know the original source address from an application
   message bus.  The logging information may be used by administrators
   offline to inspect use behavior and preference analysis, and accurate
   advertisement delivery.

4.3.  DNS Resolving

   In the case of NAT64-FE, 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

Chen, et al.             Expires August 4, 2013                [Page 10]
Internet-Draft              NAT64 Deployment                January 2013

   registered in the authoritative DNS for a given domain to represent
   these IPv4-only hosts.  How to design the FQDN for the IPv6 service
   is out-of-scope of 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 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 IPv4 backend servers.  There are also some ways of load
   balance for the cases, where load balancer is placed in front of
   NAT64-FE.

4.5.  MTU Consideration

   As compared to the MTU consideration in NAT64-CGN, the MTU of IPv4
   network 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 the risk of fragmentation
   discussed in [I-D.ietf-6man-ipv6-atomic-fragments].

4.6.  Anti-DDoS/SYN Flood

   For every incoming new connection from the IPv6 Internet, the
   stateful NAT64-FE creates state and maps that connection to an
   internally-facing IPv4 address and port.  An attacker can consume the
   resources of the NAT64-FE device by sending an excessive number of
   connection attempts.  Without a DDOS limitation mechanism, the
   NAT64-FE is exposed to attacks.  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

Chen, et al.             Expires August 4, 2013                [Page 11]
Internet-Draft              NAT64 Deployment                January 2013

   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, Hui Deng, Lee Howard, Iljitsch van Beijnum and Philip
   Matthews for their helpful comments.  Many thanks to Wesley George
   and Satoru Matsushima for their reviews.

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

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

Chen, et al.             Expires August 4, 2013                [Page 12]
Internet-Draft              NAT64 Deployment                January 2013

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-29 (work in progress), November 2012.

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

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

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

Chen, et al.             Expires August 4, 2013                [Page 13]
Internet-Draft              NAT64 Deployment                January 2013

              Petersson, A. 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 (work in
              progress), March 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-04 (work in
              progress), August 2012.

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

   [I-D.ietf-v6ops-icp-guidance]
              Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
              Content and Application Service Providers",
              draft-ietf-v6ops-icp-guidance-05 (work in progress),
              January 2013.

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

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

Chen, et al.             Expires August 4, 2013                [Page 14]
Internet-Draft              NAT64 Deployment                January 2013

   [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 August 4, 2013                [Page 15]
Internet-Draft              NAT64 Deployment                January 2013

   David Binet
   France Telecom
   Rennes
   35000
   France

   Email: david.binet@orange.com

Chen, et al.             Expires August 4, 2013                [Page 16]