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 draft-tan-v6ops-nat64-experiences-00 Abstract 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 IPv6. 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 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 (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 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 device. 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 NAT-PT. 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., ipv6.google.com. The address is the "real" IPv6 address. However, if an IPv6 host initiates an AAAA record request for some website, e.g., www.abc.com, 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 blog.163.com. 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 released. 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 None. 6. Informative References [I-D.ietf-behave-v6v4-xlate-stateful] 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 Phone: Email: tanjh@gsta.com Jinyan Lin China Telecom 109, Zhongshan Ave. West, Tianhe District, Guangzhou 510630 P.R. China Phone: Email: jasonlin.gz@gmail.com 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 Phone: Email: MWeiboLI@gmail.com Tan, et al. Expires September 8, 2011 [Page 8]