Internet Engineering Task Force                                   J. Tan
Internet-Draft                                                    J. Lin
Intended status: Informational                                     W. Li
Expires: September 8, 2011                                 China Telecom
                                                           March 7, 2011

                   Experience from NAT64 applications


   This document discusses our experiences from deploying NAT64 devices
   for various Internet applications.  Before the final transition to an
   IPv6-only network, NAT64 is one of the possible technologies which
   may be used to give users access to the IPv4-only parts of the
   Internet via an IPv6-only network.  This document analyzes the
   testing results for a number of popular applications and describes
   the problems to be solved in the period of transition from IPv4 to

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 8, 2011.

Copyright Notice

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

Tan, et al.             Expires September 8, 2011               [Page 1]

Internet-Draft     Experience from NAT64 applications         March 2011

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Network Topology Setup  . . . . . . . . . . . . . . . . . . . . 3
   3.  Experiences With Various Use Cases  . . . . . . . . . . . . . . 4
     3.1.  Web Applications  . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Email Client  . . . . . . . . . . . . . . . . . . . . . . . 5
     3.3.  Instant Messaging . . . . . . . . . . . . . . . . . . . . . 5
     3.4.  Peer-to-Peer (P2P) Applications . . . . . . . . . . . . . . 6
     3.5.  Gaming  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.6.  VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
       3.6.1.  Stream Media Player . . . . . . . . . . . . . . . . . . 6
   4.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Tan, et al.             Expires September 8, 2011               [Page 2]

Internet-Draft     Experience from NAT64 applications         March 2011

1.  Introduction

   This document discusses our experiences from deploying NAT64
   [I-D.ietf-behave-v6v4-xlate-stateful] devices for various Internet
   applications, both traditional and new.  The main conclusion is that
   it is possible to deploy NAT64 devices at the edge of IPv6-only
   networks, but there are a number of issues unsolved such as lack of
   IPv6 support in PPTP and VPN connections.

      Note: Since no NAT64 and DNS64 devices are available for the time
      being, NAT-PT was used instead.  Tests were run both with DNS-ALG
      enabled and with DNS-ALG disabled.

2.  Network Topology Setup

   The operating system we tested was Microsoft Windows 7 and the tested
   applications are the currently updated version.  The IPv6 prefix was
   delegated as 2001:c68:100:100::/64, while the global IPv6 address was
   configured via SLAAC.  The NAT-PT device was connected to the edge
   router of CNGI (China Next Generation Internet).  A static route was
   configured in this device to direct packets destined to prefix 2001:
   c68:100:2:: (the prefix for the IPv6 DNS server) to the NAT-PT

   In the NAT-PT device, the IPv4 addresses of the target websites or
   servers were mapped to global IPv6 addresses through dynamic or
   static mappings.  When the tested terminal sent packets to these
   global IPv6 addresses, they were routed to the NAT-PT device which
   performed protocol translation and address translation.

   The address of IPv6 DNS server was manually configured to 2001:c68:
   100:2:1::ca61:6, with the DNS-ALG enabled at the NAT-PT device.  The
   AAAA DNS query from the terminal was transformed to an A query to the
   ISP's IPv4 DNS cache server via NAT-PT translation.  We also
   implemented a dual-stack DNS cache server and added AAAA entries for
   the tested websites.  The global IPv6 addresses of those websites are
   based on the NAT-PT's prefix and its IPv4 public addresses.  The
   terminal has been setup the DNS server address as the IPv6 address of
   this dual-stack DNS cache server while the DNS-ALG is disabled at

   The NAT Log information was acquired by remote monitoring.  The logs
   contained the 5-tuple, set up time and end-up time.  The traffic Log
   was manually exported.

Tan, et al.             Expires September 8, 2011               [Page 3]

Internet-Draft     Experience from NAT64 applications         March 2011

3.  Experiences With Various Use Cases

   This section discusses specific issues with various applications and
   appliances.  Issues to be solved are also described.

3.1.  Web Applications

   All HTTP/HTTPs based web browsers, i.e., comprehensive portal
   website, webmail,search engine and HTTP download, that we have tried
   so far seem to work well without problems.  When the DNS-ALG option
   of NAT-PT is enabled and AAAA record request is not restrained, we
   can visit websites which have AAAA records in the public DNS, e.g.,  The address is the "real" IPv6 address.  However,
   if an IPv6 host initiates an AAAA record request for some website,
   e.g.,, but there is no corresponding AAAA record in the
   DNS, the IPv4 version of the website cannot normally be visited since
   the DNS-ALG does not convert this AAAA record request to an A record
   request.  On the other hand, while the DNS-ALG option is enabledand
   the AAAA record request is restrained, we can visit the website or
   servers without IPv6 address by NAT-PT and DNS-ALG, but we cannot get
   the IPv6 address of the IPv6/Dual-stack websites or servers when the
   AAAA DNS record requests go through the NAT-PT.

   HTTP downloading via domain name works well normally, for example, to
   upload and download HTTP netdisk service.  However, problems exist in
   thosee file sharing websites which have policies based on source IP
   addresses.  In that case, downloading does not work correctly and the
   users who are sharing a public IPv4 address needs to wait for a very
   long time before starting download from the same website at the same
   time.  In addition, for some website resources which are downloaded
   directly without DNS query, downloading does not work as well.
   Especially when the website redirects the users to a separate IPv4
   server by telling the browser the IPv4 address rather than the domain
   name of the server.

   We also tested with some new web applications, e.g., Web-based video,
   Online music, Blog, SNS, Online shopping and Web-based map.  Most
   popular video sharing websites in China do not support NAT-PT because
   the video resource is normally stored separately and the web server
   or application server redirects the resources' IPv4 address to the
   user-end Flash player plug-in, which is not translated to an IPv6
   address when it goes through the NAT-PT device.

   Actually, whether using domain name lookup or connecting by address
   directly to the source depends on the content of the website,
   security policy and website provided, security policies and its
   software and hardware architecture.  It may be not easy to change the
   existing architecture which makes the transition of such kind of

Tan, et al.             Expires September 8, 2011               [Page 4]

Internet-Draft     Experience from NAT64 applications         March 2011

   websites difficult and complex.

   Blogs on most websites appear to work fine except for one webpage
   style and layout problem at  We believe that is because
   the CSS file is not loaded correctly.

   E-bank web plug-in and client (software) do not work well with NAT-PT
   devices because the client end usually communicates directly with the
   server using a known IPv4 address.  Even though the client performs a
   domain name lookup procedure, most of the client cannot recognize the
   translated IPv6 address.  Besides, there is usually a logging server
   for security purpose that may not recognize IPv6 addresses and may
   not identify and distinguish users by the shared IPv4 address.

   Google maps display normally when the browser opens six windows/tabs
   of maps simultaneously to watch different sites.  The sessions are
   limited separately to 250 and 50 in this testing.

3.2.  Email Client

   The impact of NAT64 on email protocols (POP3, SMTP and IMAP) worked
   normally.  The Microsoft Live Mail 2011 and Microsoft Office Outlook
   support IPv6, while Foxmail 6.5 does not.  But there may be a little
   problem.  Users can only wait for a new version of the software and
   access their email account via webmail during the transition period.

3.3.  Instant Messaging

   We have tested several instance messaging applications in an IPv6-
   only network with NAT64 and the test results can be found in Table 1.

                       System                 Status
                       QQ2010 client          NOT OK
                       WebQQ                  OK
                       Windows Live Messenger NOT OK
                       Ebuddy Web             OK
                       Fetion                 NOT OK
                       Skype                  NOT OK

      Table 1: Instant Messaging Applications in an IPv6-Only Network

   Most of the instant messaging systems tested were not able to log
   onto the server, by reason of lacking IPv6 support in the clients.
   However, the web-based instant messaging sysytem works well, and may
   be considered as a transition tool for the instant messaging systems
   with a large number of clients before the new versions are released.

Tan, et al.             Expires September 8, 2011               [Page 5]

Internet-Draft     Experience from NAT64 applications         March 2011

3.4.  Peer-to-Peer (P2P) Applications

   Each Peer-to-Peer (P2P) downloading software displays downloading
   resources on the information page, employing HTTP as transport.  From
   the experiments we have done, most P2P software packages do not
   support IPv6, e.g., we failed to get connection with peers from
   BitComet.  There are also P2P clients that claim to support IPv6,
   like uTorrent and emule.  However, we did not succeed when trying to
   make IPv6 connections.  The problem is probably that the peers'
   addresses of the contents stored in tracker server are mainly IPv4
   addresses.  When these addresses sent from the Tracker to the
   downloading peer is encapsulated in the payload,it cannot be
   translated when it passes through the NAT-PT device.  As a result,
   even though the uTorrent client of an IPv6 host and the Tracker
   server support IPv6, the client still can not download IPv4 resources
   from IPv4 peers via NAT64 device.

3.5.  Gaming

   Another application we have tested is online games.  We cannot log in
   to most gaming platforms unless they uses domain name.  It is
   presumably because the game client does not support IPv6.  We cannot
   make further experiments before the IPv6-supported clients are

3.6.  VPN

   The VPN testing is to estimate whether the VPN client can initial a
   connection to the remote access server through a NAT64 device.  The
   testing is based on Windows Vista (as the VPN client) and Windows
   Server 2008 R2 Standard (as the RAAS).  Two protocols were applied to
   connect to the remote access server: L2TP/IPSec and PPTP.  The
   results show that the PPTP protocol does not support IPv6 while L2TP/
   IPSec technology supports IPv.  However, the Internet Key Exchange
   failed when passing through the NAT64.

3.6.1.  Stream Media Player

   Other applications we have tested include online stream media player
   software (e.g.  PPTV, PPStream, UUSee), third Party FTP client and
   Remote cooperation/assistant tools (e.g. pcAnywhere and Windows
   Remote Desktop).  The online stream media player can download the
   playlist and advertisements normally, but it was unable to connect to
   the media server and play the media contents.

Tan, et al.             Expires September 8, 2011               [Page 6]

Internet-Draft     Experience from NAT64 applications         March 2011

4.  Conclusions

   This document discusses our experiences from deploying NAT64 devices
   for various Internet applications.  The main conclusion is that two
   problems exist from our experimention.  First is the weakness of the
   IPv6 capability of user end clients, and the second problem is that
   the IPv4 addresses can not be translated when they are carried inside
   a packet's payload.

5.  Security Considerations


6.  Informative References

              Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers (Work in progress)", July 2010.

Authors' Addresses

   Jinghua Tan
   China Telecom
   109, Zhongshan Ave. West,
   Tianhe District, Guangzhou  510630
   P.R. China


   Jinyan Lin
   China Telecom
   109, Zhongshan Ave. West,
   Tianhe District, Guangzhou  510630
   P.R. China


Tan, et al.             Expires September 8, 2011               [Page 7]

Internet-Draft     Experience from NAT64 applications         March 2011

   Weibo Li
   China Telecom
   109, Zhongshan Ave. West,
   Tianhe District, Guangzhou  510630
   P.R. China


Tan, et al.             Expires September 8, 2011               [Page 8]